ROS2为什么要用DDS作为通信中间件?

各位小伙伴大家好，我是小鱼，今天翻译一篇文章《在ROS上使用DDS》，带你了解为什么ROS2要选择DDS作为中间件。

概述

本文阐述了使用 DDS 作为 ROS 的中间件的案例，概述了这种方法的优缺点，并考虑了使用 DDS 对用户体验和代码 API 的影响。对 “ros_dds” 原型的结果也进行了总结，用于探索相关问题。

为什么要考虑 DDS

在探索 ROS 下一代通信系统的选项时，最初的选项是改进 ROS 1 传输或使用 ZeroMQ、Protocol Buffers 和 zeroconf (Bonjour/Avahi) 等组件库构建新的中间件。

但是，除了这些选项（这两个选项都涉及我们从部分或从头开始构建中间件）之外，还考虑了其他端到端（end-to-end）中间件。

在我们的研究中发现一个引人注目的中间件——DDS。

端到端中间件

使用端到端中间件（如 DDS）的好处是需要维护的代码要少得多，并且中间件的行为和确切规范已经被提炼到文档中。

除了系统级文档之外，DDS 还提供了推荐的用例和软件API。有了这个具体的规范，第三方可以审查、审计和实施具有不同程度互操作性的中间件。这是 ROS 从未有过的，除了 wiki 中的一些基本描述和参考实现。此外，如果要从现有库构建新的中间件，无论如何都需要创建这种类型的规范。

使用端到端中间件的缺点是 ROS 必须在已有的设计中工作。如果设计没有针对相关用例或不灵活，则可能需要围绕设计工作。在某种程度上，采用端到端中间件包括采用该中间件的理念和文化，没那么简单。

什么是DDS

DDS 提供了一个发布-订阅传输，它与 ROS 的发布-订阅传输非常相似。DDS 使用 Object Management Group (OMG) 定义的“接口描述语言 (IDL)”进行消息定义和序列化。DDS 有一个请求-响应式传输，类似于 ROS 的服务系统，在 2016年6月的 beta 2 中（称为 DDS-RPC） .

DDS提供的默认发现系统，需要使用DDS的发布-订阅传输，是一个分布式发现系统。这允许任何两个 DDS 程序进行通信，而无需像 ROS Master这样的工具。这使得系统更具容错性和灵活性。
但是，不需要使用动态发现机制，因为多个 DDS 供应商提供静态发现选项。

DDS从何而来

DDS 最初是一群拥有相似中间件框架的公司，并在普通客户希望在供应商之间获得更友好的切换时成为标准。DDS 标准是由 Object Management Group 创建的，他们是为我们带来 UML、CORBA、SysML 和其他通用软件相关标准的人。

在你看来，这可能是正面或负面的认可。一方面，您有一个常年存在的标准委员会，显然对软件工程社区有巨大的影响，但另一方面，您有一个行动缓慢的机构，它适应变化的速度很慢，因此可以说并不总是保持不变紧跟软件工程的最新趋势。

DDS 最初是几个类似的中间件，最终它们变得非常接近，以至于编写一个标准来统一它们变得哟意义。因此，通过这种方式，即使 DDS 规范是由一个委员会编写的，它也已通过响应用户的需求而演变为当前形式。这种规范在被批准之前的有机演变有助于减轻人们对系统是在真空中设计的，并且在实际环境中表现不佳的担忧。

有一些委员会提出了善意且描述良好的规范，但没有人愿意使用或不满足他们所服务的社区的需求，但 DDS 似乎并非如此。

还有一个问题是 DDS 是一个静态规范，它被定义并用于“遗留”系统，但没有保持最新。
这种刻板印象来自关于UML和CORBA之类的恐怖故事，它们也是OMG的产品。
】相反，DDS 似乎有一个积极和有机的规范，在最近的过去已经添加或正在添加更多规范，例如 websockets、SSL安全性、可扩展类型、请求和响应传输，以及一个新的、更多的规范。现代 C++11 风格的 API 规范，用于核心 API 以替换现有的 C++ 接口。

DDS 标准体的这种演变是令人鼓舞的事情，尽管标准体相对缓慢，但与软件工程技术趋势相比，它正在演变以满足其用户的需求。

技术信誉

