The same ROS concept explored in ROS 2 Actions, action servers are a common way to control long-running tasks like navigation. This stack makes more extensive use of actions, and in some cases, without an easy topic interface. It is more important to understand action servers as a developer in ROS 2.
Within the action server, a client will request some task to be completed, except this task may take a long time. Some examples of this may be moving a robot joint or moving a robot 10 meters to the right. Because these tasks take time, and progress messages can be generated during the process, action servers are necessary.
In this situation, action servers and clients allow us to call a long-running task in another process or thread and return a future to its result. It is permissible at this point to block until the action is complete, however, you may want to occasionally check if the action is complete and continue to process work in the client thread. Since it is long-running, action servers will also provide feedback to their clients. This feedback can be anything and is defined in the ROS .action
Along with the request and result types. In the joint example, a request may be an angle, feedback may be the angle remaining to be moved, and the result is a success or fail Boolean with the end angle. In the navigation example, a request may be a position, feedback may be the time it's been navigating for and the distance to the goal, and the result is a Boolean for success.
Feedback can be gathered synchronously by registering callbacks with the action client. They may also be gathered by asynchronously requesting information from the shared future objects. Both require spinning the client node to process callback groups.
Action servers are used in this stack to communicate with the highest-level Behavior Tree (BT) navigator through a NavigateToPose
action message. They are also used for the BT navigator to communicate with the subsequent smaller action servers to compute plans, control efforts, and recoveries. Each will have its own unique .action
type in nav2_msgs
for interaction with the servers.
Home Page: NAV 2
Next Page: Lifecycle Nodes and Bond