Apollo ROS与原生ROS对比

时间:2024-03-31 16:53:21

原生ROS主题/发布接收机制

原生ROS系统中包含一个节点管理器Master,用于管理发布者和订阅者,当产生新的发布者或订阅者时都必须先在Master上注册信息。当新的发布者在Master上注册时,Master会保存发布者的URI(统一资源标识符)和发布者发布的话题,当新的订阅者在Master上注册时,Master会在保存信息中寻找与话题匹配的发布者,然后将发布者的URI发送给订阅者,订阅者会根据发布者的URI与相对应的发布者建立TCP连接,创建连接后发布者消息会通过连接传输到订阅者。

简单来说整个过程就是:发布者/订阅者在Master上注册->Master把发布者的URI发送给订阅者->发布者/订阅者建立TCP连接。

Apollo ROS与原生ROS对比

 

Apollo对ROS的改进

Apollo从通信功能优化去中心化网络拓扑以及数据兼容性扩展三个方面做了定制化的改进。

1.通信功能优化:共享内存

自动驾驶系统为了感知复杂的道路场景,需要多种传感器协同工作,以覆盖不同场景、不同路况的需求,多传感器融合产生的巨大数据量对通信的性能无疑是一个挑战,且单个传感器消息对应多个订阅者时负载更是成倍的增长。

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

Apollo ROS与原生ROS对比

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

Apollo ROS与原生ROS对比

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

2.去中心化网络拓扑:使用 RTPS 服务发现协议

原生ROS系统非常依赖Master,一旦Master出现异常,将导致整个系统崩溃,而且Master 缺乏异常恢复机制,崩溃后无法通过监控重启等方式自动恢复。

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

整个过程分为四个步骤:

1、Sub节点启动,通过组播向网络注册

2、通过节点发现,两两建立unicast

3、向新加入的节点发送历史拓扑消息

4、收发双发建立连接,开始通信

Apollo ROS与原生ROS对比

Apollo ROS与原生ROS对比

Apollo ROS与原生ROS对比

Apollo ROS与原生ROS对比

3. 数据兼容性扩展:用 Protobuf 替换 Message

Message是ROS中描述接口的一种语言,当两个节点之间需要建立连接的时候,通常需要满足两个条件。一是接收和发送的Topic属于同一个话题,二是两个模块定义的模式要完全一致。ROS 系统为了保证收发双方的消息格式一致,会对message定义做 MD5 校验,任何字段的增减或顺序调整都会使 MD5 变化,以保证系统的健壮性。然而这种严格的限制也引起了兼容性的问题,当接口升级后,不同的模块之间就会出现不兼容问题,导致系统运行障碍。

Apollo ROS与原生ROS对比

在Apollo ROS中,做了一整套对protobuf的支持, 在工程中可以不需要做protobuf和ROS message的转换,直接publish protobuf格式的消息,调试工具也能够非常正确的解析出来正确的protobuf消息。这样既能够很好解决兼容性问题,也不会产生额外的学习成本和使用成本。

Apollo ROS与原生ROS对比

参考:

https://blog.csdn.net/DinnerHowe/article/details/79935384

https://blog.csdn.net/qq_25241325/article/details/81270967