ROS 2 Architecture: What Changed and Why

ROS 2 (Robot Operating System 2) represents a ground-up architectural redesign of the original ROS framework, driven by requirements that ROS 1 could not satisfy in production and safety-critical deployments. This page documents the structural differences between ROS 1 and ROS 2, the engineering rationale behind each major change, and the tradeoffs those changes introduce. The coverage is intended for robotics engineers, systems architects, and procurement professionals evaluating middleware stacks for real-world deployments.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix

Definition and scope

ROS 2 is an open-source robotics middleware framework maintained by Open Robotics (now integrated into the Linux Foundation's Robotics working group as of 2022) and developed collaboratively through the ROS 2 Design documentation and REP (ROS Enhancement Proposal) process. It is not a direct upgrade to ROS 1 — the two systems share naming conventions and conceptual vocabulary (nodes, topics, services, actions) but diverge at the transport, lifecycle, and security layers.

The scope of ROS 2 extends to multi-platform operation (Linux, Windows, macOS, and real-time OS targets such as QNX and VxWorks), multi-robot configurations, and safety-relevant applications where ROS 1's single-master architecture was structurally disqualifying. The framework sits within the broader robotics architecture overview as one layer of a full system stack, interacting with hardware abstraction, perception, and planning components.

ROS 2 is specified through a combination of REPs published at ros.org and interface definitions maintained in the ros2/rcl and ros2/rmw repositories on GitHub. No single government body mandates its use, but functional safety frameworks such as ISO 26262 (automotive) and IEC 62443 (industrial cybersecurity) set requirements that influenced ROS 2's design targets.

Core mechanics or structure

DDS as the transport layer. The most consequential structural change in ROS 2 is the replacement of ROS 1's custom TCPROS/UDPROS transport with Data Distribution Service (DDS), an Object Management Group (OMG) standard (OMG DDS Specification, formal/2015-04-10). DDS provides a publish-subscribe model with Quality of Service (QoS) policies, automatic peer discovery without a central master, and configurable reliability, durability, and deadline enforcement. For an expanded treatment of this layer, see DDS in robotics communication.

No ROS Master. ROS 1 required a single rosmaster process; all node registration, parameter lookup, and graph introspection flowed through it. ROS 2 eliminates this single point of failure by delegating discovery to DDS's built-in discovery protocol (SPDP/SEDP under the RTPS wire protocol). Nodes discover each other peer-to-peer across subnets, enabling multi-robot deployments and scenarios where network partitions must be tolerated.

Node lifecycle management. ROS 2 introduces a managed node lifecycle with 4 primary states: Unconfigured, Inactive, Active, and Finalized. State transitions are explicit and observable, allowing supervisory systems to bring nodes online, place them in standby, or deactivate them without restarting the process. This lifecycle model aligns with the fault-tolerance patterns described in fault-tolerant robotics design.

Actions. ROS 1's actionlib was a third-party package layered on top of topics and services. ROS 2 elevates actions to a first-class primitive in the client library (rclcpp, rclpy), with standardized goal, result, and feedback message types and built-in cancellation support.

ROS Middleware Interface (rmw). Rather than binding directly to one DDS vendor, ROS 2 defines a C-language ROS middleware interface (rmw) that abstracts vendor-specific DDS implementations. As of ROS 2 Humble Hawksbill (2022 LTS release), supported rmw implementations include eProsima Fast DDS, Eclipse Cyclone DDS, and Connext DDS from RTI.

Causal relationships or drivers

Four industrial forces drove the ROS 2 redesign:

1. Production deployment failures. ROS 1's single master created availability bottlenecks; master crashes brought down entire robot graphs. Deployments in Amazon Robotics-scale warehouse environments and autonomous vehicle programs exposed this as unacceptable.

2. Real-time requirements. ROS 1's threading model and serialization pipeline introduced non-deterministic latency. Real-time OS targets such as those required under IEC 61508 (functional safety integrity levels) demanded executor designs that could bound callback scheduling. ROS 2 introduced a composable node model and single-threaded executor options to reduce jitter.

3. Security requirements. ROS 1 had no native security layer. ROS 2 ships with SROS2 (Secure ROS 2), which applies DDS Security (OMG DDS Security Specification, formal/2018-04-01) to provide authentication, access control, and encrypted transport at the middleware level. This directly addresses concerns catalogued in the ICS-CERT advisories on robotic system vulnerabilities. For architectural context, see cybersecurity in robotics architecture.

4. Multi-platform and multi-robot scale. Commercial robotics moved from single-robot research setups to fleets of 50 to 500+ coordinated units. The masterless DDS discovery model and QoS configurability were preconditions for multi-robot system architecture at that scale.

Classification boundaries

ROS 2 distributions are versioned on a release cadence defined by the ROS 2 release policy (REP-2000). Each release targets specific platform combinations and carries either a standard (18-month) or Long Term Support (5-year) support window.

Key classification boundaries:

• ROS 1 vs. ROS 2: Not interoperable natively. The ros1_bridge package enables bidirectional topic and service bridging but introduces latency and does not bridge all message types.
• LTS vs. non-LTS releases: Humble Hawksbill (May 2022) and Iron Irwini (May 2023 — non-LTS) represent different support commitments. LTS releases are suitable for production; non-LTS releases are appropriate for development and feature evaluation.
• rmw implementations: Different DDS vendors offer different QoS policy support, maximum participant counts, and shared-memory transport capabilities. Selection of rmw is an architectural decision with measurable throughput and latency consequences.
• Managed vs. unmanaged nodes: Unmanaged nodes (the default in simple examples) do not expose lifecycle state and are not suitable for safety-critical supervisory architectures.

The relationship between ROS 2 and the broader layered control architecture places ROS 2 at the communication and coordination layer, not at the real-time control loop layer.

Tradeoffs and tensions

Complexity vs. capability. DDS is a powerful but operationally complex standard. Configuring QoS policies across 10 or more parameters per endpoint (reliability, durability, lifespan, deadline, liveliness) requires engineering expertise that ROS 1's simpler TCP transport did not demand. Misconfigured QoS policies are a common source of silent communication failures where publishers and subscribers with incompatible policies simply do not connect.

Vendor lock-in risk. The rmw abstraction reduces but does not eliminate vendor dependency. Advanced features (shared-memory zero-copy transport, extended security profiles) are often vendor-specific extensions not covered by the OMG DDS base specification.

Executor scheduling. ROS 2's executor model has been extensively critiqued in academic literature. The default multi-threaded executor does not provide rate-monotonic scheduling guarantees. Research published through the IEEE Robotics and Automation Society has documented priority inversion scenarios under high callback loads. The rclcpp::executors::StaticSingleThreadedExecutor mitigates some issues but imposes single-threaded constraints. These tensions connect directly to the design patterns covered in robot control systems design.

Ecosystem maturity. ROS 1 accumulated over 15 years of packages across robotics.org and GitHub. ROS 2 ports of those packages are incomplete as of the Humble cycle, meaning some sensor drivers and planning libraries exist only as ROS 1 packages requiring bridge operation.

These dynamics are representative of the broader robotics architecture trade-offs that engineers navigate when selecting middleware stacks.

Common misconceptions

Misconception: ROS 2 is real-time. ROS 2 is not a real-time operating system and does not provide hard real-time guarantees by itself. It can be deployed on real-time OS targets (e.g., QNX, Xenomai-patched Linux) and can be designed to minimize non-deterministic overhead, but the framework itself — particularly DDS discovery and dynamic memory allocation in rclcpp — introduces latency that violates hard real-time constraints. See real-time operating systems in robotics for the correct architectural framing.

Misconception: SROS2 provides complete security by default. SROS2 must be explicitly configured. A default ROS 2 installation without SROS2 keystore setup communicates over unencrypted, unauthenticated DDS. Security is opt-in, not opt-out.

Misconception: ros1_bridge is transparent. The bridge introduces message serialization overhead and does not support all message types, including those with unbounded arrays or non-standard field types. It is a migration tool, not a production integration layer.

Misconception: All DDS vendors are equivalent under rmw. Performance benchmarks published by Apex.AI and the ROS 2 performance testing repository (ros2/performance_test on GitHub) document throughput and latency differences of 30–50% between implementations under equivalent QoS configurations at high message rates.

Checklist or steps (non-advisory)

ROS 2 migration and deployment verification sequence:

1. Confirm target OS and ROS 2 distribution compatibility against REP-2000 platform targets.
2. Select rmw implementation based on security requirements, real-time constraints, and vendor support tier.
3. Audit all custom message and service definitions for compatibility with rosidl code generation pipeline.
4. Convert all nodes to managed lifecycle if supervisory control or fault-tolerance architecture is required.
5. Define and document QoS policies for every topic — reliability (RELIABLE vs. BEST_EFFORT), durability (TRANSIENT_LOCAL vs. VOLATILE), deadline, and liveliness.
6. Configure SROS2 keystore and access control policies before any network-exposed deployment.
7. Benchmark executor scheduling under peak callback load using ros2/performance_test tooling.
8. Verify ros1_bridge message type compatibility if operating in a hybrid ROS 1 / ROS 2 topology.
9. Validate node startup sequencing through lifecycle state machine for all safety-relevant subsystems.
10. Review all third-party package ROS 2 port status against the ROS Index (index.ros.org) for the target distribution.

The robotics architecture authority reference index provides context for where this deployment sequence fits within broader system qualification processes.

Reference table or matrix

ROS 1 vs. ROS 2 Architecture Comparison Matrix

References

• Object Management Group — DDS Specification (formal/2015-04-10)
• Object Management Group — DDS Security Specification (formal/2018-04-01)
• REP-2000: ROS 2 Releases and Target Platforms — ros.org
• ROS Index — ros2 package distribution index
• Linux Foundation Robotics — ROS 2 Technical Charter
• IEC 62443 — Industrial Cybersecurity Standard (IEC reference)
• IEC 61508 — Functional Safety of E/E/PE Safety-related Systems (IEC reference)
• IEEE Robotics and Automation Society — publications on ROS 2 executor scheduling
• ros2/performance_test — GitHub benchmark repository