ROS学习笔记（3）：ROS通信架构
目录
4.1.2 启动node : rosrun, roslaunch
4 ROS通信架构
Node:
在ROS的世界里，最小的进程单元就是节点（node）。一个软件包里可以有多个可执行文件，可执行文件在运行之后就成了一个进程(process)，这个进程在ROS中就叫做节点。 从程
序角度来说，node就是一个可执行文件（通常为C++编译生成的可执行文件、Python脚本）
被执行，加载到了内存之中；从功能角度来说，通常一个node负责者机器人的某一个单独的
功能。由于机器人的功能模块非常复杂，我们往往不会把所有功能都集中到一个node上，而
会采用分布式的方式。例如有一个node来控制底盘轮子的运动，有一个node驱动摄像头获取图像，有一个node驱动激光雷达，有一个node根据传感器信息进行路径规划……。
Master:
master在整个网络通信架构里相当于管理中心，管理着各个node。node首先在master处进行注册，之后master会将该node纳入整个ROS程序中。node之间的通信也是先由master进行“牵线”，才能两两的进行点对点通信。当ROS程序启动时，第一步首先启动master，由节点管理器处理依次启动node。
4.1 启动master和node
4.1.1启动master : roscore
启动ROS时，首先输入命令 roscore 启动master：
$ roscore
此时ROS master启动，同时启动的还有 rosout 和 parameter server ,其中 rosout 是负责日
志输出的一个节点，其作用是告知用户当前系统的状态，包括输出系统的error、warning等
等，并且将log记录于日志文件中； parameter server 即是参数服务器，它并不是一个node，
而是存储参数配置的一个服务器。每一次我们运行ROS的节点前，都需要把master启动起来，这样才能够让节点启动和注册。
4.1.2 启动node : rosrun, roslaunch
可以用rosrun, roslaunch
rosrun命令的详细用法如下：
$ rosrun [--prefix cmd] [--debug] pkg_name node_name [ARGS]
rosrun将会寻找PACKAGE下的名为EXECUTABLE的可执行程序，将可选参数ARGS传入。
roslaunch命令:
roslaunch pkg_name file_name.launch
能一次性启动master和多个node. roslaunch命令首先会自动进行检测系统的roscore有没有运行，也即是确认节点管理器是否在运行状态中，如果master没有启动，那么roslaunch就会首先启动master，然后再按照launch的规则执行。
4.1.3 rosnode命令
- rosnode list 列出当前运行的node信息
- rosnode info node_name 显示出node的详细信息
- rosnode kill node_name 结束某个node
- rosnode ping 测试连接节点
- rosnode machine 列出在特定机器或列表机器上运行的节点
- rosnode cleanup 清除不可到达节点的注册信息
rosnode help 来查看 rosnode 命令的用法。
4.2 ROS的通信方式
ROS的通信方式是ROS最为核心的概念,ROS的通信方式有以下四种：
- Topic 主题
- Service 服务
- Parameter Service 参数服务器
- Actionlib 动作库
4.2.1 Topic
ROS中的通信方式中，topic是常用的一种。对于实时性、周期性的消息，使用topic来传输是最佳的选择。topic是一种点对点的单向通信方式，这里的“点”指的是node，也就是说node之间可以通过topic方式来传递信息。topic要经历下面几步的初始化过程：首先，publisher节点和subscriber节点都要到节点管理器进行注册，然后publisher会发布topic，subscriber在master的指挥下会订阅该topic，从而建立起sub-pub之间的通信。注意整个过程是单向的。Subscriber接收消息会进行处理，一般这个过程叫做回调(Callback)。所谓回调就是提前定义好了一个处理函数（写在代码中），当有消息来就会触发这个处理函数，函数会对消息进行处理。
topic通信是一种单向异步的通信方式。
其结构示意图如下所示;
4.2.1.1 rostopic 命令:
- 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_name 查看某个topic的频率
- rostopic find topic_type 查找某个类型的topic
- rostopic type topic_name 查看某个topic的类型(msg)
4.2.1.2 msg文件
Message是topic内容的数据类型，也称之为topic的格式标准。定义在以.msg为后缀的文件中。
基本的msg数据类型包括bool、int8、int16、int32、int64(以及uint)、float、float64、string、time、duration、header、可变长数组array[]、固定长度数组array[C]。
我们用一个具体的msg来了解，例如msg sensor_msg/image ,位置存放在 sensor_msgs/msg/image.msg 里,它的结构如下：
std_msg/Header header
uint32 seq
time stamp
string frame_id
uint32 height
uint32 width
string encoding
uint8 is_bigendian
uint32 step
uint8[] data
4.2.1.3 rosmsg 命令：
- rosmsg list 列出系统上所有的msg
- rosmsg show msg_name 显示某个msg的内容
4.2.2 Service
Service通信是双向的，它不仅可以发送消息，同时还会有反馈。所以service包括两部分，一部分是请求方（Clinet），另一部分是应答方/服务提供方（Server）。这时请求方（Client）就会发送一个request，要等待server处理，反馈回一个reply，这样通过类似“请求-应答”的机制完成整个服务通信。
这种通信方式的示意图如下：Node B是server（应答方），提供了一个服务的接口，叫做 /Service ，我们一般都会用string类型来指定service的名称，类似于topic。Node A向Node B发起了请求，经过处理后得到了反馈。
Service是同步通信方式，所谓同步就是说，此时Node A发布请求后会在原地等待reply，直到
Node B处理完了请求并且完成了reply，Node A才会继续执行。Node A等待过程中，是处于
阻塞状态的通信。这样的通信模型没有频繁的消息传递，没有冲突与高系统资源的占用，只有接受请求才执行服务，简单而且高效。
4.2.2.1 topic VS service
4.2.2.2 rosservice命令
- rosservice list 显示服务列表
- rosservice info 打印服务信息
- rosservice type 打印服务类型
- rosservice uri 打印服务ROSRPC uri
- rosservice find 按服务类型查找服务
- rosservice call 使用所提供的args调用服务
- rosservice args 打印服务参数
4.2.2.3 srv文件
srv文件是用来描述服务（service数据类型的，service通信的数据格式定义在*.srv中。它声明了一个服务，包括请求(request)和响应（reply）两部分。
其格式声明如下：举例：
msgs_demo/srv/DetectHuman.srv
bool start_detect
---
my_pkg/HumanPose[] pose_data
msgs_demo/msg/HumanPose.msg
std_msgs/Header header
string uuid
int32 number_of_joints
my_pkg/JointPose[]joint_data
msgs_demo/msg/JointPose.msg
string joint_name
geometry_msgs/Pose pose
floar32 confidence
srv文件格式很固定，第一行是请求的格式，中间用---隔开，第三行是应答的格式。在本例中，请求为是否开始检测，应答为一个数组，数组的每个元素为某个人的姿态（HumanPose）。而对于人的姿态，其实是一个msg，所以srv可以嵌套msg在其中，但它不能嵌套srv。
4.2.2.4 rossrv命令
- rossrv show 显示服务描述
- rossrv list 列出所有服务
- rossrv md5 显示服务md5sum
- rossrv package 列出包中的服务
- rossrv packages 列出包含服务的包
4.2.3 Parameter server
参数服务器（parameter server）也可以说是特殊的“通信方式”。特殊点在于参数服务器是节点存储参数的地方、用于配置参数，全局共享参数。参数服务器使用互联网传输，在节点管理器中运行，实现整个通信过程。
参数服务器，作为ROS中另外一种数据传输方式，有别于topic和service，它更加的静态。参数服务器维护着一个数据字典，字典里存储着各种参数和配置。
参数服务器的维护方式有三种：
- 命令行维护
- launch文件内读写
- node源码
4.2.3.1命令行维护：rosparam
- rosparam set param_key param_value 设置参数
- rosparam get param_key 显示参数
- rosparam load file_name 从文件加载参数
- rosparam dump file_name 保存参数到文件
- rosparam delete 删除参数
- rosparam list 列出参数名称
load&&dump文件
load和dump文件需要遵守YAML格式，YAML格式具体示例如下：
name:'Zhangsan'
age:20
gender:'M'
score{Chinese:80,Math:90}
score_history:[85,82,88,90]
4.2.3.2 launch文件内读写
launch文件中有很多标签，而与参数服务器相关的标签只有两个，一个是 <param> ，另一个
是 <rosparam> 。
4.2.3.3 node源码
ROS源码，也就是利用API来对参数服务器进行操作。具体内容我们学习完后面章节再进行介绍。
4.2.4 Action
Actionlib是ROS中一个很重要的库，类似service通信机制，actionlib也是一种请求响应机制的
通信方式，actionlib主要弥补了service通信的一个不足，就是当机器人执行一个长时间的任务
时，假如利用service通信方式，那么publisher会很长时间接受不到反馈的reply，致使通信受
阻。当service通信不能很好的完成任务时候，actionlib则可以比较适合实现长时间的通信过
程，actionlib通信过程可以随时被查看过程进度，也可以终止请求，这样的一个特性，使得它
在一些特别的机制中拥有很高的效率。
4.2.4.1 Action的工作原理
Action的工作原理是client-server模式，也是一个双向的通信模式。通信双方在ROS
Action Protocol下通过消息进行数据的交流通信。client和server为用户提供一个简单的
API来请求目标（在客户端）或通过函数调用和回调来执行目标（在服务器端）。
工作模式的结构示意图如下：
客户端会向服务器发送目标指令和取消动作指令,而服务器则可以给客户端发送实时的状态信息,结果信息,反馈信息等等,从而完成了service没法做到的部分.
4.2.4.2 action文件
利用动作库进行请求响应，动作的内容格式应包含三个部分，目标、反馈、结果。
- 目标
机器人执行一个动作，应该有明确的移动目标信息，包括一些参数的设定，方向、角度、速度等等。从而使机器人完成动作任务。
- 反馈
在动作进行的过程中，应该有实时的状态信息反馈给服务器的实施者，告诉实施者动作完成的状态，可以使实施者作出准确的判断去修正命令。
- 结果
当运动完成时，动作服务器把本次运动的结果数据发送给客户端，使客户端得到本次动作的全部信息，例如可能包含机器人的运动时长，最终姿势等等。
Action规范文件的后缀名是.action，它的内容格式如下：
# Define the goal
uint32 dishwasher_id # Specify which dishwasher we want to use
---
# Define the result
uint32 total_dishes_cleaned
---
# Define a feedback message
float32 percent_complete