SCIENCE ROBOTICS | REVIEW

ROBOTS AND SOCIETY Copyright © 2022

The Authors, some
Robot Operating System 2: Design, architecture, rights reserved;
exclusive licensee
and uses in the wild American Association
for the Advancement
of Science. No claim
Steven Macenski1*, Tully Foote2, Brian Gerkey2, Chris Lalancette2, William Woodall2 to original U.S.
Government Works
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.

Downloaded from https://www.science.org on July 25, 2024

INTRODUCTION philosophical changes that have driven its success. Then, we will
Many software platforms have been proposed, sometimes called expand on that foundation to demonstrate how ROS 2 is influencing
middlewares, introducing modular and adaptable features that the deployment of autonomous systems in several unique domains.
make it easier to build robot systems. Over time, some middlewares Five case studies explore how ROS 2 has enabled or accelerated
have grown to become rich ecosystems of utilities, algorithms, and robots into the wild on land, sea, air, and even space.
sample applications. Few rival the Robot Operating System (ROS 1)
in its significance on the maturing robotics industry.
ROS 1 was popularized by the robotics incubator Willow Garage RELATED WORK
(1). Every effort was made to create a quality and performant system, but The history of robot software is long and storied, going back more than
security, network topology, and system up-time were not prioritized. 50 years with robots like Shakey (9). Over time, much has been
Regardless, ROS 1 has become influential in nearly every intelligent written about how to structure classical planners, concurrent behav-
machine sector. Its commercial rise was the result of flagship projects iors, and three-layer architectures (10–12). An early example of this
providing autonomous navigation, simulation, visualization, control, is the Task Control Architecture (TCA), which was used to control
and more (2–4). As commercial opportunities transitioned into products, a variety of robots. For example, Carnegie Mellon Robot Navigation
ROS’s foundation as a research platform began to show its limitations. Toolkit (CARMEN) was built on TCA’s message-passing system called
Security, reliability in nontraditional environments, and support IPC (interprocess communications) (13, 14). Message passing has its
for large-scale embedded systems became essential to push the own rich history in distributed systems: from IBM’s work on message
industry forward. Further, many companies were building work- queuing, Java’s Jini, and middlewares such as MQ Telemetry Transport
arounds on top or inside of ROS 1 to create reliable applications (5). (MQTT) (15–17).
The second generation of the Robot Operating System, ROS 2, Robotics frameworks provide architectural methods to decom-
was redesigned from the ground up to address these challenges pose complex software into smaller and more manageable pieces.
while building on the success of its community-driven capabilities Some of these components can find reuse in other systems and may
(6). ROS 2 is based on the Data Distribution Service (DDS), an open be established into libraries to be leveraged by users. An early
standard for communications that is used in critical infrastructure attempt to manage this complexity was via a client/server approach
such as military, spacecraft, and financial systems (7). It solves many in Player (18). A Player server communicates with robot hardware
of the problems in building reliable robotics systems. DDS enables and runs the algorithms needed to perform its task. Clients can
ROS 2 to obtain best-in-class security, embedded and real-time sup- connect to the server to extract data and control the robot over a
port, multirobot communication, and operations in nonideal net- Transmission Control Protocol (TCP) connection. However, its
working environments. DDS was selected after considering other architecture hampered reliability, code reuse, and ability to change
communication technologies, e.g., ZeroMQ and RabbitMQ, because out components.
of its breadth of features including a User Datagram Protocol (UDP) Yet Another Robot Platform (YARP) aids in building control
transport, distributed discovery, and a built-in security standard (8). systems organized as peers, communicating over several proto-
In this Review, we will establish ROS 2’s state-of-the-art suitability cols (19). It facilitates research development and collaboration by
for modern robot systems and showcase the technological and promoting code reuse and modularity while retaining high perform­
ance. YARP can be used for any application, but its community
1 has focused on humanoid and legged robotics, such as iCub
Samsung Research America, Mountain View, CA 94043, USA. 2Open Robotics,
Mountain View, CA 94041, USA. and the Massachusetts Institute of Technology’s Cheetah, and only
*Corresponding author. Email: [email protected] supports C++.

Macenski et al., Sci. Robot. 7, eabm6074 (2022) 11 May 2022 1 of 12

SCIENCE ROBOTICS | REVIEW

Lightweight Communications and Marshalling (LCM) is a middle- via the SROS project. Although successful, it was difficult to maintain
ware that uses a publish/subscribe model with bindings in many and needed further development to meet security trends. These are
languages. It concentrates on handling messaging and data marshaling just two of the many attempts to patch ROS 1, which extended its
in high-bandwidth low-latency environments (20). This limits the useful lifetime but did not solve its core limitations.
range of robotic applications for which LCM can be effectively
used. Open Robot Control Software (OROCOS) is a set of libraries
for robot control, focused on real-time control systems and related ROS 2
topics, such as computing kinematic chains and Bayesian filtering ROS 2 is a software platform for developing robotics applications,
(21). The project has grown into a full framework integrating the also known as a robotics software development kit (SDK). Impor-
Common Object Request Broker Architecture (CORBA) middleware tantly, ROS 2 is open source and distributed under the Apache 2.0
and tooling for deterministic computation in real-time applications. License, which grants users broad rights to modify, apply, and redis-
The LCM and OROCOS frameworks each concentrate on smaller tribute the software, with no obligation to contribute back (22).
pieces of the overall system, with a nontrivial proportion of the over- ROS 2 relies on a federated ecosystem in which contributors are en-
all robotics problem left to the end-user. couraged to create and release their own software. Most additional packages
ROS 1 contains a set of libraries that are useful when building also use the Apache 2.0 License or similar. Making code free is fundamen-
many kinds of robots (1). There are utilities for monitoring processes, tal to driving mass adoption—it allows users to leverage ROS 2 without
introspecting communications, receiving time-series transforma- constraining how they use or distribute their applications.
tions, and more. ROS 1 also has a large ecosystem of sensor, control,
and algorithmic packages made available by community contribu- Scope
tions, enabling a small team to build complex robotics applications. ROS 2 supports a broad range of robotics applications, from education
Although ROS 1 solves many of the complexity issues inherent to and research to product development and deployment. It comprises

Downloaded from https://www.science.org on July 25, 2024

