Another essential feature implemented by an operating system is the management and the communication
between processes, enabling different processes often executed in parallel to exchange messages and
information.
In Russia.
These processes are called nodes where a node is simply an application that performs a specific functionality.
For example, a node could be a mobile robot application that plans a path to a goal while avoiding
obstacles.
This node may require information processed in other nodes such as obstacle detection.
Communication between two nodes in ros2 can occur in three different ways using three different communication
protocols.
The first mode is through topics using the publisher subscriber communication protocol.
In this communication protocol, a node also known as publisher, publish a message within a topic which
acts as a channel in the same channel.
Another node known as subscriber can listen and so can receive all the messages that are transmitted
within that channel.
Multiple nodes can subscribe to the same channel simultaneously as several applications.
Might be interested in the data transmitted within the channel.
Moreover, within the same channel, multiple applications can also send messages.
There is no limit to the number of channels that can be created as long as each channel is identified
by an unique name.
For instance, a node can publish within two topics or two channels, while another node can listen
and receive messages that are transmitted in both channels.
Furthermore, a node is not limited to being only a publisher or a subscriber, but can fulfil both
roles simultaneously.
A node can be, for example, interested in data transmitted within a channel, then process it and
then republish the processed result in a separate channel in a separate topic.
The second communication protocol that is available in Ros two for Inter-process communication is through
services.
In this communication protocols.
There are two actors involved, a service server.
So that is a node that offers a functionality as a service client.
That is another node that requests the functionalities provided by the server.
For example, a service server node can offer the functionality for the calculation of an integral.
And so any other node that requires to calculate the integral instead of implementing the logic and
the code can instead directly call the server.
The communication begins when the client node sends a request to the server that is offering this functionality
by sending a request message.
The service server upon receiving a request, process it, and performs the necessary calculation to
respond to the request.
For example, in this case calculating the requested integral.
While the server processes the request, the client can continue its execution and, for example, may
perform other operation while he's waiting for the server to complete the request.
And so to return a response.
Once the server completes its processing, it sends back a response message containing the result back
to the client, who can then use this information and continue with its execution.
The third and last communication protocol for Inter-node communication that is available in Ros2 is
through actions.
In this communication protocol, the actors are again two nodes, an action server that offers an action,
and this is typically a long running task and an action client that requests the action execution.
Despite its similarity to the services action communication differs in the type of the functionality
provided by the server to the client.
As we have seen, our service server can offer functionalities like calculating an integral, which
has a relatively quick execution time.
Conversely, an action server may offer a navigation service for a robot from a point A to point B,
which is clearly a more time consuming task.
Thus, it is preferable to use an action server to implement such functionalities rather than a service
server.
Communication through actions begins when the client node requests the execution of the action offered
by the server by sending a goal message.
For example, if in this case the action server is offering a robot navigation functionality, the goal
can be the desired position or the destination that the robot needs to reach.
Upon receiving the goal, the action server initiates its functionalities, performing all the necessary
calculations and movements to guide the robot to the desired position, and it remains in the execution
until the goal is achieved.
Since to complete this action might take some time.
The client node can continue executing other operations while waiting for the server to complete its
execution.
In this case, unlike services, the action server periodically sends feedback messages to the client,
informing it about the progress of the action while it's being executed.
Finally, once the goal is achieved, the action server notifies the client of the completion of its
execution by sending a result message.
During the action execution.
So after the client has initiated the server execution with the goal message, upon receiving the initial
feedback messages, the client may decide to cancel the action if it is not satisfied with the partial
feedback or if the goal, for example, has changed.
This is achieved by sending a cancel message from the action client to the action server.
Anyway, upon receiving the cancel message, the action server interrupts its execution and returns
a result message to the client, indicating that the action has been successfully aborted.