PaperlayerView exact revision on arXiv

Source-linked AI summary

Robot Operating System 2: Design, Architecture, and Uses In The Wild

Steve Macenski, Tully Foote, Brian Gerkey, Chris Lalancette, William Woodall

arXiv:2211.07752v1cs.RO

TL;DR

ROS 1 lacked production-grade features needed for secure, reliable deployment across modern robotic environments. This review describes ROS 2’s architectural and philosophical redesign, communication patterns, and case studies, finding that ROS 2 accelerates robot deployment, reuse, collaboration, and trusted platform development across diverse domains.

  • Problem

    ROS 1 was not designed with many production-grade features needed for reliable robotics systems in diverse commercial and exploratory environments.

  • Method

    The review analyzes ROS 2’s architecture and communication patterns and examines adoption through case studies spanning land, sea, air, and space.

  • Results

    The case studies show ROS 2 accelerating useful robot deployment across environments and scales while supporting software reuse, collaboration, and trusted platforms.

  • Takeaways & Limitations

    ROS 2’s standardization, freely available licensing, and design principles are associated with faster development, new collaborations, and broader deployment.

Abstract

from arXiv · show

The next chapter of the robotics revolution is well underway with the deployment of robots for a broad range of commercial use-cases. Even in a myriad of applications and environments, there exists a common vocabulary of components that robots share - the need for a modular, scalable, and reliable architecture; sensing; planning; mobility; and autonomy. The Robot Operating System (ROS) was an integral part of the last chapter, demonstrably expediting robotics research with freely-available components and a modular framework. However, ROS 1 was not designed with many necessary production-grade features and algorithms. ROS 2 and its related projects have been redesigned from the ground up to meet the challenges set forth by modern robotic systems in new and exploratory domains at all scales. In this review, we highlight the philosophical and architectural changes of ROS 2 powering this new chapter in the robotics revolution. We also show through case studies the influence ROS 2 and its adoption has had on accelerating real robot systems to reliable deployment in an assortment of challenging environments.

I. INTRODUCTION

ROS 1 matured robotics research and commercial development through modular middleware and a large ecosystem, but its research-oriented foundations lacked production-grade security, reliability, and scalability. ROS 2 was redesigned around DDS to address these challenges, and the review examines its architecture and real-world adoption.

  • ROS 1 and its ecosystem: ROS 1 became influential by providing reusable utilities, algorithms, and applications for navigation, simulation, visualization, and control.Its ecosystem helped small teams build complex robotics applications.
  • ROS 1 limitations: Security, reliability in non-traditional environments, system uptime, and large-scale embedded-system support were not prioritized in ROS 1.As robotics products emerged, these limitations became increasingly important.
  • ROS 2 and the review: ROS 2 was redesigned from the ground up around DDS, an open communications standard used in critical infrastructure.The review presents ROS 2’s architectural and philosophical changes and assesses its suitability through five case studies across land, sea, air, and space.
  • Related frameworks: Earlier frameworks pursued modularity, reuse, or specialized communication, but often imposed narrower application or reliability trade-offs.Player hampered reliability and component replacement, YARP supported only C++, and LCM focused on high-bandwidth, low-latency environments.
  • ROS 1 limitations: ROS 1 struggled to consistently deliver data over lossy links and included a single point of failure, prompting difficult patches and workarounds.Security extensions such as SROS were successful but difficult to maintain and required further development.

III. ROS 2

