ROS 2 is the second generation of the Robot Operating System, a modular framework of freely available robot software, rebuilt because ROS 1 lacked production-grade featuresSource 7. Lyrical Luth, the current long-term-support release, shipped on 22 May 2026 and is supported until May 2031Source 1 Source 8.

A white two-armed PR2 robot with raised grippers stands at a Maker Faire booth under banners for PR2, TurtleBot and ROS.
A Willow Garage PR2 under the ROS banner at Maker Faire 2011. Willow Garage developed ROS alongside this robot, and ROS 2 is its rebuild for production use.
Photo: Timothy Vollmer / Wikimedia Commons. Licence: CC BY 2.0.

Self-check

A fetch task takes 30 seconds, reports progress and may need cancelling. Which ROS 2 interface fits?
Read the reasoning
  • Publish the request repeatedly on a topicTopics fit continuous streams. This task needs acceptance, feedback, completion and cancellation semantics.
  • Block on a service call until it finishesServices are intended for short request-response operations. A long task needs feedback and preemption without holding a synchronous request open.
  • Use a ROS action: goal, feedback, result and cancellationActions model long-running, preemptible work. The client can observe progress and cancel while the server owns execution.

Topics stream, services answer short requests, and actions manage long-running goals with feedback and cancellation.

The graph: nodes and typed interfaces

A node is one participant, such as a camera driver, policy server or controller bridge. Nodes talk through topics for continuous streams, services for short request-response calls, and actions for long-running goals with feedback, cancellation and a resultSource 2. A geometry_msgs/PoseStamped carries the timestamp and frame a bare array lacks, and REP 103 puts ROS on SI unitsSource 9.

ROS 2 interfaces
Nodes stream, ask, or run a job
Way of talking
Lit: the message just sent; task manager at left, fetch skill at rightAction · Progress updates; it can be cancelled

Schematic; node names are examples

Use a stream for sensor data, a question for quick answers, an action for long tasks.
How this was made
In ROS 2, nodes talk through topics for continuous streams, services for short request and response calls, and actions for long-running goals with feedback, cancellation and a result. The node names are examples: a camera driver publishes pictures on a topic, a policy server asks a gripper driver a yes-or-no question as a service, and a task manager sends a 30-second fetch job as an action.
The bench is a schematic: the cabinet at the left is the node that starts the exchange, the one at the right the node that answers. The conveyor in front carries a stream of pictures and brings nothing back; the duct in the middle carries a question capsule over and an answer capsule back; the shuttle at the back carries a job out while the three flags on the left cabinet rise, two for progress updates and the last for the result, and the lever on its front can cancel the job.

Through an action, the task manager and the fetch skill exchange 4 messages: a goal, progress updates and a result, and it can be cancelled. A topic carries 4 pictures one way, a service 2 messages and an action 4.

The messages each way of talking sends
way of talkingmessages, in orderreply
Topicpicture; picture; picture; picturenone
ServiceIs the gripper closed?; Yesone answer
ActionGoal: fetch the cup; Progress: 30%; Progress: 60%; Done: cup fetchedprogress, then a result
ROS 2 Project 2026.

QoS is part of the model input

ROS 2 inherits Quality of Service (QoS) from DDSSource 10. The default profile keeps the last 10 messages and delivers reliably, while the sensor-data profile uses best effort and a smaller queue, because timely readings matter more than complete ones; lifespan silently drops messages older than its limit, and endpoints with incompatible policies never connectSource 3.

End-to-end latency depends strongly on the DDS implementation, and ROS 2 can add 50% over raw DDSSource 11. Since Kilted Kaiju (May 2025), Zenoh's rmw_zenoh_cpp is a Tier 1 middlewareSource 12.

Quality of Service
Deep queues feed the robot old pictures
Queue keeps
Lit: the picture the model is handedLast 10 pictures · the model gets one 0.33 seconds old

Illustrative camera rate

