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

Steve Macenski Tully Foote Brian Gerkey

Samsung Research America Open Robotics Open Robotics
[email protected] [email protected] [email protected]

Chris Lalancette William Woodall

Open Robotics Open Robotics
[email protected] [email protected]
arXiv:2211.07752v1 [cs.RO] 14 Nov 2022

Abstract— 1 The next chapter of the robotics revolution is well embedded systems became essential to push the industry for-
underway with the deployment of robots for a broad range of ward. Further, many companies where building workarounds
commercial use-cases. Even in a myriad of applications and on top or inside of ROS 1 to create reliable applications [5].
environments, there exists a common vocabulary of components
that robots share - the need for a modular, scalable, and reliable The second generation of the Robot Operating System,
architecture; sensing; planning; mobility; and autonomy. The ROS 2, was redesigned from the ground up to address these
Robot Operating System (ROS) was an integral part of the last challenges while building on the success of its community-
chapter, demonstrably expediting robotics research with freely- driven capabilities [6]. ROS 2 is based on the Data Dis-
available components and a modular framework. However, ROS tribution Service (DDS), an open standard for communica-
1 was not designed with many necessary production-grade fea-
tures and algorithms. ROS 2 and its related projects have been tions that is used in critical infrastructure such as military,
redesigned from the ground up to meet the challenges set forth spacecraft, and financial systems [7]. It solves many of the
by modern robotic systems in new and exploratory domains at problems in building reliable robotics systems. DDS enables
all scales. In this review, we highlight the philosophical and ROS 2 to obtain best-in-class security, embedded and real-
architectural changes of ROS 2 powering this new chapter time support, multi-robot communication, and operations
in the robotics revolution. We also show through case studies
the influence ROS 2 and its adoption has had on accelerating in non-ideal networking environments. DDS was selected
real robot systems to reliable deployment in an assortment of after considering other communication technologies, e.g.
challenging environments. ZeroMQ, RabbitMQ, due to its breadth of features including
a UDP transport, distributed discovery, a builtin security
I. I NTRODUCTION standard [8].
Many software platforms have been proposed, sometimes In this review article, we will establish ROS 2’s state of
called middlewares, introducing modular and adaptable fea- the art suitability for modern robot systems and showcase
tures making it easier to build robot systems. Over time, the technological and philosophical changes that have driven
some middlewares have grown to become rich ecosystems its success. Then, we will expand on that foundation to
of utilities, algorithms, and sample applications. Few rival demonstrate how ROS 2 is influencing the deployment of
the Robot Operating System (ROS 1) in its significance on autonomous systems in several unique domains. Five case
the maturing robotics industry. studies explore how ROS 2 has enabled or accelerated robots
ROS 1 was popularized by the robotics incubator, Willow into the wild on land, sea, air, and even space.
Garage [1]. Every effort was made to create a quality II. R ELATED W ORK
and performant system, but security, network topology, and
system up-time were not prioritized. Regardless, ROS 1 The history of robot software is long and storied, going
has become influential in nearly every intelligent machine back more than 50 years with robots like Shakey [9].
sector. Its commercial rise was the result of flagship projects Over time, much has been written about how to structure
providing autonomous navigation, simulation, visualization, classical planners, concurrent behaviors, and three-layer ar-
control, and more [2], [3], [4]. As commercial opportunities chitectures [10], [11], [12]. An early example of this is
transitioned into products, ROS’s foundation as a research the Task Control Architecture (TCA), which was used to
platform began to show its limitations. Security, reliability control a variety of robots. For example, CARMEN was
in non-traditional environments, and support for large scale built on TCA’s message-passing system called IPC (Inter-
Process Communications) [13], [14]. Message-passing has
1 This manuscript has been accepted for publication in Science Robotics. its own rich history in distributed systems: from IBM’s work
This version has not undergone final editing. Please refer to the complete on message queuing, Java’s Jini, and middlewares such as
version of record at https://www.science.org/doi/10.1126/ MQTT [15], [16], [17].
scirobotics.abm6074. The manuscript may not be reproduced or
used in any manner that does not fall within the fair use provisions of Robotics frameworks provide architectural methods to
the Copyright Act without the prior, written permission of AAAS. decompose complex software into smaller and more man-
 Category ROS 1 ROS 2
