1. INTRODUCTION

近年来，诸如自动驾驶车辆的实时分布式嵌入式系统变得越来越复杂和多样化。 自2007年11月3日DARPA城市挑战赛以来，自主驾驶引起了人们的关注[34]。 机器人操作系统（ROS）[28]是开源中间件，经历了快速发展[11]，并已广泛用于机器人应用（例如自动驾驶系统）。 ROS几乎完全是从头开始构建的，自2007年以来一直由Willow Garage [7]和开源机器人基金会（OSRF）[2]维护.ROS提高了生产力[12]，提供发布/订阅传输，多个库（例如 ，OpenCV和Point Cloud Library（PCL）[3]），以及帮助软件开发人员创建机器人应用程序的工具。

Contribution:

在本文中，我们提供了DDS方法对ROS的概念证明。我们阐明了ROS1和ROS2在各种情况下的数据传输性能。性能意味着延迟特性，吞吐量和分布式功能。关注DDS功能，根据DDS供应商和配置，我们从各个方面探索和评估潜在和约束：延迟，吞吐量，线程数和内存消耗。从实验结果中，我们安排指南以及我们可以采取哪些措施来解决当前的约束问题。据我们所知，这是第一项探索ROS2性能的研究。

 但是，ROS不满足实时运行要求，只能在少数操作系统上运行。此外，ROS无法保证容错，期限或进程同步。此外，ROS需要大量资源（例如，CPU，内存，网络带宽，线程和核心），并且无法管理这些资源以满足时间限制。因此，ROS不适用于实时嵌入式系统。许多研究团体已经考虑过这个关键问题，包括ROS开发人员，并且已经提出并评估了各种解决方案[13]，[19]，[36]。但是，这些解决方案不足以解决ROS对实时嵌入式系统的限制。

 为了满足现在更广泛的ROS社区的需求，ROS将对ROS2进行重大升级[23]。 ROS2将考虑以下新用例：实时系统，小型嵌入式平台（例如传感器节点），非理想网络和跨平台（例如，Linux，Windows，Mac，实时操作系统（RTOS），否则OS）。为了满足这些新用例的要求，将重建现有版本的ROS（以下简称ROS1）以改进用户界面API并采用新技术，如数据分发服务（DDS）[24]，[30]，Zeroconf ，协议缓冲器，ZeroMQ，Redis和WebSockets.2 ROS1传输系统将被DDS取代，DDS是一种行业标准的实时通信系统和端到端中间件。 DDS可以提供​​类似于ROS1的可靠发布/订阅传输。

 DDS适用于实时嵌入式系统，因为它具有各种传输配置（例如，期限，可靠性和耐久性）和可扩展性。 DDS满足分布式系统的安全性，弹性，可扩展性，容错性和安全性要求。 DDS可以通过减少库大小和内存占用，为某些实时环境和一些小型/嵌入式系统提供解决方案。由不同的DDS供应商开发，该通信系统的若干实现已经用于任务关键环境（例如，火车，飞机，船舶，水坝和金融系统）并且已经由NASA和美国国防部验证。研究人员[37]，[32]和DDS供应商已对几种DDS实施进行了评估和验证。这些评估表明DDS既可靠又灵活。

Organization:

本文的其余部分安排如下。第2节提供了背景信息，并描述了ROS和DDS系统模型。第3节验证了实验情况，并评估了ROS1和ROS2在各种配置下的性能。第4节讨论相关工作。最后，第5节总结了论文，并为未来的工作提出了建议。

2. BACKGROUND

在本节中，我们提供背景知识。 首先，我们描述了与ROS1相比的ROS2系统模型，重点是其通信系统。 然后，我们回顾ROS的各个方面，例如发布/订阅模型。 最后，我们描述了DDS，它被用作ROS2中实时系统的通信系统。

2.1 Robot Operating System (ROS)

