Robot Operating System (ROS) is an open-source software platform for building robot applications. Despite its name, ROS is not a conventional operating-system kernel: it does not schedule processes or manage hardware as a host operating system does. It supplies communication abstractions, client libraries, build and launch tools, debugging utilities, and a package ecosystem above a host platform.[1][2]

There are two distinct ROS generations. ROS 1 established the original graph, package, and tooling model but reached project-wide end of life in May 2025. ROS 2 is a redesign with a middleware abstraction, distributed discovery, configurable Quality of Service (QoS), managed node lifecycles, and security and real-time-oriented facilities. They share concepts and naming, but they are not wire-compatible versions of one runtime.[2]

ROS is used across robotics research, education, and product development. It is a framework for assembling components, not a complete autonomy system by itself. Perception, planning, mapping, control, hardware drivers, and application logic come from separate ROS packages or other software.

History and stewardship

The first ROS code commit at Willow Garage was made on November 7, 2007. A 2009 paper by Morgan Quigley and colleagues described ROS as a communications layer above a host operating system, with peer-to-peer processes, language-neutral message definitions, command-line tools, and separately maintained packages.[1][3]

Willow Garage initially stewarded ROS and the Gazebo simulator. The Open Source Robotics Foundation, incorporated on March 22, 2012 and later known as Open Robotics, took over that stewardship as the projects moved beyond Willow Garage.[4]

Open Robotics announced the Open Source Robotics Alliance (OSRA) in March 2024. Under the announced structure, the OSRA uses a mixed membership and meritocratic participation model. A Technical Governance Committee oversees project management committees, while the Open Source Robotics Foundation board retains final oversight. The ROS Project Charter defines ROS as an OSRF project whose governance responsibility is assigned to the OSRA.[5][6]

This governance model covers the project and its shared infrastructure. Individual community packages remain the responsibility of their own maintainers, so maintenance level, release cadence, and compatibility can differ across the ecosystem.

Core model

A running ROS system is represented as a graph. Its principal entities are:

Entity	Role
Node	A named participant that performs computation and exposes ROS interfaces. One process can contain one or more nodes.
Topic	An asynchronous, typed publish-subscribe channel, often used for sensor streams or state updates. A topic can have multiple publishers and subscribers.
Service	A typed request-response interface for operations that should return a result.
Action	A goal-oriented interface for longer operations that need feedback and cancellation.
Parameter	A value associated with a node and accessed through parameter APIs and services.

The original ROS design used processes connected in a peer-to-peer data topology after they found one another through a name service called the master.[1] ROS 2 instead uses middleware-provided discovery and a ROS graph API. In both generations, the graph is a logical view: nodes can run in separate processes or hosts, and in ROS 2 multiple composable nodes can also share a process.[2][7][8]

Interfaces are strongly typed. Message, service, and action definitions generate language-specific code so that nodes written with different supported client libraries can exchange the same interface types. ROS 2's maintained client libraries include rclcpp for C++ and rclpy for Python. They share lower-level functionality through the C library rcl.[2][9]

Packages, workspaces, and builds

ROS software is divided into packages. A package declares its metadata and dependencies in package.xml and can contain nodes, libraries, interface definitions, launch files, configuration, tests, or documentation. A ROS distribution is a versioned set of packages, not one monolithic executable.

ROS 2 packages commonly use the ament_cmake or ament_python build types. The colcon command-line tool discovers, builds, and tests multiple packages in a workspace. By convention, source packages are placed under a workspace's src directory; builds then create separate build, install, and log artifacts.[10] Released ROS 2 packages are automatically added to docs.ros.org and the ROS Index, which records their released distributions and package metadata.[11]

Packages can depend on software outside ROS and can use different open-source or proprietary licenses. The ROS 1 recommendation was the 3-Clause BSD License, while the ROS 2 recommendation is Apache License 2.0. Migrated code keeps the license attached to earlier contributions unless the relevant copyright holders authorize a change.[12]

