一、Service

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

这种情况下，就需要有另外一种请求查询式的通信模型——service(服务)。

1、工作原理

为了解决以上问题，service方式在通信模型上与topic做了区别。

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等待过程中，是处于阻塞状态的成通信。这样的通信模型没有频繁的消息传递，没有冲突与高系统资源的占用，只有接受请求才执行服务，简单而且高效。

2、topic VS service

名称	Topic	Service
通信方式	异步通信	同步通信
实现原理	TCP/IP	TCP/IP
通信模型	Publish-Subscribe	Request-Reply
映射关系	Publish-Subscribe(多对多)	Request-Reply（多对一）
特点	接受者收到数据会回调（Callback）	远程过程调用（RPC）服务器端的服务
应用场景	连续、高频的数据发布	偶尔使用的功能/具体的任务
举例	激光雷达、里程计发布数据	开关传感器、拍照、逆解计算

注意：远程过程调用(Remote Procedure Call，RPC)，可以简单通俗的理解为在一个进程里调用另一个进程的函数。

3、操作命令

在实际应用中，service通信方式的命令时rosservice，具体的命令参数如下表：

rosservice 命令	作用
rosservice list	显示服务列表
rosservice info	打印服务信息
rosservice type	打印服务类型
rosservice uri	打印服务ROSRPC uri
rosservice find	按服务类型查找服务
rosservice call	使用所提供的args调用服务
rosservice args	打印服务参数

二、Srv

类似msg文件，srv文件是用来描述服务（service数据类型的，service通信的数据格式定义在*.srv中。它声明了一个服务，包括请求(request)和响应（reply）两部分。其格式声明如下：

举例：

1、操作命令

rossrv 命令	作用
rossrv show	显示服务描述
rossrv list	列出所有服务
rossrv md5	显示服务md5sum
rossrv package	列出包中的服务
rossrv packages	列出包含服务的包

2、修改部分文件

定义完了msg、srv文件，还有重要的一个步骤就是修改package.xml和修改CMakeList.txt。

这些文件需要添加一些必要的依赖等，例如：

<build_depend>** message_generation **</build_depend>
<run_depend>** message_runtime **</run_depend>

3、常见srv类型

三、参数服务器Parameter server

1、简介

前文介绍了ROS中常见的两种通信方式——主题和服务，这节介绍另外一种通信方式——参数服务器（parameter server）。

与前两种通信方式不同，参数服务器也可以说是特殊的“通信方式”。
特殊点在于参数服务器是节点存储参数的地方、用于配置参数，全局共享参数。
参数服务器使用互联网传输，在节点管理器中运行，实现整个通信过程。

参数服务器，作为ROS中另外一种数据传输方式，有别于topic和service，它更加的静态。

参数服务器维护着一个数据字典，字典里存储着各种参数和配置。

字典简介
何为字典，其实就是一个个的键值对，小时候学习语文的时候，常常都会有一本字典，当遇到不认识的字了可以查部首查到这个字，获取这个字的读音、意义等等，而这里的字典可以对比理解记忆。

键值kay可以理解为语文里的“部首”这个概念，每一个key都是唯一的。每一个key不重复，且每一个key对应着一个value。也可以说字典就是一种映射关系，在实际的项目应用中，因为字典的这种静态的映射特点，往往将一些不常用到的参数和配置放入参数服务器里的字典里，这样对这些数据进行读写都将方便高效。

2、维护方式

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

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

（1）命令行维护

使用命令行来维护参数服务器，主要使用rosparam语句来进行操作的各种命令，如下表：

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]

简明解释。就是“名称+：+值”这样一种常用的解释方式。一般格式如下：

key : value

遵循格式进行定义参数。其实就可以把YAML文件的内容理解为字典，因为它也是键值对的形式。

（2）launch文件内读写

launch文件中有很多标签，而与参数服务器相关的标签只有两个一个是，另一个是。这两个标签功能比较相近，但一般只设置一个参数。

（3）node源码

除了上述最常用的两种读写参数服务器的方法，还有一种就是修改ROS的源码，也就是利用API来对参数服务器进行操作。

四、动作库Action

1、简介

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

2、 Action 规范

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

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

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

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

4、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

标签：架构,service,rosparam,通信,参数,服务器,ROS,字典
来源： https://blog.csdn.net/qyt_722/article/details/118803029