本文的翻译来自,ROS answers 官方的问答区 2014/7/30 点击打开链接
topics seem like the best way for storing "states" of the robot (stateful). so that we can monitor all states/components of the robots like position, temperature, voltage, etc. that makes sense to me.
however, i also see a lot of people using topics as a way to send instructions/commands to the robots (like the topic /head_pan_joint/command for sending commands to servos, like /cmd_vel for sending movement instructions to mobile base, etc). in this case, it doesn't make sense to me.
it seems to me that this should be designed as a service (stateless). if you want to send a command to servo, create a service at the servo level that can be called upon. if you want to send a command to mobile base, create a service at the mobile base that can be called upon.
what are the advantages of designing things like /cmd_vel and /head_pan_joint/command as topics? what are the disadvantages of desigining them as services?
thanks.
answers
From the data receiver's perspective, topics are fire and forget communication, and are asynchronous by default - that is why callbacks need to be setup at receiving nodes.
Services are synchronous - data is requested, and then the receiver blocks until the data is received. While potentially this could be used for commands (with the data representing success and failure), the blocking nature makes this awkward in most use cases.
Basic commands, with no feedback required, are implemented using topics for their simplicity. Commands that require feedback/state tracking, and take a non-trivial time to complete, are implemented using actionlib.
Take a look at move_base in the navigation stack - a 'client' requesting the robot move would likely want to know the robot's progress throughout the move action, but would not want to halt operation (block) while waiting, hence actionlib. For a fire-and-forget movement command, the move_base_simple topic exists, but here you would have no idea if the robot ever successfully moves or not, and is not suitable for the complexities of most high-level planners.
thanks paul. really appreciated it. following your explaination, it seems like actionlib and topics can handle pretty much everything. why do we even need to use services? can you give me a couple of real-world use cases that we must use services vs. topics / actionlib?
d
(Jul 31 '14)
Say one node is maintaining some giant datastore and another node needs to retrieve a small subset of that data. Actionlib is a lot of boilerplate and overhead when all you need a simple request - response. Bare topics give you no control over the contents of the data. Service API gives you a nice middle ground.
paulbovbel
(Jul 31 '14)
从数据接收者这边来看，topic 这边是断开联系的，并且默认是异步接收的（收、发不同时）——这也是为什么callback函数（响应函数）需要在接收端的node这边启动的原因。
比较而言service是同步收发的——请求数据，响应它直到数据被对方接受到。有时候这也可以用来发送指令（传回的消息可以代表动作成功还是失败），
==========================================================================
ROS/Patterns/Communication - ROS Wiki
Topics
处理连续数据流，topic是一种多对多的形式，一个Node可以订阅多个Topic，可以publish到多个topic上。
topic中的数据只要准备好了，就可以被callback——回调函数调用。而发送端的topic的发送时机由publisher自己决定。
Service
用于那些快速停止的程序，如查询一个node 的状态，或是做数学运算，比如机械臂的运动学反解IK（inverse kinematic）。它不应当被用于那些需要长时间运行的进程中，特别是有异常处理的子进程。绝不应该用于状态的变化。
Actions它由三部分组成：目标goal、反馈feedback和结果result。它和service和topic有相同也有不同，重要的是它可以中途取消。而且相比于service能够提供长久稳定的反馈，service是一问一答型。
用于离散的行为，如让小车前进一段时间，并在运行过程中提供反馈。
它最主要的特点就是运行过程中可以被中断，中断通常是靠Action server来实现。比如《ROS by Example》书中想让小车走1米，运行过程中需要不断检测是否走了1米，走到了就中断它，让它停下来。
即使在同一个Action Server上运行不同的两个action goal, 它们的状态也能够利用各自的ID被区分开来。
像视觉处理等需要较多时间来启动或终止的程序也是利用action来实现的一个不错的例子。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