ageable pieces. Some of these components can find re-use Network Transport Bespoke protocol Existing standard
in other systems and may be established into libraries to built on TCP/UDP (DDS), with
be leveraged by users. An early attempt to manage this abstraction
supporting
complexity was via a client/server approach in Player [18]. addition of others
A Player server communicates with robot hardware and runs Network Architecture Central name Peer-to-peer
the algorithms needed to perform its task. Clients can connect server (roscore) discovery
Platform Support Linux Linux, Windows,
to the server to extract data and control the robot over a TCP macOS
connection. However, its architecture hampered reliability, Client Libraries Written Sharing a
code reuse, and ability to change out components. independently in common
each language underlying C
YARP aids in building control systems organized as peers, library (rcl)
Node vs. Process Single node per Multiple nodes
communicating over several protocols [19]. It facilitates process per process
research development and collaboration by promoting code Threading Model Callback queues Swappable
reuse and modularity while retaining high performance. and handlers executor
Node State Management None Lifecycle nodes
YARP can be used for any application, but its community Embedded Systems Minimal Commercially
has focused on humanoid and legged robotics, such as iCub experimental supported
and the MIT Cheetah and only supports C++. support implementation
(rosserial) (micro-ROS)
Parameter Access Auxilliary Implemented
LCM is a middleware which uses a publish/subscribe protocol built on using service calls
model with bindings in many languages. It concentrates on XMLRPC
handling messaging and data marshalling in high-bandwidth Parameter Types Type inferred Type declared and
when assigned enforced
low-latency environments [20]. This limits the range of
robotic applications for which LCM can be effectively used. TABLE I: Summary of ROS 2 features compared to ROS 1
OROCOS is a set of libraries for robot control, focused on
real-time control systems and related topics, such as comput-
ing kinematic chains and Bayesian filtering [21]. The project III. ROS 2
has grown into a full framework integrating the CORBA
ROS 2 is a software platform for developing robotics
middleware and tooling for deterministic computation in real-
applications, also known as a robotics software development
time applications. The LCM and OROCOS frameworks each
kit (SDK). Importantly, ROS 2 is open source. ROS 2 is
concentrate on smaller pieces of the overall system, with a
distributed under the Apache 2.0 License, which grants users
non-trivial proportion of the overall robotics problem left to
broad rights to modify, apply, and redistribute the software,
the end-user.
with no obligation to contribute back [22]. ROS 2 relies on
ROS 1 contains a set of libraries that are useful when a federated ecosystem, in which contributors are encouraged
building many kinds of robots [1]. There are utilities for to create and release their own software. Most additional
monitoring processes, introspecting communications, receiv- packages also use the Apache 2.0 License or similar. Making
ing time-series transformations, and more. ROS 1 also has a code free is fundamental to driving mass adoption - it allows
large ecosystem of sensor, control, and algorithmic packages users to leverage ROS 2 without constraining how they use
made available by community contributions, enabling a small or distribute their applications.
team to build complex robotics applications. While ROS 1 A. Scope
solves many of the complexity issues inherent to robotics,
ROS 2 supports a broad range of robotics applications,
it struggles to consistently deliver data over lossy links (like
from education and research to product development and
WiFi or satellite links), has a single point of failure, and does
deployment. It comprises a large set of interrelated software
not have any built-in security mechanisms. A table of key
components that are commonly used to develop robotics
differences between ROS 1 and ROS 2 can be seen in Table
applications. The software ecosystem is divided into three
I.
categories:
The ROS 1 community attempted to address some of these • Middleware: Referred to as the plumbing, the ROS 2
concerns, but in nearly all cases, there were compromises middleware encompasses communication among com-
made due architectural and engineering limitations. For ex- ponents, from network APIs to message parsers.
ample, to address the single point of failure (“rosmaster”), • Algorithms: ROS 2 provides many of the algorithms
it was required to patch all of the existing client libraries commonly used when building robotics applications,
individually with bespoke solutions. In other cases, it was e.g. perception, SLAM, planning, and beyond.
possible to extend ROS 1 for security, via the SROS project. • Developer tools: ROS 2 includes a suite of command-
Though successful, it was difficult to maintain and needed line and graphical tools for configuration, launch, in-
further development to meet security trends. These are just trospection, visualization, debugging, simulation, and
two of the many attempts to patch ROS 1, which extended logging. There is also a large suite of tools for source
its useful lifetime but did not solve its core limitations. management, build processes, and distribution.
In this section, we will explore the first category, the mid- and malicious misuse. ROS 2’s integrated security system
dleware, as the foundation of ROS 2. includes authentication, encryption, and access control [27],
[28], [29]. Designers can configure ROS 2 to meet their
B. Design needs through access control policies that define who can
1) Design Principles: The design of ROS 2 has been communicate about what [30].
guided by a set of principles and a set of specific require- Embedded systems As a general rule, a robot includes
ments. The following principles are asserted: sensors, actuators, and other peripherals. These devices can
Distribution As with similarly complex domains, prob- be relatively sophisticated, containing micro-controllers that
lems in robotics are best tackled with a distributed systems need to communicate with CPU(s) where ROS 2 is running.
approach [23]. Requirements are separated into functionally A full ROS 2 stack is not expected to run on small embedded
independent components, like device drivers for hardware, devices, though ROS 2 should facilitate and standardize in-
perception systems, control systems, executives, and so on. tegration of CPUs and micro-controllers. Micro-ROS allows
At run-time, these components have their own execution ROS 2 to be reused on embedded systems [31].
context and share data via explicit communication. This Diverse networks Robots are used in a variety of net-
composition should be conducted in a decentralized and working environments, from wired LAN for robot arms
secure manner. on assembly lines to multi-hop satellite connections for
Abstraction To govern communication, interface spec- planetary rovers. Additionally, robots will often use internal
ifications must be establish. These messages define the networks to connect processes within and across CPUs.
semantics of the data exchanged. A favorable abstraction ROS 2 provides quality of service that configures how data
balances the benefits of exposing the details of a component flows through the system, thereby adapting to the constraints
against the costs of overfitting the rest of the application to of a network [32].
that component, thereby making it difficult to substitute an Real-time computing From humanoids to self-driving
alternative. This approach leads to an ecosystem of interop- cars, it is common for robot applications to include real-time
erable components abstracted away from specific vendors of computing requirements. To meet safety and/or performance
hardware or software components [24]. goals, some parts of a system must execute in deterministic
Asynchrony The messages defined are communicated amounts of time. ROS 2 offers APIs for developers of real-
among the components asynchronously, creating an event- time systems to enforce application-specific constraints [33],
based system [25]. With this approach, an application can [34].
work across the multiple time domains that arise from com- Product readiness When a robot moves beyond the lab
bining physical devices with a host of software components; and into commercial use, new constraints are introduced.
each of which may have its own frequency for providing ROS 2 aims to meet product requirements spanning design,
data, accepting commands, or signaling events. development, and project governance. One objective result
Modularity The UNIX design goal to ‘make each pro- of these efforts is Apex.AI’s functional safety (ISO 26262)
gram do one thing well’ is mirrored [26]. Modularity is en- certification of their ROS 2-based autonomous vehicle soft-
forced at multiple levels, across library APIs, message defini- ware [35]. This allows ROS 2 to be run in safety critical
tions, command-line tools, and even the software ecosystem systems like autonomous vehicles and heavy machinery.
itself. The ecosystem is organized into a large number of
federated packages, as opposed to a single codebase. C. Communication Patterns
We do not pretend that these design principles are universal The ROS 2 APIs provide access to communication pat-
and without trade-offs. Asynchrony can also make it more terns. These are notably topics, services, and actions, which
difficult to achieve deterministic execution. For any single, are organized under the concept of a node. ROS 2 also
well-defined problem, it is possible to construct a special- provides APIs for parameters, timers, launch, and other
purpose monolithic solution that is more computationally ef- auxiliary tools which can be used to design a robotic system.
ficient because it does not involve abstractions or distributed Topics The most common pattern that users will interact
communication. with is topics, which are an asynchronous message passing
However, after a decade of experience with the ROS 1 framework. This is similar to other asynchronous frame-
project, we claim that adherence to these principles will works, such as ASIO [36]. ROS 2 provides the same publish-
generally lead to better outcomes. This approach facilitates subscribe functionality, but focuses on using asynchronous
code reuse, software testing, fault isolation, collaboration messaging to organize a system using strongly typed inter-
within interdisciplinary project teams, and cooperation at a faces. It does so by organizing endpoints in a computational
global scale. graph under the concept of a node. The node is an important
2) Design Requirements: ROS 2 aims to meet certain organizational unit which allows a user to reason about a
requirements based on the design principles and needs of complex system, shown in Fig. 1.
robotics developers. The anonymous publish-subscribe architecture allows
Security Any software that interacts with a network must many-to-many communication, which is advantageous for
include features to secure that interaction against accidental system introspection. A developer may observe any messages
passing on a topic by creating a subscription to that topic Users may choose different rmw implementations, and
without any changes. thereby different middleware technologies, based on a va-
Services Asynchronous communication is not always the riety of constraints like performance, software license, or
right tool. ROS 2 also provides a request-response style supported platforms. While all of the supported rmws are
pattern, known as services. Request-response communica- based on DDS, a few community-supported rmws exist for
tion provides easy data association between a request and other communications methods [7]. This abstraction layer
response pair, which can be useful when ensuring a task provides flexibility to ROS 2, allowing it to change over
was completed or received, shown in Fig. 1. Uniquely, time with minimal impact to the systems built atop it.
ROS 2 allows a service client’s process to not be blocked The network interfaces (e.g. topics, services, actions) are
during a call. Services are also organized under a node defined with Message Types using an Interface Description
for organization and introspection, allowing a subsystem’s Language (IDL). ROS 2 defines these types using the ros
interfaces to appear together in system diagnostics. idl format (.msg files) or the OMG IDL standard (.idl
Actions A unique communication pattern of ROS 2 is files). User-provided interface definitions are generated at
the action. Actions are goal-oriented and asynchronous compile time and create code required for communication
communication interfaces with a request, response, periodic in any client library language.
feedback, and the ability to be canceled, Fig. 1. This pattern 2) Architectural Node Patterns: There are additional ar-
is used in long-running tasks like autonomous navigation or chitectural patterns to help developers structure their pro-
manipulation, though it has a variety of uses. Like services, grams. ROS 2 provides a pattern for managing the lifecycle
actions are non-blocking and organized under the node. of nodes which transition through a state machine with states
like Unconfigured, Inactive, Active, and Finalized. These
D. Middleware Architecture states allow system integrators to control when certain nodes
Adhering to the previous design philosophies, the archi- are active. This is an important tool for coordinating various
tecture of ROS 2 consists of several important abstraction parts of the distributed asynchronous system.
layers distributed across many decoupled packages. These As previously discussed in the last section, communi-
abstraction layers make it possible to have multiple solu- cations are agnostic to the location of endpoints within
tions for required functionality, e.g. multiple middlewares or machines and processes. However, in which machine or
loggers. Additionally, the distribution across many packages process to put each node is not something that should be
allows users to replace components or take only the pieces decided when writing the node, but instead depends on
of the system they require, which may be important for how the node is used in the larger system. Nodes that are
certification. written as components can be allocated to any process as a
1) Abstraction Layers: Figure 2 displays the abstraction configuration. This is an important feature for systems under
layers within ROS 2. They are generally hidden behind the development, allowing the developer to rearrange where
client library during development and developers would only nodes are running based on a variety of circumstances. For
need to be aware of them for unusually application-specific example, multiple nodes might be configured to share a
needs. Most users will experience only the client libraries. process in order to conserve system resources or reduce
The client libraries provide access to the core communica- latency.
tion APIs. They are tailored to each programming language
E. Software Quality
to make them more idiomatic and take advantage of language
specific features. Communication is agnostic to how the For ROS 2 to be adopted in critical applications, it must
system is distributed across compute resources - whether be designed and implemented in a demonstrably high-quality
they be in the same process, a different process, or even manner. Regulatory and certification bodies need to under-
a different computer. A user may distribute their application stand the current state of a system and the processes that
across multiple machines and processes, and even leverage led to it. To that end, a three-part approach is continuously
cloud compute resources, with minimal changes to the source executed to measure and expose software quality:
code. ROS 2 is capable of connecting to cloud resources over • Design documentation: Prior to a major addition, a
the internet. There are products to assist integration of ROS 2 written rationale and design for the work must be
into cloud platforms, such as AWS IoT RoboRunner and established. This documentation manifests as a design
related RoboMaker products [37]. It is advisable, however, article or a ROS Enhancement Proposal (REP) [38],
to use more specialized purpose-built technologies. [39]. At the time of writing, there are 44 design articles
The client libraries depend on an intermediate interface, and 7 REPs documenting the design of ROS 2.
rcl, which provides common functionality to each client • Testing: Each feature in ROS 2 requires tests to ensure
library. This library is written in C and is used by all of that it behaves correctly. Those tests are executed reg-
the client libraries, although not required. Below rcl, the ularly in continuous integration. A combination of unit
middleware abstraction layer called rmw (ROS MiddleWare) and integration tests are deployed, as well as a suite of
provides the essential communication interfaces. The vendors static analysis tools (“linters”). At the time of writing,
for each middleware implements the rmw interface and are 32,000–33,000 tests are run on ROS 2, including 13
made interchangeable without code changes. linters.
 Fig. 1: ROS 2 node interfaces: topics, services, and actions.