robotics, it struggles to consistently deliver data over lossy links a large set of interrelated software components that are commonly
(like WiFi or satellite links), has a single point of failure, and does used to develop robotics applications. The software ecosystem is
not have any built-in security mechanisms. A table of key differences divided into three categories:
between ROS 1 and ROS 2 can be seen in Table 1. 1) Middleware: Referred to as the plumbing, the ROS 2 middleware
The ROS 1 community attempted to address some of these encompasses communication among components, from network
concerns, but in nearly all cases, there were compromises made application program interfaces (APIs) to message parsers.
because of architectural and engineering limitations. For example, 2) Algorithms: ROS 2 provides many of the algorithms commonly
to address the single point of failure (“rosmaster”), it was required used when building robotics applications, e.g., perception, Simulta-
to patch all of the existing client libraries individually with bespoke neous Localization and Mapping (SLAM), planning, and beyond.
solutions. In other cases, it was possible to extend ROS 1 for security, 3) Developer tools: ROS 2 includes a suite of command-line and
graphical tools for configuration, launch, introspection, visualiza-
tion, debugging, simulation, and logging. There is also a large suite
of tools for source management, build processes, and distribution.
Table 1. Summary of ROS 2 features compared with ROS 1. In this section, we will explore the first category, the middleware,
Category ROS 1 ROS 2 as the foundation of ROS 2.
Existing standard (DDS),
Bespoke protocol
Network transport with abstraction supporting Design
built on TCP/UDP
addition of others Design principles
Network Central name The design of ROS 2 has been guided by a set of principles and a set
Peer-to-peer discovery
architecture server (roscore) of specific requirements. The following principles are asserted:
Linux, Windows, and Distribution. As with similarly complex domains, problems in
Platform support Linux
macOS robotics are best tackled with a distributed systems approach (23).
Written independently Sharing a common Requirements are separated into functionally independent compo-
Client libraries
in each language underlying C library (rcl) nents, such as device drivers for hardware, perception systems,
Single node per Multiple nodes per control systems, executives, and so on. At runtime, these compo-
Node versus process
process process nents have their own execution context and share data via explicit
Callback queues communication. This composition should be conducted in a decen-
Threading model Swappable executor
and handlers tralized and secure manner.
Node state Abstraction. To govern communication, interface specifications
None Lifecycle nodes
management must be established. These messages define the semantics of the
Minimal Commercially supported data exchanged. A favorable abstraction balances the benefits of
Embedded systems experimental implementation exposing the details of a component against the costs of overfitting
support (rosserial) (micro-ROS) the rest of the application to that component, thereby making it
Auxilliary protocol Implemented using difficult to substitute an alternative. This approach leads to an
Parameter access
built on XMLRPC service calls ecosystem of interoperable components abstracted away from
Type inferred when Type declared and specific vendors of hardware or software components (24).
Parameter types
assigned enforced Asynchrony. The messages defined are communicated among the
components asynchronously, creating an event-based system (25).

Macenski et al., Sci. Robot. 7, eabm6074 (2022) 11 May 2022 2 of 12

SCIENCE ROBOTICS | REVIEW

With this approach, an application can work across the multiple time Communication patterns
domains that arise from combining physical devices with a host of The ROS 2 APIs provide access to communication patterns. These
software components, each of which may have its own frequency are notably topics, services, and actions that are organized under
for providing data, accepting commands, or signaling events. the concept of a node. ROS 2 also provides APIs for parameters,
Modularity. The UNIX design goal to “make each program do timers, launch, and other auxiliary tools that can be used to design
one thing well” is mirrored (26). Modularity is enforced at multiple a robotic system.
levels, across library APIs, message definitions, command-line tools, and Topics
even the software ecosystem itself. The ecosystem is organized into The most common pattern that users will interact with is topics,
a large number of federated packages, as opposed to a single which are an asynchronous message-passing framework. This is
codebase. similar to other asynchronous frameworks, such as ASIO (36). ROS
We do not pretend that these design principles are universal and 2 provides the same publish-subscribe functionality but focuses on
without trade-offs. Asynchrony can also make it more difficult to using asynchronous messaging to organize a system using strongly
achieve deterministic execution. For any single, well-defined typed interfaces. It does so by organizing end points in a computa-
problem, it is possible to construct a special-purpose monolithic tional graph under the concept of a node. The node is an important
solution that is more computationally efficient because it does not organizational unit that allows a user to reason about a complex
involve abstractions or distributed communication. system, shown in Fig. 1.
However, after a decade of experience with the ROS 1 project, we The anonymous publish-subscribe architecture allows many-to-­
claim that adherence to these principles will generally lead to better many communication, which is advantageous for system introspection.
outcomes. This approach facilitates code reuse, software testing, A developer may observe any messages passing on a topic by creating
fault isolation, collaboration within interdisciplinary project teams, a subscription to that topic without any changes.
and cooperation at a global scale. Services

Downloaded from https://www.science.org on July 25, 2024

Design requirements Asynchronous communication is not always the right tool. ROS 2
ROS 2 aims to meet certain requirements based on the design also provides a request-response style pattern, known as services.
principles and needs of robotics developers. Request-response communication provides easy data association
Security. Any software that interacts with a network must in- between a request and response pair, which can be useful when
clude features to secure that interaction against accidental and ensuring a task was completed or received, shown in Fig. 1. Uniquely,
malicious misuse. ROS 2’s integrated security system includes ROS 2 allows a service client’s process to not be blocked during a
authentication, encryption, and access control (27–29). Designers call. Services are also organized under a node for organization and
can configure ROS 2 to meet their needs through access control introspection, allowing a subsystem’s interfaces to appear together
policies that define who can communicate about what (30). in system diagnostics.
Embedded systems. As a general rule, a robot includes sensors, Actions
actuators, and other peripherals. These devices can be relatively A unique communication pattern of ROS 2 is the action. Actions
sophisticated, containing microcontrollers that need to communi- are goal-oriented and asynchronous communication interfaces with
cate with CPU(s) where ROS 2 is running. A full ROS 2 stack a request, response, periodic feedback, and the ability to be canceled
is not expected to run on small embedded devices, although ROS 2 (Fig. 1). This pattern is used in long-running tasks such as auton-
should facilitate and standardize integration of CPUs and micro- omous navigation or manipulation, although it has a variety of uses.
controllers. Micro-ROS allows ROS 2 to be reused on embedded Similar to services, actions are nonblocking and organized un-
systems (31). der the node.
Diverse networks. Robots are used in a variety of networking
environments, from wired LAN for robot arms on assembly lines to Middleware architecture
multihop satellite connections for planetary rovers. In addition, Adhering to the previous design philosophies, the architecture of
robots will often use internal networks to connect processes within ROS 2 consists of several important abstraction layers distributed
and across CPUs. ROS 2 provides quality of service that configures across many decoupled packages. These abstraction layers make it
how data flow through the system, thereby adapting to the constraints possible to have multiple solutions for required functionality, e.g.,
of a network (32). multiple middlewares or loggers. In addition, the distribution across
Real-time computing. From humanoids to self-driving cars, it is many packages allows users to replace components or take only the
common for robot applications to include real-time computing pieces of the system they require, which may be important for
requirements. To meet safety and/or performance goals, some parts certification.
of a system must execute in deterministic amounts of time. ROS 2 offers Abstraction layers
APIs for developers of real-time systems to enforce application-­ Figure 2 displays the abstraction layers within ROS 2. They are
specific constraints (33, 34). generally hidden behind the client library during development, and
Product readiness. When a robot moves beyond the laboratory developers would only need to be aware of them for unusually
and into commercial use, new constraints are introduced. ROS 2 application-specific needs. Most users will experience only the client
aims to meet product requirements spanning design, development, libraries.
and project governance. One objective result of these efforts is The client libraries provide access to the core communication
Apex.AI’s functional safety [International Organization for Stan- APIs. They are tailored to each programming language to make
dardization (ISO) 26262] certification of their ROS 2-based auton- them more idiomatic and take advantage of language specific fea-
omous vehicle software (35). This allows ROS 2 to be run in safety tures. Communication is agnostic to how the system is distributed
critical systems like autonomous vehicles and heavy machinery. across compute resources—whether they are in the same process, a

