ROS通信架构及其弊端

ROS通信架构及其弊端

严格来讲ROS并非是一种操作系统，它只是一种通信框架，一种基于消息传递通信的分布式多进程框架。ROS的主要组成包括ROS Mastar 、 ROS Node、ROS Service等。不同的功能可以由不同的节点实现，节点之间可以通过发布和订阅话题来传递消息，它的本质是基于TCP/IP的Socket通信机制。不同的模块可以被单独设计，在运行时松散耦合，它执行若干种类型的通信，比如基于服务的同步RPC通信、基于话题的异步数据流通信以及基于参数服务器的数据存储等。

ROS具备丰富的机器人功能库，比如用于坐标变换的 Tf、用于导航的SLAM功能库、用于视觉的OPenCV功能库、用于运动的MoveIt、用于激光雷达的PCL点云库等等，这些丰富的功能库可以使得开发人员快速开发并验证自己的机器人原型；ROS还具备非常便利的数据分析、仿真、调试、可视化工具，比如RVIZ、Gazebo等，还有rosbag、rqt等可以提供数据记录功能等，这些工具可以方便的进行调试开发、验证、仿真自己的机器人，从而提高开发速度。
当然正是由于ROS的这种架构使得它存在一些弊端：

1 Master 与 Node 之间并不关心对方的存在，Master 作为网络拓扑的中心，一旦Master崩溃，整个系统将会崩溃；
2 当 Master 或 Node 崩溃后ROS没有应对策略，ROS不具备动态发现、生存检测、访问控制等机制，因此对系统是一种灾难；
3 系统存在大量的话题和数据时，一个节点与多个节点通信时，一个消息会拷贝多次，因此对系统资源也是一种极大的浪费，并降低系统通信效率，严重时会丢包；
4 ROS通信的消息数据是开放的未加密的，如果通信过程中Master或Node任何一个或多个被劫持，那系统将无法继续有效的运作下去，如果是安全性要求比较高的系统比如无人驾驶中，那么所带来的灾难是不可估量的；

可尝试的改进

去中心化

ROS并非完全的基于分布式的框架结构，它严重依赖 Master 中心节点，因此可以尝试在架构中去掉 Master 这个中心节点，采用节点自发现模式，动态的添加和去掉节点，比如ROS2.0所采用的DDS(Data Distribution Service)数据分发服务，以及 Apollo 中的基于 RTPS 协议的服务发现机制，当一个新的节点加入时，系统的自发现机制会自动向其他节点广播消息，各个节点也会将自己的信息发送至新加入的节点，从而代替 Master 功能。

采用共享内存，提高数据传输效率

摒弃ROS中的多个消息接收端拷贝多次现象，直接采用共享内存的方式实现，提高数据吞吐量，减少CPU负担，提高系统效率。

实时监控

实时监测并记录节点的运行数据，当检测到系统错误时做出报警，并采取必要的措施进行解决。监测记录节点的运行数据、统计数据、运行状态等，能够为错误追踪提供必要的线索，在系统发生紧急情况时做出反应。记录节点的状态，也是为了恢复宕掉的节点，如果没有记录这些状态，那么再启动将会丢失一些必要的数据，造成系统错误。

信息加密与安全

节点之间传递的信息很容易被截获，或被伪造，在无人驾驶领域，发生这种情况意味着严重的事故。必要时可以对发送的信息进行加密，或虚拟化处理，限制ROS节点进程权限，避免对其他节点造成破坏。

转至：https://zhuanlan.zhihu.com/p/35219808