ROS 2 is an open-source robotics SDK organized as a federated ecosystem of middleware, algorithms, and developer tools. Its design emphasizes distributed, abstracted, asynchronous, and modular components, while acknowledging trade-offs against specialized monolithic solutions.

  • ROS 2 ecosystem: ROS 2 is an open-source robotics software development kit distributed under the Apache 2.0 License.The license permits modification, application, and redistribution without requiring users to contribute changes back.
  • ROS 2 ecosystem: The ROS 2 ecosystem comprises middleware, algorithms, and developer tools supporting communication, perception, SLAM, planning, configuration, debugging, simulation, and logging.Middleware is treated as the foundation explored in this section.
  • Design principles: ROS 2 distributes robotics functionality across independent components that communicate explicitly and asynchronously in a decentralized system.This distribution accommodates components with different data, command, and event frequencies.
  • Design principles: Abstraction uses interface specifications to support interoperable components without overfitting applications to particular hardware or software vendors.The intended balance exposes useful component semantics while preserving substitutability.
  • Design principles: Modularity is enforced across APIs, message definitions, tools, and federated packages rather than a single codebase.The paper connects these principles with code reuse, testing, fault isolation, collaboration, and global cooperation.
  • Design trade-offs: Asynchrony can make deterministic execution harder, while a specialized monolithic solution can be more computationally efficient for a single well-defined problem.The authors therefore present the design principles as useful but not universal or free of trade-offs.

2) Design Requirements:

ROS 2 targets production robotics requirements spanning security, embedded integration, diverse networks, real-time computing, and safety-critical deployment. Its communication APIs provide topics, services, and actions for different interaction patterns.

  • Design Requirements: ROS 2 integrates authentication, encryption, and access control through configurable policies defining who may communicate about what.These features address accidental and malicious misuse of network interactions.
  • Design Requirements: Micro-ROS enables reuse of ROS 2 on embedded systems while integrating CPUs with microcontrollers.The full ROS 2 stack is not expected to run on small embedded devices.
  • Design Requirements: Quality-of-service settings let ROS 2 adapt data flow to networks ranging from wired LANs to multi-hop satellite connections.These environments include internal networks connecting processes within and across CPUs.
  • Design Requirements: ROS 2 offers real-time APIs that let developers enforce application-specific timing constraints for deterministic execution.The requirement is motivated by safety and performance goals in applications such as humanoids and self-driving cars.
  • Design Requirements: Apex.AI achieved functional safety certification under ISO 26262 for ROS 2-based autonomous-vehicle software.The paper presents this as an objective result supporting use in safety-critical systems such as autonomous vehicles and heavy machinery.
  • Communication Patterns: Topics provide asynchronous publish-subscribe messaging, services provide request-response communication, and actions provide cancellable long-running task interfaces.Actions include requests, responses, periodic feedback, and cancellation; services are non-blocking for clients.

D. Middleware Architecture

ROS 2’s middleware architecture separates user-facing client libraries from interchangeable communication implementations and other abstraction layers. This structure supports distribution across processes and machines, configurable deployment, and lifecycle coordination.

  • Middleware Architecture: ROS 2 uses decoupled abstraction layers so users can replace middleware or logging solutions and select only required components.The package structure can matter when systems need certification.
  • Middleware Architecture: Client libraries expose core communication APIs in language-specific forms while remaining agnostic to whether computation is colocated or distributed.Applications can span processes, machines, and cloud resources.
  • Middleware Architecture: The rcl interface provides common functionality across client libraries, while rmw supplies interchangeable middleware interfaces without code changes.Middleware vendors implement rmw, allowing users to change communication technologies beneath application code.
  • Middleware Architecture: Users can choose rmw implementations according to performance, licensing, or platform constraints, preserving flexibility as ROS 2 evolves.Supported rmws are based on DDS, with some community implementations using other communication methods.
  • Middleware Architecture: ROS 2 interface definitions in ros idl or OMG IDL generate communication code for client-library languages at compile time.Topics, services, and actions use these message types to define network interfaces.
  • Middleware Architecture: Node lifecycle states such as Unconfigured, Inactive, Active, and Finalized let integrators control when distributed components operate.This supports coordination of the distributed asynchronous system.
  • Middleware Architecture: Component nodes can be allocated to different processes as configuration, including sharing a process to conserve resources or reduce latency.This lets developers rearrange deployment as system circumstances change.

