ROS Service

A ROS Service is a blocking, one-to-one communication pattern. A client node sends a request message to a server node and blocks its execution thread until it receives a reply. This is fundamentally different from the asynchronous, streaming nature of topics.

• Blocking Call: The client's call() or call_async() (followed by spin_until_future_complete) function waits for the server's response.
• Defined Interface: Each service has a single, strictly typed .srv file defining the structure of the request and response messages.
• Use Case: Ideal for remote procedure calls (RPC), performing calculations, querying a database, or triggering a discrete, non-continuous action where an immediate result is required.

The communication contract for a service is defined in a .srv file. This file specifies the exact data types for the request and the response, separated by three dashes (---).

Example (AddTwoInts.srv):

codeCopy
int64 a
int64 b
---
int64 sum

• Top Section (Request): Defines the message the client must send (a and b).
• Bottom Section (Response): Defines the message the server will return (sum).
• Strict Typing: Like ROS messages, .srv definitions use primitive types (e.g., int32, string, bool) or other message types, ensuring data integrity. The ROS build system generates language-specific code (e.g., C++/Python classes) from these files.

The service pattern enforces a clear server-client relationship, unlike the many-to-many topology of topics.

• Service Server: A node that advertises a service by name (e.g., /add_two_ints). It registers a callback function that is executed each time a request is received. This function processes the request data and must return a response message.
• Service Client: A node that creates a client for a specific service name. It populates a request message object and calls the service. There can be multiple clients for a single server.
• Discovery: Using the underlying middleware (e.g., DDS in ROS 2), clients dynamically discover available servers. A client will fail if it attempts to call a service for which no server is currently advertising.

ROS Services fill a specific niche between Topics and Actions in the ROS communication toolbox.

Services are simpler than Actions but lack feedback and preemption capabilities, making them unsuitable for long-duration operations.

ROS Services are employed for discrete operations where a direct answer is needed.

• Configuration & Calibration: A client calls a set_parameters service to configure a sensor node.
• Triggering Operations: save_map, start_recording, or calibrate_imu.
• Querying State: get_plan from a planner, get_transform from TF (though TF2 uses a more efficient system).
• Simple Computations: A centralized calculate_inverse_kinematics service for a manipulator.

ROS 2 Python Example (Client):

pythonCopy
from example_interfaces.srv import AddTwoInts
...
client = node.create_client(AddTwoInts, 'add_two_ints')
req = AddTwoInts.Request()
req.a = 5
req.b = 3
future = client.call_async(req)
rclpy.spin_until_future_complete(node, future)
response = future.result()
node.get_logger().info(f'Sum: {response.sum}') # Output: 'Sum: 8'

In ROS 2, service communication benefits from configurable Quality of Service (QoS) policies, inherited from the underlying DDS layer. These are set when creating the server or client.

Key QoS profiles for services include:

• Reliability: Typically set to RELIABLE (ensure request/response delivery) versus BEST_EFFORT.
• History Depth: For the request queue on the server side.
• Deadline: Optional duration within which the service call should complete.

These policies allow tuning service behavior for different network conditions, making ROS 2 services more robust and suitable for deterministic systems compared to ROS 1 services. The default QoS profile for services is generally reliable, matching the expectation of a guaranteed response.

Services are the standard mechanism for a node to dynamically request configuration data from a central parameter server or another configuration node. This is a core alternative to the parameter server's asynchronous event system.

• Example: A navigation node calls a /get_map service to request the current occupancy grid from a map server before planning a path.
• Key Benefit: The client node blocks until it receives the necessary configuration, ensuring it does not proceed with stale or missing data.

Services are used to trigger a specific, often resource-intensive, computation and return a single result. This is preferred over a continuous topic stream when data is only needed occasionally.

• Example: A /detect_object service where a client sends an image and blocks until the server returns the bounding boxes and classifications.
• Example: A /calculate_inverse_kinematics service for a robotic arm, where the client provides a desired end-effector pose and receives the corresponding joint angles.

Services provide a clean interface for discrete, one-shot commands that change a system's operational mode or state. The client receives immediate confirmation of success or failure.

• Example: A /start_recording or /calibrate_sensor service for a data logging node.
• Example: In ROS 2 Lifecycle Nodes, the ~/change_state service is used to transition a node between its managed states (e.g., Unconfigured → Inactive → Active).

