What is a ros2 service as we did for Ros topics.
Let's start with a real life analogy.
I will make an analogy with an online weather service here.
Again, this is just an analogy.
So the point is to make things simple enough and to focus on understanding ros2 services.
Let's say we have a weather service online which can give us the local weather after we send our location.
Now imagine that you are behind your computer and you want to get the weather from this service.
You on your site are considered as the client and the weather service online is the server.
You will be able to access the server through an HTTP request with a URL.
You can think of the http url as a ros2 service name.
So first of all, your computer will send a request to the server.
The request will contain a message.
Here we send our location and the server will then process the request and send back a response.
The response will also contain a message here.
The requested weather.
Note that in order to communicate, the request sent by the client must be a location, or else the
server will not be able to process the data and the server must send back a weather data.
Otherwise the client will not understand what the response is.
Okay, we have now one client and one server communicating through a service.
But what if we have multiple clients?
Well, that's not a problem.
All the clients will send a request containing a location to the server through the same http url.
The server will then process the requests and send back a response to each client, so you can have
several clients.
However, note that you should not have more than one server for the same service here.
With this example, if we come back to the Ros2 terminology, we have three different computer nodes
and one node for the weather service.
The http url can be seen as a ros2 service name.
The computer nodes each contain a service client.
This service client will call the Ros two service and send a request with a location on the other side.
The weather service contains a Ros to service server, which will process all the requests and send
back a response through the Ros two service.
And again, all clients and the server inside nodes are not aware of each other, they only see up to
the service interface.
Now let's see another example, this time dealing directly with robotics.
This example can be a part of a real Ros two application.
So let's say that you have one node in your application which is controlling an LED panel.
The node is dealing with the hardware to power on and power off the LEDs.
Of course you want this node to be able to communicate with the outside.
For example, other nodes could ask this node to power on or off a specific LED.
In this case, you create a Ros to service that you name.
For example set LED.
Inside the LED panel node.
You will have a service server for this set LED service.
Now you have another node in your application dealing with the battery of a robot.
One of the functionalities is to check if the battery is low and to notify the user.
Let's say that we want to turn on one LED.
To do that, the battery node will contain a service client for the set led service.
Imagine now that the battery is going low.
When it is detected, the battery node will send a request to the Ros2 service.
It will send an LED number and a state.
The server, which is the LED panel node, will expect to receive that information.
If the data structure is the same as expected, the node can process the information and as requested
here, power on the third LED.
Once this is done, the server will send back a response.
The response here will contain a success flag, and during this process, the battery node is waiting
synchronously or asynchronously with a callback upon reception of that success flag.
The battery node knows that the requested action was successfully done or not.
And that's it.
The communication is finished.
The server is still up and waiting for new requests.
Later on, after charging the battery, the battery node detects that the battery is now full again.
It will then decide to send a new request to the set led service to power off the third LED.
The server receives this request, performs the operation, and sends back a success flag.
The communication is done.
All right, that's it.
For this example, you should now have a better idea of what Ros2 services are and when you should use
them.
To recap here, a Ros2 service is a client server system.
It can be either synchronous or asynchronous.
When synchronous, the client will send a request and then block until it receives a response.
When asynchronous, the client will send a request and then register a callback function for the response
and continue its execution.
When the server replies, the callback will be triggered and as you will see later, that's the method
that we will choose.
Also, a service is defined by a name and a pair of messages.
So two messages here.
One message is the request, the other one is the response.
As for nodes and topics, you can directly create service clients and servers inside ros2 nodes using,
for example, the RCL cpp library for Cplusplus and the CLP library for Python.
Finally, and this is an important point, a service server can only exist once, but can have many
clients and basically the service will start to exist when you create the server.
To conclude, you can see that services offer a nice complementarity with topics.
Topics will be used for unidirectional data streams and services will be used when you need a client
server.
Communication.