ROS 1 and ROS 2

ROS 2 kept the node, topic, service, parameter, package, and graph vocabulary while changing the underlying architecture.

Area	ROS 1	ROS 2
Discovery	Central ROS master used for graph registration and lookup; payload data normally flows directly between peers	Distributed discovery through the selected ROS middleware implementation
Transport	ROS-specific serialization and transport protocols, principally TCPROS and UDPROS	ROS middleware (`rmw`) abstraction, initially built around DDS and RTPS and now also supporting Zenoh
Communication policy	Relatively limited transport choices	Per-endpoint QoS policies for reliability, durability, history, deadlines, liveliness, and other behavior
Parameters	A graph-wide parameter server plus node-specific dynamic reconfigure mechanisms	Parameters belong to nodes and are exposed through node services and events
Node deployment	Ordinarily one node per process, with nodelets used for same-process composition	Nodes may be separate processes or composable components in a shared process
Build tooling	Catkin became the principal ROS 1 build system	Ament build types, normally orchestrated across a workspace by colcon
Security	No integrated security model in the original architecture	DDS Security integration and SROS2 tooling, when configured and enabled
Project status	Final distribution Noetic is end of life	Multiple maintained stable distributions plus Rolling

The distinction between a centralized master and peer-to-peer data is important. ROS 1 used the master for registration and connection setup, but it did not route every topic message through that master. ROS 2 removes the central discovery service and delegates discovery, serialization, and transport to the selected middleware implementation.[1][13]

Middleware and discovery in ROS 2

ROS 2 separates the public client APIs from transport-specific code. A typical stack is:

rclcpp or rclpy -> rcl -> rmw -> selected middleware

The rmw interface allows a ROS 2 installation to use different middleware implementations without changing normal node source code. DDS and its RTPS wire protocol were the initial foundation. Current ROS documentation also lists a Zenoh RMW implementation.[2][14]

As of the research cutoff, eProsima Fast DDS is the default RMW and is packaged with binary releases. Eclipse Cyclone DDS also has full support and is packaged. RTI Connext DDS has full ROS support, but the Connext product must be installed separately. Eclipse Zenoh has full support and has been packaged with binary releases since Kilted Kaiju.[14]

Middleware interchangeability has limits. ROS documentation says that cross-vendor DDS communication works in many cases but is not guaranteed, and recommends using the same ROS version and RMW implementation throughout a distributed system. Communication between nodes built for different ROS distributions is likewise not guaranteed.[7][14]

Discovery and connectivity also depend on the network. Firewalls, multicast policy, interface selection, virtual private networks, containers, domain IDs, and vendor configuration can determine which participants can find and reach one another. A visible process is therefore not necessarily a discoverable or compatible ROS endpoint.

Quality of Service

ROS 2 applies QoS profiles independently to publishers, subscriptions, service clients, and service servers. Policies include:

Reliability, commonly best effort or reliable.
Durability, including volatile or transient local behavior.
History and depth, which determine how samples are retained.
Deadline, lifespan, and liveliness, which describe timing and availability expectations.

QoS is not a general setting that simply makes a system "reliable." Publisher and subscriber policies must be compatible, or no messages may be delivered. The appropriate profile also depends on the data: a sensor stream may prefer fresh best-effort samples, while a command or state update may require different delivery behavior.[15]

ROS 2 supplies predefined profiles for common uses, but system designers still need to test them under the intended payload sizes, rates, network losses, and middleware implementation. A profile that behaves well on a wired laboratory network may not have the same latency or loss characteristics over Wi-Fi or a routed network.

Execution, composition, and lifecycles

Client libraries receive work such as subscriptions, timers, services, and action callbacks and dispatch it through executors. Executor choice, callback grouping, process composition, operating-system scheduling, and middleware queues all affect latency and concurrency. Placing components in one process can reduce serialization and transport overhead, but it also changes fault isolation and scheduling interactions.[2]

