自动驾驶基础-无人驾驶操作系统四

机器人操作系统（RobotOperating System, ROS）是一个专门为机器人应用而设计的，被广泛使用的高性能分布式的计算框架（参见下图是一个典型机器人操作系统）。

每个机器人所要完成的任务（如自身定位）都由一个ROS的子节点处理。这些节点间是通过话题和服务进行相互连接的。它对于自主驾驶而言是一个合适的操作系统，但也有一些问题：

·可靠性：ROS只有一个主节点而且对子节点没有监控，从而无法实现失效恢复。

·性能：在发送广播消息的时候，ROS会把消息复制多份，这就导致性能的降低。

·安全性：ROS没有认证和加密的机制。

虽然ROS 2.0版宣称要修复这些问题，但它还没有被广泛的测试过，并且很多特性也没有实现。为了在自主驾驶车辆上使用ROS，我们需要先解决这几个问题。

现有版本的ROS的实现仅有一个主节点。因此当主节点崩溃时，整个系统就崩溃了。这一点并不能满足自主驾驶的安全性要求。为了解决这一问题，我们在ROS上实现了一个类似ZooKeeper的机制。

如下图所示，就是在ROS上使用ZooKeeper的示意图。

这个设计包含一个主节点和一个备份主节点。当主节点失效时，备份节点就接替主节点，并确保系统能持续运行无间断。另外，ZooKeeper的机制还可以监控所有节点，并在节点失效时重启它们。从而可以确保整个系统的可靠性。

性能问题是现有ROS实现的另外一个缺陷。ROS节点间通信很频繁，因此节点之间的通信就必须是非常高效的。首先，ROS客户端节点间的通信采用的是环回机制。每完成一次环回的管道，就会带来约20毫秒的开销。为了降低这个节点间通信的开销，我们可以使用共享内存的机制来避免消息传输必须经过TCP/IP的打包/拆包的过程。另外，ROS的节点在广播消息的时候，消息会被复制多次，极大地占用了系统带宽。改用多点传送机制就能够很好地提升系统吞吐量。

而安全性问题，更是ROS的最大的死穴。设想两个场景：第一个，某个ROS的节点被“黑”了，随后操作系统内存被持续的占用并最终导致内存溢出，从而开始杀掉其他的ROS的节点。最终黑客成功地让整个系统崩溃。第二个场景，ROS的消息默认是不加密的。黑客可以很容易地监听节点间的通信，然后使用消息拦截机制发动攻击。

为了解决第一个安全问题，我们可以使用Linux容器机制（LXC）来限制每个节点可以使用的资源数量，并提供沙箱机制来防止一个节点被其他节点破坏。这样可以有效地防止资源溢出。对于第二个问题，可以通过加密消息来阻止消息被窃听。

因此我们首先会在模拟器上测试新算法，例如在ROS节点上做数据重现。然而，如果只是在一个单机上测试新算法，要不会花费很长时间，要不就没有能做到全覆盖测试。

为了解决这个问题，我们可以使用一个分布式的模拟平台，如下图所示是Spark和基于ROS的模拟平台。

这里，Spark被用于管理分布式计算节点。每个节点上，我们可以运行一个ROS再播放实例。在一个单机服务器上做自动驾驶物体识别测试将会需要3个多小时。而使用分布式系统，水平扩展到8个服务器，整个测试在25分钟内完成。

如下图所示是一个基于云平台的高清晰度地图生成。高清晰度地图的生成是一个复杂的过程，涉及到很多步骤。包括原始数据处理，点云生成，点云对齐，2维反射地图生成，高精度地图标记以及最终地图生成。使用Spark，我们可以把所有的这些步骤放入一个任务中完成。Spark的一大优点是它提供基于内存的运算机制。这样我们就可以不用存储中间数据到硬盘上，从而可以级大地提升地图生成的速度。

因为我们为自主驾驶使用了多种不同的深度学习模型，所以持续更新模型来保证它们的有效性和高效性就非常重要。然而，由于原始数据的量非常的大，仅仅靠单机是很难快速地完成模型的训练的。为了解决这个问题，我们使用Spark和Paddle（最近由百度开源的一个深度学习平台）开发了一个高可扩展的分布式深度学习系统。

在Spark驱动程序里，它可以管理Spark Context和PaddleContext。在每个节点里，Spark执行器容纳了一个Paddle的训练实例。在此架构之上，我们使用Alluxio作为这个系统的参数服务器。使用这一系统，我们可以实现线性的性能扩展（甚至在增加了更多资源后），从而证明它是高可扩展的。

关于自动驾驶的技术文章，可以参考前文，下面是链接：