After learning a little bit about ROS, you now have this question in mind: what is a ROS service ? As I did for ROS topics, let’s start with a real life analogy.
I will use an analogy with a weather service online. The analogy may not be 100% accurate but the point is to make it simple enough to focus on understanding ROS services. After this example, I’ll show you a more “robotic” application, with a battery and a LED panel, which can be a part of a real ROS application.
This post is a part of the What is ROS? series.
>> As an additional resource to this article I’ve also made a video explanation, with a slightly different approach. To get the most benefits, read the article and also watch the video.
After watching the video, subscribe to the Robotics Back-End Youtube channel so you don’t miss the next tutorials!
You are learning ROS?
Check out ROS For Beginners and learn ROS step by step.
Table of Contents
Our first ROS service
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 side, 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. Think as the HTTP URL as a ROS service.
First of all, your computer will send a request to the server. The request will contain a message, in this case your location. The server will then process the request, and send a response. The response will also contain a message.
Note that, in order to communicate, the request sent by the client must be a location, or else the server won’t be able to process the data. And the server must send back a weather, otherwise the client will not understand what is the response.
Multiple clients for one service
OK, we now have one client and one server communicating through a ROS service.
But, what if we have multiple clients? Well, that’s not a problem, all clients will send a request containing a location to the server, through the HTTP URL. The server will then process the requests and send back a response to each client. Note that you should not have more than one server for the same service.
As you can see, in this example we have 3 different computer nodes, and one node for the weather service. The HTTP URL can be seen as a ROS service.
The computer nodes contain a service client. This service client will call the ROS service and send a request with a location.
On the other side, the weather service contains a ROS service server which will process all requests and send back a response through the ROS service.
Again, all clients and the server inside nodes are not aware of each other. They only see up to the ROS service interface.
A more robotic example
Now, let’s see another example, this time dealing directly with robotics. This example can be a part of a real ROS application.
So, let’s say that you have one node in your application which is controlling a 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 other ROS nodes. For example, other nodes could ask this node to power on or off a specific LED.
In this case, you create a ROS service, named “Set Led”. Inside the Led panel node, you create a service server for this ROS service.
Now, you have another node dealing with the battery. One of the functionality is to check if the battery is low, and to notify the user when it’s happening. To do that, the battery node will contain a service client for the “Set Led” Service.
Imagine that the battery is going low. When it’s detected, the battery node will send a request to the ROS service. It will send a 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, power ON the third LED.
Once this is done, the server will send back a response. This response here, will contain a success flag. During all the ROS service process, the battery node is waiting. Upon reception of this success flag, the battery node knows that the action requested was successfully done.
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. 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 the example. You should have now a better ideas of what are ROS services, and when you should use them.
Wrapping things up – What is a ROS service ?
A ROS service is a client/server system.
Here are some of the main characteristics of a ROS service:
- It is synchronous. The client sends a requests, and blocks until it receives a response.
- You should use ROS services only for computations and quick actions. For example the client will send some data, and receive another piece of data, just like we saw with the weather service. You can also use a service for quick actions, for example if you want to enable or disable an actuator, or any immediate action. As the service call is blocking, you don’t want your client to be stuck for too long.
- A service is defined by a name, and a pair of messages. One message is the request, one message is the response. You must respect the format of the data on both side of the communication.
- As for nodes and topics, you can directly create service clients and servers inside ROS nodes, using for example the rosccp library for c++ and the rospy 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 be created when you create the server.
To conclude, you can see that ROS services complements topics well.
Topics will be used for unidirectional data streams, and services will be used when you need a client/server architecture.