Fig. 2: ROS 2 Client Library API Stack.

• Quality declaration: Not every ROS 2 package needs suffered in these situations.
to be rigorously documented and tested. Thus, a multi- ROS 2 does not struggle in these situations. DDS uses
level quality policy is defined [40]. This policy defines UDP to deliver data, which does not attempt to re-transmit
the requirements for each quality level in terms of devel- data. Instead, DDS decides when and how to re-transmit
opment practices, test coverage, security, and more. At in unreliable conditions. DDS introduces Quality-of-Service
the time of writing, 45 ROS 2 packages have achieved (QoS) to expose these settings to optimize for the available
the highest level, Quality Level 1. bandwidth and latency.
F. Performance and Reliability The reliability setting determines whether message de-
Networking is an important aspect of robotics frameworks. livery is guaranteed. Using ‘best-effort’, the publisher will
In reliable networking situations, the standard solution is attempt to deliver the message once, useful when new data
TCP/IP due to its optimizations in most operating systems. will make the old obsolete (e.g. sensor data). Set to ‘reliable’,
Unfortunately, TCP/IP struggles to deliver data in wireless the publisher will continue to send data until the receiver
communications since interruptions can cause back-offs, re- acknowledges receipt.
transmits, and delays. ROS 1 was built on TCP/IP and The durability QoS setting determines the persistence of
a message. ‘Volatile’ messages will be forgotten once after at communicating information larger than 1 MB, which
being sent. Meanwhile, ‘transient-local’ will store and send represents a real challenge to users. There are a few reasons
late-joining subscriptions data as necessary. for this: the small default UDP buffer sizes, UDP fragmen-
A connection’s history determines the behavior when tation limits, and DDS reliability guarantees requiring the
the network cannot keep up with the data. Set to ‘keep- re-transmit of packets. Many of these issues can be removed
all’, all data is retained until the application consumes it. with tuning of the networking parameters at the expense of
Most applications use ‘keep-last’, which retains a fixed-sized compute resources. The performance may also be improved
queue of data, overriding the oldest as needed. Other settings, by using the composition and intra-process communication
including deadline, lifespan, liveliness, and lease duration to patterns in ROS 2. Composition is the recommended design
help in designing real-time systems. pattern in ROS 2 and is made simple to encourage its
Experiments were conducted to benchmark the networking adoption.
performance of ROS 2. The charts in Figure 3a shows The charts in Figure 3b shows the resilience of ROS 2 to
the results of sending and receiving different sizes of mes- packet loss in the network. The tests were run on an Ubuntu
sages through ROS 2. This experiment was run on a 6- 20.04 virtual machine, containing 6 Intel Xeon E5-2666 v3
core Intel i7-6800K CPU running at 3.4GHz, with 32Gb CPUs at 2.9GHz and 16GB of RAM, using the CycloneDDS
of RAM. The machine was running Fedora 34, using rmw. For each test the same publisher and subscription node,
CycloneDDS, and the latest ROS 2 Rolling distribution in separate processes, were run. The networking was run
packages as of September 23, 2021 [41]. The performance through mininet, a network emulator which lets users
tests utilized can be found in https://github.com/ specify arbitrary topologies and link characteristics. In this
ros2/performance_test and https://github. experiment, the bandwidth was capped at 54Mbps (compa-
com/ros2/buildfarm_perf_tests. rable to a slow wireless network) and the packet loss was
The tests comprise of one publisher and one subscription. varied between 0 and 20 percent. Each message consisted of
For each message size, 1,000 messages are sent per second an array of 1000 bytes and the number of messages that
and the system records the latency, effective publication rate, were received was tallied. In a network with a moderate
and CPU utilization. The message sizes are selected to test amount of loss, ROS 2 can still deliver data over the network
different aspects, ranging from small to larger messages at effectively. 20% is a particularly bad networking environment
key intervals. The test is repeated in different processes, where performance is expected to drop more significantly.
within the same process, and within the same process using G. Security
intra-process communication.
Security is an important element to any modern com-
The data shows that intra-process communication is the
mercial robotics SDK. ROS 2 relies on the DDS-Security
most efficient, with 95th percentile latency below 1 mil-
standard, but also provides an additional suite of tools,
lisecond for all sizes below 8 MB. Intra-process is the most
SROS2, to make managing security infrastructure easy. There
reliable, meeting the sending rate for all sizes below 8 MB.
are 3 main concepts in DDS-security:
This bypasses the middleware stack and delivers data by
Authentication Establishes the identity of a message or
passing pointers from the publisher to the subscription. This
participant in the network. ROS 2 uses digital signatures for
improvement is particularly magnified when working with
authentication, known as public key cryptography. SROS2
large messages, around 1 MB and larger, which are most
includes command-line utilities for generating and storing
often associated with images, pointclouds, or other forms of
these digital signatures.
high-resolution data. When using node composition, the data
Access Control Allows for fine-grained policies to be
shows a similar story - the 95th percentile latency is below
applied to the authenticated network participants. It allows
1 millisecond with no dropped messages for sizes below 8
a participant to only discover approved participants and
MB.
communicate over pre-approved network interfaces. SROS2
Multi-process communication allows the publisher and
has command-line tools for generating these configurations.
subscription to be on separate machines on the network.
Encryption This ensures that third-parties cannot eaves-
Expectedly, it also shows the highest latency, below 1 mil-
drop or replay data into the network. Encryption is performed
lisecond until 1 MB, then spiking to 7.85 milliseconds by 8
using AES-GCM symmetric-key cryptography. The key ma-
MB. The send rate shows a similar trend; at sizes up to 2
terial is derived from the shared secret obtained as part of
MB, the 95th percentile send rate is 1000 Hz, decreasing to
authentication.
213 Hz for 8 MB.
Using multiple processes and inter-process communication IV. C ASE S TUDIES
is the most flexible scenario, but it also displays the highest Five case studies were conducted that highlight the mate-
latency and CPU utilization. Simply using node composition rial acceleration provided by ROS 2. Each study provides a
and/or intra-process communication, the latency, CPU uti- principally qualitative analysis of ROS 2’s influence on each
lization, and sending rate are each cut significantly. However, organization based on interviews, customer experiences, and
for small messages, all of the mechanisms were able to codebases analyzed during the study. The variety of use cases
publish reliably in excess of 1kHz without loss. and scales demonstrates the significance of ROS 2 across the
DDS’s default configurations is not particularly effective robotics sector.
 10 35 1,000