E. Software Quality

ROS 2 combines documented design, continuous testing, quality levels, and configurable communication mechanisms to support reliable operation across networking conditions and message sizes.

  • Quality practices: ROS 2 uses design documentation, continuous testing, and a multilevel quality policy to measure and expose software quality.Major additions require a written rationale; features undergo unit, integration, and static-analysis testing; packages can achieve defined quality levels.
  • Quality practices: 32,000–33,000 tests, including 13 linters, run on ROS 2 at the time of writing.
  • Communication design: ROS 2 uses DDS and QoS settings to manage delivery reliability, persistence, buffering, and real-time communication behavior.Best-effort delivery sends once, reliable delivery retransmits until acknowledgment, and durability controls persistence for late-joining subscriptions.
  • Performance: 95th percentile intra-process latency stays below 1 millisecond for message sizes below 8 MB, with reliable sending at those sizes.Intra-process communication bypasses the middleware stack by passing pointers from publisher to subscription; node composition shows similar latency with no dropped messages below 8 MB.
  • Performance: Multi-process communication reaches 7.85 milliseconds at 8 MB, while its 95th percentile send rate falls from 1000 Hz at 2 MB to 213 Hz at 8 MB.It supports publishers and subscriptions on separate machines but has the highest latency and CPU utilization; small messages publish above 1kHz without loss.
  • Limitations: DDS default configurations are ineffective for information larger than 1 MB, although network tuning and intra-process or composition patterns can improve performance.The stated causes include small UDP buffers, UDP fragmentation limits, and retransmission requirements; tuning can require additional compute resources.
  • Reliability: In a 54 Mbps emulated network with packet loss varied from 0% to 20%, ROS 2 delivered data effectively under moderate loss, with larger degradation expected at 20%.The experiment used 1000-byte messages and tallied received messages across separate publisher and subscription processes.

G. Security

ROS 2 uses DDS-Security and SROS2 to manage authentication, access control, and encryption for robotic networks.

  • Security architecture: ROS 2 relies on the DDS-Security standard and provides SROS2 tools for managing security infrastructure.The security model is organized around authentication, access control, and encryption.
  • Authentication: Authentication establishes participant or message identity through digital signatures and public key cryptography.SROS2 provides command-line utilities to generate and store the signatures.
  • Access control: Access control applies fine-grained policies governing participant discovery and communication over approved interfaces.SROS2 includes command-line tools for generating these configurations.
  • Encryption: Encryption prevents third parties from eavesdropping on or replaying network data using AES-GCM symmetric-key cryptography.The key material derives from the shared secret obtained during authentication.

IV. CASE STUDIES

Five case studies examine ROS 2 across diverse robotic applications, with examples spanning land, air, and sea. The studies report qualitative evidence from organizations using ROS 2 to structure software, support collaboration, and accelerate deployment.

  • IV. CASE STUDIES: Five case studies qualitatively analyze ROS 2’s influence across varied organizations, use cases, and deployment scales.The analyses draw on interviews, customer experiences, and codebases.
  • Land: Ghost Robotics: Ghost Robotics uses ROS 2 on its Nvidia Jetson Xavier for mission execution, gait planning, terrain mapping, and localization.Approximately 90% of Ghost’s software uses ROS 2, with the remainder planned to follow suit.
  • Land: Ghost Robotics: ROS 2 publish-subscribe interfaces separate Ghost Robotics’ subsystems, enabling parallel development while preserving a consistent API.The architecture lets teams improve internal techniques without disrupting other projects.
  • Land: Ghost Robotics: ROS 2 lifecycle and component nodes let Ghost dynamically activate capabilities and combine independently developed modules at run time.This supports mission-dependent features such as switching between GPS-based and VIO-based localization.
  • Land: Ghost Robotics: ROS 2 tools enabled Ghost Robotics to create a flexible autonomy system in months rather than the many years it estimated would be required from scratch.The result supported new custom user applications in the field.
  • The COVID-19 Pandemic: During pandemic hardware restrictions, Ghost Robotics used Gazebo simulation to develop the entire autonomy system for a USAF demonstration.A single engineer created the required custom plugins and simulation files.

