ROS基础篇（三）-- 通信框架

1 Node & Master

1.1 Node

        在 ROS 的世界里，最小的进程单元就是节点（node）。 一个软件包里可以有多个可执行文件，可执行文件在运行之后就成了一个进程(process)，这个进程在 ROS 中就叫做节点。 从程序角度来说，node 就是一个可执行文件（通常为 C++ 编译生成的可执行文件、Python脚本）被执行，加载到了内存之中；从功能角度来说，通常一个node负责者机器人的某一个单独的功能。这种模块化分工的设计可以降低程序发生崩溃的可能性。

1.2 Master

        Master（节点管理器）在整个网络通信架构里相当于管理中心，管理着各个node。 node 首先在 master 处进行注册，之后 master 会将该 node 纳入整个 ROS 程序中。node 之间的通信也是先由 master 进行“牵线”，才能两两的进行点对点通信。当 ROS 程序启动时，第一步首先启动 master，由节点管理器处理依次启动 node。

 roscore		# 启动master和node

        此时 ROS master 启动，同时启动的还有 rosout 和 parameter server ,其中 rosout 是负责日志输出的一个节点，其作用是告知用户当前系统的状态，包括输出系统的 error、warning 等等，并且将 log 记录于日志文件中，parameter server 即是参数服务器，它并不是一个 node，而是存储参数配置的一个服务器 。每一次我们运行 ROS 的节点前，都需要把 master 启动起来，这样才能够让节点启动和注册。

        启动 master 之后，节点管理器就开始按照系统的安排协调进行启动具体的节点。具体启动 node 的语句如下：

rosrun pkg_name node_name

        通常我们运行ROS，就是按照这样的顺序启动，有时候节点太多，我们会选择用 launch 文件来启动。

        小结：Master、Node 之间以及 Node 之间的关系如下图所示：

---

2 launch文件

2.1 简介

        对于一个复杂的工程，在运行操作时要开启很多个 node，每个节点依次进行 rosrun 就会比较麻烦，ROS 为我们提供了一个命令能一次性启动 master 和多个 node。

roslaunch pkg_name file_name.launch

        roslaunch 命令首先会自动进行检测系统的 roscore 有没有运行，即确认节点管理器是否在运行状态中，如果 master 没有启动，那么 roslaunch 就会首先启动 master，然后再按照 launch 的规则执行。launch 文件里已经配置好了启动的规则。 所以 roslaunch 就像是一个启动工具，能够一次性把多个节点按照我们预先的配置启动起来，减少我们在终端中一条条输入指令的麻烦。

2.2 写法与格式

        launch 文件同样也遵循着 xml 格式规范，是一种标签文本，它的格式包括以下标签：

<launch>       <!--根标签-->
<node>         <!--需要启动的node及其参数-->
<include>      <!--包含其他launch-->
<machine>      <!--指定运行的机器-->
<env-loader>   <!--设置环境变量-->
<param>        <!--定义参数到参数服务器-->
<rosparam>     <!--启动yaml文件参数到参数服务器-->
<arg>          <!--定义变量-->
<remap>        <!--设定参数映射-->
<group>        <!--设定命名空间-->
</launch>      <!--根标签-->

        作为初学者，我们可以先了解这些标签，如果需要自己写 launch 文件，可以先从改 launch 文件的模板入手，基本可以满足普通项目的要求。

---

3 Topic

3.1 topic通信方式

        在 ROS 的通信方式中，topic 是常用的一种异步通信方式。对于实时性、周期性的消息，使用 topic 来传输是最佳的选择。 topic 是一种点对点的单向通信方式，这里的“点”指的是 node，也就是说 node 之间可以通过 topic 方式来传递信息。一个 topic 可以被多个节点同时发布，也可以同时被多个节点接收。ROS Master （管理者）负责保管 Talker（发布者） 和 Listener （订阅者）注册的信息，并匹配话题相同的 Talker 与 Listener，帮助 Talker 与 Listener 建立连接，连接建立后，Talker 可以发布消息，且发布的消息会被 Listener 订阅。注意整个过程是单向的。其结构示意图如下：

        整个流程实现的步骤如下：

（1）Talker注册

        Talker启动后，会通过RPC在 ROS Master 中注册自身信息，其中包含所发布消息的话题名称。ROS Master 会将节点的注册信息加入到注册表中。