图1简要说明了ROS1和ROS2的系统模型。在图1的左侧，ROS1的实现包括通信系统TCPROS / UDPROS。由于ROS1的实现，此通信需要主进程（在分布式系统中是唯一的）。相反，如图1右侧所示，ROS2建立在DDS之上并包含DDS抽象层。由于此抽象层，用户无需了解DDS API。该层允许ROS2具有高级配置并优化DDS的利用率。此外，由于使用DDS，ROS2不需要主过程。这是容错方面的一个重要点。

 ROS应用程序由称为节点的独立计算过程组成，这些过程可促进故障隔离，更快的开发，模块化和代码可重用性。节点之间的通信基于发布/订阅模型。在此模型中，节点通过主题传递消息进行通信。消息具有由.msg文件定义的简单数据结构（很像C结构）。节点通过主题名称标识消息的内容。当节点向主题发布消息时，另一个节点订阅该主题并利用该消息。例如，如图2所示，“Camera”节点将消息发送到“Images”主题。主题中的消息由“汽车检测”节点和“行人检测”节点接收。发布/订阅模型设计为精细化的模块化，适用于分布式系统。

在ROS1中，上述通信系统使用TCP和UDP套接字实现为基于TCPROS和UDPROS的中间件。当启动订阅节点和发布节点时，它们与主节点交互，主节点收集信息并管理主题，类似于服务器。在与主节点进行XML /远程过程调用（RPC）事务之后，订阅节点使用商定的连接协议请求与发布节点的连接。实际数据（即消息）直接在节点之间传输。此数据不通过主数据路由。 ROS1实现节点之间的对等数据传输。

 可选地，ROS1提供节点，其提供有效的节点组合以用于优化的数据传输而无需TCPROS和UDPROS。 nodelet通过传递指针实现同一进程中节点之间的非序列化数据传输。 ROS2继承此选项作为进程内通信，它解决了nodelet的一些基本问题（例如，安全内存访问）。

 ROS2采用DDS作为其通信系统。但是，作为例外，在没有DDS的情况下执行进程内通信。 DDS由许多供应商提供，并具有多种实现类型。开发人员可以从各种DDS供应商中选择适当的DDS实施。

2.2 Data Distribution Service (DDS)

DDS规范[21]是由对象管理组（OMG）[1]为发布/订阅数据分发系统定义的。 OMG管理定义和标准化API;然而，OMG隐藏了实施的细节。不同供应商已经开发了几种实现方式（例如，RTI [29]和PRISMTECH [25]）。 DDS支持广泛的应用，从小型嵌入式系统到大型系统，如基础设施。请注意，还支持分布式实时嵌入式系统。

 DDS的核心是以数据为中心的发布 - 订阅（DCPS）模型，旨在即使在分布式异构平台中也能在进程之间提供高效的数据传输。 DCPS模型创建了一个可由任何独立应用程序访问的“全局数据空间”。 DCPS有助于高效的数据分发。在DDS中，发布或订阅数据的每个进程称为参与者，其对应于ROS中的节点。参与者可以使用类型化界面从/向全局数据空间读取和写入。

如图3所示，DCPS模型由DCPS实体构成：DomainParticipant，Publisher，Subscriber，DataWriter，DataReader和Topic。根据服务质量（QoS）策略执行进程之间的每个数据传输。

DomainParticipant: 用于跟踪其他实体和服务入口点的容器。在DDS中，所有应用程序在域内相互通信，从而促进隔离和通信优化。

Publisher: 发布是负责数据发布的对象。管理一个或多个DataWriters，发布将数据发送到一个或多个主题。

Subscriber: 订阅负责接收已发布的数据并使数据可用。订阅代表一个或多个DataReader行事。根据订阅，DomainParticipant可以接收和发送不同指定类型的数据。

DataWriter: DataWriter是DomainParticipant必须使用的对象，以通过Publisher发布数据。 DataWriter发布给定类型的数据。

DataReader: DataReader是附加到订阅服务器的对象。使用DataReader，DomainParticipant可以接收和访问其类型必须与DataWriter的类型相对应的数据。

