浩为 java_这是一份详细的Apollo自动驾驶平台上手指南

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

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

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。百度提供了一键启动版本，可以将后台的应用和前端显示完整启动。

目前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 机制、迁移等问题，即能够精准的预测出周围的环境。

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