（2）Listener注册

        Listener启动后，也会通过RPC在 ROS Master 中注册自身信息，包含需要订阅消息的话题名。ROS Master 会将节点的注册信息加入到注册表中。

（3）ROS Master实现信息匹配

        ROS Master 会根据注册表中的信息匹配Talker 和 Listener，并通过 RPC 向 Listener 发送 Talker 的 RPC 地址信息。

（4）Listener向Talker发送请求

        Listener 根据接收到的 RPC 地址，通过 RPC 向 Talker 发送连接请求，传输订阅的话题名称、消息类型以及通信协议(TCP/UDP)。

（5）Talker确认请求

        Talker 接收到 Listener 的请求后，也是通过 RPC 向 Listener 确认连接信息，并发送自身的 TCP 地址信息。

（6）Listener与Talker建立连接

        Listener 根据步骤4 返回的消息使用 TCP 与 Talker 建立网络连接。

（7）Talker向Listener发送消息

        连接建立后，Talker 开始向 Listener 发布消息。

上述实现流程中，前四步使用的 RPC协议，最后两步使用的是 TCP 协议
Talker 与 Listener 的启动无先后顺序要求
Talker 与 Listener 都可以有多个
Talker 与 Listener 连接建立后，不再需要 ROS Master。也即，即便关闭ROS Master，Talker 与 Listern 照常通信。

        Subscriber（Listener）接收消息会进行处理，一般这个过程叫做回调(Callback)。所谓回调就是提前定义好了一个处理函数（写在代码中），当有消息来就会触发这个处理函数，函数会对消息进行处理。

        小结：

• topic 通信方式是异步的，发送时调用 publish() 方法，发送完成立即返回，不用等待反馈。
• subscriber 通过回调函数的方式来处理消息。
• topic 可以同时有多个 subscribers，也可以同时有多个 publishers。

3.2 Message

        Message 按照定义解释就是 topic 内容的数据类型，也称之为 topic 的格式标准。基本的msg包括bool、int8、int16、int32、int64(以及uint)、float、float64、string、time、duration、header、可变长数组array[]、固定长度数组array[C]。

---

4 Service

        topic 是 ROS 中的一种单向的异步通信方式。 但有些时候单向的通信满足不了通信要求，比如当一些节点只是临时而非周期性的需要某些数据，如果用 topic 通信方式时就会消耗大量不必要的系统资源，造成系统的低效率高功耗。这种情况下，就需要有另外一种请求-查询式的通信模型。

4.1 工作原理

        Service通信是双向的，它不仅可以发送消息，同时还会有反馈。所以service包括两部分，一部分是请求方（Clinet），另一部分是应答方/服务提供方（Server）。ROS Master 负责保管 Server 和 Client 注册的信息，并匹配话题相同的 Server 与 Client ，帮助 Server 与 Client 建立连接，连接建立后，Client 发送请求信息，Server 返回响应信息。这种通信方式的示意图如下：

        整个流程的实现步骤如下：

（1）Server注册

        Server 启动后，会通过RPC在 ROS Master 中注册自身信息，其中包含提供的服务的名称。ROS Master 会将节点的注册信息加入到注册表中。

（2）Client注册

        Client 启动后，也会通过RPC在 ROS Master 中注册自身信息，包含需要请求的服务的名称。ROS Master 会将节点的注册信息加入到注册表中。

（3）ROS Master实现信息匹配

        ROS Master 会根据注册表中的信息匹配Server和 Client，并通过 RPC 向 Client 发送 Server 的 TCP 地址信息。

（4）Client发送请求

        Client 根据步骤2 响应的信息，使用 TCP 与 Server 建立网络连接，并发送请求数据。

（5）Server发送响应

        Server 接收、解析请求的数据，并产生响应结果返回给 Client。

客户端请求被处理时，需要保证服务器已经启动；
服务端和客户端都可以存在多个。

        Service 是同步通信方式，比如 Talker 发布请求后会在原地等待 reply，直到 Listener 处理完了请求并且完成了reply，Talker 才会继续执行。Talker 等待过程中，是处于阻塞状态的通信。这样的通信模型没有频繁的消息传递，没有冲突与高系统资源的占用，只有接受请求才执行服务，简单而且高效。