Topic: 主题用于标识DataWriter和DataReader之间的每个数据对象。每个主题由名称和数据类型定义。

QoS Policy: 所有DCPS实体都有QoS策略，表示其数据传输行为。每个数据事务都可以通过许多QoS策略选项在不同的粒度级别进行配置。在图4中，我们显示了遵循QoS策略的DDS数据传输示例。目前为止，历史深度和通信可靠性由QoS策略配置。表1显示了ROS2支持的QoS策略的详细信息。在DDS中，还有许多其他QoS策略[21]，ROS2应该支持扩展其功能。

 在DCPS模型中，给定类型的数据从一个或多个DataWriters发布到主题（其名称在域中是唯一的）。一个或多个DataReader按主题名称标识数据对象，以便订阅该主题。在此事务之后，DataWriter使用分布式系统中的实时发布/订阅（RTPS）协议[20]连接到DataReader。 RTPS协议（DDS标准协议）允许来自多个供应商的DDS实现通过抽象和优化传输（例如TCP / UDP / IP）来互操作。 RTPS协议是灵活的，并且被定义为利用QoS策略。一些供应商使用UDP和共享内存传输进行通信。但是，在某些情况下，发现和数据交换可能需要TCP协议。

DataWriter和DataReader之间的数据传输根据QoS策略在RTPS协议中执行。每个DCPS实体根据唯一的用户指定的QoS策略管理数据样本。 DCPS中间件负责基于QoS策略的分布式系统中的数据传输。在不考虑详细的传输实现的情况下，DDS用户将代码生成为DomainParticipant，包括使用DDS API的QoS策略。因此，用户可以仅关注其目的并确定轻松满足实时约束的方法。

3. EVALUATIONS

本节阐明了ROS1和ROS2的功能和潜伏期特征。 目前，ROS2已作为alpha版本发布，其主要功能是C++客户端库，构建系统以及来自多个供应商的部分DDS中间件的抽象。 请注意，ROS2是一个非常粗略的草案，目前正在大力发展。 因此，该评估试图阐明ROS2当前可实现的能力和延迟特性。

 进行以下实验以评估发布/订阅消息传递的端到端延迟。延迟的测量是从单个节点上的调用发布函数开始到另一个节点接到数据进入回调函数为止，使用硬件和软件环境如表2所示。传输数据大小的范围是256 B到4 MB，因为大图像数据（例如， 2 MB）和点云数据（.pcd）经常用于ROS应用，例如自动驾驶系统[18]。字符串类型消息用于此评估。在下面的实验中，我们使用两个QoS设置，即可靠策略(reliable policy)和效果最优策略(best-effort)，如表3所示。在可靠策略中，TRANSIENT_LOCAL允许节点为延迟加入的订阅节点保留所有消息，RELIABLE便于可靠通讯。在best-effort策略中，节点不会保留消息并且也不会考虑通信是否可达。虽然每个节点以10 Hz执行，但实验重复最多4 MB。给出了每个数据大小的100次测量获得的箱线图和中位数。对于精确的评估方法，我们在[5]和[6]中开源代码。我们比较了三种DDS实现，即Connext [29]，OpenSplice [25]和FastRTPS [14]。 Connext和OpenSplice是众所周知的商业许可证DDS实现。请注意，Connext还拥有研究许可证。已经在LGPL许可下发布了OpenSplice和FastRTPS的几种实现。默认情况下，Connext使用UDPv4和共享内存来交换数据。请注意，OpenSplice3和FastRTPS不支持共享内存数据传输。对于精确的评估和实时要求，节点遵循SCHED FIFO [15]和mlockall系统调用。 SCHED FIFO进程优先于任何非SCHED FIFO进程，即使用默认Linux调度的进程。使用mlockall，进程的虚拟地址空间在物理RAM中得到修复，从而防止将内存分页到交换区域。

3.1 Experimental Situations and Methods

