ROS 2 Services and Actions: Requests, Feedback and Results

Robot software often needs one component to ask another to do work. In ROS 2, “service” and “action” are names for different communication patterns, not interchangeable labels for a physical robot function. Understanding the expected duration, response and feedback of a task can make a software description much clearer.

A service is a request and a response

The ROS 2 Jazzy service concepts documentation describes a service as a remote procedure call: a client sends a request to a server, which performs a computation and returns a response. The documentation says services are expected to return quickly because a client generally waits for the result.

A service description should identify the service name, the request fields, the response fields and the component expected to provide it. It is also useful to record the ROS 2 version and the source of the interface definition. A service name that resembles a topic name does not turn the service into a topic; the documentation describes them in different namespaces.

An action represents a longer-running goal

The ROS 2 Jazzy action concepts documentation describes actions as long-running remote procedure calls with feedback and the ability to request cancellation or preemption. An action has a client and a server; the server handles a goal, provides feedback as it progresses and returns a result according to the interface and implementation.

The official example uses a navigation task to illustrate why feedback can matter while work is underway. That example is a software concept, not a guarantee that a particular physical robot can safely navigate or stop in every environment. Actual behaviour depends on the implementation, configuration and the wider safety system.

Compare the information available during work

In a service interaction, a reviewer normally looks for the request and the returned response. In an action interaction, the interface also includes feedback associated with a goal and a way to request cancellation. A request to cancel is not itself proof that a physical device has reached a safe state; the application must be assessed using its own documented behaviour and appropriate safety processes.

Consider a hypothetical training exercise that computes a small arithmetic result and another that tracks a longer simulated task. A learner can inspect which interaction pattern the example uses and what information it exposes while running. This example does not prescribe a controller architecture or claim that a specific device uses ROS 2.

Keep interface design separate from hardware claims

A service or action definition describes data exchanged by software components. It does not, by itself, establish a robot’s speed, payload, accuracy, approval status or physical safety. An action named after a motion does not prove that a real robot executed that motion, and a response indicating a result must be interpreted according to the actual interface.

For a documentation review, list the interface name, type, field definitions, source version and the component responsible for the server. Identify any assumptions about timeouts, feedback and cancellation from the implementation’s documentation. If those details are missing, mark them for follow-up instead of guessing from the name of the interface.

Record what an example actually demonstrates

A tutorial may use simulated data or a small calculation to show how an interaction is structured. Record the environment, software version, example name and observed output. Distinguish a goal being sent, feedback being observed and a final result being received. If the example fails or does not provide a piece of information, note that explicitly rather than reconstructing it from an expected outcome.

Do not try to validate cancellation or exceptional behaviour on a physical machine merely by following a vocabulary article. Such testing needs a suitable environment, authorised personnel, equipment-specific documentation and the applicable safety procedure. Classroom examples can help explain terminology without serving as acceptance tests for deployed systems.

Use the terms consistently in a glossary

A useful glossary entry links each term to its source and states which software version the explanation covers. It can then distinguish service clients and servers from action clients and servers, and explain the roles of requests, responses, goals, feedback and results without claiming that all systems implement them identically. If a project uses a custom interface, preserve a link to its own definition and describe any project-specific interpretation separately from the general ROS 2 terminology.

For related terminology, read the site’s guide to robots, nodes, topics and frames. The industry information section offers further background. Before using an interface in a real project, consult the documentation and implementation for that project’s actual ROS 2 version.