ROS 通信机制

ROS通信机制概述：

机器人是一种高度复杂的系统性实现，在机器人上可能集成各种传感器（雷达、摄像头、GPS...）以及运动控制实现，为了解耦合，在ROS中每一个功能点都是一个单独的进程，每一个进程都是独立运行的。更确切的讲，ROS是进程（也称为Nodes）的分布式框架。应为这些进程甚至还可以分布于不同主机，不同主机协同工作，从而分散计算压力。不过随之也有一个问题：不同的进程是如何通信的？换言之，不同进程间如何实现数据交换的？就需要学习ROS中的通信机制了。

ROS中的基本通信机制主要有如下三种实现策略：

        话题通信（发布订阅模式）

        服务通信（请求响应模式）

        参数服务器（参数共享模式）

主要内容：介绍各个通信机制的应用场景、理论模型、代码实现以及相关操作命令

话题通信：

概述：

话题通信是ROS中使用频率最高的一种通信模式，话题通信是基于发布订阅模式的，即：一个节点发布消息，另一个节点订阅该消息。话题通信的应用场景极其广泛，例如：

机器人在执行导航功能，使用的传感器是激光雷达，机器人会采集激光雷达感知到的信息并计算，然后生成运动控制信息驱动机器人底盘运动。

在上述场景中，不只一次使用到了话题通信：

        以激光雷达信息的采集处理为例，在ROS中有一个节点需要实时发布当前雷达采集到的数据，导航模块中也会有节点会订阅并解析雷达数据。

        再以运动消息的发布为例，导航模块会根据传感器采集到的数据实时的计算出运动控制信息并发布给底盘，底盘也可以有一个节点订阅运动信息并最终转换成控制电机的脉冲信号。

以此类推，像雷达、摄像头、GPS...等等一些传感器数据的采集，也都是使用了话题通信，换言之，话题通信适用于不断更新的数据传输相关的应用场景

---

概念：以发布订阅的方式实现不同节点之间数据交互的通信模式

作用：用于不断更新的，少逻辑处理的数据传输场景

理论模型：

话题通信的实现模型是比较复杂的，该模型如下图所示，该模型中涉及到三个角色

        ROS Master（管理者） 管理匹配话题

        Talker（发布者） 

        Listener（订阅者）

ROS Master 负责保管 Talker 和 Listener 注册的信息，并匹配话题相同的 Talker 与 Listener，帮助 Talker 与Listener 建立连接(二者的媒介)，连接建立后,Talker 可以发布消息，且发布的消息会被 Listener 订阅。

图解：

第0步：Talker在Master当中进行注册操作，提交自己的话题和RPC地址（即foo：1234）

第1步：Listener在Master中进行注册操作，注册自己所关注的话题

第2步：Master将Talker和Listener关注的话题进行比对，若比对一致，将发布者的RPC地址发送给Listener

第3步：Listener根据RPC地址远程访问Talker

第4步：Talker再作响应，响应中包括Talker的TCP地址

第5步：Listener根据TCP地址访问Talker

第6步：Talker 发消息，Listener收消息

注意：

1、使用的协议有 RPC 和 TCP 其中从步骤0~4都是RPC，5,6是TCP

2、步骤0和1没有先后顺序，谁先注册都一样

3、talker和 listener都可以存在多个

4、talker 和 listener 建立连接后，master 就可以关闭了

5、上述实现流程已经被封装，直接调用即可

话题通信应用时关注点：

0、大部分实现已经被封装了

1、话题设置

2、关注发布者实现

3、关注订阅者实现

4、关注消息载体

案例：ROS话题通信例程-CSDN博客

1、实现最基本的发布订阅模型，发布方以固定频率发送一段文本，订阅方接受文本并输出。

2、实现对自定义消息的发布与订阅

---

---

---

---

---

服务通信

概述：

服务通信也是ROS中一种极其常用的他弄个新模式，服务通信是基于请求响应模式的，是一种应答机制。也即：一个节点A向另一个节点B发送请求，B接收处理请求并产生相应结果返回给A，比如如下场景：

机器人在巡逻过程中，控制系统分析传感器数据发现可疑物体或人，此时需要拍摄照片并留存

上述场景中，就使用到了服务通信

        一个节点需要向相机节点发送拍照请求，相机节点处理请求，并返回处理结果

与上述应用类似的，服务通信更适用于对实时性有要求、具有一定逻辑处理的应用场景

---

概念：以请求响应的方式实现不同节点之间数据交互的通信模式

作用：对于偶然的、对实时性有要求、有一定逻辑处理需求的数据传输场景

案例：

实现两个数字的求和，客户端节点，运行会向服务器发送两个数字，服务器端口=节点接收两个数字求和并将结果响应回客户端

ROS 服务通信例程-CSDN博客

理论模型：

Talker应叫Server    服务端

Listener应叫Client       客户端

流程：

master 会根据话题实现 Server 和 Client 的连接

第零步：Server在Master中注册自己信息（话题名称，远程RPC地址）

第一步：Client在Master中注册信息，只注册话题

第二部：Master对于话题进行匹配，匹配成功后报Server的地址传输给Client，但传输的不是foo中的1234，而是ROSRPC中的3456

第三步：客户端拿到地址之后请求服务端

第四步：服务端接收请求之后响应于客户端（使用TCP通信）

注意：

1、需要保证顺序，客户端发起请求时，需要确保服务端已经启动

2、客户端和服务端都可以存在多个
 

---

---

---

---

---

参数服务器

参数服务器在 ROS 中主要用于实现不同节点之间的数据共享。参数服务器相当于是独立于所有节点的一个公共容器，可以将数据存储在该容器中，被不同的节点调用，当然不同的节点也可以往其中存储数据，关于参数服务器的典型应用场景如下：

导航实现时，会进行路径规划，比如：全局路径规划，设计一个从出发点到目标点的大致路径。本地路径规划，会根据当前路况生成实时的行进路径

上述场景中，全局路径规划和本地路径鬼话时，就会使用参数服务器：

        路径规划时，需要参考小车的尺寸，我们可以将这些尺寸信息存储到参数服务器，全局路径规划节点与本地路径规划节点都可以从参数服务器中调用这些参数

参数服务器，一般适用于存在数据共享的一些应用场景

---

概念：以共享的方式实现不同节点之间数据交互的通信模式

作用：存储一些多节点共享的数据，类似于全局变量。

案例：实现参数增删改查 操作

ROS 参数服务器例程-CSDN博客        没写完还

理论模型：

参数服务器实现是最为简单的，该模型如下图所示，涉及到三个角色：

        ROS Master（管理者）

        Talker（参数设置者）

        Listener（参数调用者）

        ROS Master作为一个公共容器保存参数，Talker可以向容器中设置参数，Listener可以获取它