如图5所示，在以下实验中评估ROS1和/或ROS2中的节点之间的各种通信情况。而ROS1用于（1-a）、（1- b）和（1-c）中，ROS2用于（2-a）、（2-b）和（2-c）。在（3-a）和（3-b）中，ROS1和ROS2节点共存。注意，由于进程内通信，即共享存储器传输，（2-c）的情况不需要DDS。共享内存传输用于（1-c）nodelet和（2-c）进程内情况。在实验中，Machine1仅用于（1-b）、（1-c）、（2-b）、（2-c）和（3-b）。通过在节点之间发送消息，在同一台机器上测量端到端延迟。消息在本地情况下通过本地环回，即（1-b），（2-b）和（3-b）。否则，对于通过网络的通信，Machine1和Machine2用于远程情况，即（1-a）、（2-a）和（3-a）。它们通过本地IP网络连接，无需任何其他网络。

ROS1和ROS2节点之间的通信需要一个ros_bridge [33]，这是一个转换DDS主题的桥接节点。 ros_bridge计划已由开源机器人基金会（OSRF）发布[2]。 ros_bridge动态地为ROS2中的节点编组几个主题。因此，在（3-a）和（3-b）中，启动ros_bridge，ROS2节点在其上运行。图6显示了用于评估从ROS1到ROS2的通信的节点图。请注意，在使用ros_bridge时，唯一使用的是besteffort策略，因为ros_bridge不支持QoS策略中的RELIABLE策略。

3.2 Capabilities of ROS1 and ROS2

表4显示了是否可以测量每个数据大小的端到端延迟，并评论实验结果的因果因素。表4总结了ROS2的功能，并且可以进行一些有趣的观察。在“初始丢失”列中，ROS1无法在节点首次发送消息时获取初始消息，即使ROS1使用具有256 B等小数据的TCPROS并且在发布节点开始发送之前启动了订阅节点消息。虽然TCPROS对于传递中间消息是可靠的，但它不支持初始消息的可靠传输。当使用ros_bridge时，这会影响ROS2。相比之下，即使使用4 MB等大数据，ROS2也不会丢失初始消息。这证明了DDS的可靠性。在best-effort策略中，必须在发布节点开始发送没有“初始丢失”的消息之前启动订阅节点。另一方面，使用ROS2可靠策略，在发布节点开始发送消息之前不必启动订阅节点。这归因于QoS策略的耐久性中的TRANSIENT_LOCAL。可靠的策略被调整为为后期加入的订户节点提供弹性。在ROS1中，已发布的消息丢失并且从未恢复。此QoS策略可加速容错。

表4中另一个有趣的观察结果是ROS2在传输大数据时存在许多问题。在ROS2的各种情况下，许多实验都失败了;但是，我们可以观察到Connext和OpenSplice之间的性能差异。这些对大数据的约束源于Connext和OpenSplice的最大有效载荷为64 KB。这是IP协议的最大包大小。默认情况下，使用QoS策略维护分段数据包很困难。因此，我们认为DDS不是为处理大数据而设计的。这对于分析ROS2性能很重要。例如，FastRTPS不支持大数据，因为它被设计为嵌入式系统的轻量级实现。即使是256 B的字符串也超过了FastRTPS中的最大长度。许多DDS供应商不支持使用可靠的连接和通用API发布大数据。为了发送和管理分开的数据包，这些DDS供应商提供了一个备用API，例如异步发布者和流控制器，它们尚未从ROS2中抽象出来。在我们的实验中，当数据大于64 KB时，具有可靠策略的Connext会产生错误。尽力而为策略的一些失败是由于不可靠通信导致的频繁消息丢失。当发布节点不能将数据传输到订户节点时，我们无法收集足够的样本并进行评估。若干评估在（3-b）和远程通信中失败，如表4所示。目前，上述结果表明ROS2不适合处理大型消息。

3.3 Latency Characteristics of ROS1 and ROS2