Macenski et al., Sci. Robot. 7, eabm6074 (2022) 11 May 2022 3 of 12

SCIENCE ROBOTICS | REVIEW

(ROS MiddleWare) provides the essential

communication interfaces. The vendors
for each middleware implements the rmw
interface and are made interchangeable
without code changes.
Users may choose different rmw
implementations, and thereby different
middleware technologies, based on a
variety of constraints like performance,
software license, or supported platforms.
Although all of the supported rmws are
based on DDS, a few community-supported
rmws exist for other communications
methods (7). This abstraction layer pro-
vides flexibility to ROS 2, allowing it to
change over time with minimal impact
to the systems built atop it.
The network interfaces (e.g., topics,
Fig. 1. ROS 2 node interfaces: Topics, services, and actions.
services, and actions) are defined with
message types using an interface descrip-
tion language (IDL). ROS 2 defines these

Downloaded from https://www.science.org on July 25, 2024

types using the ros idl format (.msg files)
or the OMG IDL standard (.idl files).
User-provided interface definitions are
generated at compile time and create
code required for communication in
any client library language.
Architectural node patterns
There are additional architectural pat-
terns to help developers structure their
programs. ROS 2 provides a pattern
for managing the lifecycle of nodes
that transition through a state machine
with states like unconfigured, inactive,
active, and finalized. These states al-
low system integrators to control when
certain nodes are active. This is an
important tool for coordinating vari-
ous parts of the distributed asynchro-
nous system.
As previously discussed in the last
section, communications are agnostic to
the location of end points within ma-
chines and processes. However, in which
machine or process to put each node is
Fig. 2. ROS 2 Client Library API Stack. not something that should be decided
when writing the node but instead de-
different process, or even a different computer. A user may distribute pends on how the node is used in the larger system. Nodes that are
their application across multiple machines and processes and even written as components can be allocated to any process as a configu-
leverage cloud compute resources, with minimal changes to the source ration. This is an important feature for systems under development,
code. ROS 2 is capable of connecting to cloud resources over the allowing the developer to rearrange where nodes are running based
internet. There are products to assist integration of ROS 2 into cloud on a variety of circumstances. For example, multiple nodes might
platforms, such as Amazon Web Services (AWS) Internet of Things be configured to share a process to conserve system resources or
(IoT) RoboRunner and related RoboMaker products (37). It is advisable, reduce latency.
however, to use more specialized purpose-built technologies.
The client libraries depend on an intermediate interface, rcl, which Software quality
provides common functionality to each client library. This library is For ROS 2 to be adopted in critical applications, it must be designed
written in C and is used by all of the client libraries although not and implemented in a demonstrably high-quality manner. Regulatory
required. Below rcl, the middleware abstraction layer called rmw and certification bodies need to understand the current state of a

Macenski et al., Sci. Robot. 7, eabm6074 (2022) 11 May 2022 4 of 12

SCIENCE ROBOTICS | REVIEW

system and the processes that led to it. To that end, a three-part ROS 2 does not struggle in these situations. DDS uses UDP to
approach is continuously executed to measure and expose soft- deliver data, which does not attempt to retransmit data. Instead,
ware quality: DDS decides when and how to retransmit in unreliable conditions.
1) Design documentation: Before a major addition, a written DDS introduces quality of service (QoS) to expose these settings to
rationale and design for the work must be established. This docu- optimize for the available bandwidth and latency.
mentation manifests as a design article or an ROS Enhancement The reliability setting determines whether message delivery is
Proposal (REP) (38, 39). At the time of writing, there are 44 design guaranteed. Using “best-effort,” the publisher will attempt to deliver
articles and seven REPs documenting the design of ROS 2. the message once, useful when new data will make the old obsolete
2) Testing: Each feature in ROS 2 requires tests to ensure that it (e.g., sensor data). Set to “reliable,” the publisher will continue to
behaves correctly. Those tests are executed regularly in continuous send data until the receiver acknowledges receipt.
integration. A combination of unit and integration tests are deployed, The durability QoS setting determines the persistence of a message.
as well as a suite of static analysis tools (“linters”). At the time of “Volatile” messages will be forgotten once after being sent. Mean-
writing, 32,000 to 33,000 tests are run on ROS 2, including 13 linters. while, “transient-local” will store and send late-joining subscriptions
3) Quality declaration: Not every ROS 2 package needs to be data as necessary.
rigorously documented and tested. Thus, a multilevel quality policy A connection’s history determines the behavior when the net-
is defined (40). This policy defines the requirements for each quality work cannot keep up with the data. Set to “keep-all,” all data are
level in terms of development practices, test coverage, security, and retained until the application consumes them. Most applications
more. At the time of writing, 45 ROS 2 packages have achieved the use “keep-last,” which retains a fixed-sized queue of data, overrid-
highest level, quality level 1. ing the oldest as needed. Other settings, including deadline, life span,
liveliness, and lease duration, help in designing real-time systems.
Performance and reliability Experiments were conducted to benchmark the networking

Downloaded from https://www.science.org on July 25, 2024

Networking is an important aspect of robotics frameworks. In reliable performance of ROS 2. The charts in Fig. 3A show the results of
networking situations, the standard solution is TCP/IP (Internet sending and receiving different sizes of messages through ROS 2.
Protocol) because of its optimizations in most operating systems. This experiment was run on a six-core Intel i7-6800K CPU running
Unfortunately, TCP/IP struggles to deliver data in wireless communi- at 3.4 GHz, with 32 GB of RAM. The machine was running Fedora
cations because interruptions can cause back-offs, retransmits, and 34, using CycloneDDS, and the latest ROS 2 Rolling distribution
delays. ROS 1 was built on TCP/IP and suffered in these situations. packages as of 23 September 2021 (41). The performance tests used

A Different message sizes

B Sending data with packet loss

Fig. 3. ROS 2 performance results (SD not shown because it is so small). (A) Different message sizes. (B) Sending data with packet loss.

Macenski et al., Sci. Robot. 7, eabm6074 (2022) 11 May 2022 5 of 12

SCIENCE ROBOTICS | REVIEW

