机器人开发--Apollo ROS介绍

1 介绍

1.1 概述

阿波罗是百度发布的名为“Apollo（阿波罗）”的向汽车行业及自动驾驶领域的合作伙伴提供的软件平台。是百度重金押注的项目。

1.2 历程

• 从2015年开始，百度大规模投入无人车技术研发。
• 2016年9月获得美国加州自动驾驶路测牌照，11月在浙江乌镇开展普通开放道路的无人车试运营。
• 2017年7月，将率先开放封闭场地的自动驾驶能力，年底输出在城市简单路况下的自动驾驶能力。
• 2018年1月8日下午，在拉斯维加斯举办的BAIDU WORLD发布会上，百度正式推出了旗下第二代自动驾驶平台Apollo 2.0。
• 2018年2月15日，Apollo无人车亮相2018年中央电视台春节联欢晚会广东珠海分会场。在春晚直播中，百余辆Apollo无人车跨越港珠澳大桥。
• 2018年4月19日，百度Apollo开放平台正式发布Apollo2.5版本。Apollo2.5支持限定区域视觉高速自动驾驶，“解锁”高速公路场景。提到高速公路，发布会现场演示了长沙智能驾驶研究院有限公司利用Apollo2.5，快速实现高速公路场景下重型卡车自动驾驶的案例。百度方面表示，这意味着Apollo新增卡车物流应用场景，再度扩宽了其商业化想象空间。
• 2018年7月4日，在Baidu Create 2018百度AI开发者大会上，百度发布Apollo3.0。
  Apollo已经开放了超过22万行代码，超过1万名开发者推荐使用Apollo的开放代码，生态合作伙伴规模达到116家。面向量产，Apollo发布了自主泊车（Valet Parking）、无人作业小车（MicroCar）、自动接驳巴士（MiniBus）三套自动驾驶解决方案，帮助开发者及合作伙伴三个月内即可打造出属于自己的“阿波龙”。基于Apollo自主泊车解决方案，百度已联合盼达用车实现了中国首次自动驾驶共享汽车示范运营，并联合现代汽车展开定点接驳的落地应用。
• 2018年7月10日，百度（NASDAQ:BIDU）与宝马集团宣布合作 。
• 2019年1月，百度在拉斯维加斯举行的2019CES(消费电子展)上宣布，全球首个最全面智能驾驶商业化解决方案Apollo Enterprise正式问世。百度Apollo3.5发布，可支持复杂城市道路自动驾驶，并发布了全球首个面向自动驾驶的高性能开源计算框架Apollo Cyber RT。
• 2019年，100辆自动驾驶出租车将在湖南长沙130英里的城市道路上行驶，配备百度的V2X技术。这支车队将成为中国第一批自主驾驶出租车，由百度的V2X系统管理。
• 2020年4月，百度 Apollo 正式对外发布“ACE 交通引擎”并完整介绍百度“ACE 交通引擎”的《Apollo 智能交通白皮书》。百度“ACE 交通引擎”综合解决方案已在北京、长沙、保定等10余个城市落地实践。百度“ACE交通引擎”具体是指：Autonomous Driving、Connected Road、Efficient Mobility，即自动驾驶、车路协同、高效出行。
• 2020年7月30日，百度与伟创力,在伟创力苏州吴中工厂举行了Apollo Computing Unit （ACU）量产下线发布仪式。发布会上，百度宣布全球首个量产自动驾驶计算平台ACU正式下线。
• 2020年9月10日，百度Apollo宣布在北京正式开放自动驾驶出租车服务Apollo Go，北京用户可以在百度地图及Apollo官网上预约体验Robotaxi。北京此次开放的自动驾驶载人测试区域总长度约700公里，覆盖亦庄、海淀、顺义的生活圈和商业圈等近百个站点，全国开放区域最广、测试里程最长。
• 2021年9月27日，世界互联网大会乌镇峰会在浙江乌镇召开，Apollo“汽车机器人”（阿波罗）在会上发布。
• 2021年11月25日，百度Apollo获国内首个自动驾驶收费订单，这标志着自动驾驶正迎来“下半场”——商业化运营阶段。
• 2022年2月14日，萝卜运力（深圳）科技有限公司获批深圳市智能网联汽车示范应用。

2 ROS的不足

