基础部分参见:【机器人】ROS程序框架:架构部分
本系列用时8天,博主也是从零开始,尽力去写的,如果发现了错误一定要私信告诉我呀。这么努力的博主,关注一下吧。
作者:杨丝儿
座右铭:始于兴趣,源于热爱,成于投入。
介绍:爱丁堡大学 人工智能专业。技术兴趣点集中在机器人、人工智能可解释性、数学、物理等等。
聊天吹水QQ群:兔叽的魔术工房 (942848525)
个人博客:discover304.top
个人B站账号:杨丝儿今天也在科学修仙(UP主跨站求个三连加关注)
在ROS中有三个主要的通信方式:话题、服务和动作。我们之前已经完成话题的学习,并且参考工程案例(【机器人】ROS工程案例:基础部分)完成了最简单的ROS程序。
接下来,我们对服务和动作相关的知识点进行整理,包括提出契机,定义方法及其流程,执行方法。
关于代码以及使用部分,参见:【机器人】ROS工程案例:服务和动作。通信方法间的对比,参见:【机器人】ROS消息机制横向对比,到底该如何进行选择?
:star:服务
有人说:服务调用非常适合只需要偶尔去做并且会在有限时间完成的事情。确实运行服务的场景是这样的,但是这是表象,服务的价值是分布式计算,能够把一个迫切需要的(接下来就要用到的)计算任务交给性能更好的服务端,而不需要在客户端进行计算。例如某某节点希望获取历史记录图片数据,那就可以调用一个数据库服务节点获取相关数据。
服务其实就是同步的跨进程函数调用;他们能够让一个节点调用运行在另一个节点中的函数。
: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:动作
动作动作,顾名思义就是机器的一个行为,需要去执行。这种行为往往是很复杂的,像是机器人跳舞或者执行一个后台计算。
动作机制会在执行过程中向客户端发送执行进度,并且支持被客户端中断和实时反馈等特性。
: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机器人编程实践》
- ROS学习笔记(四)—— 服务 Service 详解
- ROS 学习笔记(五)—— 动作 Action 详解
下一篇:【机器人】ROS工程案例:服务和动作