can be found in https://github.com/ros2/performance_test and security infrastructure easy. There are three main concepts in
https://github.com/ros2/buildfarm_perf_tests. DDS security:
The tests comprise one publisher and one subscription. For each Authentication
message size, 1000 messages are sent per second, and the system This establishes the identity of a message or participant in the
records the latency, effective publication rate, and CPU utilization. network. ROS 2 uses digital signatures for authentication, known as
The message sizes are selected to test different aspects, ranging from public key cryptography. SROS2 includes command-line utilities
small to larger messages at key intervals. The test is repeated in for generating and storing these digital signatures.
different processes, within the same process, and within the same Access control
process using intraprocess communication. This allows for fine-grained policies to be applied to the authenti-
The data show that intraprocess communication is the most efficient, cated network participants. It allows a participant to only discover
with 95th percentile latency below 1 ms for all sizes below 8 MB. Intra­ approved participants and communicate over preapproved network
process is the most reliable, meeting the sending rate for all sizes below interfaces. SROS2 has command-line tools for generating these
8 MB. This bypasses the middleware stack and delivers data by passing configurations.
pointers from the publisher to the subscription. This improvement Encryption
is particularly magnified when working with large messages, around This ensures that third parties cannot eavesdrop or replay data into
1 MB and larger, which are most often associated with images, point- the network. Encryption is performed using Advanced Encryption
clouds, or other forms of high-resolution data. When using node com- Standard Galois/Counter Mode (AES-GCM) symmetric-key crypto­
position, the data show a similar story—the 95th percentile latency is graphy. The key material is derived from the shared secret obtained
below 1 ms with no dropped messages for sizes below 8 MB. as part of authentication.
Multiprocess communication allows the publisher and subscrip-
tion to be on separate machines on the network. Expectedly, it also shows

Downloaded from https://www.science.org on July 25, 2024

the highest latency, below 1 ms until 1 MB, then spiking to 7.85 ms CASE STUDIES
by 8 MB. The send rate shows a similar trend; at sizes up to 2 MB, the Five case studies were conducted that highlight the material accelera-
95th percentile send rate is 1000 Hz, decreasing to 213 Hz for 8 MB. tion provided by ROS 2. Each study provides a principally qualitative
Using multiple processes and interprocess communication is the analysis of ROS 2’s influence on each organization based on interviews,
most flexible scenario, but it also displays the highest latency and customer experiences, and codebases analyzed during the study.
CPU utilization. Simply using node composition and/or intraprocess The variety of use cases and scales demonstrates the significance of
communication, the latency, CPU utilization, and sending rate are ROS 2 across the robotics sector.
each cut significantly. However, for small messages, all of the mech-
anisms were able to publish reliably in excess of 1 kHz without loss. Land: Ghost Robotics
DDS’s default configurations is not particularly effective at Ghost Robotics is a Philadelphia-based company specializing in
communicating information larger than 1 MB, which represents a quadruped robots for defense, enterprise, and research. Their robots
real challenge to users. There are a few reasons for this: the small (Fig. 4A) are made for unstructured natural environments that
default UDP buffer sizes, UDP fragmentation limits, and DDS cannot be traversed by traditional wheeled or tracked robots. Ghost’s
reliability guarantees requiring the retransmit of packets. Many of Vision-60 robot is being deployed in caves, mines, forests, and
these issues can be removed with tuning of the networking parameters deserts and can easily walk through several inches of water or snow.
at the expense of compute resources. The performance may also be Their robots were used by the University of Pennsylvania team in
improved by using the composition and intraprocess communica- the DARPA Subterranean Challenge and Ghost has active partner-
tion patterns in ROS 2. Composition is the recommended design ships with the U.S. military for base security and other experimental
pattern in ROS 2 and is made simple to encourage its adoption. applications (42).
The charts in Fig. 3B show the resilience of ROS 2 to packet loss ROS 2 is used on their main compute platform, an Nvidia Jetson
in the network. The tests were run on an Ubuntu 20.04 virtual Xavier, which handles mission execution, high-level gait planning,
machine, containing six Intel Xeon E5-2666 v3 CPUs at 2.9 GHz terrain mapping, and localization. Approximately 90% of Ghost’s
and 16 GB of RAM, using the CycloneDDS rmw. For each test, the software uses ROS 2 for its communication and architecture, and
same publisher and subscription node, in separate processes, were the remaining is planned to follow suit in the near future.
run. Networking was run through mininet, a network emulator that Software architecture
lets users specify arbitrary topologies and link characteristics. In this ROS 2 has had a powerful role in structuring their internal collabo-
experiment, the bandwidth was capped at 54 Mbps (comparable to a rations and software design. Both their high-level and mission-­
slow wireless network), and the packet loss was varied between 0 control software architectures are heavily integrated with ROS 2.
and 20%. Each message consisted of an array of 1000 bytes, and the They leverage publish-subscribe interfaces between their main
number of messages that were received was tallied. In a network with subsystems, allowing them to enjoy a consistent API while the tech-
a moderate amount of loss, ROS 2 can still deliver data over the network niques within each are being continuously improved. This clean
effectively. Twenty percent is a particularly bad networking environ- separation between projects has allowed them to perform parallel
ment where performance is expected to drop more significantly. development without disrupting the activities of other teams.
According to Hunter Allen, senior autonomy engineer, “It’s been
Security great; it is fundamental to our autonomy architecture.” Their
Security is an important element to any modern commercial robotics mission control software uses ROS 2 actions to request, cancel, or
SDK. ROS 2 not only relies on the DDS security standard but also attain feedback regarding an current mission. It takes a mission
provides an additional suite of tools, SROS2, to make managing identifier to cross-reference with an internal database of potential

Macenski et al., Sci. Robot. 7, eabm6074 (2022) 11 May 2022 6 of 12

SCIENCE ROBOTICS | REVIEW

Downloaded from https://www.science.org on July 25, 2024

Fig. 4. Case-study robot systems deployed on land, air, and sea. (A) Ghost Robotic’s Vision-60 robot. (B) Mission Robotics submersible robot. (C) OTTO Motor’s
“OTTO 100” robots. (D) Auterion-powered drone by Freefly. Image credits: (A) Ghost Robotics Corp. (B) Mission Robotics Inc. (C) OTTO Motors/Clearpath Robotics.
(D) Auterion Ltd.

missions to execute. Next, it assembles each task in the mission and reduced access to crucial hardware. At the same time, they were
activates the required capabilities for the particular mission, modeled preparing for a demonstration with the U.S. Air Force (USAF) only
as lifecycle nodes. Last, it executes the mission. months away. Ultimately, the company was successful by pivoting
Most of Ghost’s software is implemented as both lifecycle and their processes to use capabilities made available in ROS 2.
component nodes. The lifecycle nodes are used to dynamically Before the pandemic, most of the development occurred using
activate and deactivate features depending on the current mission robots in their offices. When access to robots was abruptly stopped,
requirements, such as toggling between Global Positioning System– Ghost had to switch development over to the ROS 2 simulator,
based and Visual Inertial Odometry (VIO)–based localization. Gazebo. A single engineer was able to create custom Gazebo plugins
They have dozens of unique capabilities readily available for differ- and simulation files required to represent the quadruped. This simula-
ent missions, which take up little background resources when idle. tion was used to develop the entirety of the USAF demonstration’s
The component nodes are independent modules developed by multiple autonomy system. This new capability is still used long after they
teams and combined at runtime. Ghost found that these strategies were able to return to their offices—it has permitted faster internal
are important when collaborating with a large interdisciplinary development to create custom behaviors and deploy them onto cus-
team on a limited-­compute platform. tomer’s robots.
The provided ROS 2 tools allowed Ghost to create a highly flexible ROS 2 as an equalizer
and efficient autonomy system in only a few months. By contrast, ROS 2 is a strong equalizing force for Ghost Robotics. It has helped
the company estimates that it would have taken many years with multiple them compete effectively with well-funded and entrenched competitors.
engineers to create a similar capability if starting from scratch, Rather than building an end-to-end proprietary portfolio of software,
thereby helping support new custom user applications in the wild. they leverage ROS 2’s capabilities where possible. According to
The COVID-19 pandemic Hunter Allen, “We have a competitive product because we have
After the initial coronavirus disease 2019 (COVID-19) lockdowns, the tools needed to make a competitive product. We don’t have to
the robot software team doubled in effective size while having waste time making what ROS 2 already does.” With only 23 employees,