A deep queue hands the model old pictures first, so log each picture's age at the model.
How this was made
The ROS 2 default Quality of Service profile keeps the last 10 messages and delivers them reliably, in order. The sensor-data profile uses best effort and a smaller queue, because a fresh reading matters more than a complete one. When the camera sends pictures faster than the model can use them, a reliable queue of 10 stays full, and the model is always handed the oldest of the 10.
The figure assumes a camera sending 30 pictures a second and a model slower than that, both illustrative, so the picture used is the queue depth divided by 30 seconds old. Log message age at the policy boundary to catch it.
The bench is illustrative: the camera drops each picture as a card into the slot it stands over, an indexer moves the row one slot toward the model per camera frame, and the model's gantry lifts the oldest card out. The camera stands as many slots from the model as the queue keeps pictures, so its pointer reads the age on the scale, one tick a frame and a long tick every tenth of a second. Running, the bench is slowed about 70 times.

With a camera queue that keeps the last 10 pictures and a camera sending 30 pictures a second, the model acts on a picture 0.33 seconds old; the age equals queue depth over the camera rate.

How old the picture the model uses is
queue keepsage of the picture used (seconds)
Last 100.33
Newest only0.03
Queue default: ROS 2 Project 2026.

Time and synchronization

Camera, depth, joint and force streams arrive at different rates, so inputs need acquisition and arrival timestamps. MCAP records a publish time and a log time for every messageSource 13.

Logging source, receipt and inference-completion times splits latency into sensing, transport, model execution and command delivery; ros2_tracing does it at an average overhead of 0.0033 ms per messageSource 14. With use_sim_time set, ROS time follows the latest /clock messageSource 15, so nodes that mix it with wall time see spurious timeouts. The calibration guide covers spatial and temporal alignment.

tf2: the coordinate-frame graph

tf2 keeps a time-buffered tree of coordinate frames and transforms data between any two frames at any timeSource 16. A lookup at an image timestamp can wait for the transform; the tf2 tutorial raises an exception only if it is still missing after a 50 ms timeoutSource 17.

REP 105 defines odom as a drifting short-term reference and map as a frame whose poses can jumpSource 18, and camera optical frames take an _optical suffix and a different axis conventionSource 9. A policy trained on base-frame end-effector deltas cannot be sent tool-frame deltas in the same layout; Modern Robotics covers the geometrySource 6.

URDF, robot state and MoveIt

URDF, the most common robot-description formatSource 19, lists links, joints, geometry and limits, and robot_state_publisher combines it with joint states to publish the frame tree. MoveIt 2's Planning Scene combines robot state, model and world geometry for kinematics, constraint and collision checksSource 4, so a learned policy can use it to plan or check collision-free motion.

rosbag2 is the experiment record

rosbag2 records timestamped messages for replay, in MCAP by default since Iron IrwiniSource 20, and since Kilted it can replay in publication order instead of receipt orderSource 12. Learning pipelines convert bags to episode formats such as RLDSSource 21.

A production policy layout

A learned-policy graph can separate drivers, state assembly, a policy server, a command gate, a controller bridge and a supervisor. The supervisor can drive ROS 2 managed nodes, which leave a primary state only on an external request or an errorSource 22. Inference stays outside the hard real-time loop unless its worst case fits, and ROS 2's real-time guidance keeps page faults, dynamic allocation and blocking synchronization out of that pathSource 23. Lyrical's EventsCBGExecutor cuts executor CPU overhead, but its event queue is unboundedSource 24.

ROS 2 software layout
The AI's moves pass a safety check first
camera and joint sensorsgathers the latest readingsAI that suggests movessafety checkdrives the motorsrobot armsuggested moveschecked moves onlyEvery suggestedmove is checkedhere first
what the robot sensesmoves

Schematic: one recommended layout, not a required one