DDS 有一个广泛的各种安装列表，这些安装通常是关键任务。
DDS 已用于：

战列舰
大坝等大型公用设施
金融系统
空间系统
飞行系统
火车总机系统

以及许多其他同样重要和多样的场景。这些成功的用例使 DDS 的设计既可靠又灵活。

DDS 不仅满足了这些用例的需求，而且在与 DDS 的用户（在本例中也是 ROS 用户的政府和 NASA 员工）交谈后，他们都称赞它的可靠性和灵活性。这些用户会注意到 DDS 的灵活性是以复杂性为代价的。API 的复杂性和 DDS 的配置是 ROS 需要解决的问题。

DDS总线规范 (DDSI-RTPS) 非常灵活，可用于可靠的高级系统集成以及实际嵌入式设备上的时间应用程序。一些 DDS 供应商为嵌入式系统提供了特殊的 DDS 实现，这些系统拥有与库大小和内存占用相关的规范，规模为数十或数百KB。

由于 DDS 在默认情况下是在UDP上实现的，因此它不依赖于可靠的传输或硬件进行通信。这意味着 DDS 必须重新发明可靠性轮子（基本上是 TCP 加上或减去一些特性），但作为交换，DDS 获得了可移植性和对行为的控制。

用于控制可靠性参数，DDS称为服务质量 (QoS)，在控制通信行为方面提供了最大的灵活性。
例如，如果您担心延迟，例如软实时，您基本上可以将 DDS 调整为只是一个UDP 报文。
在另一种情况下，您可能需要行为类似于 TCP 的东西，但需要更能容忍长时间的丢失，并且使用 DDS，所有这些东西都可以通过更改 QoS 参数来控制。

尽管 DDS 的默认实现是通过 UDP 实现的，而且只需要传输的那种级别的功能，但 OMG 还在其规范的 1.2 版本中添加了对基于 TCP 的 DDS 的支持。
简单看一下，两家供应商（RTI和ADLINK科技）都支持基于 TCP 的 DDS。