Macenski et al., Sci. Robot. 7, eabm6074 (2022) 11 May 2022 7 of 12

SCIENCE ROBOTICS | REVIEW

as of August 2021, compared with competitors an order of magnitude ROS 2 as an accelerator

larger, ROS 2 has leveled the playing field. Ghost was able to re- Support for ROS 2 is a selling point for Mission, providing abstractions
lease their Vision-60 robot to customers for deployed use after only for internal systems and offering a familiar developer experience. Cross
30 engineer-years (approximately 7.5 engineers over 4 years). reports that for at least three of their customers, “support for ROS 2
ROS 2 provides high-quality communications and countless integration has explicitly played a role in their purchasing decision.”
utilities that Ghost uses such as TF2, URDF, rosbag, rviz, roscli, and Mission sees ROS 2 as an accelerator for their entire industry.
Gazebo, which have accelerated Ghost’s robots into the wild. According to Cross, “in the marine sector, there is little standardization
and lack of building on existing capabilities.” As a result, “people
Sea: Mission robotics keep reinventing the wheel,” from data logging, sensor integra-
Mission Robotics is a San Francisco Bay Area company building tion, to message formats. This duplicate effort is wasteful and
marine robots (Fig. 4B). Their design prioritizes flexibility, supporting a leads to a proliferation of incompatible systems.
wide range of customers who each customize the platform for their Mission Robotics believes that ROS 2 is changing this for marine
application. Use cases for Mission’s robots include structure inspec- robotics as it has done for other industries. A common set of
tion, environmental survey, salvage, and security. These tasks are messages, APIs, and tools will greatly accelerate the work of Mission
traditionally performed by professional divers, whose time is scarce and other companies in the sector. In particular, the use of rosbag
and valuable. The addition of robots allows important underwater for data logging opens the door to collaboration. Such information
work to be done more often, for longer periods of time, and at far exchange can benefit robotics engineers, operators, and marine
less risk to humans. scientists who are the often the end-users of the data. As Cross
Mission’s vehicles carry sensors that gather data about the surface says, “using a consistent communications system is a big win for
and underwater environment. The robot’s sensor suite will vary be- this industry.”
tween users and even between dives performed by a user. It is im-

Downloaded from https://www.science.org on July 25, 2024

portant that users be able to add and remove components for a given Air: Auterion systems
dive while being assured of having reliable access to the resulting Auterion is an aerial drone startup from Zürich, Switzerland. It was
data. Mission Robotics uses ROS 2 as the common data bus for these founded with the goal of nurturing the open-source PX4 Autopilot
data streams and to enable customers to easily integrate new hardware. developer community (43). Building on their PX4 flight experience,
Customer architecture Auterion produces a commercial autopilot based on the project and
Mission’s core on-robot software does not rely on ROS 2. The offers commercial support for customer integrations. Auterion’s
engineering team, having experience using DDS, built their internal products are used widely throughout the industry and support
system on Cyclone and Connext DDS directly (41). This internal many types of airframes, including Freefly (Fig. 4D).
software is maintained exclusively by a small subset of the team Historically, drones could only be operated safely by skilled
at Mission. pilots or in open spaces. Auterion aims to bring drones into
The requirements of marine missions are typically specific to unstructured spaces with hazards while operating under more
customers and not easily generalized, resulting in customization autonomy. With their emphasis on open standards, Auterion selected
after purchase. A common practice in the industry is to attach ROS 2 to integrate higher-level functionality into their drone systems
additional sensors or tools as needed but operate and access each alongside the PX4 Autopilot.
additional peripheral independently, via various device-specific Logging and introspection
interfaces. ROS 2’s logging, introspection, and debugging improved the efficiency
Mission instead uses ROS 2 as the common interface. When a of their development process on Skynode, their fully integrated
new sensor, such as a special low-light camera, is to be integrated, a autopilot solution. The logging capabilities from ROS 2 are used
device driver is developed that communicates with the sensor and to collect runtime events such as errors, debug outputs, and other
publishes its data over ROS 2. The driver is deployed in a docker metadata about the system. These are stored for later analysis and
container, isolating it from the rest of the vehicle. Importantly, debugging. Auterion also relies on rosbag2 to collect the raw data
Mission’s customers can create their own extensions, using ROS 2 stream at runtime from all layers of the system, from sensor streams
as the lingua franca, allowing them to modify their robots quickly for to vehicle behaviors. This comprehensive logging is especially valuable
custom applications and share common infrastructure. for drones because environmental aspects such as wind have im-
As an example, Mission worked with Aqualink to add depth portant effects on flight conditions, which are difficult to reproduce.
sensing to an autonomous surface vessel. The payload of interest As a consequence, ROS 2’s dataset and logging capabilities are central
was a Zed stereo camera, which had out-of-the-box ROS 2 drivers, to effective development, debugging, and validation processes.
including support for the Jetson Nano single-board computer used. Auterion also takes advantage of robust introspection capabilities.
According to Mission Robotics CTO Charles Cross, “stereo cameras Auterion uses rviz2, a three-dimensional renderer that can visualize
are growing in popularity in the marine robotics space, especially drones and all of their sensor data in an interactive environment.
in clear-water applications like coral reef mapping and species iden- The three-dimensional visualization, data recording, and logging
tification.” By integrating the Zed camera via ROS 2 on the Jetson, capabilities in ROS 2 were one of the driving reasons Auterion uses
Mission and Aqualink were able to create a starting point for ROS 2. The value of these tools was captured most succinctly by
anyone wanting to develop new computer vision and autonomy Nuno Marques, a software engineer at Auterion, “the fact that we
capabilities for marine applications. This work has attracted the have introspection and visualization tools makes all the difference.”
attention of other potential customers, with one of them saying that Leveraging these capabilities has allowed the company to focus their
Mission’s approach to payload integration feels “like it was almost development efforts on core flight control capabilities and customer
ahead of its time.” requirements rather than building foundational tooling.

Macenski et al., Sci. Robot. 7, eabm6074 (2022) 11 May 2022 8 of 12

SCIENCE ROBOTICS | REVIEW

