【机器人】ROS1程序中的服务Service：精简解析

基础部分参见：【机器人】ROS程序框架：架构部分

本系列用时8天，博主也是从零开始，尽力去写的，如果发现了错误一定要私信告诉我呀。这么努力的博主，关注一下吧。

作者：杨丝儿
座右铭：始于兴趣，源于热爱，成于投入。
介绍：爱丁堡大学人工智能专业。技术兴趣点集中在机器人、人工智能可解释性、数学、物理等等。
聊天吹水QQ群：兔叽的魔术工房 (942848525)
个人博客：discover304.top
个人B站账号：杨丝儿今天也在科学修仙（UP主跨站求个三连加关注）

在ROS中有三个主要的通信方式：话题、服务和动作。我们之前已经完成话题的学习，并且参考工程案例（【机器人】ROS工程案例：基础部分）完成了最简单的ROS程序。

接下来，我们对服务和动作相关的知识点进行整理，包括提出契机，定义方法及其流程，执行方法。

关于代码以及使用部分，参见：【机器人】ROS工程案例：服务和动作。通信方法间的对比，参见：【机器人】ROS消息机制横向对比，到底该如何进行选择？

:star:服务

有人说：服务调用非常适合只需要偶尔去做并且会在有限时间完成的事情。确实运行服务的场景是这样的，但是这是表象，服务的价值是分布式计算，能够把一个迫切需要的（接下来就要用到的）计算任务交给性能更好的服务端，而不需要在客户端进行计算。例如某某节点希望获取历史记录图片数据，那就可以调用一个数据库服务节点获取相关数据。

服务其实就是同步的跨进程函数调用；他们能够让一个节点调用运行在另一个节点中的函数。

ros_service_graph

:sparkles:提出契机

话题机制针对的是一对多，且不需要对进程上锁的情况，例如传感器广播信息。
在一些不需要广播的任务上，也就是一对一的情况下，就需要一种新的通信机制，于是就有了服务。

服务通信机制是同步的，也就是说客户端会一直阻塞等待服务器的结果（不等待也不行啊，客户端之后的任务会使用到这个返回值）。

:sparkles:定义方法

就像消息定义文件一样，服务定义文件只是一个消息类型列表，也就是<类型> <名称>的列表。这些类型可以是内建的，也可以是自己定义的。
服务的定义文件分为两部分，请求和相应。列表中间使用---隔开。

graph TD
    q[包下创建srv文件夹] --> w
    subgraph 同msg文件
        w[创建并编辑 <服务名>.srv 文件]-->
        e[修改CMakeLists.txt文件]-->
        r[修改package.xml]-->
        t[catkin_make]
    end

:sparkles:执行方法

直接调用（适合调试使用）：$rosservice call <服务名> <参数>
程序内调用：$rosrun <包名> <程序名.py>。客户端程序中构造一个服务请求对象（有多种方法）订阅服务。

小贴士：ROS服务相关指令有两个：rosservice和rossrv，前者是对ROS服务本身的管理，后者是对ROS 服务类型的管理，相当于话题的rostopic和rosmsg。

:star:动作

动作动作，顾名思义就是机器的一个行为，需要去执行。这种行为往往是很复杂的，像是机器人跳舞或者执行一个后台计算。

动作机制会在执行过程中向客户端发送执行进度，并且支持被客户端中断和实时反馈等特性。

ros_action_graph

:sparkles:提出契机

因为服务机制是同步的（这是服务的性质决定的），所以完全不可以进行异步的行为（后台计算）。为了实现异步执行，ROS引入了动作机制。

:sparkles:定义方法

同样是消息定义文件，动作定义文件只是一个消息类型列表，也就是<类型> <名称>的列表。这些类型可以是内建的，也可以是自己定义的。
动作定义分为三部分，目标、结果和反馈。中间使用---隔开。

其他的和服务的定义方法是一样的。

graph TD
    q[包下创建action文件夹] --> w
    subgraph 同msg文件
        w[创建并编辑 <动作名>.action 文件]-->
        e[修改CMakeLists.txt文件]-->
        r[修改package.xml]-->
        t[catkin_make]
    end