Services, Actions, and Parameters

The 40-second docking challenge

A mobile robot must reach its dock. The operation takes about 40 seconds. The operator needs progress updates and must be able to cancel if a person blocks the route.

Choose before reading on: topic, service, action, or parameter?

The best answer is an action. Docking is a goal with a lifecycle: accepted, executing, producing feedback, then succeeded, aborted, or canceled. A service is designed for a short request and response—not a long process that may need interruption.

Four interfaces, four jobs

Use this decision rule:

1. Is it a continuing stream of samples? Use a topic.
2. Is it a quick request that returns one answer? Use a service.
3. Is it a long-running goal that needs progress or cancellation? Use an action.
4. Is it configuration that changes how one node behaves? Use a parameter.

Why an action is not just a slow service

A service client usually waits for a server to perform a short computation and reply. ROS 2's official service guidance says services should return quickly and should not be used for long-running work that may need preemption.

An action exposes the lifecycle deliberately:

client -- goal --> action server
client <-- accepted/rejected -- server
client <-- feedback ----------- server
client -- cancel request -----> server   (optional)
client <-- final result -------- server

Feedback answers “how is it going?” A result answers “how did it finish?” Cancellation requests that the server stop the active goal safely. These are different pieces of evidence and should not be collapsed into one delayed response.

Read the goal state, not just the animation

The ROS 2 action design gives every accepted goal a state machine. Active states are ACCEPTED, EXECUTING, and CANCELING. Terminal states are SUCCEEDED, ABORTED, and CANCELED. A rejected goal never enters that state machine.

This separation prevents a common UI mistake: showing “done” immediately after goal acceptance rather than after a terminal result.

Worked robot architecture

Imagine a warehouse robot:

• A lidar node publishes /scan as a topic because measurements arrive continuously and localization plus obstacle avoidance both consume them.
• A localization node offers /reset_odometry as a service because the caller makes one request and expects a quick acknowledgement.
• Navigation exposes /navigate_to_pose as an action because travel takes time, produces progress, and may need cancellation.
• A controller owns max_speed as a parameter because it configures behavior; it is not a stream of drive commands.

A useful boundary test

Ask what happens if the work lasts ten times longer than expected.

• For a service, a long delay leaves the client waiting without a standard progress channel.
• For an action, the client can keep receiving feedback and can request cancellation.

That makes duration, progress, and interruptibility architectural requirements—not implementation details.

Common design mistakes

Streaming sensor data through a service

Repeatedly polling a service for camera frames hides a continuous data stream inside repeated request/response calls. A topic states the true relationship and allows multiple subscribers.

Treating a parameter as a command bus

max_speed=0.5 is configuration. “Drive forward now” is an operational command. Parameters should not disguise time-sensitive commands or event streams.

In ROS 2, each node maintains its own parameters. Values can be provided at startup with --ros-args -p, loaded from YAML, queried, changed, and monitored for parameter events. That machinery makes parameters useful for explicit node settings, but it does not turn them into a replacement for a topic, service, or action.

Assuming availability means success

A discovered service or action server only proves an endpoint exists. Your evidence must still include response semantics, action status, feedback, result code, and robot behavior.

Evidence checklist

Before accepting an interface design, write down:

• frequency: once, occasionally, or continuously;
• expected duration and timeout;
• whether feedback is valuable;
• whether cancellation or preemption is required;
• number of producers and consumers;
• whether the data is configuration or operation;
• observable success and failure evidence.

Retrieval practice

Classify each interaction:

1. A 20 Hz joint-state feed → topic
2. Clear a costmap and report whether the request was accepted → service
3. Move an arm to a pose with percent-complete feedback → action
4. Set the controller's acceleration limit → parameter

Now explain each answer using communication shape—not merely the example name.

Sources and further study

• ROS 2 interfaces: topics, services, and actions — official primary documentation; retrieved 2026-08-19.
• ROS 2 Services — official primary documentation; retrieved 2026-08-19.
• ROS 2 Interfaces — official primary documentation; retrieved 2026-08-19.
• Passing ROS arguments to nodes — official primary documentation for node-owned parameter overrides and YAML loading; retrieved 2026-08-19.
• Monitoring parameter changes — official primary tutorial for observing parameter updates; retrieved 2026-08-19.
• ROS 2 Actions — official primary documentation for long-running goals, feedback, and cancellation; retrieved 2026-08-19.
• ROS 2 action design — primary design specification for goal, result, feedback, and goal states; retrieved 2026-08-19.
• Writing a ROS 2 action server and client — official primary implementation tutorial for goal, cancellation, feedback, and result callbacks; retrieved 2026-08-19.
• Understanding ROS 2 services — official supported-distribution tutorial for service types, endpoint counts, calls, and optional introspection; retrieved 2026-08-19.
• Topics vs Services vs Actions — official supported-distribution design guidance on streams, quick stateless services, and cleanly preemptable goal-scoped actions; retrieved 2026-08-19.
• ROS 2 parameter API design — primary design rationale for node-owned parameters, validation, rejection, lifetime, and atomic updates; retrieved 2026-08-19.

External sources are linked and cited for learning; no third-party text, figures, or footage are republished.