Safe, automated testing Environment for Remote Virtual Exploration (VERVE), which
Flying drones has inherent risks to people and things on the ground, allows operators to visualize the rover’s environment (45). The
as well as to the airframe itself. A great deal of labor and time is operators use the result to simulate a move and then finally execute
required to conduct safe flight testing because every physical flight the move on the rover.
has a risk of crashing. In simulation, however, the cost and risks Mission testing in simulation
associated with test flights are near zero. A failure in simulation can Because VIPER is a spaceflight mission, the team is focused on
be fixed and iterated upon quickly and then rerun. Auterion uses producing highly reliable software. To achieve this, they are exten-
ROS 2’s simulation, Gazebo, to be able to conduct end-to-end tests sively using Gazebo to provide high-fidelity testing of all their
of the software before hardware testing to validate safe functionality. components and systems. Mark Allan said that “having a simulator
Gazebo is used in their continuous integration pipeline to prevent [Gazebo] is essential for the development of all the VIPER software
regressions on an array of vehicle types and scenarios. Tests are run in some capacity.”
in parallel for fast results, which allows developers to focus on a The VIPER team turned to Gazebo to aid in development because
specific problem while remaining confident that the software is safe. it was infeasible to model an accurately functioning lunar rover on
Auterion also leverages simulation testing to validate features in Earth. They emphasized that “the Lunar environment is so unique,
challenging scenarios during development. For example, they can with lighting and gravity, testing in simulation [is] incredibly import-
set up flight regimes or specific situations that are important to ant since its impossible to test on the ground on Earth effectively.”
validate their work. In 2021, Auterion flew approximately 22,000 hours The project was able to create a simulation using custom plugins to
within Gazebo, including high-risk scenarios impractical to test Gazebo’s user interfaces. It is designed for a high degree of custom-
with the hardware. Auterion estimates that these simulations re- ization to support a broad range of robotics needs—even space.
placed 12 full-time engineers to provide the same value in live NASA developed new plugins to model mission specifics, such
tests. The cost of their airframes ranges from $1000 to $100,000, so as camera lens flare, lunar lighting conditions, gravity, and terrain

Downloaded from https://www.science.org on July 25, 2024

there is considerable risk in any testing—especially in dangerous flight on the lunar surface. NASA was able to simulate the vehicle inter-
conditions that need testing. ROS 2 simulations in development and faces down to low-level serial links. The simulation was valuable
validation combine to enable lower costs and faster development. to help iterate and improve upon system design choices for
VIPER. With the rover simulated down to the hardware level, the
Space: NASA VIPER VIPER team used Gazebo to test and validate almost all of their
NASA’s Volatiles Investigating Polar Exploration Rover (VIPER) rover’s software before launch.
mission is scheduled to be launched to the southern polar region of VIPER reused 284,500 significant lines of code (SLOC) without
the Moon in November 2023. The VIPER rover will use a variety of modification from Gazebo, modifying <1% to pass validation.
instruments to search for water ice and other resources during a NASA’s estimated development rate for the simulator was 116 SLOC
100-day mission. Earth compute resources will be used to map, per work-month (2456 work-months to fully implement). This
register terrain, and compute stereo solutions to aid in operations code reuse accelerated development, allowing them to produce a
through its X-band link to the Deep Space Network. Many of the simulation in merely 266 work-months, focused on VIPER-specific
Earth-based operation tools, compute modules, and high-fidelity elements (46).
simulations are based on ROS 2 and Gazebo, as shown in Fig. 5. A combination of Gazebo and ROS 2 is used to train the rover’s
NASA’s Core Flight system provides hardware interfaces, basic operators. ROS 2 is used to inject faults into the rover; using VERVE,
error checking, and payload services (44). A satellite link carries the operators need to determine how to clear the faults to get the
commands to and telemetry from the rover. Earth-bound telemetry rover moving.
is received and sent to a ROS 2 network and processed by an ensem- Creating a legacy
ble of nodes. The nodes transform the image data into pointclouds, NASA has used many different communication mechanisms, but in
compute visual odometry and terrain registration, and fuse the data recent years, many projects have chosen DDS because of its ability
to provide pose corrections. Those data are fed into NASA’s Visual to traverse satellite links that may have high latency, low bandwidth,

Fig. 5. VIPER rover in Lunar simulation with command and control software, VERVE. (A) VIPER on Lunar Surface (rendering), (B) Command and Operations Software.

Macenski et al., Sci. Robot. 7, eabm6074 (2022) 11 May 2022 9 of 12

SCIENCE ROBOTICS | REVIEW

and low reliability. The VIPER team evaluated the options and whole business might not have been feasible. It would have been too
selected DDS as well for the Earth-based operations. expensive.” He estimates that their continuing engineering costs
Besides a communications mechanism, the VIPER team was would be 5 to 10% higher annually without it.
eager to use ROS 2 for its rapid development capabilities, intro- Acceleration of development
spection, and visualization tools, and openly available source. These OTTO Motors’ development and deployment have been sped up in
characteristics shorten the learning curve for new engineers to two additional areas. First, it has accelerated their internal feature
apply what they know onto flight missions. development process. The distributed architecture and isolation of
However, using new software in a flight mission requires a rigorous processes have allowed a large, physically distributed team to
verification and validation (V&V) process. NASA prefers to use collaborate. Using clearly defined ROS 2 interfaces allowed OTTO
components that have been vetted in previous missions; leveraging to separate major classes of tasks. Ryan Gariepy stated in an inter-
heritage software leads to reduced development times and costs view, “at the scale of robots we’re building and the complexity that
(47). VIPER is reusing 84% of the 588,000 lines of code from the is modern manufacturing, you really need the flexibility to
Resource Prospector along with Gazebo and approximately 312 patch in and out capabilities and share across a large team.” Their
open-source ROS 2 packages (46). ROS 2 has not been used in prior product software is spread across many repositories owned by
missions, but the VIPER team decided that the features that it different teams in a diverse set of languages, combined at runtime
provides were worth the extra administrative overhead of going via ROS 2.
through the process. After ROS 2 has been validated and used in Next, providing ROS 2 support has proven valuable to their
ground operations for the VIPER mission, it becomes much easier customers and clients. OTTO and Clearpath sell their platforms to
for ROS 2 to be used in future missions in multiple roles and allow other businesses to build on top of custom products. A company
for more reuse of robotic software between mission programs. recently bought platforms from OTTO to create ultraviolet-sanitizing
robots in response to the COVID-19 pandemic. Because they have

Downloaded from https://www.science.org on July 25, 2024