如图7，图8，图9，图10所示，在图5所示的每种情况下，都清楚了端到端延迟特性的趋势。在（2-a）和（2-b）中，ROS2使用OpenSplice和 可靠的策略，因为ROS1使用TCPROS，即可靠的通信。 在（3-a）和（3-b）中，为了评估具有大数据（例如，512KB和1MB）的等待时间，使用具有尽力而为策略的Connext。 首先，我们分析ROS2与ROS1相比的性能。 然后，我们使用不同的DDS实现和配置（例如QoS策略）来评估ROS2。

3.3.1 Comparison between remote and local cases

ROS1和ROS2远远小于远程和本地通信之间的差异。图7和图8显示了远程和本地病例的延迟中位数。由于从ROS1到ROS2以及从ROS2到ROS1的转换影响是相似的，图7和8包含单向数据。在图7中，所有延迟的行为始终为4 KB。相反，远程情况下的延迟从16 KB急剧增长，如图7和图8所示。这是因为ROS1和ROS2将消息分成15 KB数据包以通过以太网传输数据。远程和本地情况之间的这种差异对应于Machine1和Machine2之间的数据传输时间，这是在初步实验中测量的。初步实验使用ftp或http测量每个数据大小的传输时间。该对应关系表明RTPS协议和QoS策略数据对网络中的数据传输时间影响很小。此外，通过测量数据传输时间可以预测所有延迟。

3.3.2 Comparison among local, nodelet, and intraprocess cases

 在小数据和大数据的情况下，延迟特性不同。为了便于讨论，我们将图分为图9和图10，它们显示了本地回环和共享内存传输的端到端延迟的中位数。这是因为消息是否被分成几个数据包是考虑端到端延迟的导入问题。

 对于小于64 KB的数据大小，会观察到ROS2的持续开销，如图9所示，因为DDS需要对QoS策略进行编组各种配置和决策。无论数据大小如何，我们都会在延迟和QoS策略之间进行权衡。尽管QoS策略产生了不可避免的开销，但延迟是可预测的并且很小。由于ros_bridge交易，（3-b）有很大的开销。在（3-b）情况下，ros_bridge导致与ROS1和ROS2通信的开销更大。

 对于大数据，ROS2具有显着的开销，具体取决于数据的大小，如图10所示。（2-b）中ROS2的开销归因于两个因素，即DDS的数据转换和处理DDS。注意，（2-a）和（2-b）中的ROS2必须两次转换ROS2和DDS之间的消息。一次转换是从ROS2到DDS，另一种转换是从DDS到ROS2。在这些转换之间，ROS2调用DDS API并将消息传递给DDS。图11和图12显示了（2-b）OpenSplice 在reliable策略和best-effort策略中端到端延迟的细分。我们观察到ROS2仅需要转换和处理DDS。如图11和12所示，“其他”几乎没有交易。此外，请注意，数据大小会影响转换和DDS处理。与ROS1相比，DDS开销不是恒定的，并且DDS的影响在大数据时是显着的。因此，ROS2在大数据时具有显着的开销，而DDS的影响取决于QoS策略。

 此外，在图10中观察到共享存储器与大数据的影响。随着数据变大，可以观察到显着的差异。但是，图9中的影响似乎很小，因为小数据隐藏了共享内存的影响。

 另一个有趣的观察是，尽管使用共享内存，但（2-c）进程内的延迟大于（1-b）中的延迟。此结果不是由于DDS的转换和DDS的处理，因为进程内通信不通过DDS路由。随着ROS2的开发，这些差距将被关闭。需要改进进程内通信。

3.3.3 Comparison within ROS2

