这是一份详细的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是一个强大而灵活的机器人编程框架,同时也是学术界使用最广泛的框架,它具有三大特性:完整的开发工具包、灵活的计算调度模型以及丰富的调试工具,能够统一提供配置管理、部署运行、底层通信等功能,让开发者将更多精力放在算法功能的研发上,快速构建系统原型,验证算法和功能。
![](https://res.infoq.com/news/2017/07/Apollo-baidu-AI/zh/resources/43.png)
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 机制、迁移等问题,即能够精准的预测出周围的环境。
郁浩最后总结道,自动驾驶的模型构建还在探索阶段,百度希望与开发者和合作伙伴一起,通过资源和能力的开放,开发出一套真正智能、完整、安全的自动驾驶解决方案。