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 首先启动，可分成图中所示的七步来分析建立通信的详细过程：
Talker 注册Talker 启动，通过 1234 端口使用 RPC 向 ROS Master 注册发布者的信息，包含所发布消息的话题名；ROS master 会将节点的注册信息加入注册列表中。
Listener 注册Listener 启动，同样通过 RPC 向 ROS Master 注册订阅者的信息，包含需要订阅的话题名。
ROS Master 进行信息匹配Master 根据 Listener 的订阅信息从注册列表中进行查找，如果没有找到匹配的发布者，则等待发布者的加入；如果找到匹配的发布者信息，则通过 RPC 向 Listener 发布 Talker 的 RPC 地址信息。
Listener 发送连接请求Listener 接收到 Master 发回的 Talker 地址信息，尝试通过 RPC 向 Talker 发送连接请求，传输订阅的话题名、消息类型以及通信协议（TCP/UDP）。
Talker 确认连接请求Talker 接收到 listener 发送的连接请求后，继续通过 RPC 向 Listener 确认链接信息，其中包含自身的 TCP 地址信息。
Listener 尝试与 Talker 建立网络连接Listener 接收到确认信息后，使用 TCP 尝试与 Talker 建立网络连接。
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 通信。
- Talker 注册Talker 启动，通过 1234 端口使用 RPC 向 ROS Master 注册发布者的信息，包含所发布消息的话题名；ROS master 会将节点的注册信息加入注册列表中。
- Listener 注册Listener 启动，同样通过 RPC 向 ROS Master 注册订阅者的信息，包含需要订阅的服务名。
- ROS Master 进行信息匹配Master 根据 Listener 的订阅信息从注册列表中进行查找，如果没有找到匹配的服务提供者，则等待该服务提供者的加入；如果找到匹配的服务提供者信息，则通过 RPC 向 Listener 发布 Talker 的 TCP 地址信息。
- Listener 尝试与 Talker 建立网络连接Listener 接收到确认信息后，使用 TCP 尝试与 Talker 建立网络连接，并发送服务的请求数据。
- 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 的通信。
- Talker 设置变量Talker 使用 RPC 向 ROS Master 发送参数设置数据，包含参数名和参数值；ROS Master 会将参数名和参数值保存到参数列表中。
- Listener 查询参数值Listener 通过 RPC 向 ROS Master 发送参数查找请求，包含索要查找的参数名。
- 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）。