Large scale: OTTO Motors both clearly defined and standard APIs, these external collaborators
OTTO Motors is an Ontario-based Clearpath Robotics spinoff easily leveraged the robot platform and tied it into their autonomy
company selling land and sea research platforms. OTTO produces systems. R. Gariepy summarized it as follows: “With the ROS APIs
warehouse and factory material handling services using autonomous we provide, our external partners are now able to build apps on top
robots to replace manually controlled equipment at scale (Fig. 4C). of our autonomy capabilities without requiring us to train them in
They have deployed thousands of robots worldwide and operate robotics concepts or proprietary libraries.” This ability to separate
fleets of more than 100 in a single facility. Customers such as Toyota concerns and abstract vendor specific hardware, even an entire
and General Electric have adopted OTTO. This case study provides robot platform, allows companies to rapidly build a new product to
unique insight into large-scale robot applications. ROS 2 has coordinated ensure public safety.
more than 2 million hours of operation and 1.5 million km traveled
since it was deployed on OTTO’s robots.
Scaling multirobot technology DISCUSSION
OTTO Motors originally developed their technology on ROS 1. These five case studies illustrate an extensive range of applications,
Using it, they were unable to test more than 25 robots on the same environments, and rationales for the use of ROS 2. These were
shared ROS 1 network using a custom multimaster system with selected to provide a unique cross section of modern, applied
their fleet management software. This was sufficient for small fleets, robotics systems deployed in every domain. However different
but as OTTO grew into larger facilities, this became a bottleneck. they are in their applications, there exist several common threads
OTTO conducted a survey of available technologies and inde- they share.
pendently came to the same conclusion that the best technology for ROS 2 enables many to better reuse software components in
the multirobot fleet communications was DDS. The greater net- their systems. Mission Robotics leverages the ROS community’s
work effect worked in their favor to continue in the ROS ecosystem; device drivers and integrations such that their customers can quickly
thus, they were one of the early adopters of ROS 2. This allowed adapt to a particular use case in marine robotics. Likewise, Auterion
them to take advantage of the capabilities enabled in ROS while not uses not only lower-level drivers but also the higher-level algorithms
independently maintaining a proprietary DDS framework. from the community. The VIPER team uses ROS 2 to facilitate
After migrating to ROS 2, OTTO was able to scale up to 100+ software reuse within the agency. During our interviews, they ex-
robots in customer facilities. Larger multirobot scale was enabled pressed that it was challenging to get other NASA groups to reuse
because ROS 2 has fine-grained and scalable network topology code and that the ROS ecosystem has internal name recognition,
management as well as better support for managing bandwidth making it easier to encourage such collaborations.
through QoS on shared network links. These deployments in 2017 Another common thread was enabling collaborations, both
represented some of the first commercial deployments of ROS 2 internally and externally. Ghost Robotics and OTTO Motors use
anywhere in the world. ROS 2 demonstrably accelerated their time interfaces and composition nodes to separate parts of a complex
to market by quickly enabling them to scale to unprecedented num- system so that teams can collaborate without needing to concern
bers of robots. OTTO Motors estimates they have saved between themselves with the details of other parts of the system. Both Mission
(U.S.) $1 million and (U.S.) $5 million over 5 years by using ROS 2. and Auterion are able to build custom solutions collaboratively
In addition, they saved hundreds of engineering hours by not re- with their customers using ROS 2.
writing these tools into a proprietary framework. Last, ROS 2 has allowed businesses to accelerate others via the
OTTO Motor’s CTO Ryan Gariepy considers the ROS ecosystem sale of trusted platforms. All of the companies surveyed sell their
to be necessary to the business: “Had ROS writ large not existed, the platforms to other businesses to build products on top of. The

Macenski et al., Sci. Robot. 7, eabm6074 (2022) 11 May 2022 10 of 12

SCIENCE ROBOTICS | REVIEW

proliferation of ROS expertise in the industry, matched with its 14. M. Montemerlo, N. Roy, S. Thrun, Perspectives on standardization in mobile robot
freely available licensing, has made it the major robotics SDK. By programming: The carnegie mellon navigation (carmen) toolkit, in Proceedings 2003
IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2003) (Cat. No.
using ROS 2 and its conventions, they are able to sell platforms that
03CH37453) (IEEE, 2003), vol. 3, pp. 2436–2441.
can be put to work in bespoke applications quickly. 15. C. Mohan, R. Dievendorff, Recent work on distributed commit protocols, and recoverable
It should be noted that these themes—software reuse, collabora- messaging and queuing. Data Eng. 17, 1 (1994).
tions, and trusted platforms—are highly correlated with the design 16. J. Waldo, The jini architecture for network-centric computing. Commun. ACM 42, 76–82
principles laid out in the “Design principles” section. In particular, (1999).
17. OASIS, MQTT Version 5.0: OASIS Standard, (OASIS MQTT Technical Committee, 2019).
they are in line with the design principles of Distribution, Abstraction,
18. B. P. Gerkey, R. T. Vaughan, K. Støy, A. Howard, G. S. Sukhatme, Maja J Matarić, Most
and Modularity. The adherence to those design principles has directly Valuable Player: A robot device server for distributed control, in Proceedings of the IEEE/
resulted in the emergent themes in our studies, which represent RSJ International Conference on Intelligent Robots and Systems (IEEE, 2001).
some of the largest acceleration factors for the robotics indus- 19. G. Metta, P. Fitzpatrick, L. Natale, YARP: Yet another robot platform. Int. J. Adv. Robot. Syst.
try today. 3, 8–48 (2006).
20. A. S. Huang, E. Olson, D. C. Moore, LCM: Lightweight Communications and Marshalling, in
IEEE/RSJ International Conference on Intelligent Robots and Systems (IEEE, 2010),
pp. 4057–4062.
CONCLUSION 21. H. Bruyninckx, P. Soetens, B. Koninckx. The real-time motion control core of the Orocos
ROS 2 has been redesigned from the ground up to meet the challenges project, in Proceedings of the IEEE International Conference on Robotics and Automation
of modern robotics. It was designed based off of a thoughtful set of (IEEE, 2003).
principles, modern robotics requirements, and support for exten- 22. Apache Software Foundation, Apache License, Version 2.0 (2021); https://www.apache.
org/licenses/LICENSE-2.0.html [accessed 3 September 2021].
sive customization. Largely based on DDS, ROS 2 is a reliable and
23. K. Birman, T. A. Joseph, Exploiting virtual synchrony in distributed systems, in ACM
high-quality robotics framework that can support a broad range of Symposium on Operating Systems Principles (1987), pp. 123–138.
applications. This framework continues to help accelerate the

Downloaded from https://www.science.org on July 25, 2024

