In this lecture, we will look into the desirability of (non)-blocking executions, which leads to ROS Actions. We will show you how the terminology works and give an example of implementation of a counter.

We don’t always want blocking execution. ROS Actions allow non-blocking execution. This way, multiple things can happen at the same time. They are a generalized request-response system (as for services): a client-server infrastructure. Actions are defined by three message types:

1. A goal (request),
2. The result (response),
3. And feedback.

There are a few ROS commands to interact with actions:

Generate action messages manually:
$ rosrun actionlib_msgs genaction.py <path_to_action_file>
Show the contents of an action message:
$ rosmsg show <stack_name>_msgs/<ActionMessage>

ROS actions have a few functions available to process requests:

• The goalCallback function processes a goal request.
• Goal statuses: ACTIVE, SUCCEEDED, ABORTED.

Nomenclature:

• Action server: A ROS node that advertises an action, so that other nodes can request action goals to be processed.
• Action client: A ROS node that sends goal requests to the action server.

Code example

Here, we will show the general structure of an action file.

Requirement: Counter with a 1s delay between each increment.

Goal message: Number to count up to (uint32)
Result message: A status message (string)
Feedback message: The number of counts completed (uint32)