ROS 2 managed lifecycle nodes expose a state machine with primary states such as unconfigured, inactive, active, and finalized. A supervisor can configure and activate components in an ordered way or clean them up and restart them through a known interface. A node is managed only if it implements the lifecycle interface; ordinary nodes do not acquire lifecycle behavior automatically.[16]

Real-time use

ROS 2 was designed to make time-critical systems more feasible than the original ROS architecture, but installing ROS 2 does not make an application deterministic. The official real-time design guidance identifies latency, update period, and predictability as application-specific requirements. It also calls out sources of nondeterminism such as page faults, dynamic allocation, synchronization, and operating-system scheduling.[17]

ROS 2 C++ APIs support custom allocators for publishers, subscriptions, and executors so that an application can avoid the default heap allocator in a critical execution section. This is one engineering mechanism, not a proof that the complete path meets a deadline.[18]

Published performance studies have found that results depend on transport, process placement, QoS, message size, and implementation details.[19] Response-time research likewise models both ROS executors and host scheduling, because callbacks can form processing chains across processes, cores, and hosts. A real-time deployment therefore needs bounded workloads, an appropriate kernel or real-time operating system, scheduling and priority configuration, resource control, and measurement or schedulability analysis for the actual application.[20]

Security

ROS 2 integrates with the DDS Security specification. The ROS design maps DDS Security functions to authentication, access control, and cryptographic protection. SROS2 provides tools for creating keys, certificates, governance files, permission policies, keystores, and security enclaves.[21]

These facilities are configurable rather than automatic. A deployment must create and protect its key material, define which graph operations are allowed, distribute the correct artifacts, enable security, and decide how to handle participants that cannot be authenticated. The ROS keystore separates public, private, and enclave materials and can be integrated with an organization's public key infrastructure.[22]

Research on SROS2 describes both tooling and a process for modeling a ROS graph, generating policies and artifacts, deploying them, and monitoring the result. It also notes usability and human-error risks in security configuration.[23] Encrypting ROS traffic does not replace host hardening, dependency updates, network segmentation, credential rotation, physical safety controls, or an application-specific threat model.

Embedded systems and micro-ROS

Small microcontrollers often cannot host a full desktop ROS 2 stack. micro-ROS brings ROS 2 client concepts to supported microcontroller and real-time operating-system environments. Its architecture uses a client on the embedded target and an agent that connects the client to the wider ROS 2 system, commonly through the DDS-XRCE protocol. It also provides the C-oriented rclc client layer.[2][24]

micro-ROS does not mean that every ROS 2 package can run unchanged on a microcontroller. Memory, operating-system support, transport, generated interfaces, executor configuration, and agent availability remain deployment constraints.

Tools and related projects

ROS 2's ros2 command is the entry point for tools that inspect or interact with nodes, topics, services, actions, parameters, interfaces, components, lifecycle nodes, and recorded data. The command-line graph view may use a background daemon to cache discovery information.[25]

The launch system describes which programs to run, their arguments and ROS-specific configuration, and how to react to process events. ROS 2 launch files can be written in Python, XML, or YAML.[26] Other widely used facilities include:

rosbag2 for recording and replaying typed message streams.
tf2 for tracking coordinate-frame transformations over time.
RViz for visualization and interactive inspection.
Gazebo and other simulators for testing robots and environments.
Nav2 for ROS 2 navigation and MoveIt for motion planning and manipulation.

These projects have separate repositories, maintainers, releases, and compatibility matrices. Being commonly used with ROS does not make every version part of the ROS core or supported on every ROS distribution.

Migration from ROS 1

Migration is usually a port, not an in-place upgrade. A package may preserve much of its implementation or may be replaced by a differently structured ROS 2 package. Before a ROS 1 package can be migrated, its dependencies must exist on ROS 2. Package manifests, dependency names, build files, node APIs, parameter handling, launch files, and communication assumptions may all require changes.[12]

