Robot Software
ROS 1 vs ROS 2: What Changed and What Broke
ROS 1 reached end of life in May 2025. What ROS 2 changed underneath, which concepts survived, and the five migration problems that consume most of the effort.
ROS 1 reached end of life with the final Noetic release in May 2025, so the question is no longer whether to migrate. The substantive change is that the central roscore master is gone, replaced by peer-to-peer discovery over DDS, and with it come real-time friendly execution, quality of service settings, lifecycle-managed nodes and a security model. Topics, services and the node graph survive largely intact.
What actually changed
| Aspect | ROS 1 | ROS 2 |
|---|---|---|
| Discovery | Central roscore master | Peer-to-peer via DDS |
| Transport | Custom TCPROS and UDPROS | DDS with pluggable implementations |
| Single point of failure | Yes, the master | No |
| Quality of service | Latched topics only | Reliability, durability, history, deadline, liveliness |
| Real-time suitability | Poor, allocations in the hot path | Designed for it, with care |
| Node lifecycle | Ad hoc | Managed states with transitions |
| Security | None | DDS-Security: authentication, encryption, access control |
| Multi-robot | Awkward, namespace tricks | Domain IDs, native |
| Windows and embedded | Limited | Supported |
| Build system | catkin | colcon with ament |
| Python | rospy | rclpy on a shared C core |
The row worth dwelling on is quality of service. In ROS 1 a subscriber either received messages or it did not. In ROS 2 a publisher and subscriber must have compatible settings, and incompatible ones connect silently and deliver nothing. A best-effort publisher and a reliable subscriber is the single most common cause of a topic that publishes into the void.
The five problems that consume the effort
- Quality of service mismatches. Sensor data usually wants best effort with a small history depth; commands want reliable. Getting this wrong produces either silence or unbounded latency under load.
- Discovery on a busy network. Peer-to-peer discovery scales poorly beyond roughly 30 to 50 nodes on a shared subnet, because every participant announces to every other. Discovery servers or a different middleware become necessary sooner than teams expect.
- Time. ROS 2 separates system time, steady time and simulation time, and code that assumed one clock in ROS 1 needs auditing. Simulation time handling is a frequent source of subtle bugs.
- Parameters. The global parameter server is gone; parameters belong to nodes and are declared, typed and optionally validated. Configuration files usually need rewriting rather than porting.
- Executors and callbacks. Callback groups and multi-threaded executors give control over concurrency that ROS 1 did not offer, and code written assuming a single-threaded spin can deadlock without them.
What survived
The conceptual model is intact, which is why migration is work rather than a rewrite. Nodes, topics, services, actions, transforms, launch files, message definitions and the general package structure all carry over. Message definitions largely port with mechanical changes, and the tooling equivalents are recognisable. Most application logic moves with modest edits; the effort sits in the infrastructure around it.
A migration strategy that works
- Start with the message definitions. They are the contract, and porting them first lets both stacks coexist.
- Use a bridge during transition. Running a ROS 1 to ROS 2 bridge lets a system migrate node by node rather than in one cut, which is essential on anything with hardware drivers.
- Port drivers last or first, never in the middle. Hardware interfaces are where the platform differences are sharpest, so isolate them at one end of the plan.
- Choose the LTS release. Long-term support versions carry multi-year support windows; intermediate releases carry roughly a year. For production, the LTS choice is not close.
- Fix quality of service settings explicitly. Do not rely on defaults, and write the intended setting into the code with a comment saying why.
Frequently asked questions
Is ROS 1 still supported?
No. The final ROS 1 distribution, Noetic Ninjemys, reached end of life in May 2025. Systems still running it receive no upstream fixes, including security fixes.
What is the biggest difference between ROS 1 and ROS 2?
The removal of the central master. ROS 2 uses peer-to-peer discovery over DDS, which eliminates the single point of failure and brings quality of service settings, security and real-time friendly execution with it.
Why does my ROS 2 topic publish nothing?
Most often a quality of service mismatch. Incompatible reliability or durability settings between publisher and subscriber prevent a connection without raising an error, because the middleware treats it as valid configuration.
How many nodes can ROS 2 discovery handle?
Plain peer-to-peer discovery degrades somewhere around 30 to 50 participants on a shared subnet, since every participant announces to every other. Larger systems use a discovery server or a middleware implementation designed for scale.
Which ROS 2 release should a product use?
A long-term support release. LTS versions carry multi-year support, currently ending in 2027 and 2029 for the two most recent, while intermediate releases carry roughly a year.
Can ROS 1 and ROS 2 run together?
Yes, through a bridge that translates messages between the two. That is the standard way to migrate a system with hardware drivers, since it allows node-by-node porting instead of a single cutover.
Sources
- ROS 2 releases and support windowsOpen Robotics documentation, distribution dates and end-of-life schedule
- About quality of service settingsOpen Robotics documentation, compatibility rules between publishers and subscribers
- ROS on DDSROS 2 design article explaining the middleware decision and its consequences