Apollo ROS原理（二）

ROS能否满足自动驾驶工作需求？

1、大数据量传输性能瓶颈
2、单中心网络存在的风险
3、数据格式缺乏后向兼容

1、大数据量传输性能瓶颈

问题：ROS里面所采用的Topic（message）数据量很小，一般是几k，最多一两兆，不到10兆数量级。
然而，在实际自动驾驶里，数据量很大，比如：
Lidar:7M/1帧，10帧/s>>70M/s
Camera:5M/帧，10帧/s>>50M/s
因此，在数据传输时，ROS架构存在一个性能瓶颈，这瓶颈最直接的影响就是时延高，这在自动驾驶整个系统里非常危险。因此，ROS本身并不能满足自动驾驶需求。

优化：
一对一传输：

一对多传输：

结果对比：

2、单中心网络存在的风险

问题：存在单点风险，ROS架构虽然是一个松耦合概念，节点管理器只是在节点交互之前有一个简单地拓扑映射，这种方式虽然极大程度上释放各个节点之间的耦合，但也存在了很大的风险，比如ROScore出现故障退出，而此时节点之间使用了一些需要不定时的交互方式（Service，Param）,这个时候就会存在风险；还有就是如果是分布式系统，因为ROScore只存在一台机器上，如果出问题，两台机器的通信就是不可信的状态。

优化：去中心化网络拓扑

把中心化网络拓扑去掉，建立了一个点对点的复杂网络拓扑，这里面一个核心概念就是使用RTPS服务发现协议来完成这种P2P的网络。
节点建立流程：
（1）
订阅节点在启动的时候，它会向当前这个域里面发送一个信息，告诉大家我现在有一个新的节点要启动。
（2）
所有节点在收到新加入的这个新的节点发生的拓扑信息变更之后，他们会和新加入的节点分别建立一个两两连接关系。
（3）
当这种连接关系建立起来后，所有已经存在的节点会向新加入的节点发布他们的拓扑信息，也就是在这个节点加入之前，每个节点其实是维护了他和其他节点的一个连接关系，这个连接关系发送给新加入节点，工这个接收节点去更新他自己的网络拓扑结构。
（4）
当新加入节点接收到其它节点发来的拓扑信息结构之后，它会根据自己注册的实际消息内容去决定和哪些节点去建立通信连接。

3、数据格式缺乏后向兼容

ROS是基于Message的分发和订阅的一个消息通讯框架，这个Message是需要提前设置好的，包含哪些数据以及数据类型。如果要在这个Message里面新增一个数据类型，则下游相应的订阅模块也需要修改，原来的实验数据也需要批量修改，这样就去少一个后向兼容。



优化：数据兼容性扩展
引入Protobuf这一块，Protobuf具有良好的向后兼容特性，只需要在使用的过程中定义好一些必须的字段或新增字段，这样在模块升级时，下游模块就不需要关注你的改变对他的影响，如果下游要使用，就要进行一定程度的匹配。