ROS 2 vs ROS 1: What Changed and Why It Matters
ROS 1 reached end of life in May 2025. Its final release, Noetic Ninjemys, no longer receives patches or updates. For new projects, the answer is ROS 2. For existing deployments, migration pressure is building. Here’s what actually changed.
The Problem with ROS 1
ROS 1 was built for research labs: single machines, controlled networks, no real-time requirements, no security concerns. A centralized ROS Master handled node discovery, and nodes communicated over plain TCP. It worked well for its purpose — but industrial automation, multi-robot systems, and consumer robotics exposed hard architectural limits that couldn’t be patched away.
Communication: DDS Replaces the Master
The biggest change is the replacement of the ROS Master with DDS (Data Distribution Service), a decentralized publish-subscribe standard. Nodes discover each other via multicast — no central directory, no single point of failure. If a node crashes, the rest of the system continues undisturbed.
DDS also introduces QoS policies: per-topic control over reliability, durability, deadlines, and liveliness. Sensor streams can use best-effort delivery; control commands can require reliable delivery. Publishers and subscribers only connect when their policies are compatible. ROS 2 abstracts the specific DDS implementation (Fast DDS, Cyclone DDS, RTI Connext) through an rmw layer, so application code is portable.
Real-Time Support
ROS 1 offers none. ROS 2 supports real-time execution through configurable multi-threaded executors, lock-free message passing, intra-process communication by pointer, and compatibility with the PREEMPT_RT Linux kernel patch. On a properly configured system — isolated CPU cores, pre-allocated memory, PREEMPT_RT — hard real-time control loops at 1 kHz with sub-millisecond worst-case latency are achievable.
Security
ROS 1 has no security model. Any process on the network can read or publish to any topic. ROS 2 Security (SROS2) adds DDS Security: per-node certificates, in-transit encryption, and signed access control policies that specify exactly which topics each node may publish or subscribe to — enforced at the middleware layer without touching application code. It adds deployment complexity, but the infrastructure exists for environments where it’s needed.
Node Lifecycle
ROS 1 nodes have no managed state. ROS 2 defines a standardized lifecycle — unconfigured → inactive → active → finalized — with explicit transitions for configuration, activation, deactivation, and shutdown. This enables ordered startup sequences (sensors before localization, localization before planning) and graceful recovery from partial failures without restarting the whole stack.
Launch System
ROS 1 uses XML. ROS 2 uses Python. Conditions, loops, composable launch fragments, command-line parameterization, and lifecycle-aware startup sequencing are all first-class. The trade-off is Python parsing overhead, which is negligible for most systems.
Migration
ROS 1 and ROS 2 can’t communicate directly, but ros1_bridge provides bidirectional topic translation for incremental migrations. Code changes involve the client library API (rclcpp/rclpy replace roscpp/rospy), the build system (ament_cmake replaces catkin), and parameter handling. Most changes are mechanical. The ROS 2 package ecosystem in 2025 covers most of the ROS 1 space — verify your specific dependencies before committing to a timeline.