数据小于16 KB的端到端延迟在（2-b）中表现出类似的性能。我们讨论16 KB到4 MB数据的性能。

 图13显示了（2-b）中不同DDS实现的比较。我们使用besteffort策略评估（2-b）中有和没有共享内存的OpenSplice和Connext。尽管共享内存，但性能并没有明显优于本地环回。这是由各种工具（例如，记录器和观察者）的编组引起的，即使在使用共享存储器传输时也是如此。此外，OpenSplice在延迟方面优于Connext，如图13所示，因为我们使用的是Connext DDS Professional，它具有比OpenSplice DDS社区版更丰富的功能。我们假设Vortex OpenSplice的性能与OpenSplice DDS社区版的性能类似。但是，Vortex OpenSplice需要商业许可证，ROS2不支持。

 此外，QoS策略对端到端延迟的影响在（2-b）OpenSplice中使用可靠的策略，reliable策略和* -depth策略进行评估。 * -depth策略为此评估做好准备，并按深度配置，如表5所示。图14显示了延迟的差异，具体取决于可靠的策略和尽力而为策略。 QoS策略的影响如图11和12所示。在该评估中，网络是理想的，即发布者节点很少重新发送消息。如果网络不理想，可靠政策的延迟会增加。 QoS策略中可靠性和耐用性的差异导致开销，代价是可靠的通信和对后加入订户的弹性。图15显示了根据* -depth策略的深度没有差异。这些QoS策略在节点数保存消息中是不同的。虽然此数字会影响资源，但这不会影响延迟，因为存档邮件是在每个发布中进行的。

最后，通过将片段大小更改为64 KB的最大UDP数据报大小，使用OpenSplice在（2-b）中测量片段开销。 Connext和OpenSplice的最大有效负载源自此UDP数据报大小，因为将大数据划分为多个数据报会对QoS策略的许多实现产生重大影响。 如图16所示，随着片段数据大小的增加，端到端的延迟会降低。 对于大的片段大小，DDS不需要将大数据分成许多数据报，这意味着更少的系统调用和更少的开销。 就端到端延迟而言，我们应该在使用大数据时将片段大小预设为64 KB。

3.4 Throughput of ROS1 and ROS2

我们还测量了远程情况下ROS1和ROS2的每个吞吐量。在我们的单向消息传输实验中，网络的最大带宽为12.5 MB /秒，因为我们使用100 Mbps以太网（100BASE-TX）和全双工，如表2所示。发布者节点以10Hz重复传输每条消息。

 在从256 B到2 KB的小数据中，我们可以观察到具有OpenSplice的ROS1，ROS2和来自图20的具有Connext的ROS2之间的恒定间隙。这些附加数据对应于用于QoS策略和心跳的RTPS分组。因此，这些差距不依赖于数据大小。此外，Connext吞吐量低于OpenSplice。当用户处理具有高Hz和/或网络带宽的多种小数据时，这将产生巨大影响。

在2 KB至4 MB的大数据中，图21的曲线显示了可持续的理论吞吐量。 ROS1和ROS2能够利用所有可用带宽，并且在这种情况下表现相似。吞吐量受网络限制，而不受DDS限制。

3.5 Thread of ROS1 and ROS2

在本节中，我们测量每个节点上的线程数。 表6显示了测量结果。 请注意，表6中描述的数字取决于包括QoS策略在内的DDS配置。 供应商不会修复该号码。

 首先，我们可以观察到Open-Splice的ROS2节点有很多线程。 这可能导致并行处理以及OpenSplice比Connext快得多的事实，如图13所示。

 另一个有趣的点是FastRTPS线程。 具有FastRTPS的ROS2节点实现了发现和序列化，以及具有相同数量的ROS1节点线程的发布/订阅数据传输。 此结果证明在没有额外资源的情况下提高了容错能力，因为FastRTPS不需要主节点。

3.6 Memory consumption of ROS1 and ROS2

我们还测量ROS1和ROS2中共享库对象（.so）的内存大小。 共享库是节点在启动时动态加载的库。 它们不与可执行文件链接，但它们将是估计内存大小的重要指南。 我们将结果安排在表7中。在此表中，我们将pub / sub传输的库数据大小相加。 在ROS2中，共享库分为DDS库和ROS2抽象库。 虽然DDS库由每个供应商提供，但ROS2库抽象DDS API并转换DDS的消息。 在表7中，DDS和ROS2库因供应商而异。 由于其QoS功能和抽象，这些库数据大小趋于增加。 对于小型嵌入式系统，我们需要一个最小的DDS实现和轻量级抽象层。