ROS在开发过程中，基于功能把整个自动驾驶系统分成多个模块，每个模块负责自己消息的接收、处理、发布。当模块需要联调时，通过框架可以把各个模块快速的集成到一起。

大数据传输性能瓶颈

实验性项目采用的Topic是Message，数据量是比较小的，可能只有几K或者最多1~2MHZ，但在实际自动驾驶场景中数据量非常大。例如Lidar一帧数据大概是7M，一秒钟10帧，就会产生70M/S的流量；一个Camera按5M计算，四个Camera就是20M，如果是按10HZ计算一秒钟会产生200M左右的数据。ROS架构对大数据传输存在很大的性能瓶颈，一种直接后果是时延非常高，这在自动驾驶整个系统里面是非常危险的。

单中心的网络存在单点风险（ROS2为分布式避免该问题）

ROS1 中，在运行节点之前，需要启动 ROS 主节点。ROS1 主节点将充当节点的 DNS 服务器，以便它们可以相互检索。主节点因故障退出，节点间通信会不可信。
ROS2 中，不再有 ROS 主节点！这不再是一个集中式系统。每个节点都具有发现其他节点的能力。可以简单地启动一个节点，而不必担心是否有主节点正在运行。可以创建完全分布式系统。

数据格式缺乏向后兼容

ROS是基于Message的分发和订阅的消息通讯框架，使用Message需要提前设置Message包含哪些类型的数据。相应的下游所有订阅此节点都要去做对应的适配。ROS现有的数据格式缺少后向兼容，此问题在Apollo ROS里面得到解决。

3 Apollo ROS的改进

通信性能优化

• 自动驾驶大量使用传感器引发很大的传输带宽需求
• 单路传感器消息有多个消费者时负载成倍增长
  
  针对这一问题，Apollo ROS做了一个基于共享内存的通信机制减少数据的复制次数，从而提升这种通信模式的效率。
  如上图所示，左侧是ROS原生的通讯框架，一个数据从发送方到接收方经历四次数据复制。第一次是从节点到用户内存的数据复制，第二次是从发送方到内核的数据复制，第三次是经过TCP连接，从内核再向接收节点用户态空间的复制，第四次是接收节点拿到这个信息之后，通过反序列化把信息取出来组成一个结构变化的信息。
  右侧是Apollo ROS优化后的框架，它基于共享内存改进，可以减少两次数据拷贝。第一次是发送节点把消息序列化成流式数据，第二次是接收节点直接从共享内存里面取相应的消息指针，把共享内存消息取出来进行反序列化成结构化信息进行使用。减少了从用户到内核态以及从内核态到用户的两次数据拷贝。
  
  对于有多个订阅节点的情况，例如Camera下游会有很多订阅节点，如果是三个节点，会有三条通信链路，分别是四次的内存拷贝，也就是12次数据拷贝。而在基于共享内存的通信方式下，每一条链路内存拷贝的次数只需要两次，三条链路只需要六次。
  

消息通信延时

随着消息逐渐增大，基于共享内存通信延时比基于原声ROS Socket的通信延时降低一半。以5M数据为例，传送一帧5M大小的数据，基于ROS Socket大概需要四毫秒左右的时间，基于共享内存通信只需要两毫秒左右。

吞吐量

整个自动驾驶系统的网络拓扑结构非常复杂，数据流向的拓扑结构也比较复杂。在一些极端的情况下，整机数据量会增加。在一些多车道，路面状况比较复杂，车辆较多的情况下，感知和Planning模块，或者和其它模块之间的数据流就会成倍增加，所以在测试一些极端情况下，系统吞吐量也是自动驾驶需要考虑的一个重要方面。

CPU资源占用率

CPU资源占用率在共享内存通信情况下降低约30%， 主要是因为减少了多次内存复制。

去中心化网络拓扑（使用RTPS服务发现协议去完成P2P网络拓扑）

Apollo ROS进行了比较大的改造：先把这个中心化的网络拓扑给去掉，然后建立了一个点对点之间的一个复杂网络拓扑，主要是使用RTPS服务发现协议去完成P2P网络拓扑。
左下角RTPS是新引入的一个功能。改造之后的ROS Node架构，当一个节点被启动的时候，它会通过RTPS向所有的节点发送信息：现在有一个新的节点要加入到这个拓扑网络。当它离开的时候，也会发送消息告诉所有的节点：现在这个节点要退出。以前这些功能都是通过Rosmaster来完成的。