24. J. Corbet, A. Rubini, G. Kroah-Hartman, Linux device drivers ("O’Reilly Media Inc., 2005).
deployment of robots out of the laboratory, into the wild, and is 25. G. Mühl, L. Fiege, P. Pietzuch, Distributed Event-Based Systems (Springer Science & Business
driving the next wave of the robotics revolution. Media, 2006).
We have shown through a series of case studies how it is demon- 26. M. D. McIlroy, E. N. Pinson, B. A. Tague, Unix time-sharing system: Foreword. Bell Syst.
Tech. J. 57, 1899–1904 (1978).
strably accelerating companies and institutions into useful deploy-
27. A. Sundaresan, L. Gerard, Secure ros: Imposing secure communication in a ros system, in
ment in many types of environments at a wide variety of scales. ROSCon Vancouver 2017 (Open Robotics, September 2017).
They display that ROS 2 is an enabler, an equalizer, and an accelerator. 28. K. Fazzari, ROS 2 DDS-Security integration, (2021); https://design.ros2.org/articles/
The standardization around ROS 2 in a variety of industries is ros2_dds_security.html [accessed 6 September 2021].
creating opportunities for new collaborations, faster development, 29. OMG, DDS Security (2022); www.omg.org/spec/DDS-SECURITY/1.0/PDF [accessed
and propelling newly developed technologies forward. This trend 9 February 2022].
30. R. White, G. Caiazza, H. Christensen, A. Cortesi, Procedurally provisioned access control
will likely continue to manifest in the coming years as ROS 2 for robotic systems, in Proceedings of the IEEE/RSJ International Conference on Intelligent
continues to reach its peak maturity. Robots and Systems (IEEE, 2018).
31. I. Lütkebohle, B. O. Gamarra, I. M. Goenaga, J. M. Losa, V. Mayoral Vilches, micro-ROS: ROS
2 on microcontrollers, In ROSCon (Open Robotics, October 2019).
REFERENCES AND NOTES 32. Object Management Group, Data Distribution Service for Real-time Systems Specification
1. M. Quigley, B. Gerkey, K. Conley, J. Faust, T. Foote, J. Leibs, E. Berger, R. Wheeler, A. Ng.
(December, 2004).
ROS: An open-source Robot Operating System, in IEEE International Conference on
33. L. Puck, P. Keller, T. Schnell, C. Plasberg, A. Tanev, G. Heppner, A. Rönnau, R. Dillmann,
Robotics and Automation Workshop on Open Source Software (IEEE, 2009).
Distributed and Synchronized Setup towards Real-Time Robotic Control using ROS2 on
2. S. Chitta, E. Marder-Eppstein, W. Meeussen, V. Pradeep, A. R. Tsouroukdissian, J. Bohren,
Linux, in Proceedings of the 2020 IEEE 16th International Conference on Automation Science
D. Coleman, B. Magyar, G. Raiola, M. Lüdtke, E. F. Perdomo, ros_control: A generic
and Engineering (CASE) (IEEE, 2020), pp. 1287–1293.
and simple control framework for ROS. J. Open Source Soft. 2, 456 (2017).
34. J. Staschulat, I. Lütkebohle, R. Lange, The rclc Executor: Domain-specific deterministic
3. E. Marder-Eppstein, E. Berger, T. Foote, B. Gerkey, K. Konolige, The Office Marathon:
scheduling mechanisms for ROS applications on microcontrollers: Work-in-progress, in
Robust navigation in an indoor office environment, in IEEE International Conference on
International Conference on Embedded Software (IEEE, 2020), pp. 18–19.
Robotics and Automation (IEEE, 2010), pp. 300–307.
35. M. Sagar, ISO Certification of ROS 2, in Embedded World Conference (March 2021).
4. D. Coleman, I. Sucan, S. Chitta, N. Correll, Reducing the barrier to entry of complex robotic
36. J. Torjo, Asio C++ Network Programming: Enhance your skills with practical Examples for
software: A MoveIt! case study. J. Soft. Eng. Robot. 5, 3–16 (2014).
C++ Network Programming (2013).
5. B. Cairl, Deterministic, asynchronous message driven task execution with ros, in
ROSCon Madrid 2018 (Fetch Robotics Inc., Open Robotics, September 2018). 37. C. Yun, AWS IoT RoboRunner for Building Robot Fleet Management Applications (2022);
6. S. Macenski, F. Martín, R. White, J. G. Clavero, The Marathon 2: A Navigation System, in https://aws.amazon.com/blogs/aws/preview-aws-iot-roborunner-for-building-robot-
Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems fleet-management-applications/ [accessed 11 February 2022].
(IEEE, 2020). 38. ROS 2 Design, (2021); http://design.ros2.org/ [accessed 5 August 2021].
7. G. Pardo-Castellote, OMG Data-Distribution Service: Architectural overview, in 39. ROS Enhancement Proposals (2021); https://ros.org/reps/rep-0000.html [accessed 5
International Conference on Distributed Computing Systems Workshops (2003), August 2021].
pp. 200–206. 40. W. Woodall. REP 2004: Package Quality Categories (2021); https://ros.org/reps/rep-2004.
8. W. Woodall, ROS on DDS (2022); https://design.ros2.org/articles/ros_on_dds.html html [accessed 5 August 2021].
[accessed 11 February 2022]. 41. Eclipse Foundation, Cyclone DDS (2021); https://cyclonedds.io/ [accessed 3 September
9. B. Kuipers, E. A. Feigenbaum, P. E. Hart, N. J. Nilsson, Shakey: From conception to history. 2021].
AI Magazine 38, 88–103 (2017). 42. I. D. Miller, F. Cladera, A. Cowley, S. S. Shivakumar, E. S. Lee, L. Jarin-Lipschitz, A. Bhat,
10. R. E. Fikes, N. J. Nilsson, Strips: A new approach to the application of theorem proving N. Rodrigues, A. Zhou, A. Cohen, A. Kulkarni, J. Laney, C. J. Taylor, V. Kumar, Mine tunnel
to problem solving. Artificial Intell. 2, 189–208 (1971). exploration using multiple quadrupedal robots. IEEE Robot. Autom. Lett. 5, 2840–2847
11. R. Brooks, A robust layered control system for a mobile robot. IEEE J. Robot. Autom. 2, (2020).
14–23 (1986). 43. L. Meier, D. Honegger, M. Pollefeys, Px4: A node-based multithreaded open source
12. E. Gat, On three-layer architectures. Artificial Intell. Mobile robots 1998, 195–210 (1998). robotics framework for deeply embedded platforms, in Proceedings of the 2015
13. R. G. Simmons, Structured control for autonomous robots. IEEE Trans. Robot. Autom. 10, IEEE International Conference on Robotics and Automation (ICRA) (IEEE, 2015),
34–43 (1994). pp. 6235–6240.

Macenski et al., Sci. Robot. 7, eabm6074 (2022) 11 May 2022 11 of 12

SCIENCE ROBOTICS | REVIEW

44. D. McComas, NASA/GSFC’s Flight Software Core Flight System, in Flight Software Acknowledgments: We would like to thank the companies’ representatives interviewed in
Workshop (Southwest Research Institute San Antonio, Texas, 2012). the case studies. These include H. Allen and J. Laney from Ghost Robotics, C. Cross from
45. S. Y. Lee, S. Lees, T. Cohen, M. Allan, M. Deans, T. Morse, E. Park, T. Smith, Reusable Mission Robotics, N. Marques and M. Achtelik from Auterion, M. Allan and T. Fong from NASA
science tools for analog exploration missions: xgds web tools, verve, and gigapan Ames, and R. Gariepy from OTTO Motors. We would also like to thank the team at Open
voyage. Acta Astronaut. 90, 268–288 (2013). Robotics, members of the ROS 2 Technical Steering Committee, and the community for their
46. S. Stukes, M. Allan, Matthew Deans Georgia Bajjalieh, T. Fong, J. Hihn, H. Utz, An passionate support.
innovative approach to modeling viper rover software life cycle cost, in Proceedings of
the 2021 IEEE Aerospace Conference (50100) (IEEE, 2021). Submitted 4 October 2021
47. C. Price, Heritage Software Save up to 97% on future V&V for real projects (2021); www. Accepted 13 April 2022
nasa.gov/sites/default/files/03-09_ivv_guidance_for_ivv_for_product_line_software.pdf Published 11 May 2022
[accessed 7 September 2021]. 10.1126/scirobotics.abm6074

Downloaded from https://www.science.org on July 25, 2024

Macenski et al., Sci. Robot. 7, eabm6074 (2022) 11 May 2022 12 of 12