The ros1_bridge can exchange supported messages and services between ROS 1 and ROS 2 systems. Prebuilt bridges contain common interface types; custom types require the bridge to be built from source after both the ROS 1 and ROS 2 interfaces are available. The bridge only supports types compiled into it. ROS 1 Noetic is not supported on Ubuntu 24.04, so that platform cannot provide the ROS 1 side required by the bridge.[27]

ROS 1 Noetic reached end of life on May 31, 2025. The ROS team stopped providing new features, security updates, bug fixes, support, and updated binaries. Existing binaries remain hosted and existing installations do not stop running solely because of the date, but continued operation carries growing platform, dependency, and security risk.[28]

Distributions and support status

A ROS distribution is a coordinated, versioned set of packages. Stable distributions limit breaking changes in core packages, while higher-level community packages can follow less strict policies. The official distribution table and each package's own release status should both be checked before selecting a platform.[7][29]

As of July 28, 2026, the official ROS 2 distribution table listed these maintained stable releases:

Distribution	Released	Published end of life
Humble Hawksbill	May 23, 2022	May 2027
Jazzy Jalisco	May 23, 2024	May 2029
Kilted Kaiju	May 23, 2025	December 2026
Lyrical Luth	May 22, 2026	May 2031

Lyrical Luth is the twelfth ROS 2 release and a long-term support release.[30] Rolling Ridley is a continuously updated development distribution and staging area for future stable releases. Rolling can receive breaking changes in place, so the ROS documentation recommends a current stable distribution for most users.[7]

Support also depends on the target platform. The ROS platform policy removes build-farm jobs after a vendor platform reaches end of life, even if the ROS distribution itself remains active. Previously built packages may remain available but stop receiving updates for that platform.[31] Published end-of-life dates are therefore necessary but not sufficient for choosing a deployment: the operating system, architecture, middleware, and required packages must all be within their supported combinations.

Limitations

ROS reduces integration work, but it does not remove system-engineering constraints:

Distributed discovery and message delivery depend on network and middleware configuration.
QoS mismatches can prevent endpoints from communicating.
Security requires keys, policies, deployment procedures, and maintenance.
Real-time performance depends on the complete software and hardware path.
Community packages differ in quality, documentation, maintenance, licensing, and release coverage.
Large graphs can be difficult to observe, reproduce, and debug without disciplined naming, logging, launch configuration, and interface ownership.
A supported distribution does not imply that every package or third-party driver is maintained for its entire lifetime.

The practical value of ROS is its common graph model, reusable interfaces, and shared tooling. Reliability still depends on validating the exact packages, versions, middleware, network, operating system, and robot hardware used in a deployment.

See also

Robotics
Data Distribution Service
Open-source AI
Robot learning
Simultaneous localization and mapping
Multi-robot systems

References

