ROS1的通信架构的基础通信方式及相关概念

ROS的通信架构是ROS的灵魂所在，它包括数据处理，进程运行，消息传递等 。这篇文章主要介绍ROS1的通信架构的基础通信方式和相关概念，因为ROS1和ROS2的通信方式相差很大，文章后面会介绍ROS2 的通信框架和差异。

接下来介绍一下三组概念：master<-->node<-->launch、topic<-->msg、service<-->srv<-->parameter <-->action.

一、master<-->node<-->launch

node: ROS最小的进程单元就是节点node。一个软件包里面有多个可执行文件，可执行文件被运行就是进程（process）,这个进程就是节点node。

rosnode list 列出当前运行的node信息

rosnode info node_name 显示出node的详细信息

rosnode kill node_name 结束某个node

rosnode ping 测试链接节点

rosnode machine 列出在特定机器或列表机器上运行的节点

rosnode cleanup 清除不可到达节点的注册信息

master: ROS网络架构的管理中心，管理着各个node。node先在master进行注册，node之间通信需要经过master编排才能点对点的通信。所以ROS程序启动， 第一步先执行roscore指令启动master,执行指令后同时启动的还有rosout（负责日志输出、记录当前系统状态）和parameter server（参数服务器，非node,负责存储参数配置） ,再由节点管理器按照cmakelists.txt、package.xml配置执行rosrun pkgname node_name 依次启动node 。

launch: 复杂节点启动管理文件。执行roslaunch pkg_name file_name.launch 指令后，首先系统先检测roscore是否启动，如果没有启动会默认自动拉起。然后按照launch配置启动规则，有序启动多个节点，减少终端输入。

二、topic<-->msg

ROS1的通信方式有四种：topic主题，service服务，parameter service 参数服务器 ,actionlib动作库。

topic： ROS通信最常用的一种，对实时性、周期性消息，使用topic传输是最佳选择。简单的说，启动topic 首先需要publisher和subscriber 节点到master进行注册，然后publisher 会发布topic，subscriber在master指挥下会订阅topic,从而建立sub-pub之间的通信。一个topic可以有多个publisher,一个publisher可以同时向多个subscriber发送消息，subscriber 接收消息会进行处理（回调函数 callback），publisher发送消息后就继续执行下一个动作，消息的状态和处理结构都不会影响publisher执行，subscriber只管消息接受和处理，publisher挂死不会对subscriber节点状态影响,所以topic通信实现了node之间的解耦，此通信方式属于异步通信。

rostopic list 列出当前所有topic

rostopic info topic_name 显示某个topic的属性信息

rostopic echo topic_name 显示某个topic的内容

rostopic pub topic_name 向某个topic发布内容

rostopic bw topic_name 查看某个topic的带宽

rostopic hz 查看某个topic的频率

rostopic find topic_type 查看某个类型的topic

rostopic type topic_name 查看某个topic类型的msg

message: 直观查看message就是一种数据格式。严格说按照规定的格式发送的数据就是message消息，所以消息既是内容也是标准格式。基本的msg包括bool、int8、int16、int32、int64(以及uint)、float、float64、string、time、 duration、header、可变长数组array[]、固定长度数组array[C]。

rosmsg list 列出系统消息

rosmsg show msg_name 显示某个msg的格式

---常见消息名称--

Vector 矢量; 向量

twist 转动，旋转

covariance 协方差；协变性；共离散;

Odometry 里程计

quaternion 四元组

• 话题的通信机制

此处假设 Talker 首先启动，可分成图中所示的七步来分析建立通信的详细过程：

1. Talker 注册Talker 启动，通过 1234 端口使用 RPC 向 ROS Master 注册发布者的信息，包含所发布消息的话题名；ROS master 会将节点的注册信息加入注册列表中。

2. Listener 注册Listener 启动，同样通过 RPC 向 ROS Master 注册订阅者的信息，包含需要订阅的话题名。

3. ROS Master 进行信息匹配Master 根据 Listener 的订阅信息从注册列表中进行查找，如果没有找到匹配的发布者，则等待发布者的加入；如果找到匹配的发布者信息，则通过 RPC 向 Listener 发布 Talker 的 RPC 地址信息。

