Robot Operating System (ROS)
Last reviewed
Sources
30 citations
Review status
Source-backed
Revision
v5 · 6,404 words
Improve this article
Add missing citations, update stale details, or suggest a clearer explanation.
Suggest edit
CtrlK
Last reviewed
Sources
30 citations
Review status
Source-backed
Revision
v5 · 6,404 words
Add missing citations, update stale details, or suggest a clearer explanation.
The Robot Operating System (ROS) is an open-source robotics middleware suite that provides software libraries, tools, and conventions for developing robot applications. Despite its name, ROS is not a traditional operating system. As the original 2009 paper put it, ROS "is not an operating system in the traditional sense of process management and scheduling; rather, it provides a structured communications layer above the host operating systems of a heterogenous compute cluster."[1] It functions as a meta-operating system layer that sits on top of a host OS (typically Linux) and provides hardware abstraction, low-level device control, message passing between processes, and package management.[1] Since its origins at Stanford University and Willow Garage in the mid-2000s, ROS has grown into the de facto standard framework for robotics software development worldwide, used by researchers, hobbyists, and commercial companies alike: by 2022 more than 740 commercial companies reported using ROS, and over 501 million ROS packages were downloaded in that single year.[4][20] The shorter encyclopedia entry on the framework lives at ROS; this article serves as the comprehensive reference.
ROS exists in two parallel lineages. The original ROS, retrospectively called ROS 1, was designed for academic research on single robots in controlled environments and reached end of life in May 2025.[18] ROS 2 is a ground-up redesign built on the Data Distribution Service standard.[7] It targets production deployment, real-time control, security-conscious systems, and multi-robot fleets.[25] As of 2026 the ecosystem is fully oriented around ROS 2, with the Jazzy Jalisco LTS release providing a stable foundation through 2029 and the Rolling Ridley distribution serving as a continuously updated development branch.[5]
The earliest components of what would become ROS took shape at Stanford University around 2006 and 2007.[3] Morgan Quigley, a PhD student at the Stanford Artificial Intelligence Laboratory, developed a software framework called Switchyard as part of the Stanford AI Robot (STAIR) project, a platform for research in general-purpose robotic manipulation and perception.[3] Switchyard addressed a recurring problem in academic robotics: every new research project required significant effort to build basic infrastructure before any real research could begin.[3]
At the same time, Eric Berger and Keenan Wyrobek were PhD students in Kenneth Salisbury's robotics laboratory at Stanford, leading the Personal Robotics Program.[3] They built the PR1 (Personal Robot 1) prototype and envisioned creating a Linux for robotics that would let researchers share code across different robot platforms.[3] The two efforts converged when Berger and Wyrobek connected with Scott Hassan, a technology entrepreneur who had founded Willow Garage in late 2006 in Menlo Park, California.[2] Hassan shared their vision and invited them to pursue the idea full-time at Willow Garage.[2]
The seminal 2009 paper laid out five philosophical goals that drove the framework's architecture, and these principles still explain why ROS looks the way it does:[1]
| Design goal | What it means |
|---|---|
| Peer-to-peer | A system built with ROS is a set of processes, potentially across many hosts, connected at runtime in a peer-to-peer topology rather than routed through a central server for message traffic. |
| Multi-lingual | ROS is language-neutral. The 2009 paper supported C++, Python, Octave, and LISP, with message definitions compiled into native code for each language. |
| Tools-based | Rather than a monolithic runtime, ROS ships a large set of small command-line and graphical tools for building, introspecting, and debugging systems. |
| Thin | Algorithms are meant to live in standalone libraries that have no dependency on ROS, so code stays reusable outside the framework and is easier to extract. |
| Free and open-source | The full source is released under a permissive license to encourage debugging, collaboration, and reuse across the research community. |
In 2007, Morgan Quigley began collaborating with Willow Garage, and the first commit of ROS code was made to SourceForge on November 7, 2007.[4] Over the next two years, Quigley oversaw the core ROS architecture while Willow Garage's growing engineering team extended and refined the framework.[2] A key advantage during this period was that ROS prototypes were simultaneously driving both the PR2 robot at Willow Garage and multiple Stanford robots, which forced the design to be sufficiently general rather than tailored to a single platform.[2]
Willow Garage developed the PR2 robot, which became an important testbed and reference platform for the ROS community.[2] The company distributed PR2 units to leading research institutions, seeding a global community of ROS developers.[2] Early tutorials on ROS were posted in December 2008, and ROS 1.0 was released on January 22, 2010.[4] The first official distribution, ROS Box Turtle, followed on March 2, 2010.[4]
The seminal paper describing the framework, ROS: an open-source Robot Operating System by Quigley, Conley, Gerkey, Faust, Foote, Leibs, Wheeler, and Ng, appeared in the Open-Source Software workshop at the IEEE International Conference on Robotics and Automation (ICRA) in 2009.[1] The paper laid out the rationale for treating robotics software as a structured communications layer above a heterogeneous compute cluster rather than as a monolithic application, and it became one of the most cited works in modern robotics.[1]
As ROS adoption grew rapidly among researchers and began attracting commercial interest, it became clear that the project needed an independent steward. In May 2012, the Open Source Robotics Foundation (OSRF) was established to shepherd the ongoing development of ROS and the Gazebo simulator.[4] OSRF's initial backers included Willow Garage and DARPA, which awarded OSRF its first contract to support open-source simulation software for the DARPA Robotics Challenge.[4]
Willow Garage itself wound down operations in early 2014, but by then ROS had achieved sufficient momentum and community support to continue thriving under OSRF's stewardship.[2] In September 2016, a taxable subsidiary named the Open Source Robotics Corporation (OSRC) was created to enable greater collaboration with industry.[4] Together with OSRF, these organizations came to be known collectively as Open Robotics in May 2017.[4]
In December 2022, Alphabet's robotics subsidiary Intrinsic acquired the Open Source Robotics Corporation and its Singapore office (OSRC-SG).[17] The nonprofit OSRF remained independent and unaffected by the acquisition, continuing its oversight of ROS and Gazebo.[17]
In March 2024, OSRF announced the creation of the Open Source Robotics Alliance (OSRA), a new governance initiative modeled after organizations like The Linux Foundation.[15] OSRA commenced operations on April 15, 2024, and uses a mixed membership and meritocratic model to provide the community with greater involvement in the technical direction of ROS, Gazebo, and Open-RMF.[15] At ROSCon 2025 in Singapore, OSRA chartered a new Physical AI Special Interest Group focused on real-time robot control, accelerated AI processing, and tooling for autonomous behavior, formalizing the convergence of large neural models with traditional robotics middleware.[20]
At its core, ROS organizes software into a distributed computation graph. The fundamental building blocks of this graph are nodes, topics, messages, services, actions, and parameters.[1]
| Concept | Description |
|---|---|
| Nodes | Individual processes that perform computation. A robot control system typically consists of many nodes, each responsible for a specific task such as sensor processing, motor control, or path planning. |
| Topics | Named buses over which nodes exchange messages using a publish-subscribe pattern. A node that produces data publishes messages to a topic, and any node interested in that data subscribes to the same topic. |
| Messages | Typed data structures used for communication. ROS defines standard message types for common data such as sensor readings, joint states, and poses, and developers can define custom message types as needed. |
| Services | A synchronous request-reply mechanism for communication that does not fit the publish-subscribe pattern. A service has a defined request and response type, and a node calls the service and waits for the result. |
| Actions | An asynchronous mechanism for long-running tasks. Actions extend the service model with feedback during execution and the ability to cancel goals. |
| Parameters | Configuration values that nodes can get and set at runtime, enabling dynamic reconfiguration without restarting processes. |
The publish-subscribe model is the primary communication pattern. Nodes are loosely coupled: a publisher does not need to know which nodes are subscribing, and subscribers do not need to know which nodes are publishing.[1] This decoupling makes it straightforward to add, remove, or replace nodes without modifying other parts of the system. Switching from a simulated laser scanner to a physical lidar requires changing only the driver node; all downstream subscribers continue to work without modification.
ROS software is organized into packages, the smallest buildable and releasable units. Each package contains source code, build files, configuration, launch files, and documentation, described by a package.xml manifest. Packages are developed within workspaces, which contain a src folder with one or more packages. The build tool compiles all packages in the workspace and manages their interdependencies, so a robot project typically pulls together hundreds of upstream packages alongside a small number of project-specific packages built from source.
ROS has used several build systems over its history. The progression reflects a long migration from custom CMake macros toward fully standard CMake plus modular meta-build tools.
| Build System | ROS Version | Description |
|---|---|---|
| rosbuild | ROS 1 (Box Turtle through Fuerte) | The original build system. Wrapped CMake commands in custom macros, built packages in-source, and lacked proper install targets. |
| catkin | ROS 1 (Fuerte onward) | Replaced rosbuild starting with the Fuerte distribution. Built on CMake more cleanly, supported out-of-source builds, parallel compilation of interdependent packages, and proper install targets. |
| ament | ROS 2 | The build system for ROS 2, with ament_cmake and ament_python as the recommended build types. |
| colcon | ROS 2 | The meta-build tool for ROS 2 that iterates on catkin_make, catkin_tools, and ament_tools. Supports multiple build types including ament_cmake, ament_python, and pure CMake. |
The original ROS, now referred to as ROS 1, was designed primarily for academic research on single robots operating in controlled environments. Its architecture relies on a central ROS Master node (roscore) that provides name registration and lookup services so that nodes can find each other.[9] While this design simplified development, it introduced a single point of failure and made multi-robot systems more complex to configure.[9]
ROS 1 supports two primary client libraries: roscpp for C++ and rospy for Python.[29] Communication between nodes uses a custom TCP-based protocol called TCPROS, with optional UDP support through UDPROS for low-latency or lossy links.[9] The master directs initial node discovery, after which nodes establish direct peer-to-peer connections for actual message traffic.[9]
ROS 1 followed an alphabetically named distribution scheme, with each name referencing a turtle species (a nod to the project's educational roots and the Turtlesim simulator). New distributions were initially released roughly every six months, later shifting to an annual cadence. Long-term support (LTS) releases, tied to Ubuntu LTS versions, received five years of support.[6]
| Distribution | Release Date | EOL Date | Target Ubuntu | Notes |
|---|---|---|---|---|
| Box Turtle | March 2010 | First official distribution | ||
| C Turtle | August 2010 | |||
| Diamondback | March 2011 | |||
| Electric Emys | August 2011 | |||
| Fuerte Turtle | April 2012 | Introduced catkin build system | ||
| Groovy Galapagos | December 2012 | July 2014 | 12.04 | |
| Hydro Medusa | September 2013 | May 2015 | 12.04/13.04 | |
| Indigo Igloo | July 2014 | April 2019 | 14.04 | First LTS release |
| Jade Turtle | May 2015 | May 2017 | 14.04/15.04 | |
| Kinetic Kame | May 2016 | April 2021 | 16.04 | LTS |
| Lunar Loggerhead | May 2017 | May 2019 | 17.04 | |
| Melodic Morenia | May 2018 | May 2023 | 18.04 | LTS |
| Noetic Ninjemys | May 2020 | May 2025 | 20.04 | Final ROS 1 release, LTS |
ROS Noetic Ninjemys was the last ROS 1 distribution. Its end-of-life date of May 31, 2025 marked the official end of ROS 1 as an actively maintained project.[18] The final package sync (noetic/2025-05-29) was the 89th and last for ROS Noetic.[18] After that date, security fixes and new features for ROS 1 were no longer published, although source repositories remain available and a few community forks continue to apply patches for legacy installations.[18]
ROS 2 is a ground-up redesign of the framework, initiated to address the limitations of ROS 1 for production, safety-critical, and multi-robot deployments.[25] The 2022 Science Robotics paper documenting the rewrite states that ROS 2 and its related projects "have been redesigned from the ground up to address the challenges set forth by modern robotic systems in new and exploratory domains at all scales."[25] Development of ROS 2 began around 2014, with the first alpha releases in 2015 and the first official distribution (Ardent Apalone) released in December 2017.[5] Rather than incrementally evolving ROS 1, the ROS 2 team chose a fresh codebase so that long-standing architectural compromises, especially the central master and custom transport, could be replaced rather than wrapped.[9]
DDS Middleware. The most significant architectural change in ROS 2 is its adoption of the Data Distribution Service (DDS) as the underlying communication middleware.[7] DDS is an Object Management Group (OMG) standard originally developed for military, aerospace, and industrial systems including air traffic control, financial trading, and naval combat systems.[7] ROS 2 wraps DDS behind an abstract middleware interface (rmw) that provides:[7]
Real-Time Capabilities. ROS 2 includes improved support for real-time computing. The DDS QoS system enables low-latency, high-throughput data exchange, and the framework supports deterministic execution through careful memory management and threading models.[25] While not a hard real-time system by default, ROS 2 can be configured to meet soft real-time requirements when paired with a real-time operating system kernel such as PREEMPT_RT Linux. Researchers benchmarking ROS 2 against ROS 1 have repeatedly demonstrated lower jitter and tighter latency bounds, although careful tuning of the DDS implementation, executor, and memory allocator is required to reach the best numbers.[26]
Security. ROS 2 integrates the DDS Security specification, which provides authentication, encryption, and access control at the topic level.[8] This enables fine-grained security policies where different data flows can have different security levels on the same network, an essential property for industrial deployments where command-and-control traffic must be protected while telemetry can flow freely.[8]
Multi-Robot Support. The elimination of the central ROS Master and the use of DDS domains make ROS 2 inherently better suited for multi-robot systems.[25] Robots can discover each other on the network without pre-configuration, and DDS domain IDs allow logical separation of communication between different robot groups operating on the same physical network.[7]
Cross-Platform Support. ROS 2 officially supports Linux (Ubuntu), Windows, and macOS, broadening its accessibility beyond the Linux-only support of ROS 1.[5] Build artifacts and continuous-integration infrastructure cover all three platforms.[5]
Lifecycle Nodes. ROS 2 introduces managed lifecycle nodes with well-defined states (unconfigured, inactive, active, finalized), giving developers explicit control over node initialization, activation, and shutdown sequences.[25] This makes startup ordering deterministic and allows orchestrators to bring large robot stacks online in a controlled fashion.
The practical difference between the two lineages comes down to a handful of architectural decisions. ROS 2 replaced the central ROS Master with decentralized DDS discovery, swapped the custom TCPROS transport for DDS (and, from the Kilted Kaiju release, Zenoh), and added built-in security, native multi-robot support, and managed lifecycle nodes that ROS 1 lacked. The full comparison appears in the Comparison of ROS 1 and ROS 2 table below.
Starting with the Kilted Kaiju release in May 2025, ROS 2 added Tier 1 support for Eclipse Zenoh as an alternative middleware, marking the first time a non-DDS middleware was officially supported at the highest tier.[22] Zenoh offers advantages for certain use cases including lower overhead on constrained devices, better performance over wide-area networks, and a unified data model that spans pub-sub, queries, and storage.[22]
ROS 2 follows an annual release schedule, with new distributions released on May 23 (World Turtle Day). Even-year releases are LTS versions with five years of support; odd-year releases receive approximately 18 months of support.[5] Each release targets a specific Ubuntu LTS as its primary platform.[5]
| Distribution | Release Date | EOL Date | Type | Target Ubuntu |
|---|---|---|---|---|
| Ardent Apalone | December 2017 | December 2018 | Non-LTS | 16.04 |
| Bouncy Bolson | June 2018 | June 2019 | Non-LTS | 18.04 |
| Crystal Clemmys | December 2018 | December 2019 | Non-LTS | 18.04 |
| Dashing Diademata | May 2019 | May 2021 | LTS | 18.04 |
| Eloquent Elusor | November 2019 | November 2020 | Non-LTS | 18.04 |
| Foxy Fitzroy | May 2020 | May 2023 | LTS | 20.04 |
| Galactic Geochelone | May 2021 | November 2022 | Non-LTS | 20.04 |
| Humble Hawksbill | May 2022 | May 2027 | LTS | 22.04 |
| Iron Irwini | May 2023 | November 2024 | Non-LTS | 22.04 |
| Jazzy Jalisco | May 2024 | May 2029 | LTS | 24.04 |
| Kilted Kaiju | May 2025 | November 2026 | Non-LTS | 24.04 |
| Lyrical Luth (planned) | May 2026 | November 2027 | Non-LTS | 24.04 |
| Rolling Ridley | June 2020 | Ongoing | Rolling | Latest |
Rolling Ridley is a continuously updated development distribution that serves as a staging area for future stable releases.[5] Unlike stable distributions, Rolling receives frequent updates that may include breaking changes, and library maintainers are expected to keep their packages building on Rolling so that the next stable cut requires minimal extra work.[5]
The ROS 2 ecosystem includes thousands of community-maintained packages. The following table highlights the most widely deployed building blocks, all of which form the foundation of typical robot stacks.
| Package | Domain | Purpose |
|---|---|---|
| Nav2 | Navigation | Behavior-tree-driven autonomous navigation stack for mobile robots |
| MoveIt 2 | Manipulation | Motion planning, kinematics, and collision checking for robot arms |
| ros2_control | Control | Hardware-agnostic real-time control framework with pluggable controllers |
| Cartographer | SLAM | Google's 2D and 3D lidar SLAM system, ported to ROS 2 |
| slam_toolbox | SLAM | Recommended ROS 2 SLAM solution with online and offline mapping |
| RViz2 | Visualization | 3D visualization of sensor data, robot models, and plans |
| rqt | Tooling | Qt-based graphical tool framework for introspection and debugging |
| tf2 | Transforms | Spatial coordinate-frame management library |
| ros_gz | Simulation | Bridge between ROS 2 and modern Gazebo |
| Isaac ROS | Acceleration | NVIDIA's CUDA-accelerated perception and planning packages |
| micro-ROS | Embedded | ROS 2 client for microcontrollers using DDS-XRCE |
Nav2 is the second generation of the ROS navigation stack, designed for ROS 2. It provides a complete autonomous navigation solution for mobile robots, including global and local path planning, obstacle avoidance, recovery behaviors, and waypoint following.[11] Nav2 replaced the original ROS Navigation Stack's finite state machine architecture with behavior trees, offering greater flexibility and modularity.[26] Key components include:
Nav2 supports multiple planning algorithms including NavFn, Smac Planner (2D, Hybrid-A*, and lattice-based), and Theta*.[11] It is widely used on differential-drive robots, Ackermann-steering vehicles, and omnidirectional platforms, from cleaning robots to delivery couriers to industrial AMRs.[26]
MoveIt is the most widely used open-source framework for robotic manipulation, supporting over 150 different robots.[10] Its first commit was made in October 2011, and it was initially developed at Willow Garage by Sachin Chitta, Ioan Sucan, and other team members.[10] SRI International supported MoveIt between October 2013 and June 2015.[10] Since 2015, PickNik Robotics has led the maintenance and development of the project.[10]
MoveIt 2 is the ROS 2 port of MoveIt, incorporating the latest advances in motion planning, 3D perception, kinematics, control, and navigation.[10] Its capabilities include:
ros2_control is the hardware-agnostic real-time control framework for ROS 2. It defines a clean separation between hardware interfaces (which expose joints, sensors, and actuators) and controllers (which implement closed-loop logic such as joint trajectory tracking, admittance control, or differential-drive kinematics).[12] Both Nav2 and MoveIt consume the controller interfaces exposed by ros2_control, which means that swapping a robot's actuation backend rarely requires touching application code.[12] Practical industrial deployments increasingly bridge ros2_control to fieldbus standards such as EtherCAT, CANopen, and Modbus.
Simultaneous Localization and Mapping (SLAM) is a critical capability for mobile robots operating in unknown environments. The ROS ecosystem includes several SLAM implementations:
The ROS perception stack provides tools for processing sensor data from cameras, depth sensors, and lidar. image_pipeline bridges raw camera drivers and higher-level computer vision applications including calibration, rectification, and stereo processing. vision_opencv (cv_bridge) provides a bridge between ROS image messages and OpenCV representations. pcl_ros integrates with the Point Cloud Library for 3D point cloud processing, filtering, segmentation, and feature extraction.
NVIDIA Isaac ROS is a collection of CUDA-accelerated ROS 2 packages that leverage GPU hardware for high-performance perception and planning.[19] Key modules include Isaac ROS Visual SLAM, nvBlox for 3D mapping, cuMotion for GPU-accelerated motion planning, and ESS for stereo depth.[19] The NITROS (NVIDIA Isaac Transport for ROS) system enables efficient zero-copy GPU memory sharing between ROS 2 nodes, avoiding unnecessary CPU-GPU data transfers that historically dominated the cost of running deep models inside a ROS pipeline.[19]
In August 2025 NVIDIA released the Jetson Thor developer kit and production modules, a Blackwell-class robotics computer offering roughly 7.5 times the AI compute and 3.5 times the energy efficiency of the previous Jetson Orin platform.[21] At ROSCon 2025 in Singapore, NVIDIA announced Isaac ROS 4.0 running on Jetson Thor, contributed GPU-aware abstractions directly into the ROS 2 framework, and joined the new OSRA Physical AI Special Interest Group.[20]
Gazebo is a physics-based robot simulator tightly integrated with ROS. Originally developed alongside ROS at Willow Garage, Gazebo allows developers to test robot software in realistic virtual environments before deploying to physical hardware.[24]
Gazebo Classic (versions numbered 1 through 11) was the long-standing simulation platform for the ROS community. Gazebo 11, released in January 2020, was the final Classic release.[24] Gazebo Classic was retired in 2025, with the modern Gazebo line taking over.[24]
A complete rewrite of Gazebo, originally developed under the name Ignition, was renamed back to simply Gazebo in 2022 (after the Ignition trademark dispute was resolved).[24] Modern Gazebo uses lettered release names and features a modular architecture with improved rendering, physics, and sensor simulation. Key releases include:
| Release | Date | Support |
|---|---|---|
| Fortress | September 2021 | 5 years (LTS) |
| Garden | September 2022 | Through November 2024 |
| Harmonic | September 2023 | 5 years (LTS) |
| Ionic | September 2024 | 2 years |
| Jetty | September 2025 | 5 years (LTS) |
Modern Gazebo communicates with ROS through the ros_gz bridge package, which provides bidirectional message transport between Gazebo Transport and ROS topics. Alongside Gazebo, NVIDIA Isaac Sim has emerged as a complementary high-fidelity GPU-accelerated simulator, particularly for training reinforcement learning agents and for synthetic-data generation. The two tools are converging on a shared ROS 2 simulation interface that NVIDIA and Robotec.ai jointly proposed at ROSCon 2025.[20]
Not every robot can carry a Linux SBC. micro-ROS is a project that brings the ROS 2 client API onto microcontrollers ranging from low-power Cortex-M parts to mid-range 32-bit MCUs.[27] The architecture follows a client-agent model: a micro-ROS client runs on the MCU and exchanges messages over a serial, UDP, or CAN link with a micro-ROS Agent on a companion computer, which in turn bridges into the standard DDS network used by the rest of the robot.[27] On the wire it uses DDS-XRCE (DDS for Extremely Resource-Constrained Environments), an OMG standard designed for tens of kilobytes of RAM rather than the megabytes a full DDS implementation requires.[27]
micro-ROS supports several real-time operating systems including FreeRTOS, Zephyr, NuttX, and bare-metal builds.[27] Its client API is built on rclc, the ROS Client Library for C, plus a set of convenience helpers tuned for static memory allocation and predictable timing.[27] Bosch, Eclipse Foundation, and a consortium of European partners drive much of the upstream development under the OFERA project umbrella.[27]
ROS-Industrial (ROS-I) is an open-source project that extends ROS capabilities to manufacturing and industrial automation.[13] Launched in 2012 with the formation of the ROS-Industrial Consortium, the project is led by three regional organizations:[13]
The consortium's members include major industrial companies such as ABB, Siemens, Universal Robots, Yaskawa, BMW, 3M, and Bosch, among others.[13] Members drive development through Focused Technical Projects (FTPs) based on near-term automation needs, and the consortium provides training, technical support, and roadmap planning for ROS-I.[13] The ROS-Industrial Europe Conference 2025, held in Strasbourg in November 2025, highlighted production-oriented applications including robotic bin-picking, automated post-processing, and AI-supported workflows for small-batch manufacturing.[14]
ROS-Industrial provides standardized interfaces for industrial robot arms, grippers, and sensors, along with tools for path planning, calibration, and process automation.[13] It has enabled ROS adoption in applications such as welding, painting, material handling, and quality inspection.[13]
ROS has achieved broad adoption across both academic and commercial robotics. As of the mid-2020s, more than 740 commercial companies use ROS in their products or development workflows, and the broader NVIDIA-aligned robotics stack alone counts over 2 million developers.[20]
The scale of ROS usage has grown dramatically over the years. In May 2015, nearly 9 million ROS packages were downloaded from over 70,000 unique IP addresses.[4] By 2022, total Debian package downloads for ROS exceeded 501 million in a single year (501,333,806 deb downloads), with 173.35 terabytes of ROS packages served.[4] In 2022, ROS 2 accounted for 39.82% of all ROS downloads, reflecting growing momentum toward the newer version.[4] By 2025, with ROS 1 reaching end of life, ROS 2 became the dominant share of new installations.[18]
| Organization | Application |
|---|---|
| NASA | Robonaut 2, the first robot to run ROS in space, operated on the International Space Station starting September 2014 |
| Amazon | AWS RoboMaker, a cloud robotics service for simulation and deployment of ROS applications, launched November 2018, and Amazon Robotics fulfillment fleets |
| Microsoft | Ported core ROS to Windows in September 2018 and provides ROS support through Azure and Visual Studio |
| NVIDIA | Isaac ROS packages for GPU-accelerated perception and planning on Jetson and workstation platforms |
| Toyota | Toyota Research Institute has donated over $1 million annually to OSRF and partnered on robotics and autonomous vehicle research using ROS |
| Bosch | Active contributor and ROSCon gold sponsor, using ROS in research and product development |
| BMW | Uses ROS in manufacturing automation and logistics robotics |
| Boston Dynamics | Maintains a community Spot ROS 2 driver via the Boston Dynamics AI Institute, enabling Spot integration with Nav2, MoveIt 2, and Isaac Sim |
| Clearpath Robotics | Builds ROS-native mobile robot platforms for research and industrial applications |
| Intrinsic | Alphabet subsidiary that owns OSRC, building production robotics infrastructure on top of ROS 2 |
| Agility Robotics, Figure, Hexagon | Humanoid and field-robotics adopters of NVIDIA's Jetson Thor and Isaac ROS stack |
ROSCon is the annual developer conference for the ROS community, held since 2012. The conference has grown substantially, from its early years to nearly 1,000 attendees at ROSCon 2024 in Odense, Denmark. Gold sponsors in recent years have included NVIDIA, Bosch, Qualcomm, and other major technology companies. ROSCon 2025 in Singapore drew more than 1,000 participants from 52 countries, and ROSCon 2026 is planned for Toronto, Canada.[30]
ROS provides client libraries for multiple programming languages, with C++ and Python being the primary supported options:[29]
| Language | ROS 1 Library | ROS 2 Library | Maintainer |
|---|---|---|---|
| C++ | roscpp | rclcpp | Core ROS 2 team |
| Python | rospy | rclpy | Core ROS 2 team |
| Java | rosjava | rcljava | Community |
| Rust | (none) | rclrs | Community |
| C | (none) | rclc | micro-ROS team |
| .NET / C# | (none) | ros2_dotnet | Community |
| Node.js | (none) | rclnodejs | Community |
| Ada | (none) | rclada | Community |
All ROS 2 client libraries sit on top of the underlying rcl C library, which in turn calls into the rmw middleware abstraction.[29] This layered design means that core behavior such as discovery, QoS, and serialization stays consistent across languages.[29] The rclc client library is particularly notable for enabling ROS 2 on microcontrollers through the micro-ROS project.[27]
ROS includes a rich set of development and debugging tools that have largely been ported from ROS 1 to ROS 2. RViz / RViz2 is the 3D visualizer for sensor data, robot models, maps, and planned paths. rqt is a Qt-based framework for graphical tools including topic monitors, node graphs, parameter editors, and plot widgets. rosbag / ros2 bag records and replays message data for offline analysis. tf2 manages coordinate frame relationships over time. roslaunch / ros2 launch starts multi-node systems from declarative launch files (XML in ROS 1, Python or YAML in ROS 2). URDF / SDF are the XML formats describing robot kinematics, dynamics, visual appearance, and collision geometry. colcon is the unified build orchestration tool for ROS 2, and the ros2 CLI exposes topic, service, action, parameter, lifecycle, and bag commands through a single entry point.
| Feature | ROS 1 | ROS 2 |
|---|---|---|
| Communication | Custom TCPROS / UDPROS | DDS (Cyclone, Fast DDS, RTI Connext) plus Zenoh from Kilted |
| Discovery | Central ROS Master | Decentralized DDS discovery |
| Real-time support | Limited; relied on external frameworks like Orocos | QoS policies, lifecycle nodes, deterministic executors |
| Security | None built-in | DDS Security: authentication, encryption, access control |
| Multi-robot | Required workarounds | Native DDS domain support |
| OS support | Linux only (officially) | Linux, Windows, macOS |
| Build system | catkin | ament + colcon |
| Python version | Python 2 (early) / Python 3 (Noetic) | Python 3 only |
| Embedded support | Not supported | micro-ROS for microcontrollers |
| Status | End of life (May 2025) | Active development |
ROS is widely adopted, but it has drawn consistent criticism from teams taking it from research code to shipping product.
Complexity. Critics argue that ROS lowers the barrier to entry for beginners while raising it for production-grade deployments. Mastering distributed debugging, package dependency management, build configuration, and launch orchestration takes substantial effort.
Real-time performance in ROS 1. ROS 1 was never designed for hard real-time guarantees.[9] Its message passing introduces unpredictable latency and jitter, and safety-critical applications historically had to layer Orocos or custom IPC on top. ROS 2 with DDS addresses many of these concerns, but achieving deterministic behavior still requires careful tuning of the executor model, memory allocator, kernel, and DDS QoS settings.[26]
Embedded constraints. Running a full ROS stack on resource-limited compute is impractical. micro-ROS addresses this for MCUs, but the architectural split (client on the MCU, agent on a companion SBC) adds operational complexity that not every product can absorb.[27]
Backward compatibility. ROS 2 is intentionally not API or wire-compatible with ROS 1.[9] Bridging packages exist, but porting a large ROS 1 codebase typically requires substantial rework around launch files, parameter handling, and the QoS model. The end of life of ROS Noetic in May 2025 forced a decision point for every team that had previously deferred migration.[18]
DDS configuration burden. While DDS gives ROS 2 enormous flexibility, the tuning surface is large. Misconfigured QoS profiles silently drop messages, multicast traffic on shared corporate networks can be problematic, and behavior can differ subtly between DDS vendors. The introduction of Zenoh as a Tier 1 alternative in Kilted Kaiju is partly a response to these pain points.[22]
Yes. Both the language-independent tools and the main client libraries (C++, Python, and Lisp) are released under the terms of the BSD license, making ROS open-source software that is free for both commercial and research use.[4] Free and open-source distribution was one of the five founding design goals stated in the 2009 paper.[1] Individual ROS packages contributed by the community may use different open-source licenses (Apache 2.0 is common for newer ROS 2 packages), and product teams typically perform a license audit before integrating community code into closed-source firmware.
With the end of ROS 1 in May 2025, the ROS community is fully focused on ROS 2 development.[18] The Jazzy Jalisco LTS release (May 2024) provides a stable foundation through 2029, the Kilted Kaiju release (May 2025) introduced Zenoh as a Tier 1 middleware alternative, and Lyrical Luth is expected in May 2026.[22]
Active areas of development include tighter integration with artificial intelligence and machine learning frameworks, GPU-aware execution and zero-copy data flow, embodied AI workloads on humanoid platforms, improved support for cloud robotics, enhanced real-time performance, and an expanding ecosystem of hardware drivers and application packages.[20] The formation of OSRA in 2024 and its Physical AI Special Interest Group in 2025 signal a maturing governance model designed to sustain the project as ROS continues to expand beyond research and into commercial production deployments.[15]
The ROS ecosystem remains one of the most active open-source communities in robotics, with contributions from hundreds of organizations and thousands of individual developers worldwide.