ROS 2 topics, services, and actions: choose the right exchange

ROS 2 topics, services, and actions support different exchanges between robot components. Odometry needs a stream, a quick reset needs a response, and navigation needs a goal with progress and an outcome. Choosing by that need makes an interface easier to use and inspect.

This illustrated lesson follows the ROS 2 Jazzy documentation and the ROS 2 action design. The traces are invented teaching examples. They describe communication semantics without requiring a ROS installation or claiming a hardware test.

Choose the communication pattern

A ROS node participates in the robot’s software system. It can publish data, subscribe to data, offer services, or handle action goals. One node can use several of these interfaces.

Need	Pattern	Example
Share successive observations or state estimates	Topic	Publish odometry samples
Ask for a short operation and receive its response	Service	Reset a diagnostic counter
Request ongoing work with progress, a result, and a cancellation protocol	Action	Navigate to a waypoint

Duration helps identify the choice, but the exchange matters too. A request that needs progress reports and cancellation benefits from an action even when it sometimes finishes quickly. ROS 2’s Jazzy action documentation uses navigation to a waypoint as an example.

Read the three exchanges

Read each panel from top to bottom. The left and right columns identify participants, and arrows show the direction of each message. Their spacing has no timing meaning.

Three communication patterns

Choose the exchange your task needs

Read each panel downward. Arrows show message direction; spacing does not measure elapsed time.

Topic: a stream of odometry samples

Service: one reset request and response

Action: a navigation goal with cancellation

The labels R7 and G42 help follow the examples. R7 names one service request for the reader; it is not a required field in the request payload. G42 abbreviates a real action goal’s UUID, which the action client generates.

Stream odometry on a topic

A topic connects publishers to subscribers. A publisher sends typed messages on a named topic, and several subscribers can consume that stream. Publishing does not require an application-level response from each subscriber. See the Jazzy topic documentation.

For a mobile cart, odometry updates can feed an estimator and a logger. The wheel-odometry lesson explains how wheel motion produces an estimate. Publishing that estimate leaves its measurement errors intact.

Consider three simplified samples with measurement timestamps and estimated x position. All positions use the same frame, and times share one clock:

Measurement time (s)	Estimated x (m)
0.0	1.00
0.1	1.02
0.2	1.04

Across the first and last samples, the average estimated speed is (1.04 − 1.00) / (0.2 − 0.0) = 0.20 m/s. That calculation uses measurement times. Message arrival times can differ because transport and processing take time.

These are selected teaching fields, not a complete odometry message definition. A useful interface must also specify its coordinate frames and data types. An estimate can support SLAM without becoming ground truth.

Use a service for a short reset

A service client sends a typed request to a named service. Its server performs the operation and returns the corresponding typed response. The Jazzy service documentation recommends operations that finish quickly.

Suppose request R7 asks a diagnostic node to clear its dropped-frame counter. Our invented interface has an empty request and a response containing a Boolean success and a string message. The server clears the counter, then replies success = true with an explanation.

A service call can be asynchronous. The client receives a future representing a pending response and can continue other work. Jazzy’s service-client guide explains this behavior and the risks of blocking calls.

Asynchronous calling changes how the client waits. It does not add per-request progress feedback or the action cancellation protocol. A long navigation task needs more than a final reset-style response.

Track navigation with an action

An action client submits a goal. The server decides whether to accept it, can send task-specific feedback, and supplies a result when that goal ends. In our navigation example, feedback might report remaining distance.

The action interface separates goal, result, and feedback data. A goal could specify a destination pose; a result could describe the final outcome. The Jazzy action documentation explains this structure.

Accepting a goal does not mean achieving it. The client can request the result after acceptance and wait asynchronously while feedback arrives. ROS 2 implements actions using services and topics, according to its action design.

Keep feedback data separate from goal status. “1.2 meters remaining” is an application-specific progress report. EXECUTING names the goal’s lifecycle state; neither establishes that the robot reached the destination.

Separate canceling from canceled

An action client can request cancellation. The server can reject that request. If it accepts cancellation for a goal, that goal enters CANCELING, an active state that allows cancellation work to continue.

The Jazzy CancelGoal interface returns a status code and a list of goals entering CANCELING. The later terminal state CANCELED reports completion of cancellation. A goal that already reached a terminal state cannot begin cancellation.

The goal-status definition distinguishes these outcomes:

• SUCCEEDED: the server reports that the goal succeeded.
• ABORTED: the server ended the goal without an external cancellation request.
• CANCELED: the goal ended following a client’s cancellation request.

An accepted cancellation request is not an emergency-stop guarantee. The protocol does not specify physical stopping distance or a safety-rated stop. Those properties depend on the robot’s controller, actuators, and safety design.

Follow one goal through cancellation

