Programming Robots with ROS

Chapter 5. Actions

The previous chapter described ROS services, which are useful for synchronous request/response interactions—that is, for those cases where asynchronous ROS topics don’t seem like the best fit. However, services aren’t always the best fit, either, in particular when the request that’s being made is more than a simple instruction of the form “get (or set) the value of X.”

While services are handy for simple get/set interactions like querying status and managing configuration, they don’t work well when you need to initiate a long-running task. For example, imagine commanding a robot to drive to some distant location; call it goto_position. The robot will require significant time (seconds, minutes, perhaps longer) to do so, with the exact amount of time impossible to know in advance, since obstacles may arise that result in a longer path.

Imagine what a service interface to goto_position might look like to the caller: you send a request containing the goal location, then you wait for an indeterminate amount of time to receive the response that tells you what happened. While waiting, your calling program is forced to block, you have no information about the robot’s progress toward the goal, and you can’t cancel or change the goal. To address these shortcomings, ROS provides actions.

ROS actions are the best way to implement interfaces to time-extended, goal-oriented behaviors like goto_position. While services are synchronous, actions are asynchronous. Similar to ...