3) ROS 2 as an Equalizer:

ROS 2 acts as an equalizing force by providing reusable communications and utilities that let smaller or customer-facing robotics teams avoid rebuilding foundational software. In marine robotics, it also supplies a common interface for changing sensor configurations and customer extensions.

  • ROS 2 as an Equalizer: Ghost Robotics uses ROS 2 utilities including TF2, URDF, rosbag, rviz, roscli, and Gazebo to accelerate robots into the field.The company uses these capabilities instead of building an end-to-end proprietary software portfolio.
  • ROS 2 as an Equalizer: Mission Robotics uses ROS 2 as a common data bus so customers can add or remove sensors while retaining reliable access to resulting data.Its core on-robot software is built directly on CycloneDDS and Connext DDS rather than ROS 2.
  • ROS 2 as an Equalizer: Mission Robotics deploys sensor drivers in Docker containers and publishes their data over ROS 2, allowing customers to create extensions for custom applications.ROS 2 serves as the common interface between new hardware and the vehicle software.

2) ROS 2 as an Accelerator:

ROS 2 accelerates robotics development by standardizing interfaces and supplying reusable tools for logging, introspection, visualization, and data exchange. The case study evidence links these capabilities to reduced reinvention and greater focus on application-specific work.

  • ROS 2 as an Accelerator: Mission Robotics identifies limited marine-sector standardization as a source of repeated work and incompatible systems.The duplicated effort includes data logging, sensor integration, and message formats.
  • ROS 2 as an Accelerator: Mission Robotics argues that common ROS 2 messages, APIs, and tools can accelerate marine robotics and enable information exchange through tools such as rosbag.The expected beneficiaries include engineers, operators, and marine scientists using the resulting data.
  • ROS 2 as an Accelerator: Auterion selected ROS 2 to integrate higher-level functionality into commercial drones alongside the PX4 Autopilot while pursuing autonomy in hazardous, unstructured spaces.Its products support multiple airframes and customer integrations.
  • ROS 2 as an Accelerator: ROS 2 logging, rosbag2, and rviz2 support Auterion’s runtime recording, debugging, and interactive visualization of drones and sensor data.These tools collect events and raw data streams across system layers for later analysis.
  • ROS 2 as an Accelerator: Auterion reports that ROS 2’s visualization, data recording, and logging tools let it focus development on core flight control capabilities and customer requirements.The company identifies these capabilities as a driving reason for using ROS 2.

2) Safe, Automated Testing:

ROS 2-related simulation supports safer and more automated testing when physical experiments are risky, expensive, or infeasible. Case studies show Gazebo being used for continuous integration, high-risk flight scenarios, and high-fidelity lunar-rover validation.

  • Safe, Automated Testing: Auterion uses Gazebo for end-to-end software tests before flight and for continuous integration across vehicle types and scenarios.Parallel tests provide fast results while helping developers remain confident in software safety.
  • Safe, Automated Testing: 22,000 hours of Gazebo simulation in 2021 covered challenging flight scenarios and were estimated by Auterion to replace the value of 12 full-time engineers in live tests.Simulation reduces the cost and risk associated with physical flight testing.
  • Safe, Automated Testing: NASA uses Gazebo because lunar lighting, gravity, and terrain are difficult to reproduce accurately on Earth.The VIPER simulation includes mission-specific plugins and vehicle interfaces modeled down to low-level serial links.
  • Safe, Automated Testing: The VIPER team used Gazebo to test and validate almost all rover software before launch and to train operators using ROS 2 fault injection.Operators practice clearing injected faults and returning the rover to motion.
  • Safe, Automated Testing: 284,500 significant lines of Gazebo code were reused without modification for VIPER, with less than 1% modified for validation.NASA estimated that simulator development required 266 work-months focused on VIPER-specific elements rather than 2,456 work-months for full implementation.