Separate parts let engineers test, stop or swap the AI without touching what moves the robot.
How this was made
One robust layout for a learned-policy graph, as the article recommends: drivers, state assembly, a policy server, a command gate, a controller bridge and a supervisor, each its own node. The drawing names them in plain words: "camera and joint sensors" is the camera and joint drivers; "gathers the latest readings" is the state assembly; "AI that suggests moves" is the policy server; "safety check" is the command gate; "drives the motors" is the controller bridge; "robot arm" is the robot hardware. It leaves out two parts to keep the chain to the motors in view: the supervisor, a "task manager", and the tf2 frame tree, a "arm positions". Each link below says in plain words what it carries, then names its ROS 2 interface, its QoS or timing, and its source.
  • The task manager (the supervisor) takes the task request. Task request to the supervisor, as an action: a long-running goal with feedback, cancellation and a result. Source: ROS 2 Project 2026.
  • Camera pictures and joint positions; late readings may be skipped. Camera and joint drivers to state assembly, over topics. The sensor-data QoS profile uses best effort and a smaller queue, because timely readings matter more than complete ones. Source: ROS 2 Project 2026.
  • The arm positions (the tf2 frame tree) give the arm position at the moment each photo was taken. tf2 frame tree to state assembly, as a tf2 lookup. tf2 keeps a time-buffered tree of coordinate frames. A lookup at the image's timestamp can wait for the transform; the tf2 tutorial raises an exception only if it is still unavailable after a 50 ms timeout. Source: ROS 2 Project 2026; ROS 2 Project 2026.
  • The newest readings, checked to be recent. State assembly to the policy server, over a topic. A reliable camera subscription with a deep queue can make a policy act on old images, so log message age at this boundary. Source: this article.
  • Suggested moves, all delivered. Policy server to the command gate, over a topic. The default QoS profile is reliable and keeps the last 10 messages. Source: ROS 2 Project 2026.
  • Checked moves, the only path to the motors. Command gate to the controller bridge, over a topic. The gate is the only node that publishes commands; two command publishers without arbitration is a common integration failure. Source: this article.
  • Motor commands at steady, exact intervals. Controller bridge to the robot hardware, in the real-time loop. ROS 2's real-time guidance keeps page faults, dynamic allocation and indefinitely blocking synchronization out of this path, so inference stays outside it unless its worst case fits. Source: ROS 2 Project 2026.
  • The task manager starts and stops these three parts: the AI that suggests moves, the safety check and the part that drives the motors. Supervisor to the policy server, command gate and controller bridge, through lifecycle transitions. ROS 2 managed nodes leave a primary state only at an external supervisor's request or on an error in the Active state. Source: Biggs et al. 2015.

Six ROS 2 nodes run top to bottom from camera and joint drivers to the controller bridge; sensor topics use best effort, proposed actions travel reliably with the last 10 messages kept, a tf2 lookup waits up to 50 ms, and only the command gate publishes commands.

Graph data
task to supervisor
action: task goal with feedback and cancel
drivers to state
topic: camera images, joint states; sensor data: best effort, small queue
tf2 to state
tf2 lookup; frames at the image's timestamp
state to policy
topic: observation; log message age here
policy to gate
topic: proposed actions; reliable
gate to bridge
topic: commands; the only command publisher
bridge to hardware
real-time loop
supervisor lifecycle
lifecycle: start, stop, deactivate

Lyrical's rosidl::Buffer lets a uint8[] field live in GPU memory without changing the .msg fileSource 25. NVIDIA deprecated its NITROS transport on 21 September 2026 in its favor, with a CUDA backendSource 26, because host round-trips add latency and use CPU and memory bandwidthSource 27.

Nav2 uses a behavior tree to orchestrate planner, controller and recovery serversSource 5. Costmap 2D accepts sensor-processing plugins for AI outputs and semantic informationSource 28, so a learned local controller can reuse a classical one's costmap, goal interface, test harness and fallback. The scene-representation module explains the map choices.

A small black and yellow four-wheeled Clearpath Jackal ground robot with a cylindrical lidar and cameras on its top deck, parked on gravel.
A Clearpath Jackal at the University of Texas robotics center in 2020. Wheeled research bases like it run Nav2, whose planner, controller and recovery servers are ordinary ROS 2 nodes.
Photo: U.S. Army / Luke J. Allen / Wikimedia Commons. Licence: Public domain.

Common integration failures

Frequent failures include a policy deployed in a different frame from its training data, a queue that hides latency, two unarbitrated command publishers, bags without transforms, wall-time assumptions under /clock, and one node holding drivers, inference and hardware commands. DDS implementations interoperate only in limited circumstances, so a system should use one ROS version and one RMW implementationSource 29. Nodes are not guaranteed to communicate across distributions; Jazzy is supported until May 2029 and Humble until May 2027Source 8. ROS 1 ended when Noetic reached end of life in May 2025Source 30.