In this lesson, we are going to study another very powerful and useful tool available in Ros two,
which will allow us to develop application more easily, start the execution, control their status
and being notified at the end of their execution.
These are the rescue actions which represent an alternative communication protocol between the rescue
nodes.
In addition to the publisher subscriber protocol used by the Ros2 topics, and in addition to the request
response protocol used by the rescue services actions offered a new communication protocol that we can
define as goal feedback result.
Let me give you a practical example to understand how this communication protocol works and when we
can use it.
Let's say that we have equipped our robot with a camera and we have developed our computer vision algorithm
that uses the camera to detect the position of an object, let's say a pen, so that the robot can grasp
it.
As our good robotic software developer, we organize our application into different nodes, each of
which performs a specific task.
One of these nodes is called pen detector, which simply subscribes to the camera messages to detect
the presence and position of a pen.
Then we develop a second node, the grab pen node, which is responsible for moving the robot to a predefined
position and grasping an object.
We can implement this node so the grab pen as an action server, meaning it acts as a node that handles
the robot movement from its current pose to a desired pose and offers this functionality to all the
other nodes that needs to move the robot to a specific position.
And this includes also our pen detector node.
Once the append position is detected, the pen detector node simply needs to send a goal to the action
server containing the position of the pen to the grab pen node, which then takes care of moving the
robot to the desired position.
Upon receiving the gold message containing the desired pose of the robot, the action server starts
planning a trajectory and moves the robot to reach the desired position.
Since this operation may take some time to complete while the action server performs its functionalities
and moves the robot to the desired position, the pen detector node, namely the action client.
So the one who requested the execution of this server continues with its execution independently from
what the action server is doing and is only notified with some feedback messages about the server progresses
and so on.
So while the robot moves, while the robot approaches its goal, the action server that is managing
its execution continuously sends feedback message to the action client.
Finally, when the robot reaches its goal as requested, the action server sends a result message to
the client to inform about the completion of the action.
This message is also sent by the server to the client, even if the action fails to execute, for example,
due to an obstacle along the robot trajectory.
This communication protocol in addition to the goal feedback and result messages also has a cancel message,
as the name suggests.
This message allows the action client to request the cancellation of a goal that was being executed
by the action server.
So let's still assume that our pen detector node has detected the presence and the position of a pen
using the robot's camera.
And it sends a goal message to the action server asking the robot to move to a specific position and
grab the pen.
The action server starts its execution.
And so it starts the robot's movements.
However, during the execution, the pen detector node realizes that the pen has been removed.
It is no longer in the previous position, so the robot doesn't need to reach that position.
The action has no reason to continue since there is nothing to grasp anymore.
For this reason the action client so depend detector node can send a cancel message to the server.
Upon receiving this message, the action server handle the goal cancellation and then safely stops the
robot.
In any case, regardless of whether the action was cancelled at the action, client requests the grab
a pen node so the action server still sends a result message at the end of the action cancellation to
inform the client whether the cancellation was successful or not.
To summarize in this communication protocol, there are two actors an action server that offers an action,
typically a task with a long execution time and an action client that requests the action execution.
Another example of an action server can be a node that offers the robot navigation from a point A to
point B as an action.
Clearly this is a task that takes more time to complete, so it's preferable to use an action server
rather than using a service to provide such functionality.
Communication through actions begins with the client node requesting the execution of the action offered
by the server with a goal message.
For instance, for the action server implementing the robot navigation.
The goal could be the point, the position that the robot needs to reach.
Upon receiving the goal, the action server starts its functionalities and executes the calculation
and movements needed to make the robot reach the desired pose.
And so it also remains in execution until the goal is reached.
Since completing the action could take some time.
While the client waits for the server to finish its execution, it can continue executing other operations,
other functionalities in this case at regular time intervals.
So during the execution of the goal, the action server can send feedback messages that inform the client
about the progress of the action.
Finally, once the goal is achieved, the action server informs the client about the completion of the
action with our result message.
It may also happen that during the execution so after the client has initiated the server execution
with the goal message upon receiving the first feedback messages, the client may decide to cancel the
execution if is not satisfied, for example, of the partial feedback that is getting.
Upon receiving the cancel message, the action server interrupts its execution and in any case, it
sends back a result message to the client to notify that the action has been correctly cancelled.