ROS Basics – ROS Action
The third main communication mechanism in ROS is Action. Action is similar to service. However, it is asynchronous, which means that you may perform other task when Action is in processing. There are situations where a service may not fit. In that case Action may be used.
For example, we want our robot to go to some particular position. If we implement this requirement using service (say the service name is goto_position). Then we send a request to the service “goto_position” containing a goal location, then we will have to wait for undetermined time until we get a response from the service server. If our program gets stuck, we will not have any information about the robot’s progress. If it takes too long, we will not be able to cancel the request. Even we will not be able to do any other task while waiting for the response. In order to overcome these shortcomings, ROS provides Action.
The service message has two parts request and response. However, the Action message has three parts that are goal, result and feedback. Goal is same as request in service, and result is same as response in service. While feedback provides additional mechanism to provide updates about the progress of the goal and also allows goals to be canceled.
If we implement the same “goto_position” task using Action. We will send a gaol to the Action “goto_position”, and will move on to other task while the robot is driving. In between, we will periodically receive the progress updates (for example distance traveled by the robot, estimated remaining time etc.). In the end we will get a result whether the task is completed or any error occurred. Meanwhile, if something more important comes up, we can cancel the goal at any time and may send robot to somewhere else.
Action is implemented in similar manner to service. A node, which acts as action server, provides the functionality. On the other hand another node, acting as action client, uses the functionality. Action message is defined in “.action” file, as the service message is define “.srv” file.
Interestingly, there is no command like “rosaction”. Instead, the actions are implemented using topics. For each action there are five topics. Which are named (along with the name of Action) as goal, cancel, status, result, and feedback.
Action Definition File
We can have a look of “.action” file in actionlib_tutorial package.
Run the command in terminal
rospack list | grep action
(To view which ros packages containing the name action are available)
Go to the package “actionlib_tutorials” tutorials
Run the command
Run the command
(To view the contents of the folder)
You will see a subdirectory named “action”. This directory contains the action definition files.
Go to the directory action
There are two action definition files “Averaging.action”, and “Fibonacci.action”
We open one of the files
Run the command
you will notice that the file “Fibonacci.action” has three parts
The first is goal part
Then there are three dashes (—)
Then result part
Again three dashes (—)
And then feedback part
The structure is similar to service. However service definition file has two parts, while action definition file has three parts.
All above commands are shown in figure below
The “Fibonacci.action” file looks like as figure below
Action Server and Action Client nodes communicate with each other using ROS topics. Client node sends “Goal” and “Cancel” messages to the server, while server node sends back the “Status”, “Result” and “Feedback” messages. The is illustrated in figure below
In next blogs, we will learn how to define Action message and how to implement Action server and Action client to provide and use the functionality.