4. Listener 发送连接请求Listener 接收到 Master 发回的 Talker 地址信息，尝试通过 RPC 向 Talker 发送连接请求，传输订阅的话题名、消息类型以及通信协议（TCP/UDP）。

5. Talker 确认连接请求Talker 接收到 listener 发送的连接请求后，继续通过 RPC 向 Listener 确认链接信息，其中包含自身的 TCP 地址信息。

6. Listener 尝试与 Talker 建立网络连接Listener 接收到确认信息后，使用 TCP 尝试与 Talker 建立网络连接。

7. Talker 向 Listener 发布数据成功建立连接后，Talker 开始向 Listener 发送话题消息数据。

   从上面的分析中可以发现，前五个步骤使用的通信协议都是 RPC，最后发布数据的过程才使用到 TCP。ROS Master 在节点建立连接的过程中起到了重要作用，但是并不参与节点之间最终的数据传输。

三、service<-->srv<-->parameter <-->action

service: 请求--查询双向同步通信模型，service分层两部分，客户端（client）和服务端（server）。客户端(client)发送请求(request)要等服务端(server)处理，反馈回复（reply）才会发送下一个请求到服务端（server）.

名称	topic	service
通信方式	异步通信	同步通信
实现原理	TCP/IP	TCP/IP
通信模型	publisher/subscriber	request/replay
映射关系	多对多	多对一
特点	subs收到数据会回调callback	远程过程调用（RPC）服务器端的服务
应用场景	连续、高频的数据发布	偶尔使用的功能、具体任务
举例	激光雷达、里程计发布数据	拍照、逆解计算、开关传感器

注意：远程过程调用（RPC）可以理解为一个进程里面调用另外一个进程的函数。

rosservice list 显示服务列表

rosservice info 打印服务信息

rosservice type 打印服务类型

rosservice uri 打印服务ROSRPC uri(统一资源标识，URI包含URL)

rosservice call 使用所提供的args调用服务

rosservice args 打印服务参数

rosservice find 查找服务

srv: service的数据类型，service通信的数据格式定义在*srv中，包含请求（request）和响应（reply）两部分。

rossrv show 显示服务描述

rossrv list 列出所有服务

rossrv md5 显示服务md5

rossrv package 列出包服务

rossrv packages 列出包含服务的包

• 服务通信机制

服务是一种带有应答的通信机制，通信原理如下图所示，与话题的通信相比，其减少了 Listener 与 Talker 之间的 RPC 通信。

1. Talker 注册Talker 启动，通过 1234 端口使用 RPC 向 ROS Master 注册发布者的信息，包含所发布消息的话题名；ROS master 会将节点的注册信息加入注册列表中。
2. Listener 注册Listener 启动，同样通过 RPC 向 ROS Master 注册订阅者的信息，包含需要订阅的服务名。
3. ROS Master 进行信息匹配Master 根据 Listener 的订阅信息从注册列表中进行查找，如果没有找到匹配的服务提供者，则等待该服务提供者的加入；如果找到匹配的服务提供者信息，则通过 RPC 向 Listener 发布 Talker 的 TCP 地址信息。
4. Listener 尝试与 Talker 建立网络连接Listener 接收到确认信息后，使用 TCP 尝试与 Talker 建立网络连接，并发送服务的请求数据。
5. Talker 向 Listener 发布数据Talker 接收到服务请求和参数后，开始执行服务功能，执行完成后，向 Listener 发送应答数据。

parameter server: 参数服务器维护的一般是静态数据字典，它使用互联网传输，在节点管理器master中运行，实现整个通信。

rosparam set param_key param_value 设置参数****rosparam get param_key 显示参数 rosparam load file_name 从文件加载参数 (yaml格式) rosparam dump file_name 保存参数到文件 (yaml格式)rosparam delete 删除参数rosparam list 列出参数名称

• 参数管理机制

  参数类似于 ROS 中的全局变量，由 ROS Master 进行管理，其通信机制较为简单，不涉及 TCP/UDP 的通信。

• 