2) Creating a Legacy:

ROS 2 is being adopted in mission-critical and large-scale robotic deployments because DDS supports challenging communications environments and scalable multi-robot operation. These deployments also establish reusable operational and software precedents, despite the additional validation burden of introducing new flight software.

  • Creating a Legacy: DDS was selected for VIPER Earth-based operations because it can traverse satellite links with high latency, low bandwidth, and low reliability.The VIPER team evaluated communication options before selecting DDS.
  • Creating a Legacy: ROS 2’s development, introspection, visualization, and open-source capabilities shortened new engineers’ learning curve for flight missions.These characteristics helped engineers apply existing knowledge to mission software.
  • Creating a Legacy: 84% of VIPER’s 588,000 lines of Resource Prospector code was reused alongside Gazebo and approximately 312 open-source ROS 2 packages.ROS 2 had not been used in prior missions, so adoption required additional Verification and Validation overhead.
  • Creating a Legacy: After validation and ground-operation use on VIPER, ROS 2 becomes easier to reuse across future missions and mission roles.The stated benefit is greater reuse of robotic software between mission programs.
  • Large Scale: OTTO Motors: OTTO’s ROS 1 multi-master system could not test more than 25 robots on one shared network, creating a bottleneck as facilities grew.The limitation affected fleet management at larger customer sites.
  • Large Scale: OTTO Motors: After migrating to ROS 2, OTTO scaled to 100+ robots in customer facilities using scalable network topology management and QoS bandwidth support.OTTO estimates savings of $1M to $5M over five years and hundreds of engineering hours by avoiding a proprietary rewrite.
  • Large Scale: OTTO Motors: OTTO estimates continuing engineering costs would be 5–10% higher annually without the ROS ecosystem.Its CTO characterized the ecosystem as necessary to the business’s feasibility.

2) Acceleration of Development:

Across the case studies, ROS 2 accelerates development by supporting modular collaboration, software reuse, and trusted platforms. Its design principles and standardization help organizations and customers build and deploy customized robotic systems across varied domains.

  • Acceleration of Development: ROS 2’s distributed architecture and process isolation let geographically distributed teams collaborate through clearly defined interfaces.OTTO combines software from multiple repositories, teams, and programming languages at runtime.
  • Acceleration of Development: Standard ROS APIs let external partners build applications on OTTO platforms and connect them to their own autonomy systems.The case study describes a customer using OTTO platforms to create UV sanitizing robots.
  • Acceleration of Development: The five case studies span diverse applications, environments, and scales while sharing common reasons for adopting ROS 2.The cases cover modern applied robotics systems across every domain.
  • Acceleration of Development: ROS 2 enables software reuse through community device drivers, integrations, and higher-level algorithms, while VIPER uses it to facilitate reuse within NASA.ROS recognition within NASA helped encourage collaboration between groups.
  • Acceleration of Development: ROS 2 interfaces and composition nodes separate complex-system components so teams can collaborate without handling other components’ details.Mission Robotics and Auterion also use ROS 2 to develop custom solutions collaboratively with customers.
  • Acceleration of Development: Freely available licensing and widespread ROS expertise let businesses sell trusted platforms that customers can quickly adapt to bespoke applications.The paper identifies platform sales as a shared pattern across the surveyed companies.
  • Acceleration of Development: Software reuse, collaboration, and trusted platforms align with ROS 2’s principles of distribution, abstraction, and modularity.The paper links adherence to these principles with major acceleration factors observed in the case studies.
  • Acceleration of Development: ROS 2 is a DDS-based framework designed for modern robotics, extensive customization, and reliable deployment across broad applications.The review presents ROS 2 as helping move robots from laboratories into real-world environments.
Loading 2211.07752v1…