What is ROS 2 in simple terms?

ROS 2 is an open-source framework, not an operating system in the usual sense, that provides the tools and libraries for building robotic applications. It moves data between the parts of a robot, defines the message types they agree on, and supplies the tooling to start, inspect, record and simulate a robot system.

What is the difference between ROS 1 and ROS 2?

ROS 1 (2007) assumed a single robot, workstation-class compute and reliable networking, and used a central master for discovery. ROS 2 redesigns the middleware around DDS, which brings distributed discovery with no central broker, configurable Quality of Service for lossy or real-time links, and support for multi-robot, embedded and production systems.

What is the difference between a ROS 2 topic, service and action?

Topics are anonymous publish/subscribe streams for continuous data such as sensor readings. Services are remote procedure calls expected to return quickly. Actions are long-running remote procedure calls that stream feedback and can be cancelled or preempted.

Do I need to know C++ to use ROS 2?

No, but C++ and Python are the two fully supported client libraries. rclcpp is the idiomatic C++ interface and rclpy is its Python counterpart, and both build on the same underlying rcl C API, so nodes written in either language interoperate. Community bindings also exist for Rust, Java, Node.js, C# and others.

Which ROS 2 distribution should I install?

Prefer a long-term support release. Jazzy Jalisco (May 2024) is supported until May 2029 and Humble Hawksbill (May 2022) until May 2027. Non-LTS releases such as Kilted Kaiju (May 2025, end of life December 2026) are supported for roughly 1.5 years.

What is ROS 2?

What ROS 2 is

ROS 2 is the open-source framework most modern robots run on. It is not a conventional operating system: the project describes ROS as “an open-source ecosystem that provides the framework, tools, and libraries for building, deploying, running, and maintaining robotic applications” (docs.ros.org). Practically, it is the contract layer between the parts of a robot, carrying sensor data from drivers to perception, routing commands from planners to motor controllers, and defining the message types that let software from different teams cooperate.

The “2” is not a version bump. ROS 1 began in 2007 as the development environment for the Willow Garage PR2 and assumed a single robot, workstation-class compute and good connectivity. ROS 2 redesigns the stack for multi-robot teams, embedded platforms, real-time control, lossy networks and production deployments (design.ros2.org). Its first non-beta release, Ardent Apalone, shipped on December 8, 2017 (docs.ros.org).

Why ROS 2 exists

ROS 1 built its own discovery, message definition, serialization and transport from scratch. ROS 2 replaced that with DDS, an industry standard, and its RTPS wire protocol. The published reasoning: an end-to-end middleware means far less code to maintain, a specification third parties can audit and implement independently, and distributed discovery in which any two DDS programs find each other without a central broker, which is more fault tolerant than ROS 1’s single master (design.ros2.org).

The switch also bought control over transport. ROS 1 used TCP, which behaves poorly on lossy wireless links. ROS 2 exposes DDS Quality of Service policies, so one topic can be as reliable as TCP or as best-effort as UDP (QoS).

Client libraries and the middleware layer

ROS 2 is layered deliberately, and three layers explain most of its behavior.

The client libraries are the APIs developers write against. rclcpp is the idiomatic C++ interface, rclpy the Python counterpart. Both build on a shared C library called rcl, which is why nodes in different languages behave consistently and interoperate. Message bindings are generated by rosidl, so a Python node can subscribe to a topic published by a C++ node (client libraries).

The ROS middleware interface, or rmw, wraps a concrete middleware implementation behind a common abstract interface, which keeps ROS 2 from being tied to one vendor.

The middleware is a DDS or RTPS implementation. The default is rmw_fastrtps_cpp, built on eProsima Fast DDS. Eclipse Cyclone DDS (rmw_cyclonedds_cpp) and RTI Connext DDS (rmw_connextdds) are fully supported alternatives, with community support for GurumNetworks GurumDDS (middleware vendors).

Nodes: the unit of computation

A node is a participant in the ROS 2 graph that uses a client library to talk to other nodes. Nodes can run in the same process, in different processes, or on different machines, and the documentation states that each node “should do one logical thing” (nodes).

Connections are established automatically through middleware discovery. A node advertises its presence to others in the same ROS domain, set by ROS_DOMAIN_ID, and keeps re-advertising so late joiners are found. A connection is made only if both sides have compatible Quality of Service settings, a frequent cause of “the topic exists but no data arrives” (discovery).

Topics, services and actions

Topics are the anonymous publish/subscribe bus, meant for continuous streams such as sensor readings and robot state. Any number of publishers and subscribers can share a topic name, and subscribers do not generally know which publisher sent a message. Messages are strongly typed: an IMU message’s angular velocity is specified in radians per second (topics).