Here is one valid, invented navigation exchange. The destination lies at x = 2.0 m in a chosen map frame; omitted pose fields and application details keep the trace short. G42 refers to the same goal throughout.

Event	Participant	Meaning
1	Client sends goal G42	Request navigation to the destination
2	Server accepts G42	Goal enters ACCEPTED; it has not finished
3	Client requests the result for G42	Result request remains pending
4	Server begins execution	Goal enters EXECUTING
5	Server sends feedback for G42	Example remaining distance: 1.2 m
6	Client requests cancellation of G42	This request alone does not change the server’s goal state
7	Server accepts cancellation	Response includes G42 among goals entering CANCELING
8	Server completes cancellation work	Goal reaches terminal state CANCELED
9	Server answers the pending result request	Final status is CANCELED, with this action’s result data

The accepted-goal state sequence is:

ACCEPTED → EXECUTING → CANCELING → CANCELED

This trace follows the ROS 2 action state machine. Other valid exchanges can reject the goal or finish with a different terminal state. A server that rejects a goal never starts its accepted-goal state machine.

An odometry topic can keep publishing throughout these events. Those samples describe estimated motion, while the action messages describe one task. Completing an action does not shut down every topic on the robot.

Check delivery and physical meaning

Naming a topic does not guarantee that every subscriber receives every sample. ROS 2 quality of service, or QoS, controls policies such as reliability, queue history, and durability. Incompatible publisher and subscriber settings can prevent communication, as the Jazzy QoS documentation explains.

To diagnose that failure with real ROS commands, follow the ROS 2 QoS tutorial. It reproduces a reliability mismatch, inspects both endpoints, and restores delivery in a tested Jazzy container.

Best-effort delivery can lose samples. Reliable delivery includes retry behavior, but a useful robot system must still account for age, resource limits, disconnections, and processing delays. A message’s arrival also does not prove that its estimate or command is correct.

For each interface, check the payload’s units and frame, the meaning of its timestamp, and what its response establishes. A navigation result reports the server’s outcome under its success conditions. Physical accuracy still depends on sensing and control.

The feedback-control lesson shows why a controller can track a biased measurement. The physical-AI loop places communication alongside perception, estimation, planning, and actuation.

To inspect a stream after its source stops, follow the ROS 2 bag tutorial. It records six stamped points, verifies the saved fields, and shows how messages can arrive while a simulated clock remains uninitialized.

Try two interface decisions

Exercise 1: Choose the exchange. A dashboard needs repeated battery readings. An operator needs to clear a diagnostic counter and learn whether the reset succeeded. A robot needs to inspect ten waypoints, report progress, and accept cancellation requests. Choose a pattern for each and explain what the caller receives.

Check the three choices

Use a topic for successive battery readings. Use a service for the short counter reset and its response. Use an action for the inspection goal, progress feedback, final result, and cancellation protocol.

The inspection server still decides whether to accept a particular cancellation request. The client must inspect the later outcome; sending the request alone does not establish completion.

Exercise 2: Read an incomplete log. A log ends after event 7 in the navigation trace. Can you conclude that G42 is canceled, the robot has stopped, or the destination is reached? What further evidence would answer each question?

Check the lifecycle and physical evidence

Event 7 establishes CANCELING for G42. A later terminal status or result establishes whether cancellation completed. Measured motion provides evidence about stopping, and a position check against the destination tolerance provides evidence about arrival.

None of those physical conclusions follows from cancellation acceptance alone. Even a terminal action result needs the application’s documented meaning and suitable measurements behind it.

An action interface describes a goal exchange without deciding who plans the motion or handles a failure. Follow those responsibilities in robot autonomy and teleoperation.

For a concrete sensor stream, inspect a 2D LiDAR scan. Its range values need angles, coordinate frames, return-status rules, and acquisition times before another node can interpret them.

To turn these interface decisions into a portfolio exercise, build a small ROS 2 system and keep a log that reproduces one communication failure and its fix. The robotics career roadmap places that kind of inspectable software project within a broader learning path.

Sources and further study

The documentation links below point to the official Jazzy branch sources, checked October 11, 2026.

• ROS 2 Jazzy: Topics describes typed publish/subscribe communication.
• ROS 2 Jazzy: Services and asynchronous service clients explain requests, responses, and how a client waits.
• ROS 2 Jazzy: Actions explains long-running goals with feedback.
• ROS 2 action design, last modified May 2020, specifies goal IDs, the state machine, and the services and topics behind an action.
• Jazzy GoalStatus and CancelGoal define lifecycle states and cancellation responses.
• ROS 2 Jazzy: QoS settings explains delivery policies and compatibility.

Continue to wheel odometry to examine how the estimates inside those streamed samples accumulate error.