ROS 2

Summary

ROS 2 is the open source middleware and tooling layer that most robotics software runs on. It moves messages between processes, tracks the coordinate frames that relate sensors to a robot’s body, and records what happened to disk. For Physical AI it matters less as a development framework than as a recording substrate, because the bag file a robot writes during operation is usually where a training corpus begins.

Overview

ROS 2 is developed in the open by the ROS 2 release team and the wider community, under the Apache 2.0 license, in the ros2 GitHub organization. It is a ground up redesign of ROS 1, whose repository was created at Willow Garage on 7 November 2007. The redesign was motivated by production requirements ROS 1 was never built for: multi-robot systems, non-ideal networks, small embedded platforms, and real-time control, with the communication layer rebuilt on off-the-shelf DDS implementations rather than custom transports (design.ros2.org). The canonical technical description is Macenski et al., “Robot Operating System 2: Design, architecture, and uses in the wild”, Science Robotics, May 2022.

Distributions ship yearly on 23 May. REP 2000 sets the policy: even numbered years produce a Long Term Support release supported for five years, odd numbered years produce a regular release supported for eighteen months, and each distribution targets exactly one Ubuntu LTS. The current LTS is Lyrical Luth, the twelfth ROS 2 release, supported until May 2031, announced on 22 May 2026. Jazzy Jalisco runs to May 2029 and Humble Hawksbill to May 2027, according to the endoflife.date ROS 2 tracker, which also records that ROS 1 left support in May 2025.

Adoption is concentrated and still growing. The 2025 ROS Metrics Report, summarized by Open Robotics in February 2026, puts annual package downloads just under one billion, up 85 percent year over year, with ROS 2 accounting for more than 90 percent of all ROS downloads. On the all time package ranking at metrics.ros.org, the top entry is tf2-ros, the coordinate frame library, which is a useful signal about what robotics software spends its time doing.

What ROS 2 Does

The programming model is a graph of independent processes called nodes, which exchange typed messages over named topics, call each other through services, and run long tasks through actions. Unlike ROS 1 there is no central master process: nodes discover each other through the middleware, so a graph can start in any order and survive the loss of any single process.

