基础部分参见:【机器人】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服务相关指令有两个:rosservicerossrv,前者是对ROS服务本身的管理,后者是对ROS 服务类型的管理,相当于话题的rostopicrosmsg


: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

:sparkles:执行方法

  • 和一般的节点启动别无二致:$rosrun <包名> <程序名.py>

:star:参考

下一篇:【机器人】ROS工程案例:服务和动作