Intra-process Intra-process 900

30
Single process Single process
8 800
Mean Latency (ms) Inter-process Inter-process
25

Sending rate (Hz)

700

Mean CPU (%)

6 600
20

500

15
4 400

10 300

2 200
Intra-process
5 Single process
100
Inter-process
0 0 0
1k 4k 16k 32k 60k 512k 1m 2m 4m 8m 1k 4k 16k 32k 60k 512k 1m 2m 4m 8m 1k 4k 16k 32k 60k 512k 1m 2m 4m 8m

Message Size (bytes) Message Size (bytes) Message Size (bytes)

(a) Different message sizes

30 30 30

25 25 25
# of Messages

# of Messages

# of Messages
20 20 20

15 15 15

10
0% packet loss 10
10% packet loss 10
20% packet loss

5 Messages Sent 5 Messages Sent 5 Messages Sent

Messages Received Messages Received Messages Received
0 0 0
2 4 6 8 10 12 14 16 2 4 6 8 10 12 14 16 2 4 6 8 10 12 14 16

Time (s) Time (s) Time (s)

(b) Sending data with packet loss

Fig. 3: ROS 2 performance results (standard deviation not shown since it is so small)

A. Land: Ghost Robotics tecture.” Their mission control software uses ROS 2 actions
Ghost Robotics is a Philadelphia-based company spe- to request, cancel, or attain feedback regarding an current
cializing in quadruped robots for defense, enterprise, and mission. It takes a mission identifier to cross-reference with
research. Their robots, shown in Figure 4a, are made for an internal database of potential missions to execute. Next, it
unstructured natural environments that cannot be traversed assembles each task in the mission and activates the required
by traditional wheeled or tracked robots. Ghost’s Vision-60 capabilities for the particular mission, modeled as lifecycle
robot is being deployed in caves, mines, forests, and deserts, nodes. Finally, it executes the mission.
and can easily walk through several inches of water or snow. Most of Ghost’s software is implemented as both lifecy-
Their robots were used by the University of Pennsylvania cle and component nodes. The lifecycle node are used to
team in the DARPA Subterranean Challenge and Ghost has dynamically activate and deactivate features depending on
active partnerships with the US military for base security and the current mission requirements, such as toggling between
other experimental applications [42]. GPS-based and VIO-based localization. They have dozens of
ROS 2 is used on their main compute platform, an unique capabilities readily available for different missions,
Nvidia Jetson Xavier, which handles mission execution, which take up little background resources when idle. The
high-level gait planning, terrain mapping, and localization. component nodes are independent modules developed by
Approximately 90% of Ghost’s software utilizes ROS 2 for multiple teams and combined at run-time. Ghost found that
its communication and architecture, while the remaining is these strategies are important when collaborating with a large
planned to follow suit in the near future. interdisciplinary team on a limited-compute platform.
1) Software Architecture: ROS 2 has had a powerful The provided ROS 2 tools allowed Ghost to create a highly
role in structuring their internal collaborations and software flexible and efficient autonomy system in only a few months.
design. Both their high level and mission control software ar- By contrast, the company estimates it would have taken many
chitectures are heavily integrated with ROS 2. They leverage years with multiple engineers to create a similar capability
publish-subscribe interfaces between their main subsystems, if starting from scratch, thereby helping support new custom
allowing them to enjoy a consistent API while the techniques user applications in the wild.
within each are being continuously improved. This clean 2) The COVID-19 Pandemic: After the initial COVID-
separation between projects has allowed them to perform 19 lock-downs, the robot software team doubled in effective
parallel development without disrupting the activities of other size while having reduced access to crucial hardware. At
teams. the same time, they were preparing for a demonstration with
According to Hunter Allen, Senior Autonomy Engineer, the US Air Force (USAF) only months away. Ultimately, the
“It’s been great; it is fundamental to our autonomy archi- company was successful by pivoting their processes to utilize
 (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.
Fig. 4: Case-study robot systems deployed on land, air, and sea.

capabilities made available in ROS 2. less utilities Ghost uses such as TF2, URDF, rosbag, rviz,
Prior to the pandemic, the majority of development oc- roscli, Gazebo, which has accelerated Ghost’s robots into
curred using robots in their offices. When access to robots the wild.
was abruptly stopped, Ghost had to switch development over
to the ROS 2 simulator, Gazebo. A single engineer was B. Sea: Mission Robotics
able to create custom Gazebo plugins and simulation files Mission Robotics is a San Francisco Bay Area company
required to represent the quadruped. This simulation was building marine robots, Figure 4b. Their design prioritizes
used to develop the entirety of the USAF demonstration’s flexibility, supporting a wide range of customers who each
autonomy system. This new capability is still utilized long customize the platform for their application. Use cases for
after they were able to return to their offices - it has permitted Mission’s robots include structure inspection, environmental
faster internal development to create custom behaviors and survey, salvage, and security. These tasks are traditionally
deploy them onto customer’s robots. performed by professional divers, whose time is scarce and
3) ROS 2 as an Equalizer: ROS 2 is a strong equalizing valuable. The addition of robots allows important underwater
force for Ghost Robotics. It has helped them compete effec- work to be done more often, for longer periods of time, and
tively with well-funded and entrenched competitors. Rather at far less risk to humans.
than building an end-to-end proprietary portfolio of software, Mission’s vehicles carry sensors that gather data about the
they leverage ROS 2’s capabilities where possible. According surface and underwater environment. The robot’s sensor suite
to Allen, “We have a competitive product because we have will vary between users and even between dives performed
the tools needed to make a competitive product. We don’t by a user. It is important that users be able to add and remove
have to waste time making what ROS 2 already does.” components for a given dive, while being assured of having
With only 23 employees, as of August 2021, compared to reliable access to the resulting data. Mission Robotics uses
competitors an order of magnitude larger, ROS 2 has leveled ROS 2 as the common data bus for these data streams and
the playing field. Ghost was able to release their Vision-60 to enable customers to easily integrate new hardware.
robot to customers for deployed use after only 30 engineer- 1) Customer Architecture: Mission’s core on-robot soft-
years (approx. 7.5 engineers over 4 years). ware does not rely on ROS 2. The engineering team, having
ROS 2 provides high-quality communications and count- experience using DDS, built their internal system on Cyclone
and Connext DDS directly [41]. This internal software is C. Air: Auterion Systems
maintained exclusively by a small subset of the team at Auterion is an aerial drone startup from Zürich, Switzer-
Mission. land. It was founded with the goal of nurturing the open-
The requirements of marine missions are typically specific source PX4 Autopilot developer community [43]. Building
to customers and not easily generalized, resulting in cus- on their PX4 flight experience, Auterion produces a commer-
tomization after purchase. Common practice in the industry cial autopilot based on the project and offers commercial
is to attach additional sensors or tools as needed, but operate support for customer integrations. Auterion’s products are
and access each additional peripheral independently, via used widely throughout the industry and support many types
various device-specific interfaces. of airframes, including Freefly shown in Fig. 4d.
Mission instead uses ROS 2 as the common interface. Historically, drones could only be operated safely by
When a new sensor, such as a special low-light camera, is to skilled pilots or in open spaces. Auterion aims to bring
be integrated, a device driver is developed that communicates drones into unstructured spaces with hazards while oper-
with the sensor and publishes its data over ROS 2. The driver ating under more autonomy. With their emphasis on open
is deployed in a Docker container, isolating it from the rest of standards, Auterion selected ROS 2 to integrate higher level
the vehicle. Importantly, Mission’s customers can create their functionality into their drone systems alongside the PX4
own extensions, using ROS 2 as the lingua franca, allowing Autopilot.
them to modify their robots quickly for custom applications 1) Logging and Introspection: ROS 2’s logging, intro-
and share common infrastructure. spection, and debugging improved the efficiency of their
As an example, Mission worked with Aqualink to add development process on Skynode, their fully-integrated au-
depth sensing to an autonomous surface vessel. The payload topilot solution. The logging capabilities from ROS 2 are
of interest was a Zed stereo camera, which had out-of- used to collect run-time events such as errors, debug outputs,
the-box ROS 2 drivers, including support for the Jetson and other metadata about the system. These are stored
Nano single-board computer used. According to Mission for later analysis and debugging. Auterion also relies on
Robotics CTO Charles Cross, “stereo cameras are growing rosbag2 to collect the raw data stream at run-time from
in popularity in the marine robotics space, especially in all layers of the system, from sensor streams to vehicle
clear-water applications like coral reef mapping and species behaviors. This comprehensive logging is especially valuable
identification.” By integrating the Zed camera via ROS 2 for drones because environmental aspects such as wind have
on the Jetson, Mission and Aqualink were able to create a important effects on flight conditions, which are difficult to
starting point for anyone wanting to develop new computer reproduce. As a consequence, ROS 2’s dataset and logging
vision and autonomy capabilities for marine applications. capabilities are central to effective development, debugging,
This work has attracted the attention of other potential and validation processes.
customers, with one of them saying that Mission’s approach Auterion also takes advantage of robust introspection
to payload integration feels “like it was almost ahead of its capabilities. Auterion uses rviz2, a 3-dimensional renderer
time.” which can visualize drones and all of their sensor data in an
2) ROS 2 as an Accelerator: Support for ROS 2 is a interactive environment.
selling point for Mission, providing abstractions for internal The 3-dimensional visualisation, data recording, and log-
systems and offering a familiar developer experience. Cross ging capabilities in ROS 2 were one of the driving reasons
reports that for at least three of their customers, “support Auterion utilizes ROS 2. The value of these tools was
for ROS 2 integration has explicitly played a role in their captured most succinctly by Nuno Marques, a Software
purchasing decision.” Engineer at Auterion, “The fact that we have introspection
Mission sees ROS 2 as an accelerator for their entire and visualization tools make all the difference.” Leverag-
industry. According to Cross, “in the marine sector, there is ing these capabilities has allowed the company to focus
little standardization and a lack of building on existing ca- their development efforts on core flight control capabilities
pabilities.” As a result, “people keep reinventing the wheel,” and customer requirements rather than building foundational
from data logging, to sensor integration, to message formats. tooling.
This duplicate effort is wasteful and leads to a proliferation 2) Safe, Automated Testing: Flying drones has inherent
of incompatible systems. risks to people and things on the ground, as well as to the
Mission Robotics believes that ROS 2 is changing this for airframe itself. A great deal of labor and time is required
marine robotics as it has done for other industries. A common to conduct safe flight testing since every physical flight has
set of messages, APIs, and tools will greatly accelerate a risk of crashing. In simulation, however, the cost and
the work of Mission and other companies in the sector. risks associated with test flights is near zero. A failure in
In particular, the use of rosbag for data logging opens the simulation can be fixed and iterated upon quickly, then rerun.
door to collaboration. Such information exchange can benefit Auterion uses ROS 2’s simulation, Gazebo to be able to
robotics engineers, operators, and marine scientists who are conduct end-to-end tests of the software prior to hardware
the often the end-users of the data. As Cross says, “using testing to validate safe functionality.
a consistent communications system is a big win for this Gazebo is used in their continuous integration pipeline
industry.” to prevent regressions on an array of vehicle types and
scenarios. Tests are run in parallel for fast results, which NASA developed new plugins to model mission-specifics,
allows developers to focus on a specific problem while such as camera lens flare, lunar lighting conditions, gravity,
remaining confident the software is safe. and terrain on the lunar surface. NASA was able to simulate
Auterion also leverages simulation testing to validate the vehicle interfaces down to low-level serial links. The
features in challenging scenarios during development. For simulation was valuable to help iterate and improve upon
example, they can setup flight regimes or specific situations system design choices for VIPER. With the rover simulated
which are important to validate their work. In 2021, Auterion down to the hardware level, the VIPER team used Gazebo
flew approximately 22,000 hours within Gazebo, including to test and validate almost all of their rover’s software prior
high-risk scenarios impractical to test with hardware. Aute- to launch.
rion estimates that these simulations replaced 12 full-time VIPER reused 284,500 significant lines of code (SLOC)
engineers to provide the same value in live tests. Since the without modification from Gazebo, modifying < 1% to pass
cost of their airframes range from $1,000 to $100,000, there validation. NASA’s estimated development rate for the simu-
is considerable risk in any testing - especially in dangerous lator was 116 SLOC per work-month (2456 work-months to
flight conditions which need testing. ROS 2 simulations in fully implement). This code reuse accelerated development
development and validation combine to enable lower costs allowing them to produce a simulation in merely 266 work-
and faster development. months focused VIPER specific elements [46].
A combination of Gazebo and ROS 2 is used to train the
D. Space: NASA VIPER
rover’s operators. ROS 2 is used to inject faults into the rover;
NASA’s Volatiles Investigating Polar Exploration Rover using VERVE, the operators need to determine how to clear
(VIPER) mission is scheduled to be launched to the southern the faults to get the rover moving.
polar region of the Moon in November 2023. The VIPER 2) Creating a Legacy: NASA has utilized many differ-
rover will use a variety of instruments to search for water ent communication mechanisms but in recent years, many
ice and other resources during a 100-day mission. Earth projects have chosen DDS because of its ability to traverse
compute resources will be used to map, register terrain, and satellite links that may have high latency, low bandwidth,
compute stereo solutions to aid in operations through its X- and low reliability. The VIPER team evaluated the options
band link to the Deep Space Network. Many of the Earth- and selected DDS as well for the Earth-based operations.
based operation tools, compute modules, and high-fidelity Besides a communications mechanism, the VIPER team
simulations are based on ROS 2 and Gazebo, as shown in was eager to use ROS 2 for its rapid development capa-
Figure 5. bilities, introspection and visualization tools, and openly
NASA’s Core Flight system provides hardware interfaces, available source. These characteristics shorten the learning
basic error checking, and payload services [44]. A satellite curve for new engineers to apply what they know onto flight
link carries commands to and telemetry from the rover. Earth- missions.
bound telemetry is received and sent to a ROS 2 network and However, using new software in a flight mission requires a
processed by an ensemble of nodes. The nodes transform rigorous Verification and Validation (V&V) process. NASA
the image data into pointclouds, compute visual odometry prefers to use components that has been vetted in previous
and terrain registration, and fuses the data to provide pose missions; leveraging heritage software leads to reduced de-
corrections. That data is fed into NASA’s Visual Environment velopment times and costs [47]. VIPER is reusing 84% of the
for Remote Virtual Exploration (VERVE), which allows 588,000 lines of code from the Resource Prospector along
operators to visualize the rover’s environment [45]. The with Gazebo and approximately 312 open-source ROS 2
operators use the result to simulate a move, and then finally packages [46]. ROS 2 has not been used in prior missions,
execute the move on the rover. but the VIPER team decided that the features that it provides
1) Mission Testing in Simulation: Since VIPER is a was worth the extra administrative overhead of going through
spaceflight mission, the team is focused on producing highly the process.
reliably software. To achieve this, they are extensively utiliz-
After ROS 2 has been validated and used in ground
ing Gazebo to provide high-fidelity testing of all their com-
operations for the VIPER mission, it becomes much easier
ponents and systems. Mark Allen said “having a simulator
for ROS 2 to be used in future missions in multiple roles and
[Gazebo] is essential for the development of all the VIPER
allow for more reuse of robotic software between mission
software in some capacity.”
programs.
The VIPER team turned to Gazebo to aid in development
since it was infeasible to model an accurately functioning lu-
E. Large Scale: OTTO Motors
nar rover on Earth. They emphasized “the Lunar environment
is so unique, with lighting and gravity, testing in simulation OTTO Motors is an Ontario-based Clearpath Robotics
[is] incredibly important since its impossible to test on spinoff company selling land and sea research platforms.
the ground on Earth effectively.” The project was able to OTTO produces warehouse and factory material handling
create a simulation utilizing custom plugins to Gazebo’s user services using autonomous robots to replace manually con-
interfaces. It is designed for a high degree of customization trolled equipment at scale - Figure 4c. They have deployed
to support a broad range of robotics needs - even space. thousands of robots worldwide and operate fleets of over
 (a) (b)
