# Robot Operating System (ROS)

> Source: https://aiwiki.ai/wiki/robot_operating_system
> Updated: 2026-07-30
> Fact-checked: 2026-07-30
> Categories: AI Tools & Products, Open Source AI, Robotics
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) - attribute to "AI Wiki (aiwiki.ai)"
> Cite as: AI Wiki. "Robot Operating System (ROS)." aiwiki.ai, 30 Jul 2026. https://aiwiki.ai/wiki/robot_operating_system
> From AI Wiki (https://aiwiki.ai), the free encyclopedia of artificial intelligence. Reuse freely with attribution.

**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](https://aiwiki.ai/wiki/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](https://aiwiki.ai/wiki/gazebo_simulator) 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](https://aiwiki.ai/wiki/robotics)
- Data Distribution Service
- [Open-source AI](https://aiwiki.ai/wiki/open_source_ai)
- [Robot learning](https://aiwiki.ai/wiki/robot_learning)
- [Simultaneous localization and mapping](https://aiwiki.ai/wiki/slam)
- Multi-robot systems

## References

1. 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
2. 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
3. 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
4. Open Robotics. (2022). A Decade of Open Robotics. https://www.openrobotics.org/blog/2022/3/22/a-decade-of-open-robotics
5. Open Robotics. (2024). Announcing the Open Source Robotics Alliance. https://www.openrobotics.org/blog/2024/3/18/announcing-the-open-source-robotics-alliance-osra
6. 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
7. ROS 2 Documentation. Distributions. https://docs.ros.org/en/lyrical/Releases.html
8. ROS 2 Documentation. Nodes. https://docs.ros.org/en/lyrical/Concepts/Basic/About-Nodes.html
9. ROS 2 Documentation. Client libraries. https://docs.ros.org/en/lyrical/Concepts/Basic/About-Client-Libraries.html
10. colcon Documentation. What is a Workspace? https://colcon.readthedocs.io/en/released/user/what-is-a-workspace.html
11. ROS 2 Documentation repository. Package Docs. https://raw.githubusercontent.com/ros2/ros2_documentation/rolling/source/Developer-Tools/Build/Package-Docs.rst
12. ROS 2 Documentation. Migrating Packages. https://docs.ros.org/en/kilted/How-To-Guides/Migrating-from-ROS1/Migrating-Packages.html
13. ROS 2 Design. Changes between ROS 1 and ROS 2. https://design.ros2.org/articles/changes.html
14. ROS 2 Documentation. Different ROS 2 middleware vendors. https://docs.ros.org/en/lyrical/Concepts/Intermediate/About-Different-Middleware-Vendors.html
15. ROS 2 Documentation. Quality of Service settings. https://docs.ros.org/en/lyrical/Concepts/Intermediate/About-Quality-of-Service-Settings.html
16. ROS 2 Design. Managed nodes. https://design.ros2.org/articles/node_lifecycle.html
17. ROS 2 Design. Proposal for Implementation of Real-time Systems in ROS 2. https://design.ros2.org/articles/realtime_proposal.html
18. ROS 2 Documentation. Implementing a custom memory allocator. https://docs.ros.org/en/lyrical/Tutorials/Advanced/Allocator-Template-Tutorial.html
19. 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
20. 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
21. ROS 2 Design. ROS 2 DDS-Security integration. https://design.ros2.org/articles/ros2_dds_security.html
22. ROS 2 Documentation. Understanding the security keystore. https://docs.ros.org/en/lyrical/Tutorials/Advanced/Security/The-Keystore.html
23. 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
24. micro-ROS. (2020). micro-ROS at ROS in 2020. https://micro-ros.github.io/download/ROSIn2020-FrancescaFinocchiaro.pdf
25. ROS 2 Documentation. Introspection with command line tools. https://docs.ros.org/en/lyrical/Concepts/Basic/About-Command-Line-Tools.html
26. ROS 2 Documentation. Creating a launch file. https://docs.ros.org/en/lyrical/Tutorials/Intermediate/Launch/Creating-Launch-Files.html
27. ros2/ros1_bridge. Bridge communication between ROS 1 and ROS 2. https://raw.githubusercontent.com/ros2/ros1_bridge/master/README.md
28. ROS. Upcoming ROS 1 End of Life. https://www.ros.org/blog/noetic-eol/
29. REP 2000. ROS 2 Releases and Target Platforms. https://ros.org/reps/rep-2000.html
30. ROS 2 Documentation. Lyrical Luth. https://docs.ros.org/en/lyrical/Releases/Release-Lyrical-Luth.html
31. ROS 2 Documentation. Platform EOL Policy. https://docs.ros.org/en/lyrical/The-ROS2-Project/Platform-EOL-Policy.html