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

电子说

1.2w人已加入

描述

陆奇去年在上海车展期间发布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 机制、迁移等问题,即能够精准的预测出周围的环境。

自动驾驶

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

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分