4.2 Srv

        类似 msg 文件，srv 文件是用来描述服务(service)数据类型的，service 通信的数据格式定义在 *.srv 中。它声明了一个服务，包括请求(request)和响应（reply）两部分。srv 文件格式很固定，第一行是请求的格式，中间用 --- 隔开，第三行是应答的格式。
举例：

# 客户端请求时发送的两个数字
bool state
int32 number_of_sensor
---
# 服务器响应发送的数据
string joint_name

        注意：定义完了msg、srv 文件，还有重要的一个步骤就是修改 package.xml 和修改 CMakeList.txt 。这些文件需要添加一些必要的依赖。

---

5 Parameter server

        参数服务器（parameter server）可以说是特殊的“通信方式”。特殊点在于参数服务器是节点存储参数的地方、用于配置参数，全局共享参数。参数服务器使用互联网传输，在节点管理器中运行，实现整个通信过程。他维护着一个数据字典，字典里存储着各种参数和配置。

字典就是一个个键值对，其中键是惟一的（其他类型的映射也是如此），但值并不唯一。每个键和它的值之间用冒号(：) 隔开，项之间用逗号(，) 隔开，而整个字典是由一对大括号括起来。

        实现流程如下图所示：

        具体实现步骤如下：

（1）Talker 设置参数

        Talker 通过 RPC 向参数服务器发送参数(包括参数名与参数值)，ROS Master 将参数保存到参数列表中。

（2）Listener 获取参数

        Listener 通过 RPC 向参数服务器发送参数查找请求，请求中包含要查找的参数名。

（3）ROS Master 向 Listener 发送参数值

        ROS Master 根据步骤2请求提供的参数名查找参数值，并将查询结果通过 RPC 发送给 Listener。

        参数服务器的维护方式非常的简单灵活，总的来讲有三种方式：

• 命令行维护
• launch文件内读写
• node源码

---

6 Action

6.1 简介

        Actionlib 是 ROS 中一个很重要的库，类似 service 通信机制，actionlib 也是一种请求响应机制的通信方式，actionlib 主要弥补了 service 通信的一个不足，就是当机器人执行一个长时间的任务时，假如利用 service 通信方式，那么 publisher 会很长时间接受不到反馈的 reply，致使通信受阻。当 service 通信不能很好的完成任务时候，actionlib 则可以比较适合实现长时间的通信过程，actionlib 通信过程可以随时被查看过程进度，也可以终止请求，这样的一个特性，使得它在一些特别的机制中拥有很高的效率。

6.2 通信原理

        Action的工作原理是client-server模式，也是一个双向的通信模式。 通信双方在 ROS Action Protocol 下通过消息进行数据的交流通信。client和server为用户提供一个简单的API来请求目标（在客户端）或通过函数调用和回调来执行目标（在服务器端）

        从上图我们可以看到，客户端会向服务器发送目标指令和取消动作指令，而服务器则可以给客户端发送实时的状态信息，结果信息，反馈信息等等，从而完成了 service 没法做到的部分.

6.3 Action规范

        利用动作库进行请求响应，动作的内容格式应包含三个部分，目标、反馈、结果。

1、目标

        机器人执行一个动作，应该有明确的移动目标信息，包括一些参数的设定，方向、角度、速度等等。从而使机器人完成动作任务。

2、反馈

        在动作进行的过程中，应该有实时的状态信息反馈给服务器的实施者，告诉实施者动作完成的状态，可以使实施者作出准确的判断去修正命令。

3、结果

        当运动完成时，动作服务器把本次运动的结果数据发送给客户端，使客户端得到本次动作的全部信息，例如可能包含机器人的运动时长，最终姿势等等。

        Action规范文件的后缀名是 .action，它的内容格式如下：

# 定义目标
int64 max
float64 duration
---
# 定义结果
int64 count
---
# 定义反馈信息
float64 percent

        注意：定义完 action 消息描述文件后，要修改 package.xml 和修改 CMakeList.txt 。这些文件需要添加一些必要的依赖。

---

参考

1. Launch文件：http://wiki.ros.org/roslaunch/XML
2. 常见msg类型：https://sychaichangkun.gitbooks.io/ros-tutorial-icourse163/content/chapter3/3.5.html
3. 常见srv类型：https://sychaichangkun.gitbooks.io/ros-tutorial-icourse163/content/chapter4/4.5.html
4. 常见action类型：https://sychaichangkun.gitbooks.io/ros-tutorial-icourse163/content/chapter4/4.6.html