ROS 1 vs ROS 2 The Major Differences
Many robotics organizations face a decision regarding if or when they should transition to ROS 2 from ROS 1. There isn’t a lot of content that discusses the major differences between the two versions. You can reference the official ROS 2 design page on the topic; however, we work to frame some of these differences in the context of what they mean for you and your robotics organization below.
The ROS 1 vs ROS 2 Decision Horizon
For organizations deciding between ROS 1 and ROS 2 today, we recommend using ROS 2. ROS 1 Noetic, the final ROS 1 distro is only officially supported through 2025 unless you’re willing to only rely on community support. The migration process typically involves using both versions of ROS until you’ve completely migrated to ROS 2.
The differences between ROS 1 and ROS 2 fall into three main categories:
- Architecture
- Features
- Tooling/Ecosystem
Architecture
Changes to the Middleware
ROS 1 uses the ROS Master-Slave Architecture and the XML-RPC middleware. ROS 2 uses Data Distribution Service (DDS), which is designed to provide higher efficiency and reliability, low latency, and scalability, as well as configurable quality of service (QoS) parameters. XML-RPC is better for simple remote procedure calls, while DDS’s added complexity allows it to better support real-time systems. Because of its distributed nature, DDS also helps remove communications single-points-of-failure from ROS 2 systems.
Changes to the ROS API
ROS 1 has two separate libraries - roscpp for C++ and rospy for Python - that are not at feature parity with each other. In contrast, ROS 2 has a base library written in C - rcl (ROS client library) - with libraries built on top of it. This ensures that core functionality is available in different APIs sooner. This is one of the key reasons that ROS 2 is able to offer more language support than just Python and C++, such as Java and C#.
Changes to the Data Format
ROS2 rosbags allow for more flexibility with regard to serialization as compared to ROS 1, which uses its own serialization format. The biggest impact of changes to the rosbag format from ROS 1 to ROS 2 is potential incompatibility of ROS 1 bag tooling with ROS 2 rosbags and subsequent impacts to developer workflows.
Features
QoS
ROS 2 allows for data flow configuration, affecting how data is sent and received. This includes settings for message reliability, deadline, and priority, which can ensure that critical messages are delivered on time.
Multi-Threaded Execution
ROS 2 supports multiple nodes truly running in parallel, allowing it to leverage modern multi-core processors far better than ROS 1.
Real-Time Processing
The summation of the features above, along with the use of DDS, allows ROS 2 to be superior at real-time processing, especially when deterministic, low-latency communication is needed.
Tooling/Ecosystem
Tooling
There are a couple notable changes to tooling between ROS 1 and ROS 2:
- Catkin is gone, replaced with Ament as a build system
- Overlays allow you to have a secondary workspace that doesn’t affect your primary workspace – this is helpful when you want to experiment with new packages without affecting your base configuration (called an “underlay”).
Ecosystem
ROS 2 is not backward compatible with ROS 1. Consequently, ROS 1 packages will likely not work with ROS 2 and would require rework, and other software you’re accustomed to using with ROS 1 may no longer work. While currently a major limitation, tools like ROSbridge are enabling improvements.
ROS 1 was primarily built for Ubuntu. ROS 2 runs on MacOS, Windows, Ubuntu, and other operating systems.
Recommendations
Teams building from the ground up should start using ROS 2.
For organizations using ROS 1, it will not be feasible to stay on ROS 1 indefinitely because official support ends in 2025. However, every organization using ROS 1 today has different considerations when determining when or how to migrate to ROS 2. Teams should work to understand the effort and staffing it would take to transition, and work out a timing to execute the plan in a manner that aligns with the organizational goals and product development cycle.
Sources/Further Reading:
ROS 1 Wiki (Noetic)