3.7 Lessons Learned

 到目前为止，我们已经从几个角度阐明了通过ROS2实现DDS的特性：ROS2功能，延迟，吞吐量，线程数和内存消耗。我们可以从实验结果中通过ROS2获得DDS的见解和指导。它们对DDS和ROS用户有意义。

DDS支持QoS策略，但在端到端延迟和吞吐量之间存在权衡。在本地案例中，ROS2的开销延迟并非微不足道。从3.3节开始，延迟是由DDS和DDS事务的两次数据转换引起的。 DDS端到端延迟是恒定的，直到消息数据大小低于最大数据包大小（64 KB），如图9所示。另一方面，当一条大消息被分成几个数据包时，延迟会急剧增加，因为显示在图10和图18中，消息数据大小是否超过64 KB是一个重要问题，尤其是在DDS中，因为管理具有QoS策略的分割数据包需要大量处理时间和某些供应商提供的备用API。我们应该了解分组数据包的影响，并在使用DDS时牢记这个问题。虽然DDS和ROS2抽象具有开销延迟，但OpenSplice比Connext更快地利用了许多线程和进程，如图13所示。这就是为什么我们当前应该在本地情况下在DDS的底层实现中使用OpenSplice的原因。在远程情况下，虽然开销延迟是微不足道的，但我们必须考虑带宽的吞吐量。如图20所示，就吞吐量而言，Connext优于OpenSplice。无论消息数据量有多小，这种恒定的开销吞吐量都是可预测的并且存在。特别是当高Hz使用多种主题时。我们建议Connext考虑远程情况下的最低必要吞吐量。

 DDS为ROS2带来了实时嵌入式系统的支持。我们认为ROS2超过了使用DDS的成本。 DDS的容错性优越，因为它能够使用QoS策略保存过去的数据，并且不需要主节点。 DDS保证了公平的延迟，如图18和19所示。此外，DDS能够在多个平台上运行，包括RTOS和交换机DDS实现。在RTPS协议下，任何ROS2节点都相互通信而与其平台无关。 FastRTPS目前是线程和内存中嵌入式系统的最佳DDS实现，如表6所示，但它不适用于小型嵌入式系统。

 由于ROS2正在开发中，我们已经明确了改进ROS2性能的空间，并且DDS的能力为ROS2带来了实时嵌入式系统的支持。我们认为ROS2超过了使用DDS的成本。 DDS的容错性优越，因为它能够使用QoS策略保存过去的数据，并且不需要主节点。 DDS保证了公平的延迟，如图18和19所示。此外，DDS能够在多个平台上运行，包括RTOS和交换机DDS实现。在RTPS协议下，任何ROS2节点都相互通信而与其平台无关。 FastRTPS目前是线程和内存中嵌入式系统的最佳DDS实现，如表6所示，但它不适用于小型嵌入式系统。由于ROS2正在开发中，我们已经澄清了改善ROS2性能和最大化DDS潜力的能力的空间。首先，ROS2支持的当前QoS策略提供容错，但它们不足以进行实时处理。 ROS2必须扩展支持的QoS策略的范围。其次，对于小型嵌入式系统，ROS2需要最小的DDS实现和最小的抽象层。例如，我们需要用于ROS2的C API库和一个小型DDS实现。由于其抽象层，ROS2很容易支持它们。 FreeRTPS [22] [27]是这个问题的一个很好的候选者，但它正在开发中。第三，我们还阐明了对大型消息管理分割数据包的替代API的需求。这对于处理大型消息至关重要。抽象将缩短DDS端到端延迟并实现表4的不足。最后，我们必须调整ROS2的DDS配置，因为有许多供应商特定的配置选项。