深度剖析Apollo自动驾驶平台，看看是不是有真的“原子弹”

陆奇去年在上海车展期间发布Apollo计划，向所有合作伙伴免费开放无人驾驶能力，当时有文章评价这是百度扔下了原子弹，炸掉了无人驾驶企业数百亿美元投入，今天让我们深度剖析一下Apollo自动驾驶平台，看看是不是有真的“原子弹”。

自百度宣布开放 Apollo 自动驾驶平台以来，很多开发者非常期待可以深入了解 Apollo 平台的开放内容，以便更充分高效的利用这个自动驾驶平台，研究并落地自己对于自动驾驶的诸多想法。

为此，7 月 22 日，由百度开发者中心主办、极客邦科技承办的 73 期百度技术沙龙设置 Apollo 主题，现场百度资深架构师从 Apollo 的开放能力、Apollo 代码开放框架以及基于深度学习的 End to End 自动驾驶方案三个技术维度做了深度分享，以期帮助开发者深度了解百度 Apollo 开放内容和平台架构，设计并实现一套完整的驾驶方案。

Apollo 的开放能力和开放数据

百度资深数据平台专家杨凡做了开场演讲，他表示：“Apollo 开放内容实质上分为两大部分：能力开放和资源开放，能力开放提供开发者实现车上自动驾驶的平台，资源开放提供开发者探索算法进化的平台，这二者相辅相成，缺一不可。”

Apollo 的开放能力

Apollo1.0 主要开放的是封闭场地循迹自动驾驶的框架，从上之下分别是服务层、软件平台层、参考硬件层以及参考汽车层，其中标蓝部分为具体开放模块。各层级的具体功能如下：

参考汽车层：实现电子化的控制，也就是线控汽车，这是最底层的一步；

参考硬件层：实现计算能力，包括计算单元、GPS/IMU、HMI Device 等；

软件平台层：最核心的层，分为 3 个部分。1、实时 RTOS 系统，要求保证实时反应；2、运行时框架；3、定位模块和控制模块以及 HMI 人机交互模块。这三块构成了本期开放的封闭场地循迹自动驾驶软件体系；

云服务层：在云服务层开放了数据开放平台和唤醒万物的 DuerOS。

以上四层构成了百度 Apollo 自动驾驶平台的整个技术栈。目前开放的 Apollo1.0 具有高效易拓展架构、立即可用硬件、一键启动更新和完备的开发工具四大特性。

Apollo 的开放资源

Apollo1.0 在资源上开放了三个关键数据集：2D 红绿灯、3D 障碍物以及 Road Hackers。百度将这三部分数据开放至云端，以便用户高效研究运用。下图为 Apollo 数据开放平台的架构逻辑介绍。

如图，用户通过云端 Docker Repository，下载基于本地的 VM + Docker 的开发环境，编写训练和预测两部分算法，配置依赖环境。通过云端用户空间的可视化训练调试平台，将用户在本机创建的算法容器，在云端实现调度，展开训练评估调试。这样用户可以在整个云中的数据开放平台中，基于海量数据利用集群的 CPU+GPU 资源训练调试 model，并在其中选取有效的 model 使用。

现场，杨凡亲自展示了 Apollo 平台的使用流程和使用方法，本文不再此赘述，想要动手实践的读者可以移步至 Apollo 官网 apollo.auto，在“开发者”/“数据开放平台”页面有详细的使用介绍。

Apollo 代码开放框架

自动驾驶系统包括障碍物检测、红绿灯识别、驾驶行为决策、路径规划等系列复杂的功能模块，如何将这些独立而又相互依赖的模块集成在一起，构建成一个稳定的运行系统，是一个巨大的挑战。百度资深架构师何玮从百度为何选用 ROS 系统、Apollo 中 ROS 的改进实践、Apollo 框架使用介绍三个角度分享了 ROS 在百度自动驾驶的探索和实践。

百度为何选用 ROS 系统？

在百度为何选用 ROS 系统的问题上，何玮给出解释，ROS 是一个强大而灵活的机器人编程框架，同时也是学术界使用最广泛的框架，它具有三大特性：完整的开发工具包、灵活的计算调度模型以及丰富的调试工具，能够统一提供配置管理、部署运行、底层通信等功能，让开发者将更多精力放在算法功能的研发上，快速构建系统原型，验证算法和功能。

Apollo 中 ROS 的改进实践

ROS 系统的优势显而易见，但其在 Apollo 平台的应用中也并非一帆风顺。百度在做研发调试到产品化的过程中，遇到的不少状况，针对这些问题，百度从通信功能优化、去中心化网络拓扑以及数据兼容性扩展三个方面做了定制化的改进。

1、通信性能优化：共享内存

问题：自动驾驶系统为了能够感知复杂的道路场景并完成驾驶任务，需要多种传感器协同工作，以覆盖不同场景、不同路况的需求。而主流的多传感器融合方案至少会包含一个激光雷达和多个相机，如此大的数据量对通信的性能有很大的挑战。

解决方案：百度采用的解决方案是共享内存，减少传输中的数据拷贝, 提升传输效率。

1 对 1 的传输场景下，同一个机器上的 ROS 节点之间是 socket 进行进程间通信，中间存在多层协议栈以及多次用户空间和内核空间的数据拷贝，造成了很多不必要的资源占用和性能损耗。共享内存的方式来替代 socket 作为进程间通信的方式，通过减少不必要的内存拷贝，来降低了系统的传输延时和资源占用。

单对多的传输场景下，ROS 在处理一对多的消息传输时，底层实现实际是多个点对点的连接，当把一份数据要发给四个节点时，相同的数据会传输四次，这会造成很大的资源浪费。共享内存的传输过程，能够支持一次写入，多次读取的功能，对于一对多的传输场景，相同的数据包只需要写入一次即可，成倍地提高了传输的效率。