来自 RTI 的网站 ([http://community.rti.com/kb/xml-qos-example-using-rti-connext-dds-tcp-transport](http://community.rti.com/kb/xml- qos-example-using-rti-connext-dds-tcp-transport)):

默认情况下，RTI Connext DDS 使用 UDPv4 和共享内存传输与其他 DDS 应用程序通信。
在某些情况下，发现和数据交换可能需要 TCP 协议。
有关 RTI TCP 传输的更多信息，请参阅 RTI 核心库和实用程序用户手册中标题为“RTI TCP 传输”的部分。

从ADLINK科技的网站上，他们从 OpenSplice v6.4 开始支持 TCP：
https://www.adlinktech.com/en/data-distribution-service.aspx

供应商和许可

OMG 与几家公司一起定义了 DDS 规范，这些公司现在是主要的 DDS 供应商。
流行的 DDS 供应商包括：

RTI
ADLINK科技
TwinOaks软件

截止小鱼翻译文章（202202）已经有更多的DDS供应商出现。

在这些供应商中，有一系列具有不同策略和许可的参考实现。

OMG 维护 DDS 供应商的活动列表。

除了提供 DDS 规范 API 实现的供应商外，还有一些软件供应商提供更直接访问 DDS 有线协议 RTPS 的实现。
例如：

eProsima

这些以 RTPS 为中心的实现也很有趣，因为它们的范围可以更小，并且仍然提供在顶部实现必要的 ROS 功能所需的功能。

RTI 的 Connext DDS 可在自定义“社区基础设施”许可证下使用，该许可证与 ROS 社区的需求兼容，但需要与社区进一步讨论以确定其作为 ROS 默认 DDS 供应商的可行性。

通过“与 ROS 社区的需求兼容”，我们的意思是，尽管它不是 OSI 批准的许可证，但研究表明它足够允许 ROS 保持BSD风格的许可证，并供 ROS 社区中的任何人以源代码或二进制形式重新分发它。

RTI 似乎也愿意就许可证进行谈判以满足 ROS 社区的需求，但 ROS 社区和 RTI 之间需要一些迭代才能确保这能够奏效。
与其他供应商一样，该许可证可用于核心功能集，基本上是基本的 DDS API，而其产品的其他部分（如开发和自省工具）是专有的。RTI 似乎拥有最大的在线业务和安装基础。

ADLINK科技的 DDS 实现 OpenSplice 在 LGPL 下获得许可，这与许多流行的开源库（如 glibc、ZeroMQ 和 Qt）使用的许可相同。它在 Github 上可用：

https://github.com/ADLINK-IST/opensplice

ADLINK科技的实现带有一个基本的、功能强大的构建系统，并且非常容易打包。OpenSplice 似乎是使用中的第二大 DDS 实现，但这很难确定。TwinOaks 的 CoreDX DDS 实现只是专有的，但显然他们专注于能够在嵌入式设备甚至裸机上运行的最小实现。

eProsima 的 FastRTPS 实现可在 GitHub 上获得，并获得 LGPL 许可：
https://github.com/eProsima/Fast-RTPS

eProsima Fast RTPS 是一个相对较新的、轻量级的、开源的 RTPS 实现。它允许直接访问 RTPS 协议设置和功能，这在其他 DDS 实现中并不总是可能的。eProsima 的实施还包括最低限度的 DDS API、IDL 支持和自动代码生成，并且他们愿意与 ROS 社区合作以满足他们的需求。

鉴于相对强大的 LGPL 选项和来自 RTI 的令人鼓舞但定制的许可证，似乎依赖甚至分发 DDS 作为依赖项应该是直截了当的。该提案的目标之一是使 ROS 2 DDS 供应商不可知。
因此，举个例子，如果默认实现是 Connext，但有人想使用 OpenSplice 或 FastRTPS 等 LGPL 选项之一，他们只需重新编译 ROS 源代码并改变一些参数，就可以使用他们的实现选择。

这之所以成为可能，是因为 DDS 在其规范中定义了一个 API。研究表明，编写与供应商无关的代码是可能的，即使不是有点痛苦，因为不同供应商的 API 几乎相同，但在返回类型（指针与 shared_ptr 之类的东西）和头文件组织等方面存在细微差别。

精神和社区

DDS 来自一组已有数十年历史的公司，由 OMG 布局，这是一个老派的软件工程组织，主要由政府和军事用户使用。因此毫不奇怪，DDS 社区看起来与 ROS 社区以及类似的现代软件项目（如 ZeroMQ）有很大不同。

尽管 RTI 有一个受人尊敬的在线形象，但社区成员提出的问题几乎总是由 RTI 的员工回答，尽管在技术上是开源的，但 RTI 和 OpenSplice 都没有花时间为 Ubuntu 或 Homebrew 或任何其他现代包提供包。他们没有广泛的用户贡献的 wiki 或活动的 Github 存储库。

社区之间精神上的这种明显差异是依赖 DDS 时最令人担忧的问题之一。与保留 TCPROS 或使用 ZeroMQ 之类的选项不同，DDS 没有大型社区可以依靠的感觉。然而，在我们的研究过程中，DDS 供应商对我们的询问非常积极，很难说当 ROS 社区提出问题时这种情况是否会继续。

尽管在决定使用 DDS 时应该考虑到这一点，但它不应该不成比例地超过 DDS 提案的技术利弊。

ROS 建立在 DDS 之上

目标是使 DDS 成为 ROS 2 的实现细节。这意味着需要隐藏所有 DDS 特定的 API 和消息定义。
DDS 提供发现、消息定义、消息序列化和发布-订阅传输。因此，DDS 将为 ROS 提供发现、发布-订阅传输以及至少底层消息序列化。

ROS 2 将在 DDS 之上提供类似 ROS 1 的接口，它为大多数 ROS 用户隐藏了 DDS 的大部分复杂性，但随后为有极端用例或需要集成的用户单独提供对底层 DDS 实现的访问其他现有的 DDS 系统。

DDS 和 ROS API 布局

访问 DDS 实现将需要取决于通常不使用的附加包。通过这种方式，您可以通过查看包依赖关系来判断一个包是否与特定的 DDS 供应商绑定。在 DDS 之上的 ROS API 的目标应该是满足 ROS 社区的所有共同需求，因为一旦用户接入底层 DDS 系统，他们将失去 DDS 供应商之间的可移植性。

DDS 供应商之间的可移植性并不是为了鼓励人们经常选择不同的供应商，而是为了让高级用户能够选择满足其特定要求的 DDS 实现，以及针对 DDS 供应商选项变化的面向未来的 ROS。

将有一个推荐和最受支持的默认 DDS 实现用于 ROS。

发现

DDS 将完全取代基于 ROS Master的发现系统。ROS 需要利用 DDS API 来获取所有节点列表、所有主题列表以及它们如何连接等信息。访问这些信息将隐藏在 ROS 定义的 API 后面，从而防止用户不得不直接调用 DDS。

DDS 发现系统的优势在于，默认情况下，它是完全分布式的，因此系统的各个部分之间不需要中心节点来相互通信。DDS 还允许在他们的发现系统中使用用户定义的元数据，这将使 ROS 能够将更高级别的概念搭载到发布-订阅中。

发布-订阅传输

DDSI-RTPS（DDS-互操作实时发布订阅）协议将取代 ROS 的 TCPROS 和 UDPROS 有线协议用于发布/订阅。

DDS API 为 ROS 1 的典型发布-订阅模式提供了更多参与者。在 ROS 中，节点的概念最明显地与 DDS 中的通信图中的参与者相似。

一个通信图的参与者可以有零到多个话题，这与 ROS 中话题的概念非常相似，但在 DDS 中表示为单独的代码对象，既不是订阅者也不是发布者。然后，从一个 DDS 话题，可以创建 DDS 订阅者和发布者，但它们同样用于表示 DDS 中的订阅者和发布者概念，而不是直接从主题读取数据或向主题写入数据。

除了主题、订阅者和发布者之外，DDS 还具有 DataReaders 和 DataWriters 的概念，它们由订阅者或发布者创建，然后专门用于特定的消息类型，然后再用于读取和写入主题的数据。这些额外的抽象层允许 DDS 进行高级配置，因为您可以在发布-订阅队列的每个级别进行 QoS 设置，从而提供尽可能高的配置粒度。

大多数这些抽象级别对于满足 ROS 的当前需求并不是必需的。因此，在更简单的类 ROS 接口（节点、发布者和订阅者）下打包常见工作将是 ROS 2 隐藏 DDS 复杂性同时暴露其一些功能的一种方式。

高效的传输方式

在 ROS 1 中，从来没有标准的共享内存传输，因为它比 localhost TCP 回环连接快得可以忽略不计。

通过在进程之间执行零拷贝形式的共享内存，可以获得非凡的性能改进，但是任何时候需要比 ROS 1 中的 localhost TCP 更快的任务，都会使用 nodelet。

Nodelet 允许发布者和订阅者通过将 boost::shared_ptr 传递给消息来共享数据。
这种进程内通信几乎肯定比任何进程间通信选项都要快，并且与网络发布-订阅实现的讨论是正交的。

在 DDS 的上下文中，大多数供应商将使用共享内存以透明的方式优化消息流量（甚至在进程之间），仅在离开本地主机时使用有线协议和 UDP 套接字。这为 DDS 提供了相当大的性能提升，而 ROS 1 则没有，因为 localhost 网络优化发生在调用 send 时。

对于 ROS 1，过程是：将消息序列化到一个大缓冲区中，在缓冲区上调用 TCP 的“send”一次。对于 DDS，该过程更像是：序列化消息，将消息分解成可能的多个 UDP 数据包，多次调用 UDP 的“发送”。以这种方式发送许多 UDP 数据报不会从与一个大型 TCP send 相同的速度中受益。
因此，许多 DDS 供应商会为 localhost 消息缩短此进程，并使用黑板式共享内存机制在进程之间进行有效通信。

但是，并非所有 DDS 供应商在这方面都是相同的，因此 ROS 不会依赖这种“智能”行为来进行有效的进程内通信。

此外，如果保留 ROS 消息格式（将在下一节中讨论），则无法阻止进程内话题转换为 DDS 消息类型。因此，需要为 ROS 开发一个自定义的进程内通信系统，它永远不会序列化或转换消息，而是使用 DDS 主题在发布者和订阅者之间传递指针（指向共享的进程内内存）。

例如，构建在 ZeroMQ 上的自定义中间件将需要这种相同的进程内通信机制。

这里要指出的一点是，无论中间件的网络/进程间实现如何，都将解决高效的 内部-intra 进程通信。

消息-Message

当前的 ROS 消息定义有很多价值。格式很简单，消息本身已经随着机器人社区多年的使用而发展。当前 ROS 代码的大部分语义内容是由这些消息的结构和内容驱动的，因此保留消息的格式和内存表示具有很大的价值。为了实现这个目标，并且为了使 DDS 成为一个实现细节，ROS 2 应该像消息定义和内存表示一样保留 ROS 1。

因此，将继续使用 ROS 1 .msg 文件，并将 .msg 文件转换为 .idl 文件，以便它们可以与 DDS 传输一起使用。将为 .msg 文件和 .idl 文件生成语言特定文件，以及用于在 ROS 和 DDS 内存实例之间进行转换的转换函数。

ROS 2 API 将专门用于内存中的“.msg”样式消息对象，并在发布之前将它们转换为“.idl”对象。

消息抓换

起初，将消息逐个字段转换为另一种对象类型以便每次调用发布的想法似乎是一个巨大的性能问题，但实验表明，与序列化成本相比，这种复制的成本是微不足道的。

转换类型的成本和序列化成本之间的比率至少是一个数量级，我们尝试过的每个序列化库都适用，除了 [Cap’n Proto](http://kentonv. github.io/capnproto/) 没有序列化步骤。因此，如果逐字段复制不适用于您的用例，则序列化和通过网络传输也不会，此时您将不得不利用进程内或零复制进程间通信。

ROS 中的进程内通信不会使用 DDS 内存表示，因此除非数据传输到网络，否则不会使用这种逐字段复制。由于此转换仅与更昂贵的序列化步骤一起调用，因此逐字段复制似乎是通过保留 ROS .msg 文件和内存表示所提供的可移植性和抽象性的合理权衡.

这并不排除使用默认值和可选字段等改进“.msg”文件格式的选项。但这是一个不同的权衡，可以稍后决定。

服务和Action

DDS 目前没有批准或实施的请求-响应式 RPC 标准，可用于实现 ROS 中的服务概念。目前 OMG DDS 工作组正在考虑批准一个 RPC 规范，并且一些 DDS 供应商拥有 RPC API 的实现草案。

然而，目前尚不清楚该标准是否适用于行动，但它至少可以支持不可抢占的 ROS 服务版本。ROS 2 可以在发布-订阅之上实现服务和操作（这在 DDS 中更可行，因为它们可靠的发布-订阅 QoS 设置）或者它可以在服务完成后使用 DDS RPC 规范，然后在其上构建操作顶部，就像在 ROS 1 中一样。

无论哪种方式，Action都将是 ROS 2 API 中的一等公民，并且服务可能只是成为动作的退化案例。

语言支持

DDS 供应商通常至少提供 C、C++ 和 Java 实现，因为这些语言的 API 由 DDS 规范明确定义。
研究发现没有任何完善的 DDS for Python 版本。因此，ROS 2 系统的一个目标是提供一流的、功能完整的 C API。

这将允许更轻松地进行其他语言的绑定，并使客户端库之间的行为更加一致，因为它们将使用相同的实现。Python、Ruby 和 Lisp 等语言可以将 C API 包装在一个精简的语言惯用实现中。

ROS 的实际实现可以使用 C 语言，使用 C DDS API，也可以使用 C++ 语言使用 DDS C++ API，然后将 C++ 实现包装在其他语言的 C API 中。

用 C++ 实现并用 C 包装是一种常见的模式，例如 ZeroMQ 就是这样做的。
然而，ZeroMQ 的作者并没有在他的新库 nanomsg 中这样做，理由是增加了复杂性和C++ stdlib 作为依赖项。

由于 DDS 的 C 实现通常是纯 C，因此可以为 ROS C API 提供纯 C 实现，一直到 DDS 实现。
然而，用 C 编写整个系统可能不是首要目标，并且为了让最小的可行产品工作，实现可能是用 C++ 和包装在 C 开始的，后来 C++ 可以用 C 替换，如果似乎有必要。

DDS 作为依赖项

ROS 2 的目标之一是尽可能多地重用代码（“不要重新发明轮子”），同时尽量减少依赖项的数量，以提高可移植性并保持构建依赖项列表的精简。

这两个目标有时是不一致的，因为它通常是在内部实现某些东西或依赖外部源（依赖）来实现之间的选择。

这是 DDS 实现大放异彩的一点，因为正在评估的三个 DDS 供应商中有两个是在 Linux、OS X、Windows 和其他更奇特的系统上构建的，没有外部依赖项。

C实现只依赖系统库，C++实现只依赖C++03编译器，Java实现只需要JVM和Java标准库。
OpenSplice (LGPL) 的 C、C++、Java 和 C# 实现在 Ubuntu 和 OS X 上捆绑为二进制文件（在原型设计期间），大小小于 3 MB，并且没有其他依赖项。

就依赖关系而言，这使得 DDS 非常有吸引力，因为它显着简化了 ROS 的构建和运行依赖关系。
此外，由于目标是使 DDS 成为实现细节，它可能会作为传递运行依赖项被删除，这意味着它甚至不需要安装在已部署的系统上。

DDS Prototype 上的 ROS

在研究了 ROS 在 DDS 上的可行性之后，留下了几个问题，包括但不限于：

可以在 DDS 之上实现 ROS 1 API 和行为吗？
从 ROS MSG 消息中生成 IDL 消息并将其与 DDS 一起使用是否可行？
打包（作为依赖项）DDS 实现有多难？
DDS API 规范是否真的使 DDS 供应商可移植性成为现实？
配置 DDS 有多难？

为了回答其中一些问题，在这个存储库中创建了一个原型和几个实验：

https://github.com/osrf/ros_dds

这个存储库中的主要工作是在 prototype 文件夹中，并且是使用 DDS 的节点、发布者和订阅者 API 的类似 ROS 1 的实现：

https://github.com/osrf/ros_dds/tree/master/prototype

具体来说，这个原型包括这些包：

从 .msg 文件生成 DDS IDL：https://github.com/osrf/ros_dds/tree/master/prototype/src/genidl
为每个生成的 IDL 文件生成 DDS 特定的 C++ 代码：https://github.com/osrf/ros_dds/tree/master/prototype/src/genidlcpp
C++ 的最小 ROS 客户端库 (rclcpp): https://github.com/osrf/ros_dds/tree/master/prototype/src/rclcpp
发布订阅和服务调用的谈话者和听众：https://github.com/osrf/ros_dds/tree/master/prototype/src/rclcpp_examples
ros_tutorials 的一个分支，其中 turtlesim 已被修改以针对 rclcpp 库构建:turtlesim
turtlesim 的这个分支功能不完整（例如，不支持服务和参数），但基本工作正常，它证明了从 ROS 1 roscpp 过渡到 ROS 2 rclcpp 原型所需的更改 没有戏剧性。

这是一个用于回答问题的快速原型，因此它根本不代表最终产品或发行。一旦关键问题得到解答，某些功能的工作就停止了。rclcpp_example 包中的示例表明，可以在 DDS 之上实现基本的 ROS 类 API，并获得熟悉的行为。
这绝不是一个完整的实现，也没有涵盖所有功能，而是出于教育目的，并解决了大多数关于使用 DDS 的疑问。

IDL 文件的生成被证明有一些症结，但最终可以解决，并且实现诸如服务之类的基本事物被证明是易于处理的问题。
除了上述基本部分之外，还起草了一个拉取请求，该请求成功地从任何公开安装的 rclcpp 和 std_msgs 标头中完全隐藏了 DDS 符号：
https://github.com/osrf/ros_dds/pull/17

这个拉取请求最终没有被合并，因为它是对代码结构的重大重构，并且在此期间已经取得了其他进展。
然而，它的目的在于它表明 DDS 实现可以被隐藏，尽管对于如何实际实现该目标仍有讨论的空间。

结论

在与 DDS 合作并对精神、社区和许可持怀疑态度之后，很难提出任何真正的技术评论。虽然围绕 DDS 的社区确实与 ROS 社区或 ZeroMQ 社区有很大不同，但 DDS 似乎只是 ROS 可以安全依赖的可靠技术。

关于 ROS 究竟如何利用 DDS 仍有许多问题，但在这一点上，它们似乎都是工程练习，而不是 ROS 的潜在交易破坏者。

文章来源：威廉伍德尔写于2014-06