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

In plain words

ROS 2 is the second generation of the Robot Operating System, the software toolkit that many robot programs use to talk to each other. Its main idea is that a robot is built from many small programs (called nodes) that pass messages to one another, rather than from one large program. The paper explains why the project was rebuilt: the first version lacked security, reliable networking and production-grade features, so the new version was designed for them from the start.

ROS 2 sends its messages with a standard networking layer called DDS, and it lets users swap that layer for another one. It also offers settings that tell the network what to do with lost or late messages. A small benchmark finds that when two parts of a robot run inside the same program, messages are much faster than when they cross process boundaries. The paper then describes how five organisations used ROS 2 on land, sea, air, space and in large robot fleets. Those accounts come mostly from interviews, not from independent measurements.

TL;DR

• ROS 2 is a robot software platform built around a publish-subscribe middleware (DDS), with typed topics, request-response services and long-running actions §3.3.
• Its design aims at security, embedded and real-time use, lossy networks and product readiness §3.2.2, and it is split into swappable layers §3.4.
• Benchmark numbers are mean latencies from one publisher and one subscriber on CycloneDDS. The text calls them 95th percentiles, which the figure does not support fig. 3. Treat them as indicative only.
• The five case studies are principally qualitative and written with the ROS community's own members. Use them as context, not as evidence of performance §4.

Problem

ROS 1 used a central name server and a bespoke TCP/UDP protocol, had a single point of failure, struggled to deliver data over lossy links and had no built-in security §2 tab. 1. Patches to ROS 1 existed but were incomplete or hard to maintain §2. The paper argues that robot systems in the field need a modular, secure and reliable transport, and that ROS 2 was rebuilt to supply one §1 §3.2.2.

Method

The paper is a review. It describes a system and gives no algorithm, equation or training procedure. The sections below summarise what the paper states, organised for implementers.

The paper gives no pseudocode. The sketch below restates the message path it describes in prose; it is not an algorithm from the paper.

# Message path for one publish (sketch of stated behaviour)
# Input:  topic, message, subscriptions (each with a process id)
# Output: delivered messages

def publish(topic, message, subscriptions):
    # Same process: pass a pointer and skip the middleware  [§3.6]
    for sub in subscriptions:
        if sub.process == self.process:
            sub.queue.push(pointer_to(message))

    # Other process or machine: hand over to the rmw layer  [§3.4]
    # Reliability and history depth come from the endpoint's QoS  [§3.6]
    for sub in subscriptions:
        if sub.process != self.process:
            rmw.send(topic, message, qos=self.qos)

Design principles §3.2.1. Four principles are asserted: distribution (components run in their own execution context and share data only through explicit communication, composed in a decentralised and secure way), abstraction (interface definitions fix the meaning of exchanged data, so vendors can be substituted), asynchrony (event-based messaging across different timing domains) and modularity (many federated packages, each doing one thing). The authors state that these principles trade determinism for flexibility and that a monolithic solution can be more efficient for a fixed problem §3.2.1.

Design requirements §3.2.2. Security (authentication, encryption, access control), embedded support (a full stack is not expected on micro-controllers; micro-ROS is the reuse path), diverse networks (quality-of-service settings), real-time (APIs for deterministic parts of a system) and product readiness. One example given is an ISO 26262 functional-safety certification of an autonomous-vehicle software stack built on ROS 2 §3.2.2.

Communication patterns §3.3, fig. 1.

1. Topics: asynchronous, typed publish-subscribe. Any subscription can observe a topic without changing the publisher, which the paper highlights for introspection.
2. Services: request-response for confirmed tasks. The client does not block while waiting.
3. Actions: a goal with a result, periodic feedback and cancellation, meant for long tasks such as navigation or manipulation.

All three are organised under a node. Parameters, timers and launch files are also provided §3.3.

Layered architecture §3.4, fig. 2, §3.4.1.

1. Client libraries, one per language, expose the communication APIs idiomatically. Most users only touch this layer.
2. rcl, a common C library used by the client libraries (use is optional).
3. rmw, the middleware abstraction. Vendors implement it, and implementations can be swapped without code changes. All supported rmw implementations are DDS-based; community implementations for other transports exist.

Messages are defined with ROS IDL (.msg) or OMG IDL (.idl). Code is generated at compile time for every client language. Communication is the same whether the endpoints share a process, run in different processes or sit on different machines §3.4.1.

Node patterns §3.4.2. Lifecycle nodes move through a state machine with Unconfigured, Inactive, Active and Finalized states, so an integrator can decide when each node runs. Component nodes can be loaded into any process by configuration, which allows several nodes to share a process to save resources or reduce latency.

Quality process §3.5. Three parts: design documents (design articles or REPs before major changes), automated testing (unit and integration tests, linters, continuous integration) and a multi-level quality declaration per package §3.5.

