In this lecture, we will learn about the basic idea behind ROS services, that allow for a “request-response” communication between ROS nodes.

Summary:

So far, communications between nodes have been handled by topics. Topics can connect many nodes to many other other nodes. There are no acknowledgements between the nodes: they are simply pumping around information. This is very useful when monitoring certain values, but can become problematic with some types of information such as video data. In cases like those, it would be nice to only receive information when requested.

ROS services implement these request-response type of communications. They consist of two message types: One for requesting data, and one for the response. These services are the gateway to event-based ROS executions. Services are defined in the same package as messages, in their own /srv folder.
The nomenclature for ROS services: One ROS node is the service server. It advertises a service, and makes it available to other nodes. Another node is the service client. It sends a request message to the service server once the service is available.

Example

A useful example of a ROS service could be a service that converts measurements in metres to measurements in imperial feet. The request message would contain the measurement in metres, and the response would contain the measurement in imperial feet plus a boolean value indicating the conversion was successful.  We would create the file hrwros_msgs/srv/ConvertMetresToFeet.srv:

One important quality of services is that they are blocking: They stop the execution of program flow until the response has been received. This is useful for sequential behaviours. It also makes it desirable to have quickly executable computations for the service callback, so that the program is blocked for the least amount of time. There is also no going back on a service call: Once a request has been made, it will be processed until a response is sent. It can’t be interrupted.