2、去中心化的网络拓扑：使用 RTPS 服务发现协议

问题：ROS 并非完全的分布式框架，每个 ROS 网络中需要有一个中心节点 ROS Master, 各个节点在初始化时会像 Master 注册拓扑信息并获取其他节点的信息。这种方式有两个缺点：1、Master 作为系统的单点，一旦崩溃整个网络将不可用；2、Master 缺乏异常恢复机制，崩溃后无法通过监控重启等方式自动恢复。

解决方案：为了解决这个问题，百度在 ROS 在框架加入了基于 RTPS 协议的服务发现功能。

整个网络拓扑不再以 master 为中心构建，而是通过域的概念进行划分。当一个新的节点加入网络时，会通过 RTPS 协议向域内的所有其他节点发送广播信息，各个节点也会将自己的服务信息发送给新的节点，以代替 Master 的信息交换功能。

通过这种方式，能够使 ROS 网络的拓扑发现不再依赖 Master 单点，提高了系统的鲁棒性。同时该修改完全基于 ROS 底层的修改，对上层应用程序完全透明，开发者也不需要对此功能有任何的代码适配工作。

3、数据兼容性扩展：用 Protobuf 替换 Message

问题：ROS 系统为了保证收发双方的消息格式一致，会对 message 定义做 MD5 校验，任何字段的增减或顺序调整都会使 MD5 变化，以保证系统的健壮性。然而这种严格的限制也引起了兼容性的问题，当接口升级后，不同的模块之间不再能够通信，大大增加了模块版本之间的耦合。

解决方案：使用 protobuf 来替换 ROS 中的 Message 来作为消息定义的格式。protobuf 本身有良好的兼容性支持，只需要在使用中定义好 required 字段，后续新增 optional 字段并不会对消息的解析造成影响。

Apollo 框架使用介绍

随后，何玮简单介绍了 Apollo 框架的使用方法：

第一步：安装 docher 系统。用 install-dacker 脚本安装和部署 docker 环境，包含下载、代码等一系列工作，安装完之后需要注销，并且用户重新登陆，这其中需要注意的是因为涉及用户权限的变更，需要当前用户注销之后才能完全生效；

第二步：编译 Apollo。编译代码：bash Apollo.sh build；

第三步，启动 Apollo。此步骤下需要对 Apollo 系统进行编译，编译完成之后启动 Apollo。百度提供了一键启动版本，可以将后台的应用和前端显示完整启动。第一步：安装 docher 系统。用 install-dacker 脚本安装和部署 docker 环境，包含下载、代码等一系列工作，安装完之后需要注销，并且用户重新登陆，这其中需要注意的是因为涉及用户权限的变更，需要当前用户注销之后才能完全生效；

目前 Apollo 开源代码已上传至 Github 网站，具体链接为：github.com/apolloauto，感兴趣的码农们可前往查阅相关的工具和文档。

基于深度学习的 End to End 自动驾驶方案

开发者想要基于 Apollo 平台设计一套完整的自动驾驶系统，前提需要了解百度的自动驾驶系统选择和方案详情，百度自动驾驶事业部资深架构师郁浩为大家分享了基于传统 Rule Based 与 End to End 自动驾驶方案的异同与优劣，以及 Apollo 平台在数据和模型上的实践。

基于深度学习的方案选择

郁浩表示，目前，业界和学术界主流还是 Rule based 系统。Rule based 从车辆、到传感器感知、World model、然后进行决策、控制、最后到车辆，形成了比较完整的闭环系统。不过，其在实际的应用上还是有比较明显的瓶颈：系统复杂（人工设计）、高精地图成本高（需要广铺以及实时更新），计算性能（资源浪费）。而 End-to-End 方式能够很好的解决这些问题。下图为 Rule based 与 End-to-End 优劣对比。

通过对比，可以看到 End-to-End 方案虽然解决了 Rule based 在应用上的部分缺点，但其在基本功能实现上需要进一步的探索和实践。郁浩认为，这两种方案，均有各自的优劣势，在现阶段，无法完全依靠某一种深度学习方案实现自动驾驶功能，Rule based 和 End-to-End 在未来的趋势上必将是吸收对方的优点进行融合而绝非对立。

Apollo 实践：数据

数据产生分一般两类，一类是真实数据，一类是模拟器数据。目前，关于中国国情的真实数据非常稀少，模拟器数据虽然能在一定的能况下起借鉴作用，但大多通过游戏渲染出来的，其渲染的纹理与真实场景的纹理千差万别，几乎无法用到真实的道路上。

百度在这方面投入甚高，每年都会使用大量数据车实地采集几百万公里的数据进行分析。郁浩表示，本次开放的数据主要摘取了前向数据，包括 Image、RTK-GPS 以及 IMU 等，每一个开源的数据文件对应一次采集任务。这里比较有意思的是，百度没有直接开源出精准坐标，而是根据坐标参数繁衍出1/R（拐弯半径的倒数）和纵向指令。开发者可以里利用它与车厂合作，直接上路行驶。

Apollo 实践：模型

百度在去年的时候使用的是简单的横向模型 CNN 以及纵向控制模型 Convolutional-LSTM，今年，百度将这二者融合到一起，采用的横向 + 纵向的模式：LRCN，该模型需要关注点时序处理、横纵向关联关系、因果 VS 轨迹预测、Attention 机制、迁移等问题，即能够精准的预测出周围的环境。

自动驾驶的模型构建还在探索阶段。百度希望与开发者和合作伙伴一起，通过资源和能力的开放，开发出一套真正智能、完整、安全的自动驾驶解决方案。