1. Talker 设置变量Talker 使用 RPC 向 ROS Master 发送参数设置数据，包含参数名和参数值；ROS Master 会将参数名和参数值保存到参数列表中。
2. Listener 查询参数值Listener 通过 RPC 向 ROS Master 发送参数查找请求，包含索要查找的参数名。
3. ROS Master 向 Listener 发送参数值Master 根据 Listener 的查找请求从参数列表中进行查找，查找到参数后，使用RPC 将参数数值发送给 Listener。

这里需要注意的是，如果 Talker 向 Master 更新参数值，Listener 在不重新查询参数值的情况下是无法知晓参数值已经被更新的。所以在很多场景中，需要一种动态参数更新机制。

action: 动作类似service,属于请求--查询双向同步通信模型，但是通信过程连续反馈状态信息和随时终止请求。通信双方在action protocol 下通过消息进行数据交流，client和server为用户提供API来请求目标或者通过函数调用和回调来执行目标。

action protocal: action协议包含三部分,目标（设定终点），反馈（实时状态信息），结果（时长、最终姿态）。

ROS1和ROS2通信架构比对

这里主要给大家介绍ROS2和ROS1的通信架构区别，ROS1和ROS2的架构如下，可以分成3层：OS层、中间层和应用层

• OS层：ROS1主要构建在Linux上，但ROS2支持多个操作系统。
• 中间层：ROS1通信基于TCPROS/UDPROS，而ROS2通信基于DDS（data distribution service）数据分发服务。它是专门为RTOS设计的数据分发/订阅标准，其技术关键是以数据为核心的发布/订阅 模型 DCPS（data-centric publish-subscribe）,DCPS模型类似现在流行的容器命名空间技术，创建了一个全局数据空间，空间内的进程都可以直接访问。另外ROS2的intra-process 和ROS1的nodelet 数据传输方式类似，只是更名了而已，哈哈哈。
• 应用层：ROS1强依赖于master单点，只要单点就会降低系统的可靠性，所以ROS1只适用于实验室研究，无法商用。ROS2取消了master节点管理器，节点间使用discover发现机制帮助彼此建立链接。

ROS 2 的通信模型

ROS 1的通信模型主要包含话题、服务等通信机制，ROS 2的通信模型会稍显复杂，加入了很多DDS的通信机制。如下图所示：

基于DDS数据分发服务的ROS2模型包含以下几个关键概念。

参与者（Participant） :在 DDS 中，每一个发布者或者订阅者都成为参与者，对应于一个使用 DDS 的用户，可以使用某种定义好的数据类型来 读/写 全局数据空间。

发布者（Publisher） :数据发布的执行者，支持多种数据类型的发布，可以与多个数据写入器（DataWriter）相联，发布一种或多种主题（Topic）的消息。

订阅者（Subscriber） :数据订阅的执行者，支持多种数据类型的订阅，可以与多个数据读取器（DataReader）相联，订阅一种或多种主题（Topic）的消息。

数据写入器（DataWriter） :上层应用向发布者更新数据的对象，每个数据写入器对应一个特定的Topic，类似于ROS 1中的一个消息发布者。

数据读取器（DataReader） :上层应用从订阅者读取数据的对象，每个数据读取器对应一个特定的Topic，类似于ROS 1中的一个消息订阅者。

话题（Topic） ：和 ROS 1 中的概念类似，话题需要定义一个名称和一种数据结构，但 ROS 2 中的每个话题都是一个实例，可以存储该话题中的历史消息数据。

质量服务原则（Quality of Service） :简称 QoS Policy，这是 ROS 2 中新增的、也是非常重要的一个概念，控制各方面与底层的通信机制，主要从时间限制、可靠性、持续性、历史记录这几个方面，满足用户针对不同场景的数据需求。

• 实时性增强：数据必须在 deadline 之前完成更新；
• 持续性增强：DDS 可以为 ROS 2 提供数据历史服务，新加入的节点也可以获取发布者发布的所有历史数据；
• 可靠性增强：配置可靠性原则，用户可以根据需求选择性能模式（BEST_EFFORT）或者稳定模式（RELIABLE）。