Services and Clients in ROS

In ROS2, clients and services enable synchronous communication between nodes. Unlike publishers and subscribers, which facilitate continuous data streams, clients and services are designed for request-response interactions. A client node sends a request to a service, and the service node processes the request and sends back a response. This is ideal for tasks that require specific actions or immediate feedback, such as controlling a robot arm or querying a sensor’s state.

You can check some basic concepts for C++:

https://docs.ros.org/en/foxy/Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.html

and for Python:

https://docs.ros.org/en/foxy/Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.html

1. ROS2 Interfaces

In ROS2, interfaces allow nodes to communicate using predefined data structures. Interfaces come in two forms:

• Messages (msg): Define the structure of data for topics.
• Services (srv): Define request-response interactions for services.

This tutorial uses examples from the robovision_interfaces package to demonstrate creating and using ROS2 interfaces.

Setting Up the Package

Organize the folder structure for your custom interfaces as follows:

robovision_interfaces/
├── CMakeLists.txt
├── package.xml
├── msg/
│   └── ObjectCentroid.msg
└── srv/
    └── GetPointCenter.srv

This folder is at the same level as any new ROS2 package in your project.

Defining a Custom Message: ObjectCentroid.msg

A custom message describes the data structure for topics. The ObjectCentroid.msg defines the centroid coordinates and an array:

float64   x
float64   y
float64   z
float64[] centroid

where

• float64 x, y, z: Represent the 3D coordinates of the centroid.
• float64[] centroid: A dynamic array to store additional data points.

Defining a Custom Service: GetPointCenter.srv

A custom service defines the structure of a request and a response. The GetPointCenter.srv file looks like this:

int64          x
int64          y
---
ObjectCentroid point

where

• Request (int64 x, y): Accepts two integer inputs (e.g., pixel coordinates).
• Response (ObjectCentroid point): Returns the computed centroid as an ObjectCentroid message.

The --- separates the request and response parts of the service definition. Notice that, if the message is defined in the same package, the package name does not appear in the service or message definition. If the message is defined elsewhere, we have to specify it, e.g. robovision_interfaces/msg/ObjectCentroid point.

Integrating the Interfaces into the Build System

Update the CMakeLists.txt to include the message and service definitions:

find_package(rosidl_default_generators REQUIRED)

rosidl_generate_interfaces(${PROJECT_NAME}
  "msg/ObjectCentroid.msg"
  "srv/GetPointCenter.srv"
)

ament_export_dependencies(rosidl_default_runtime)

and update the package.xml to declare dependencies:

<build_depend>rosidl_default_generators</build_depend>
<exec_depend>rosidl_default_runtime</exec_depend>

2. ROS Service

The main difference between a topic and a service is that, while a topic is working, a service works under request (that might save resources).

Let’s compare our “rgbd_reader” and our “robovision_service” files (both in C++ and Python). They are very similar! We have two main changes. First, we don’t have a publisher, as it sends a response under request. Second, we don’t have a timer, as it is not working indefinitely. Instead, we create a ROS2 service that enters a callback function when we call the service. In Python it is

File truncated at 100 lines see the full file