ROS 2 service

ROS 2 service – definition

A ROS 2 service is a request-response communication mechanism used when one ROS 2 node needs another node to perform a discrete operation and return a result. A service client sends a request. A service server receives it, executes a callback, and returns a response defined by the service interface.

Services are suitable for operations that have a clear completion point. Typical examples on a mobile UGV include resetting odometry, reading a hardware diagnostic state, switching a sensor configuration, saving a map, or requesting a robot subsystem to enter a defined mode. ROS 2 services are not intended for continuous telemetry, high-rate sensor streams, or long-running autonomous tasks.

In ROS 2, a service type can be defined in a .srv file with a request section and a response section separated by ---. ROS interface definitions are processed by the ROS build system and ROS interface definition tools to generate language-specific client and server code. The concept is documented in the official ROS 2 services documentation.

How ROS 2 services work

A ROS 2 service follows a client-server pattern. A node can expose one service server, multiple services, service clients, or a combination of both. For a request to be handled, a client and server must use the same service name and type; ROS 2 discovery enables them to find one another.

The basic data flow is as follows:

A client creates a request using the service request message definition.
The ROS 2 middleware transports the request to an available server.
The server callback processes the request.
The server creates a response message.
The client receives the response or the application stops waiting after its configured timeout.

ROS 2 uses a middleware abstraction layer called rmw. Most standard ROS 2 distributions use DDS-based middleware implementations, such as Fast DDS or Cyclone DDS. The exact wire-level implementation of services depends on the selected ROS middleware, while the application-level API remains consistent across supported client libraries such as rclcpp and rclpy.

Services usually use reliable communication because a request such as resetting a localization estimate should not be silently lost. ROS 2 defines standard quality-of-service profiles for services. The default service QoS profile is designed for request-response communication and is described in the ROS 2 QoS documentation.

Service interface structure

A service definition contains one request message and one response message. The request expresses the operation to perform. The response communicates whether the operation was completed and can include output values, status data, or diagnostic information.

# ResetOdometry.srv
bool reset_pose
---
bool success
string message

This example could be used by a UGV base controller. A navigation or diagnostic node sends reset_pose: true. The motor or localization subsystem then returns a result indicating whether its odometry state was reset.

After building a ROS 2 package that contains the interface, the service can be inspected from the command line.

ros2 interface show my_robot_interfaces/srv/ResetOdometry
ros2 service list
ros2 service type /reset_odometry
ros2 service call /reset_odometry my_robot_interfaces/srv/ResetOdometry "{reset_pose: true}"

Services, topics, and actions

ROS 2 provides three primary communication patterns. Selecting the wrong pattern can cause unnecessary blocking, weak observability, or poor behaviour under unreliable network conditions.

ROS 2 mechanism	Communication model	Typical UGV use
Topic	Publish-subscribe data stream	LiDAR scans, IMU data, wheel odometry, camera images, battery state
Service	Short request-response operation	Reset odometry, clear a costmap, query hardware status, trigger calibration
Action	Goal, feedback, result, cancellation	Navigate to a pose, perform a long inspection route, execute mapping

A service should not be used for a task that may take an unknown or extended amount of time. For example, a command to drive Leo Rover to a waypoint should normally be implemented as a ROS 2 action because the caller may need progress feedback and cancellation. The Nav2 stack uses actions for navigation goals and provides services for selected lifecycle and management operations.

ROS 2 services on Leo Rover and Raph Rover

Leo Rover can be integrated with ROS 2 and uses a differential-drive mobile base. In this context, services commonly connect higher-level autonomy software with base-controller, localization, sensor, or diagnostic nodes. Leo Rover does not provide autonomous navigation by default. A navigation stack, sensor drivers, transforms, maps, and safety logic must be integrated separately.

Useful service endpoints on a Leo Rover deployment may include the following:

/reset_odometry for resetting a wheel-odometry estimate after a controlled initialization procedure.
/set_camera_profile for changing a depth camera mode before a mapping run.
/save_map for persisting a map generated by a SLAM node.
/get_robot_diagnostics for returning voltage, motor-driver state, temperature, or communication status.

Raph Rover can use the same ROS 2 service architecture when configured for ROS 2 and when a project requires additional payload capacity for sensors, onboard computing, or inspection equipment. The service interface should remain hardware-neutral where possible. For example, a service that starts a payload sensor should expose an abstract request such as an operating mode rather than a board-specific register value.

Implementation considerations for mobile robots

Service callbacks run inside a ROS 2 executor. A blocking callback can delay other callbacks handled by the same executor, including safety-relevant state updates or sensor processing. Long operations should therefore be implemented as actions, state machines, or asynchronous workflows.

Service calls also require explicit failure handling. A client may fail because the server is unavailable, the request cannot be processed, the response exceeds an application timeout, or the robot is in an invalid operating state. A robust response should include a success flag and a machine-readable error code where required.

reset_odometry_client:
  ros__parameters:
    service_name: /reset_odometry
    timeout_sec: 2.0
    retry_count: 1

The timeout in this example is an application parameter, not a universal ROS 2 requirement. Its value must be selected according to the expected callback duration, compute load, network topology, and safety requirements of the UGV deployment.

Normative references and documentation

ROS 2 service behaviour should be interpreted using the ROS 2 design and interface documentation rather than ROS 1 assumptions. ROS 1 also provides services, but ROS 2 uses a different client library architecture, DDS-based middleware abstraction, discovery model, and QoS system.