Services are ideal for querying a static or slowly changing dataset, such as a semantic map, a knowledge base, or a task database. The request contains the query parameters, and the response contains the matched records.

• Example: A /query_location service that returns the coordinates of a named landmark (e.g., 'charging_station_1') from a semantic map.
• Key Benefit: The synchronous nature ensures the client has the lookup result before deciding its next action.

Services can be used for health checks and diagnostic queries where a managing node periodically requests status from subordinate nodes. The response contains detailed health information or error codes.

• Example: A /get_diagnostics service that returns the internal status, error logs, and self-test results of a motor controller.
• Contrast with Topics: While diagnostics can be published on a topic, a service allows for on-demand, guaranteed delivery of the latest status snapshot.

In complex workflows, services can act as synchronization points or barriers. A coordinating node can call a series of services on different nodes in sequence, ensuring each step completes before the next begins.

• Example: A pick_and_place sequence: 1) Call /plan_grasp service on the perception node. 2) Call /execute_trajectory service on the arm controller with the result. 3) Call /update_inventory service on the database node.
• Consideration: For long-running tasks with intermediate feedback, the ROS Action protocol is more appropriate.

A ROS Topic is a named, many-to-many communication channel for asynchronous data streaming. Nodes publish messages to a topic, and any number of subscribing nodes can receive them concurrently.

• Asynchronous & Fire-and-Forget: Publishers and subscribers operate independently; a publisher does not wait for subscribers to receive data.
• Primary Use Case: Streaming sensor data (e.g., camera images, LiDAR scans, joint states), commands, and system status.
• Contrast with Service: Topics are for continuous data flow; services are for discrete, synchronous request-response transactions.

A ROS Action is an asynchronous interface for long-running, goal-oriented tasks. It is built on top of topics and provides a client-server model with feedback, preemption, and result reporting.

• Three-Part Communication: The client sends a goal, the server streams periodic feedback, and finally sends a result upon completion or cancellation.
• Primary Use Case: Executing tasks with duration, such as navigating to a pose, performing a complex manipulation sequence, or running a lengthy computation.
• Contrast with Service: Actions are non-blocking and provide intermediate progress updates, whereas a service client blocks until the single response is received.

A ROS Parameter is a configuration value stored on a centralized parameter server (or in a distributed system in ROS 2). Nodes can retrieve, set, and monitor these values at runtime.

• Configuration, Not Communication: Parameters are for system configuration (e.g., controller gains, timeout values, operational modes), not for inter-node data exchange.
• Dynamic Reconfiguration: Nodes can declare parameters and respond to parameter events to update their behavior without restarting.
• Contrast with Service: Parameters provide static or slowly changing configuration; services provide dynamic, on-demand procedural execution.

A ROS Message is a strictly typed data structure used for serialization and deserialization in all ROS communication. Service requests and responses are defined using two message types.

• Data Contract: Defined in .msg files (for topics/actions) or .srv files (for services), messages provide the schema for all transmitted data.
• Primitive and Complex Types: Supports integers, floats, strings, arrays, and nested custom message types.
• Fundamental Dependency: Every ROS Topic, Service, and Action relies on an underlying message definition for data integrity.

A ROS Node is a single executable process that performs computation within the ROS graph. Nodes are the fundamental participants in all communication patterns, including services.

• Modular Unit: A robotic system is composed of many nodes, each responsible for a specific function (e.g., a sensor driver, a planner, a controller).
• Communication Endpoint: A node can be a service client, a service server, a publisher, a subscriber, or any combination thereof.
• Runtime Graph: The collection of running nodes and their connections forms the ROS computation graph, which can be inspected with tools like rqt_graph.

In ROS 2, Quality of Service policies govern the behavior of all communication channels, including services. These are critical for reliable operation in real-time and unreliable networks.

• Key Policies for Services:
  • Reliability: RELIABLE (guaranteed delivery) vs. BEST_EFFORT.
  • Deadline: The maximum expected time between service request and response.
  • Liveliness: How the system determines if a service server is still alive.
• System Tuning: QoS profiles allow developers to match communication semantics to system requirements, from best-effort logging to hard real-time control.