节点建立连接和通讯的一个主要流程

第一步：Sub节点启动，通过组播向网络注册。

订阅节点在启动的时候，它会向当前这个域里面所有的节点发送信息：现在有一个新的节点要启动。
第二步：通过节点发现，两两建立unicast。

所有的节点在接收到新加入这个节点发生拓扑信息变更之后，会和新加入这个节点分别建立两两连接关系。
第三步：向新加入的节点发送它们已经有拓扑信息。

所有已经存在的节点会向新加入的节点发送它们已经有拓扑信息，也就是在新节点加入之前每个节点其实是维护了它和其它所有节点的一个连接关系，这个连接关系发送给接收节点，供接收节点去更新自己的网络拓扑结构。
第四步：收发双方建立连接，开始通信。

当新加入节点接到所有节点发送出来的历史拓扑信息之后，它会根据它自己注册的实际消息内容去决定和哪些节点建立实际的通信连接。如上图所示：新加入节点只和右下角的一个节点之间有拓扑关系，它除了维护所有的节点给它发送出的整个网络拓扑信息之外，同时会和发送节点建立点对点的通信连接。
通过RTPS拓扑发现方式，Apollo ROS去除了对Rosmaster这一个单点的依赖，从而提升整个系统的鲁棒性。这个修改完全是对ROS底层的修改，用户基于原生ROS代码写的节点程序，到Apollo ROS是完全兼容的一个迁移即开发者不需要去改动任何的接口，就可以直接使用RTPS网络拓扑这种新的关系建立。

数据兼容性拓展（采用Protobuf，减少 rosbag 的体积）

原生ROS基于Message的订阅发布消息模型。发送者和接收者在进行实际通讯之前需要进行消息格式定义，其包含字段：基础的数据类型或者复杂的数据类型。在它们进行消息通信的时候，才可以有选择性的去建立通信连接和数据实际发送。如果有一个节点订阅的消息类型不是Channel预先指定的消息类型，这种通信连接是建立不起来的。或是强制指定一个节点去订阅某一种类型的Channel信息，但是它的实际回调函数里却写的是另外一种消息类型，这种编译可能在实际运行的时候就会报相关的一些错误。

Message是两个节点进行消息通信的抽象描述文件。这个描述文件提前定义好两个节点之间进行消息通信的基本数据类型。ROS采用这种方式是因为能比较大概率地对两个节点之间进行解耦合。

但是ROS基于Message这种通讯方式有很多的缺点。它最大限度解放两个点之点的一个耦合关系也带来了一些问题。比如Message接口升级，不同版本之间的兼容是需要做大量的适配工作。再如某个模块进行升级，之前所录制的一些实验数据，在进行回放的时候就会产生不匹配的现象。

深度整合Protobuf功能，实现数据兼容性扩展

• Apollo ROS实践里面引入了一种新的消息描述的格式去实现很好的向后兼容即Protobuf。只需要在使用的过程中，定义好必须的字段或者是一些新增的字段，新增的字段我们可以使用Optional属性去描述。在进行模块升级或者是模块之间的消息接口升级的时候，下游模块其实不需要关注新增字段对它来说会造成什么样的影响。如果它要去使用这个字段的话才需要去进行一定程度的适配。如果它的程序不使用这个新增的字段，就不需要做任何的修改。
• 类似json这类数据，只不过Protobuf是google团队搞得，序列化反序列化效率要高很多。
• 为了做好数据兼容，在原生ROS里面，开发者使用了一个trick：将Proto文件序列化成一个字符串信息放到Message信息里面，完成消息的向后兼容。比起Apollo ROS这个方式有两个明显的缺点：
  1> 它增加了一次数据序列化和反序列化。并把Proto序列化信息压到Message里面，增加了两次额外的数据Copy。
  2> 如果想实时调试信息，通过Rostopic echo打印出来Message里面那个序列化的字母串，若是采用Wrapper的方式，则这个字符串信息在屏幕上就会是一堆乱码。

参考

1、Apollo官网
2、百科–Apollo
3、Apollo开发者社区–进阶课程㉜丨Apollo ROS原理—1
4、Apollo开发者社区–进阶课程㉝丨Apollo ROS原理—2
5、百度apollo - Apollo对ROS优化总结