Underneath sits the ROS middleware interface, rmw, which makes the transport swappable at build or run time. Every Tier 1 implementation has historically been a DDS implementation, and eProsima Fast DDS remains the default in Lyrical Luth. Since Jazzy there is also a documented non-DDS option, rmw_zenoh, built on the Zenoh protocol and [installed by setting RMW_IMPLEMENTATION](https://docs.ros.org/en/rolling/Installation/RMW-Implementations/Non-DDS-Implementations/Working-with-Zenoh.html). DDS brings Quality of Service settings to every topic: reliability, history depth, durability, and deadline. Those settings are the reason a camera stream and a safety heartbeat can share one network without either behaving badly, and they are also a common source of silent data loss when a recorder subscribes with a profile that does not match the publisher.

tf2 maintains the transform tree: a time indexed record of where every frame sits relative to every other, so any pose can be expressed in any frame at any recorded instant. Static transforms are published once with transient local durability, and everything else streams on /tf.

rosbag2 is the recording tool. Since Iron Irwini its default storage format is MCAP, as announced by Open Robotics, an append-only container chosen for higher write throughput, chunk compression, resilience to a crash mid recording, and, most consequentially for downstream users, because it records message schemas into the file by default so applications outside a ROS 2 workspace can decode it.

Physical AI Relevance

Almost every real robot dataset passes through ROS 2 before it becomes training data, which makes the recording format a de facto part of the dataset specification whether or not anyone treats it that way.

The consequential detail is time. As MCAP records, a message can carry both log_time and publish_time. Neither is the moment the sensor captured the reading. That value, where it exists at all, lives inside the payload in the message header, written by the driver. So a single camera frame in a bag can carry three defensible timestamps, they differ by network jitter and retransmission, and the rosbag2 recorder itself distinguishes publish time from receive time in its own control interface. Picking between them is a dataset decision rather than a tooling detail, and it is the ROS 2 specific face of the problem Multimodal Dataset Synchronization covers in general.

The second is provenance. Calibration and frame conventions reach the bag only as /tf and /tf_static messages and camera info topics, so a corpus that records the sensor streams but drops the transform topics has lost the information Robot Calibration and Coordinate Frames shows is unrecoverable afterward. Schema embedding helps here: bags recorded from Iron onward carry their message definitions, while earlier bags cannot be converted without the original ROS 2 workspace sourced. A bag whose custom message definitions live only in a workspace that no longer builds is a bag nobody can read.

The third is the exit. Training corpora are not distributed as bags. They are distributed in tensor oriented formats, and the conversion from a topic stream into episodes carrying an observation and an action at each step is where episode boundaries, outcome labels, and per-episode calibration have to be supplied by hand, because ROS 2 has no concept of any of them. It records topics, not trials.

Connections

ROS 2 enables Robot Demonstration Data, since teleoperation rigs record observations and commands through it.

ROS 2 enables Multimodal Dataset Synchronization, and also constrains it, by deciding which clocks are written to the file.

ROS 2 uses Robot Calibration and Coordinate Frames through tf2, which is the mechanism by which frames reach a recording at all.

ROS 2 related Action Space Standardization: a topic name and a message type say nothing about whether a command is a joint velocity or an end effector delta, so the convention has to be recorded alongside.

ROS 2 related Robotics as the shared software substrate of the discipline, and related Autonomous Systems, whose fleet logging stacks are frequently built on it.

Limitations

1. ROS 2 is not a real-time system on its own. It removes the architectural obstacles ROS 1 had and supports real-time capable transports and executors, but determinism depends on the operating system, the scheduler, the allocator, and the DDS configuration underneath. Hard real-time control loops commonly sit below ROS 2 rather than inside it.

2. DDS discovery is a tuning problem at scale. Default multicast discovery behavior is workable on a bench and often is not on a large graph or a constrained network, which is much of the motivation for offering rmw_zenoh as an alternative.

3. A bag is a log, not a dataset. There is no episode, no success label, no task identifier, and no operator record in the format. Every one of those has to be added by a convention outside ROS 2, and a convention that lives outside the file is a convention that gets lost.

4. Recording is lossy in ways that do not announce themselves. A mismatched QoS profile, a dropped subscription, or a recorder that starts after a transient local publisher has already sent its one message all produce a bag that opens cleanly and is missing something.

5. Cross-distribution compatibility is not guaranteed. Nodes from different distributions are not promised to interoperate, and a distribution that has reached end of life stops receiving the patches that keep a long running collection program buildable.

Links

1. ROS 2 documentation, the maintained reference for the current and supported distributions.

2. ROS 2 design articles, including the rationale for the ROS 1 rewrite.

3. ros2/rosbag2, the recording and playback tool and its README.

4. MCAP format specification, the default rosbag2 storage container.

5. REP 2000, release cadence and target platform policy.

6. ROS metrics, community and package download statistics.

Kotwel’s Role

The question ROS 2 hands to whoever labels the data is which clock a label is expressed in. An annotator marking the instant of contact in a manipulation episode is looking at a video frame that carries a log_time, a publish_time, and a driver written header stamp, while the force spike they are aligning it to carries its own three. Both readings are defensible. Recorder time is consistent across every topic in the file and is what most tooling displays by default; header time is what the sensor claims and is the physically correct one, but it is absent on some drivers and not comparable across devices whose clocks were never disciplined together. The choice sets the apparent latency between observation and action that a policy learns, and a corpus that made the choice differently in different sessions teaches a timing relationship that was never true. Kotwel works at that layer: naming the time base in the labeling specification before annotation starts, recording it per episode rather than per project, and checking a delivered corpus against it. Kotwel does not write ROS 2 nodes, maintain robot software, or tune middleware configuration.