
ďƐƚƌĂĐƚ^>ĂLJĞƌ
^
>ŝŶƵdžtŝŶĚŽǁƐDĂĐZdK^
ůŝĞŶƚ>ŝďƌĂƌLJ
>ŝŶƵdž
ůŝĞŶƚ>ŝďƌĂƌLJ
dWZK^hWZK^
ƉƉůŝĐĂƚŝŽŶ
EŽĚĞ
EŽĚĞ
EŽĚĞ
DĂƐƚĞƌ
ƉƉůŝĐĂƚŝŽŶ
EŽĚĞ EŽĚĞ
$SSOLFDWLRQ
/D\HU
0LGGOHZDUH
/D\HU
26
/D\HU
ZK^ϭ
EŽĚĞůĞƚ
W/
/ŶƚƌĂͲƉƌŽĐĞƐƐ
W/
ZK^Ϯ
Figure 1: ROS1/ROS2 architecture.
for DDS approach to ROS. We clarify the performance of the
data transport for ROS1 and ROS2 in various situations.
Performance means latency characteristics, throughput and
distributed capability. Focusing on the DDS capabilities, de-
pending on DDS vendors and configurations, we explore and
evaluate the potential and constraints from various aspects:
latencies, throughput, the number of threads, and memory
consumption. From experimental results, we arrange guide-
lines and what we can do to solve current constrains. To
the best of our knowledge, this is the first study to explore
ROS2 performance.
Organization: The remainder of this paper is organized
as follows. Section 2 provides background information and
describes the ROS and DDS system models. Section 3 vali-
dates experimental situations and evaluates the performance
of ROS1 and ROS2 with various configurations. Section 4
discusses related work. Finally, Section 5 concludes the pa-
per and offers suggestions for future work.
2. BACKGROUND
In this section, we provide background knowledge. First,
we describe the ROS2 system model compared to ROS1,
focusing on its communication system. We then review as-
pects of the ROS, such as the publish/subscribe model. Fi-
nally, we describe DDS, which is used as the communication
system for real-time systems in ROS2.
2.1 Robot Operating System (ROS)
Figure 1 briefly illustrates the system models of ROS1 and
ROS2. In the left side of Figure 1, ROS1’s implementation
includes the communication system, TCPROS/UDPROS.
This communication requires a master process (unique in
the distributed system) because of the implementation of
ROS1. In contrast, as shown in the right side of Figure
1, ROS2 builds upon DDS and contains a DDS abstraction
layer. Users do not need to be aware of the DDS APIs due to
this abstraction layer. This layer allows ROS2 to have high-
level configurations and optimizes the utilization of DDS. In
addition, due to use of DDS, ROS2 does not need a master
process. This is a import point in terms of fault tolerance.
ROS applications consist of independent computing pro-
cesses called nodes, which promote fault isolation, faster de-
velopment, modularity, and code reusability. Communica-
tion among nodes is based on a publish/subscribe model.
In this model, nodes communicate by passing messages via
a topic.Amessage has a simple data structure (much like
C structs) defined by .msg files. Nodes identify the content
of the message by the topic name. As a node publishes a
message to a topic,anothernode subscribes to the topic
and utilizes the message. For example, as shown in Fig-
ure 2, the “Camera” node sends messages to the “Images”
QRGH
QRGH
QRGH
6XEVFULEH
3XEOLVK
6XEVFULEH
WRSLF
&DU'HWHFWLRQ
3HGHVWULDQ
'HWHFWLRQ
&DPHUD
,PDJHV
Figure 2: Example of ROS publish/subscribe model.
topic.Themessages in the topic are received by the “Car
Detection” node and “Pedestrian Detection” node. The pub-
lish/subscribe model is designed to be modular at a fine-
grained scale and is suitable for distributed systems.
In ROS1, the above communication system is implemented
as middleware based on TCPROS and UDPROS using TCP
and UDP sockets. When subscriber-nodes and publisher-
nodes are launched, they interact with a master-node that
collects information and manages topics, similar to a server.
After an XML/Remote Procedure Call (RPC) transaction
with the master-node, subscriber-nodes request a connection
to publisher-nodes, using an agreed upon connection proto-
col. Actual data (i.e., a message) is transported directly
between nodes. This data does not route through the mas-
ter. ROS1 realizes a peer-to-peer data transport between
nodes.
Optionally, ROS1 provides nodelets, which provide effi-
cient node composition for optimized data transport without
TCPROS and UDPROS. A nodelet realizes non-serialized
data transport between nodes in the same process by pass-
ing a pointer. ROS2 inherits this option as intra-process
communication, which addresses some of the fundamental
problems with nodelets (e.g., safe memory access).
ROS2 adopts DDS as its communication system. How-
ever, as an exception, intra-process communication is exe-
cuted without DDS. DDS is provided by many vendors and
has several implementation types. Developers can select an
appropriate DDS implementation from a variety of DDS ven-
dors.
2.2 Data Distribution Service (DDS)
The DDS specification [21] is defined for a publish/subscribe
data-distribution system by the Object Management Group
(OMG) [1]. The OMG manages the definitions and stan-
dardized APIs; however the OMG hides the details of im-
plementation. Several implementations have been developed
by different vendors (e.g., RTI [29] and PRISMTECH [25]).
DDS supports a wide range of applications, from small em-
bedded systems to large scale systems, such as infrastruc-
tures. Note that distributed real-time embedded systems
are also supported.
The core of DDS is a Data-Centric Publish-Subscribe (DCPS)
model designed to provide efficient data transport between
processes even in distributed heterogeneous platforms. The
DCPS model creates a “global data space” that can be ac-
cessed by any independent applications. DCPS facilitates
efficient data distribution. In DDS, each process that pub-
lishes or subscribes to data is called a participant, which cor-
responds to a node in the ROS. Participants canreadand
write from/to the global data space using a typed interface.
As shown in Figure 3, the DCPS model is constructed of
DCPS Entities: DomainParticipant, Publisher, Subscriber,