Contents
The publish / subscribe model is a very flexible communication paradigm, but its many-to-many one-way transport is not appropriate for RPC request / reply interactions, which are often required in a distributed system. Request / reply is done via a Service, which is defined by a pair of messages: one for the request and one for the reply. A providing ROS node offers a service under a string name, and a client calls the service by sending the request message and awaiting the reply. Client libraries usually present this interaction to the programmer as if it were a remote procedure call.
Services are defined using srv files, which are compiled into source code by a ROS client library.
A client can make a persistent connection to a service, which enables higher performance at the cost of less robustness to service provider changes.
Service Types
Like topics, services have an associated service type that is the package resource name of the .srv file. As with other ROS filesystem-based types, the service type is the package name the name of the .srv file. For example, my_srvs/srv/PolledImage.srv has the service type my_srvs/PolledImage.
In addition to the service type, services are versioned by an MD5 sum of the .srv file. Nodes can only make service calls if both the service type and MD5 sum match. This ensures that the client and server code were built from a consistent codebase.
Service Tools
rossrv: displays information about .srv data structures. See rossrv for documentation on how to use this tool.
rosservice: lists and queries ROS Services
Client Library Support
Python
See the rospy overview.
C
See the roscpp overview.
Additional Resources
Here are some additional resources contributed by the community:
Video Tutorial
The following video presents a small tutorial explaining the concept of ROS Service