Fig. 5: (a) VIPER on Lunar Surface (rendering), (b) Command and Operations Software.

100 in a single facility. Customers such as Toyota and Gen- 2) Acceleration of Development: OTTO Motors’ develop-
eral Electric have adopted OTTO. This case study provides ment and deployment have been sped up in two additional
unique insight into large scale robot applications. ROS 2 has areas. First, it has accelerated their internal feature devel-
coordinated more than 2 million hours of operation and 1.5 opment process. The distributed architecture and isolation of
million kilometers traveled since it was deployed on OTTO’s processes have allowed a large, physically distributed team to
robots. collaborate. Using clearly defined ROS 2 interfaces allowed
1) Scaling Multi-Robot Technology: OTTO Motors orig- OTTO to separate major classes of tasks. Ryan Gariepy
inally developed their technology on ROS 1. Using it, they stated in an interview, “at the scale of robots we’re building
were unable to test more than 25 robots on the same shared and the complexity that is modern manufacturing, you really
ROS 1 network using a custom multi-master system with need the flexibility to patch in and out capabilities and share
their fleet management software. This was sufficient for small across a large team.” Their product software is spread across
fleets, but as OTTO grew into larger facilities, this became many repositories owned by different teams in a diverse set
a bottleneck. of languages, combined at run-time via ROS 2.
OTTO conducted a survey of available technologies and Next, providing ROS 2 support has proven valuable to
independently came to the same conclusion that the best their customers and clients. OTTO and Clearpath sell their
technology for the multi-robot fleet communications was platforms to other businesses to build on top of for custom
DDS. The greater network effect worked in their favor to products. A company recently bought platforms from OTTO
continue in the ROS ecosystem, thus they were one of the to create UV sanitizing robots in response to the COVID-19
early adopters of ROS 2. This allowed them to take advantage pandemic. Since they have both clearly defined and standard
of the capabilities enabled in ROS, while not independently APIs, these external collaborators easily leveraged the robot
maintaining a proprietary DDS framework. platform and tied it into their autonomy systems. Ryan
Gariepy summarized it as follows, “With the ROS APIs we
After migrating to ROS 2, OTTO was able to scale up to
provide, our external partners are now able to build apps
100+ robots in customer facilities. Larger multi-robot scale
on top of our autonomy capabilities without requiring us
was enabled because ROS 2 has fine-grained and scalable
to train them in robotics concepts or proprietary libraries.”
network topology management as well as better support for
This ability to separate concerns and abstract vendor specific
managing bandwidth through QoS on shared network links.
hardware, even an entire robot platform, allows companies
These deployments in 2017 represented some of the first
to rapidly build a new product to ensure public safety.
commercial deployments of ROS 2 anywhere in the world.
ROS 2 demonstrably accelerated their time to market by F. Discussion
quickly enabling them to scale to unprecedented numbers These five case studies illustrate an extensive range of ap-
of robots. OTTO Motors estimates they have saved between plications, environments, and rationales for the use of ROS 2.
$1M to $5M over 5 years by using ROS 2. In addition they These were selected to provide a unique cross-section of
saved hundreds of engineering hours by not rewriting these modern, applied robotics systems deployed in every domain.
tools into a proprietary framework. However different they are in their applications, there exists
OTTO Motor’s CTO Ryan Gariepy considers the ROS several common threads they share.
ecosystem to be necessary to the business, “Had ROS writ ROS 2 enables many to better reuse software components
large not existed, the whole business might not have been in their systems. Mission Robotics leverages the ROS com-
feasible. It would have been too expensive.” He estimates that munity’s device drivers and integrations such that their cus-
their continuing engineering costs would be 5–10% higher tomers can quickly adapt to a particular use-case in marine
annually without it. robotics. Likewise, Auterion uses not only lower level drivers
but also the higher level algorithms from the community. The Auterion, Mark Allen and Terry Fong from NASA Ames,
VIPER team uses ROS 2 to facilitate software reuse within and Ryan Gariepy from OTTO Motors. We would also like
the agency. During our interviews, they expressed that it was to thank the team at Open Robotics, members of the ROS 2
challenging to get other NASA groups to reuse code and that Technical Steering Committee, and the community for their
the ROS ecosystem has internal name recognition making it passionate support.
easier to encourage such collaborations. R EFERENCES
Another common thread was enabling collaborations, both
[1] Morgan Quigley, Brian Gerkey, Ken Conley, Josh Faust, Tully Foote,
internally and externally. Ghost Robotics and OTTO Motors Jeremy Leibs, Eric Berger, Rob Wheeler, and Andrew Ng. ROS:
use interfaces and composition nodes to separate parts of a an open-source Robot Operating System. In IEEE International
complex system so teams can collaborate without needing Conference on Robotics and Automation Workshop on Open Source
Software, 2009.
to concern themselves with the details of other parts of the [2] Sachin Chitta, Eitan Marder-Eppstein, Wim Meeussen, Vijay Pradeep,
system. Both Mission and Auterion are able to build custom Adolfo Rodrı́guez Tsouroukdissian, Jonathan Bohren, David Coleman,
solutions collaboratively with their customers by utilizing Bence Magyar, Gennaro Raiola, Mathias Lüdtke, and Enrique Fernan-
dez Perdomo. ros control: A generic and simple control framework
ROS 2. for ROS. Journal of Open Source Software, 2(20):456, 2017.
Finally, ROS 2 has allowed businesses to accelerate others [3] Eitan Marder-Eppstein, Eric Berger, Tully Foote, Brian Gerkey, and
via the sale of trusted platforms. All of the companies Kurt Konolige. The Office Marathon: Robust navigation in an indoor
office environment. In IEEE International Conference on Robotics
surveyed sell their platforms to other businesses to build and Automation, pages 300–307, 2010.
products on top of. The proliferation of ROS expertise in [4] David Coleman, Ioan Sucan, Sachin Chitta, and Nikolaus Correll.
the industry, matched with its freely available licensing, has Reducing the Barrier to Entry of Complex Robotic Software: a MoveIt!
Case Study. Journal of Software Engineering for Robotics, 5(1):3–16,
made it the major robotics SDK. By employing ROS 2 and 2014.
its conventions, they are able to sell platforms that can be [5] Brian Cairl (Fetch Robotics Inc.). Deterministic, asynchronous mes-
put to work in bespoke applications quickly. sage driven task execution with ros. In ROSCon Madrid 2018. Open
Robotics, September 2018.
It should be noted that these themes, software reuse; [6] Steve Macenski, Francisco Martı́n, Ruffin White, and Jonatan
collaborations; trusted platforms, are highly correlated with Ginés Clavero. The Marathon 2: A Navigation System. In IEEE/RSJ
the design principles laid out in Section III-B.1. In particular, International Conference on Intelligent Robots and Systems, 2020.
[7] G. Pardo-Castellote. OMG Data-Distribution Service: architectural
they are in line with the design principles of Distribution, overview. In International Conference on Distributed Computing
Abstraction, and Modularity. The adherence to those design Systems Workshops, pages 200–206, 2003.
principles have directly resulted in the emergent themes in [8] William Woodall. ROS on DDS. https://design.ros2.org/
articles/ros_on_dds.html, accessed February 11, 2022.
our studies, which represent some of the largest acceleration [9] Benjamin Kuipers, Edward A. Feigenbaum, Peter E. Hart, and Nils J.
factors for the robotics industry today. Nilsson. Shakey: From Conception to History. AI Magazine, pages
88–103, 2017.
V. C ONCLUSION [10] Richard E Fikes and Nils J Nilsson. Strips: A new approach to
the application of theorem proving to problem solving. Artificial
ROS 2 has been redesigned from the ground up to meet the intelligence, 2(3-4):189–208, 1971.
challenges of modern robotics. It was designed based off of [11] Rodney Brooks. A robust layered control system for a mobile robot.
IEEE journal on robotics and automation, 2(1):14–23, 1986.
a thoughtful set of principles, modern robotics requirements, [12] Erann Gat, R Peter Bonnasso, Robin Murphy, et al. On three-layer
and support for extensive customization. Largely based on architectures. Artificial intelligence and mobile robots, 195:210, 1998.
DDS, ROS 2 is a reliable and high quality robotics frame- [13] Reid G Simmons. Structured control for autonomous robots. IEEE
transactions on robotics and automation, 10(1):34–43, 1994.
work that can support a broad range of applications. This [14] Michael Montemerlo, Nicholas Roy, and Sebastian Thrun. Perspec-
framework continues to help accelerate the deployment of tives on standardization in mobile robot programming: The carnegie
robots out of the lab, into the wild, and is driving the next mellon navigation (carmen) toolkit. In Proceedings 2003 IEEE/RSJ
International Conference on Intelligent Robots and Systems (IROS
wave of the robotics revolution. 2003)(Cat. No. 03CH37453), volume 3, pages 2436–2441. IEEE,
We have shown through a series of case studies how it 2003.
is demonstrably accelerating companies and institutions into [15] C Mohan and R Dievendorff. Recent work on distributed commit
protocols, and recoverable messaging and queuing. Data Engineering,
useful deployment in many types of environments at a wide 17(1):1, 1994.
variety of scales. They display that ROS 2 is an enabler, [16] Jim Waldo. The jini architecture for network-centric computing.
an equalizer, and an accelerator. The standardization around Communications of the ACM, 42(7):76–82, 1999.
[17] OASIS. MQTT Version 5.0: OASIS Standard, 2019.
ROS 2 in a variety of industries is creating opportunities [18] Brian P. Gerkey, Richard T. Vaughan, Kasper Støy, Andrew Howard,
for new collaborations, faster development, and propelling Gaurav S. Sukhatme, and Maja J Matarić. Most Valuable Player: A
newly developed technologies forward. This trend will likely Robot Device Server for Distributed Control. In IEEE/RSJ Interna-
tional Conference on Intelligent Robots and Systems, 2001.
continue to manifest in the coming years as ROS 2 continues [19] Giorgio Metta, Paul Fitzpatrick, and Lorenzo Natale. YARP: Yet
to reach its peak maturity. Another Robot Platform. International Journal of Advanced Robotic
Systems, 3(1):43–48, 2006.
VI. ACKNOWLEDGMENTS [20] Albert S. Huang, Edwin Olson, and David C. Moore. LCM:
Lightweight Communications and Marshalling. In IEEE/RSJ Inter-
We would like to thank the companies representatives national Conference on Intelligent Robots and Systems, pages 4057–
interviewed in the case studies. This includes: Hunter Allen 4062, 2010.
[21] H. Bruyninckx, P. Soetens, and B. Koninckx. The real-time motion
and James Laney from Ghost Robotics, Charles Cross from control core of the Orocos project. In IEEE International Conference
Mission Robotics, Nuno Marques and Markus Achtelik from on Robotics and Automation, 2003.
[22] Apache Software Foundation. Apache License, Version 2.0. https: files/03-09_ivv_guidance_for_ivv_for_product_
//www.apache.org/licenses/LICENSE-2.0.html, line_software.pdf, accessed September 7, 2021.
accessed September 3, 2021.
[23] K. Birman and T. A. Joseph. Exploiting virtual synchrony in
distributed systems. In ACM Symposium on Operating Systems
Principles, pages 123–138, 1987.
[24] Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. Linux
device drivers. ”O’Reilly Media, Inc.”, 2005.
[25] Gero Mühl, Ludger Fiege, and Peter Pietzuch. Distributed event-based
systems. Springer Science & Business Media, 2006.
[26] M. D. McIlroy, E. N. Pinson, and B. A. Tague. Unix Time-Sharing
System: Foreword. The Bell System Technical Journal, 57(6):1899–
1904, 1978.
[27] Aravind Sundaresan and Leonard Gerard. Secure ros: Imposing secure
communication in a ros system. In ROSCon Vancouver 2017. Open
Robotics, September 2017.
[28] Kyle Fazzari. ROS 2 DDS-Security integration. https://design.
ros2.org/articles/ros2_dds_security.html, accessed
September 6, 2021.
[29] OMG. DDS Security. https://www.omg.org/spec/
DDS-SECURITY/1.0/PDF, accessed February 9, 2022.
[30] Ruffin White, Gianluca Caiazza, Henrik Christensen, and Agostino
Cortesi. Procedurally provisioned access control for robotic systems.
In IEEE/RSJ International Conference on Intelligent Robots and
Systems, 2018.
[31] Ingo Lütkebohle, Borja Outerelo Gamarra, Iñigo Muguruza Goenaga,
Jaime Martin Losa, and Vı́ctor Mayoral Vilches. micro-ROS: ROS 2
on microcontrollers. In ROSCon. Open Robotics, October 2019.
[32] Object Management Group. Data Distribution Service for Real-time
Systems Specification, December, 2004.
[33] Lennart Puck, P Keller, Tristan Schnell, Carsten Plasberg, Atanas
Tanev, Georg Heppner, Arne Rönnau, and Rüdiger Dillmann. Dis-
tributed and Synchronized Setup towards Real-Time Robotic Control
using ROS2 on Linux. In 2020 IEEE 16th International Conference
on Automation Science and Engineering (CASE), pages 1287–1293.
IEEE, 2020.
[34] Jan Staschulat, Ingo Lütkebohle, and Ralph Lange. The rclc Execu-
tor: Domain-specific deterministic scheduling mechanisms for ROS
applications on microcontrollers: work-in-progress. In International
Conference on Embedded Software, pages 18–19. IEEE, 2020.
[35] Mehul Sagar. ISO Certification of ROS 2. In Embedded World
Conference, March 2021.
[36] John Torjo. Asio C++ Network Programming: Enhance Your Skills
with Practical Examples for C++ Network Programming, 2013.
[37] Channy Yun. AWS IoT RoboRunner for Building Robot Fleet
Management Applications, accessed February 11, 2022.
[38] ROS 2 Design. http://design.ros2.org/, accessed August 5,
2021.
[39] ROS Enhancement Proposals. https://ros.org/reps/
rep-0000.html, accessed August 5, 2021.
[40] William Woodall. REP 2004: Package Quality Categories. https:
//ros.org/reps/rep-2004.html, accessed August 5, 2021.
[41] Eclipse Foundation. Cyclone DDS. https://cyclonedds.io/,
accessed September 3, 2021.
[42] Ian D. Miller, Fernando Cladera, Anthony Cowley, Shreyas S. Shiv-
akumar, Elijah S. Lee, Laura Jarin-Lipschitz, Akhilesh Bhat, Neil
Rodrigues, Alex Zhou, Avraham Cohen, Adarsh Kulkarni, James
Laney, Camillo Jose Taylor, and Vijay Kumar. Mine tunnel exploration
using multiple quadrupedal robots, 2020.
[43] Lorenz Meier, Dominik Honegger, and Marc Pollefeys. Px4: A
node-based multithreaded open source robotics framework for deeply
embedded platforms. In 2015 IEEE International Conference on
Robotics and Automation (ICRA), pages 6235–6240, 2015.
[44] David McComas. NASA/GSFC’s Flight Software Core Flight System.
In Flight Software Workshop, 2012.
[45] Susan Y Lee, David Lees, Tamar Cohen, Mark Allan, Matthew Deans,
Theodore Morse, Eric Park, and Trey Smith. Reusable science tools
for analog exploration missions: xgds web tools, verve, and gigapan
voyage. Acta Astronautica, 90(2):268–288, 2013.
[46] Sherry Stukes, Mark Allan, Matthew Deans Georgia Bajjalieh, Ter-
rence Fong, Jairus Hihn, and Hans Utz. An innovative approach to
modeling viper rover software life cycle cost. In 2021 IEEE Aerospace
Conference (50100). IEEE, 2021.
[47] Charley Price. Heritage Software Save up to 97% on future V&V
for real projects. https://www.nasa.gov/sites/default/