Quigley, M., et al. (2009). ROS: an open-source Robot Operating System. ICRA Workshop on Open Source Software. https://ai.stanford.edu/~mquigley/papers/icra2009-ros.pdf
Macenski, S., et al. (2022). Robot Operating System 2: Design, architecture, and uses in the wild. Science Robotics, 7(66), eabm6074. https://arxiv.org/pdf/2211.07752
Open Robotics. (2020). Noetic Ninjemys: The Last Official ROS 1 Release. https://www.openrobotics.org/blog/2020/5/23/noetic-ninjemys-the-last-official-ros-1-release
Open Robotics. (2022). A Decade of Open Robotics. https://www.openrobotics.org/blog/2022/3/22/a-decade-of-open-robotics
Open Robotics. (2024). Announcing the Open Source Robotics Alliance. https://www.openrobotics.org/blog/2024/3/18/announcing-the-open-source-robotics-alliance-osra
Open Source Robotics Alliance. (2024). Charter of the Open Source Robotics Alliance Project "ROS." https://osralliance.org/wp-content/uploads/2024/03/ros_project_charter.pdf
ROS 2 Documentation. Distributions. https://docs.ros.org/en/lyrical/Releases.html
ROS 2 Documentation. Nodes. https://docs.ros.org/en/lyrical/Concepts/Basic/About-Nodes.html
ROS 2 Documentation. Client libraries. https://docs.ros.org/en/lyrical/Concepts/Basic/About-Client-Libraries.html
colcon Documentation. What is a Workspace? https://colcon.readthedocs.io/en/released/user/what-is-a-workspace.html
ROS 2 Documentation repository. Package Docs. https://raw.githubusercontent.com/ros2/ros2_documentation/rolling/source/Developer-Tools/Build/Package-Docs.rst
ROS 2 Documentation. Migrating Packages. https://docs.ros.org/en/kilted/How-To-Guides/Migrating-from-ROS1/Migrating-Packages.html
ROS 2 Design. Changes between ROS 1 and ROS 2. https://design.ros2.org/articles/changes.html
ROS 2 Documentation. Different ROS 2 middleware vendors. https://docs.ros.org/en/lyrical/Concepts/Intermediate/About-Different-Middleware-Vendors.html
ROS 2 Documentation. Quality of Service settings. https://docs.ros.org/en/lyrical/Concepts/Intermediate/About-Quality-of-Service-Settings.html
ROS 2 Design. Managed nodes. https://design.ros2.org/articles/node_lifecycle.html
ROS 2 Design. Proposal for Implementation of Real-time Systems in ROS 2. https://design.ros2.org/articles/realtime_proposal.html
ROS 2 Documentation. Implementing a custom memory allocator. https://docs.ros.org/en/lyrical/Tutorials/Advanced/Allocator-Template-Tutorial.html
Maruyama, Y., Kato, S., and Azumi, T. (2016). Exploring the Performance of ROS2. Proceedings of the 13th International Conference on Embedded Software. https://web.ics.purdue.edu/~rvoyles/Classes/ROS_MFET642/Maruyama.ExploringROS2.2016.pdf
Casini, D., Blass, T., Lütkebohle, I., and Brandenburg, B. B. (2019). Response-Time Analysis of ROS 2 Processing Chains Under Reservation-Based Scheduling. ECRTS 2019. https://t-blass.de/papers/ecrts19-rev1.pdf
ROS 2 Design. ROS 2 DDS-Security integration. https://design.ros2.org/articles/ros2_dds_security.html
ROS 2 Documentation. Understanding the security keystore. https://docs.ros.org/en/lyrical/Tutorials/Advanced/Security/The-Keystore.html
Mayoral-Vilches, V., et al. (2022). SROS2: Usable Cyber Security Tools for ROS 2. 2022 IEEE/RSJ International Conference on Intelligent Robots and Systems. https://arxiv.org/pdf/2208.02615
micro-ROS. (2020). micro-ROS at ROS in 2020. https://micro-ros.github.io/download/ROSIn2020-FrancescaFinocchiaro.pdf
ROS 2 Documentation. Introspection with command line tools. https://docs.ros.org/en/lyrical/Concepts/Basic/About-Command-Line-Tools.html
ROS 2 Documentation. Creating a launch file. https://docs.ros.org/en/lyrical/Tutorials/Intermediate/Launch/Creating-Launch-Files.html
ros2/ros1_bridge. Bridge communication between ROS 1 and ROS 2. https://raw.githubusercontent.com/ros2/ros1_bridge/master/README.md
ROS. Upcoming ROS 1 End of Life. https://www.ros.org/blog/noetic-eol/
REP 2000. ROS 2 Releases and Target Platforms. https://ros.org/reps/rep-2000.html
ROS 2 Documentation. Lyrical Luth. https://docs.ros.org/en/lyrical/Releases/Release-Lyrical-Luth.html
ROS 2 Documentation. Platform EOL Policy. https://docs.ros.org/en/lyrical/The-ROS2-Project/Platform-EOL-Policy.html

Editing: Robot Operating System (ROS)