Quality of service §3.6. Reliability (best-effort or reliable), durability (volatile or transient-local, which replays data to late subscribers), history (keep-all, or keep-last with a fixed queue size). Deadline, lifespan, liveliness and lease duration are also available for real-time designs. DDS uses UDP and decides itself when to retransmit. The paper argues this makes ROS 2 more robust on wireless links than ROS 1 over TCP. This claim is not measured separately from the benchmark §3.6.

Security §3.7. DDS-Security provides authentication (public-key signatures), access control (policies on which participants may discover each other and which interfaces they may use) and encryption (AES-GCM, with keys derived from the authentication shared secret). SROS 2 provides command-line tools that generate the keys and policies §3.7.

Case studies §4. Five organisations: Ghost Robotics (quadruped robots), Mission Robotics (marine robots), Auterion (drones), NASA VIPER (lunar rover software) and OTTO Motors (warehouse fleets). Each analysis draws on interviews, customer experiences and a review of codebases. The authors call the analysis principally qualitative §4.

Hyperparameters

The paper has no training or model hyperparameters. The benchmark setup is listed here because the results depend on it.

Results

Author-reported. The benchmark is one publisher and one subscriber, on one machine or split across processes, with CycloneDDS. The values below are the mean values plotted in fig. 3. They were read from the plotted coordinates in the paper's LaTeX source and rounded here. The text quotes different (95th percentile) numbers, see Pitfalls.

Paper vs code

The cited repository is ros2/performance_test. It is a benchmark tool, not the ROS 2 middleware itself, which lives in other repositories not cloned here. The paper links it directly §3.6, and its owner is the ROS 2 GitHub organisation, the project the paper describes.

• The paper says latency is a 95th-percentile figure §3.6. The plot is labelled mean fig. 3a, and the code's analysis writes min, max, mean and variance for latency, not a percentile analysis_result.cpp.
• The code maps QoS settings onto the ROS 2 client library: best-effort or reliable, and keep-all or keep-last with a depth ros2_communicator.hpp. The paper never says which QoS it used for the benchmark §3.6.
• The tool also has communicators for other DDS vendors and for iceoryx . The paper reports CycloneDDS only §3.6.

Pitfalls

• Percentile versus mean. The text quotes 95th percentile values, for example 7.85 ms latency at 8 MB and 213 Hz send rate §3.6. The plotted mean values are 8.37 ms and 198 Hz fig. 3a. Do not mix the two; use the plotted values and label them as means.
• Size units are inconsistent. The x-axis label says bytes, the tick labels say k and m, and the text says MB fig. 3a §3.6. The tick values 1 to 8192 only match 1 kB to 8 MB if the unit is kilobytes. Read the axis as kilobytes.
• Loss range. The text says loss was varied from 0 to 20% §3.6. The plot shows only 0%, 10% and 20% fig. 3b. The publish rate of the loss test is not stated; the plot implies about 29 messages per second.
• The benchmark's QoS is unknown. The paper ties its large-message DDS result to default UDP buffers, fragmentation and retransmission §3.6. Those results depend on QoS and buffer settings the paper does not report, so they cannot be reproduced exactly from the card.
• Default DDS is weak above about 1 MB. The paper says default settings handle data above about 1 MB poorly and that tuning or composition helps §3.6. The benchmark shows the largest gap at 8 MB, where the send rate of inter-process messages falls fig. 3a.
• Version and date. The benchmark ran on a ROS 2 Rolling snapshot from 2021-09-23 and CycloneDDS §3.6. The quality counts ("at the time of writing": 44 design articles, 7 REPs, 32,000 to 33,000 tests, 13 linters, 45 Quality Level 1 packages) and the VIPER launch date (November 2023) are out of date §3.5 §4.4.
• The paper is a journal manuscript. The arXiv v1 footnote says the work is accepted by Science Robotics and the journal version is the final one. Figure and section numbers here follow v1, and the published version may differ.
• Not an independent evaluation. Four authors are affiliated with Open Robotics and one with Samsung Research America. The case studies draw on interviews and company estimates (OTTO's savings, Auterion's engineer replacement, Ghost's effort) that the paper does not verify §4.
• Mixed evidence on rivals. The text reports that ROS 2 handles lossy wireless links better than ROS 1, but no ROS 1 measurement is shown §3.6 §2. Table 1 is a feature comparison, not a test tab. 1.
• Intra-process scope. The paper says intra-process messages pass pointers and skip the middleware §3.6. That explains why it is fastest, but it only holds when publisher and subscriber share a process.
• Missing methodology. Number of runs, duration, warm-up, CPU sampling method and message ordering are not stated fig. 3. Treat the figures as single observations.

Lineage

• Builds on: ROS 1 (cited as ros2009icra) for the API ideas and the ecosystem §1 §2; the DDS standard for transport and security §1 §3.7.
• Compared against: ROS 1 tab. 1; Player, YARP, LCM and OROCOS as other robot frameworks §2; ZeroMQ and RabbitMQ as messaging options that were considered and rejected §1.
• Superseded by: not stated.