Services are remote procedure calls pairing a request with a response. They are expected to return quickly because the client blocks waiting, so long computations belong in an action. There should be one service server per name, but any number of clients (services).

Actions are long-running remote procedure calls that stream feedback and can be cancelled or preempted. Telling a navigation subsystem to drive to a waypoint is the canonical case: the goal takes time, progress feedback arrives along the way, and the caller can abort (actions).

Parameters

Parameters belong to individual nodes and configure them at startup or runtime without editing code. Each is a key, a value and a descriptor; the value is one of a fixed set of types such as bool, int64, float64, string, or arrays of those. By default a node must declare every parameter it accepts, so names and types are pinned at startup and mistakes surface early (parameters).

Launch

A real system is many nodes across many processes and often several machines. The ROS 2 launch system describes what to run, where and with which arguments, then executes and monitors it. Launch files can be written in XML, YAML or Python and are started with ros2 launch <package_name> <launch_file_name>. Simulated time, parameter overrides and namespacing are typically configured here (launch).

Tooling

The ros2 command line is the main entry point for introspection, with subcommands including node, topic, service, action, param, bag, launch, lifecycle, component and interface (command line tools). Passing -t to ros2 topic list appends each topic’s type, which is how you discover the interface a running system actually uses:

$ ros2 topic list -t
/rosout [rcl_interfaces/msg/Log]
/turtle1/cmd_vel [geometry_msgs/msg/Twist]
/turtle1/pose [turtlesim/msg/Pose]

Alongside it, rviz2 renders live robot state, sensor data and transforms, started with ros2 run rviz2 rviz2 (RViz); rqt_graph draws the node and topic graph; and rosbag2, exposed as ros2 bag, records and replays data. Recording is ros2 bag record /turtle1/cmd_vel, and replay is ros2 bag play subset (recording).

Composition compiles multiple nodes into one process, avoiding serialization and transport cost on the hot path (composition). Managed, or lifecycle, nodes expose a state machine with four primary states, Unconfigured, Inactive, Active and Finalized, which hardware drivers use so cameras and motor drivers come up and shut down in a controlled order (managed nodes).

The ecosystem around ROS 2

Nav2 is the professionally supported successor to the ROS 1 Navigation Stack, providing localization, planning, control and behaviors. It orchestrates modular task servers through behavior trees, which communicate over ROS 2 actions and services (Nav2).

MoveIt 2 is the manipulation platform for ROS 2, covering motion planning, kinematics, 3D perception and control, released since 2019 (MoveIt 2).

Gazebo is the long-standing open-source simulator, connected to ROS 2 through the ros_gz packages. REP-2000 standardizes which Gazebo version pairs with each ROS distribution; the recommendation for new users is ROS 2 Jazzy with Gazebo Harmonic (Gazebo and ROS).

NVIDIA Isaac Sim is the GPU-accelerated alternative, connected through a ROS 2 bridge extension, with Humble and Jazzy the officially tested distributions (Isaac Sim).

Releases follow a published cadence: even years bring a long-term support release supported for about five years, odd years a non-LTS release supported for roughly 1.5 years (REP-2000). The ROS 1 line has ended, with Noetic Ninjemys reaching end of life in May 2025 (REP-3).

When ROS 2 is the wrong choice

ROS 2 is general purpose, and general purpose means overhead.

On a bare microcontroller with kilobytes of RAM and no operating system, a full DDS stack is the wrong tool. The C client library rclc complements rcl to provide a feature-complete C client library for microcontroller workflows, a path that exists because the standard stack does not shrink that far (client libraries).

If you need hard real-time guarantees, ROS 2 supports real-time work but does not hand it to you. The real-time demo requires building from source against a static DDS API, currently supported only with RTI Connext DDS, and runs only on Linux. The guidance is to keep nondeterministic operations out of the real-time path: page faults, dynamic memory allocation, and blocking synchronization primitives (real-time). That is a systems engineering problem, not a framework feature.

If your product is a closed, single-vendor pipeline with no need for third-party nodes or simulation, the ecosystem advantages do not apply and you are paying for flexibility you will not use. The same holds for small single-process control loops where a direct CAN or EtherCAT interface is simpler. ROS 2 optimizes for integration, reuse and observability across a heterogeneous system, so choose it when those are your problems.

What comes next

The development line is Rolling Ridley, where changes land before being frozen into a numbered distribution. The newest release is Lyrical Luth, dated May 22, 2026, with support projected to May 2031 (distributions). The more interesting pressure comes from robotics AI: learned policies and vision-language-action models are increasingly deployed as ROS 2 nodes, which puts middleware latency and message typing on the critical path of robot learning.

For a developer starting today: pick a long-term support distribution, learn one client library properly, then learn the introspection tools before any framework. Most ROS 2 confusion is not about the API but about discovery, Quality of Service compatibility, and which node is actually running.