基于 ROS2-DDS 中间件实现的协同驾驶在自动驾驶车辆中的性能评估

在自动驾驶和无人驾驶的领域中，协同感知（通过无线通信在车辆间交换传感器信息）为这一领域增添了新维度。自动驾驶车辆是一种特殊类型的机器人，由于功能安全的要求，需要实时高可靠的传感器输入。自动驾驶车辆配备了大量传感器，以提供所需的数据用于驾驶决策，并与周边车辆共享信息。ROS2 中引入的数据分发服务（DDS）作为通信中间件，展现了其作为可靠实时分布式系统的潜力。为简化用户体验，ROS2 将消息转换为 DDS 格式进行传输。DDS 提供了一个称为“域”的作用域机制，每当 ROS2 进程启动时，它会创建一个 DDS 参与者。然而，单个域中允许的参与者数量是有限的。

由于车辆内部传感器众多及其消息的高效处理需求，单个车辆需要多个 ROS2 节点。此外，在协同感知范式下，当一个车辆作为单个 ROS2 节点操作时，可能需要更多的 ROS2 节点。由于 DDS 参与者的限制，这些 ROS2 节点无法全部参与同一域，因此跨域通信不可避免。此外，不同厂商对 DDS 的具体实现和配置也是 ROS2 节点之间通信的关键因素。本研究评估了不同厂商的 DDS 实现方案在跨域通信场景下对多种传感器数据类型的性能表现。

初代机器人操作系统（ROS1）存在多种缺陷，包括操作系统依赖性、缺乏容错能力、进程同步问题以及时间限制，这些问题显然使其无法成为一个实时系统。而由对象管理组织（OMG）发布的 DDS 标准引入了一种具有服务质量（QoS）保障的稳健发布-订阅模型，用于可靠和及时的数据传播。DDS 支持多种传输配置，确保了安全性、可扩展性、弹性、安全性和容错性，使其成为分布式系统的完美选择。DDS 通过数据中心发布-订阅（DCPS）模型工作，包含主题、数据读取器、数据写入器、发布者和订阅者等组件。DDS 域通过域 ID 标识，允许发布者和订阅者在全局数据空间（GDS）中通过主题进行无缝通信，从而确保完全隔离。尽管 GDS（全局数据空间）和域的作用域机制使发布-订阅通信更为简单，但当域参与者和主题数量达到一定规模时也会带来一些问题。当一个 ROS2 进程在一台机器上启动时，会创建一个 DDS 参与者。每个参与者占用系统中的两个端口。因此，一台机器上超过 120 个 ROS2 进程无法共存于同一域。此外，为管理大量传感器并交换其生成的数据，单个车辆或机器人需要多个 ROS2 节点。在自动驾驶车辆的协同感知场景中，车辆或机器人作为 ROS2 节点通过无线通信进行数据交换。在这种情况下，可能有无限数量的 ROS2 节点相互通信。

参数

器具有不同的采样频率，我们将可变发布频率视为最重要的参数之一。ROS2 节点必须提供特定的数值域 ID 以参与特定域。由于我们的用例涉及不同域之间的通信，因此我们将多个域 ID 纳入参数范围。

自动驾驶车辆配备了各种类型的传感器，这些传感器生成不同类型和大小的数据。我们在实验中使用了多种数据类型（例如二进制、字符串和数值序列）以及数据大小作为参数。此外，为在 ROS2 中建立发布者和订阅者之间的通信，节点必须提供 QoS 策略配置文件。默认情况下，耐久性、可靠性和历史 QoS 设置分别为“易失性”（volatile）、“可靠”（reliable）和“保留最后的”（keep last）。历史 QoS 的默认队列大小为 10。截止时间、存活性和生命周期 QoS 设置根据系统默认值进行配置。在整个不同域通信的传感器数据交换中，我们始终使用上述 QoS 策略设置。

测量指标

对于自动驾驶车辆这样的实时系统，传输消息的延迟是最关键的指标，因此我们将延迟视为主要测量指标。在分布式系统架构中，由于不同机器的时钟需要同步，很难直接测量单向延迟。因此，我们使用往返时间（Round Trip Time, RTT）来推导延迟特性。由于我们的评估重点是不同 DDS 实现方案在不同域通信时延迟特性的表现，我们假设 ROS2 系统在不同 DDS 实现方案下具有类似的行为。

往返时间（Round Trip Time）

为了测量 RTT，我们使用多种物理设备作为 ROS2 发布者和订阅者节点，这些设备通过有线和无线通信方式连接。RTT 是指消息从发布者节点发送到订阅者节点，再从订阅者节点返回到发布者节点所需的总时间（图1）。我们使用自定义消息描述每个 ROS2 主题，因为测试中涉及不同的数据类型。

对于二进制文件类型，我们使用自定义消息类型 BinaryFile，它包括 sensor_msgs/Image 类型以存储二进制图像，以及一个 float64 数据类型以存储发布时间。在发布帧时，记录时间戳 T1T_1T1 并将其包含在消息中。位于域 5 的发布者节点创建主题 binary_image 发布二进制图像，同时创建主题 binary_image_relay 的订阅者以接收订阅者节点返回的消息。位于域 10 的 ROS2 订阅者节点订阅 binary_image 主题以接收消息，同时创建一个发布组件将接收的消息转发到 binary_image_relay 主题。当 ROS2 发布者节点收到转发的消息时，再次记录时间戳 T2T_2T2 以获取消息接收时间。通过计算 T2−T1，可以得到 RTT。

图1 往返时间示意图

延迟测量

ROS2 订阅者节点通过转发发布功能计算 RTT。在通信过程中，转发发布节点处理的中间时间会因数据大小和类型的变化而变化，从而直接影响 RTT。例如，对于 33KB 和 4MB 的二进制数据，其中间处理时间是不同的。为了测量订阅者节点的中间处理时间，在节点订阅所需主题并开始下载数据帧时记录时间戳 T3，在转发发布该数据帧时记录时间戳T4。中间处理时间通过 T4−T3计算得出。在订阅者节点本地计算中间处理时间可以避免时钟同步的复杂性。中间处理时间=T4−T3， 通过从 RTT 中减去中间处理时间并将结果除以 2，可以计算特定数据帧的延迟：延迟=（RTT−中间处理时间）/2

实验设置包括数据、硬件和软件部分。本节介绍用于评估不同 ROS2 DDS 实现性能的实验设置，包括测试数据、物理系统和软件栈。

数据

上面提到实验所需的参数，在协同自动驾驶范式中，二进制数据用于检测目标或障碍物或交通信号，而字符串和 IMU 数据用于共享驾驶决策相关的信息。我们从 ASL 数据集收集了二进制和 IMU 数据。然而，该数据集的二进制文件或图像大小固定，无法满足我们对可变文件大小的需求。为了解决这一问题，我们从互联网随机选择了不同大小的二进制文件，并使用脚本创建了一个包含各种二进制文件大小的数据集。对于字符串类型数据，我们随机从一本书中选取了不同长度的字符串。IMU 数据始终是固定大小，因此我们直接使用 ASL 数据集中的数据。为了验证我们的评估框架在实际实时数据中的表现，我们在连接 Realsense 摄像头的 Jetson Nano上运行了实验框架。

硬件

使用多种物理设备作为 ROS2 发布者和订阅者节点，以评估不同 DDS 实现方案的性能。以下表格列出了这些物理设备的硬件规格。

软件

为了为开发者提供一个稳定的代码库，开源机器人基金会（OSRF）发布了一系列不同的 ROS 软件包分发版本。ROS 分发版本直接依赖于 Linux 发行版。根据表 2 中提到的不同物理设备（如 ARM-64 和 x86_64 CPU），操作系统也必须适配这些硬件配置。选择了 Ubuntu 20.04 LTS AMD 64作为笔记本电脑的操作系统，选择了 Ubuntu 20.04 LTS ARM 64作为 Raspberry Pi 3 和 Pi 4 的操作系统，并使用 Jetson Nano（4GB）的 SD 卡镜像作为 Jetson Nano 的操作系统。

在文章的评估中，我们使用了最新的 ROS2 分发版本—ROS2 Humble。ROS2 Humble 仅支持在 Ubuntu 22.04 上安装，而不同的 DDS 实现方案对库版本有各自的依赖要求。为解决这些问题，使用了 Docker 来抽象底层操作系统、依赖库和 DDS 实现方案之间的关系。此外Docker 在运行于主机网络时产生的延迟开销可以忽略不计，因此简化了硬件和软件的构建，并不会影响性能评估。

ROS2 提供了两个客户端库：rclcpp（用于 C++）和 rclpy（用于 Python），以便创建节点、订阅者和发布者。我们使用了 rclpy 客户端库编写和构建了 ROS2 节点、主题、数据传输和通信。

实验场景

由于需要评估的参数数量繁多，可能的实验组合非常庞大。图 2 展示了从左到右所有理想实验的流程图。

图2：实验场景

评估

频率对延迟的影响： 在我们的研究中，我们观察到 Eclipse Cyclone DDS、eProsima RTPS 和 RTI Connext DDS 在不同域和连接类型下的通信延迟表现出了有趣的模式。对于不同域通信，当频率变化时，不同文件大小的延迟模式也有所不同。特别是对于 Eclipse Cyclone DDS，当文件较大时，更高的频率会导致延迟增加（如图 3a 所示）。在文件大小达到 502KB 时，无线连接节点（同域和不同域）中的延迟出现了明显的峰值。此外，我们发现，对于 eProsima Fast RTPS 和 RTI Connext DDS，在 502KB 文件大小下的延迟高于 1MB 文件大小（如图 3b 和 3c 所示）。然而，在 Eclipse Cyclone DDS 的有线连接实验中，不同域通信在所有文件大小下的延迟表现一致（如图 3d 所示），这一点与无线连接的不同域通信行为形成了鲜明对比。

图 3：在不同域的无线连接中，当文件大小超过 145KB 时，所有厂商的 DDS 实现方案均表现出延迟峰值；但对于 Eclipse Cyclone DDS 的有线连接，延迟表现较为一致。

同域通信与不同域通信

二进制数据： 在使用不同 DDS 实现方案的 ROS2 节点进行实验时，我们观察到同域通信和不同域通信在延迟特性上表现出多种有趣的模式。

无线连接： 对于使用 Cyclone DDS 的 Pi3 节点，在较小文件大小下，同域通信优于不同域通信（如图 4a 所示）。然而，对于较大的文件（特别是 1MB 文件），不同域通信在所有低发布频率下表现更佳。Pi4 节点的实验则表现出不同的行为（如图 4b 所示），随着文件大小的增加，同域通信通常表现更好。

图 4：Eclipse Cyclone DDS 在无线连接中，同域与不同域通信的性能对比（针对二进制数据）。

有线连接： 当切换到有线连接时，Pi3 和 Pi4 的延迟特性发生了显著变化。对于较大的文件，Pi3 节点的同域通信延迟较低，与无线场景下的表现完全相反。对于 eProsima DDS，在所有设备类型和连接选项中，同域通信始终优于不同域通信，无论文件大小和发布频率如何（如图 5 所示）。

图 5：eProsima DDS 在二进制数据传输中的同域和不同域通信性能对比。

RTI Connext DDS 的行为则更加复杂。在低频率下，对于无线连接的 Pi3 和 Pi4 节点，文件大小达到 87KB 时，同域和不同域通信的延迟相似。然而，对于超过 145KB 的文件，Pi3 的不同域通信表现更佳（如图 6a 所示）。笔记本节点表现出另一种模式（如图 6b 所示），无线情况下，小于 145KB 的文件在同域通信中延迟较高。

图 6：RTI Connext DDS 在无线连接中的同域与不同域通信性能对比。

字符串和 IMU 数据： 对于字符串和 IMU 数据，在 Pi3、Pi4 和笔记本的有线与无线连接中，Eclipse Cyclone DDS 和 RTI Connext DDS 的同域与不同域通信表现几乎一致。然而，eProsima Fast RTPS 在不同域通信中表现较差，与二进制数据传输类似。我们注意到，发布频率对延迟的影响通常较大，但对于使用 eProsima DDS 的无线连接 Raspberry Pi3 节点，延迟在不同频率下保持一致。令人意外的是，在所有 DDS 实现中，502KB 的二进制文件经常比 1MB 文件表现出更高的延迟。此外，对于小于 145KB 的文件大小，eProsima DDS、Eclipse Cyclone DDS 以及 RTI Connext DDS 有时表现出相似的延迟特性，无论发布频率如何。

未来工作

在未来的工作中，我们计划进一步研究 ROS2 通信和协同驾驶系统。具体来说，我们的目标包括以下几个方向：

1. 扩展 QoS 策略设置的研究范围及其兼容性

将探索更广泛的服务质量（QoS）策略配置，并分析这些设置在不同 DDS 实现方案之间的兼容性。

2. 节点压力测试

通过对节点进行压力测试，我们将评估在系统和网络负载下的性能表现。

3. 移动节点实验

为了模拟真实车辆场景，我们计划进行移动节点实验，以更好地反映现实环境中的通信需求。

4. 集成 5G 技术

我们将研究 5G 技术对通信性能的影响，评估其在自动驾驶和协同驾驶环境中的潜力。

5. 分析安全性实现的影响

我们打算分析 ROS2 安全包的实施对通信性能的影响，特别是在不同域通信场景下的性能变化。

6. 开发基于图形用户界面的推荐框架

我们计划开发一个基于机器学习的 GUI 推荐框架，帮助用户根据具体需求选择最佳的 DDS 实现方案及配置设置。

7. 502KB 数据延迟问题的调查

我们将深入研究为何 502KB 数据帧在实验中表现出突出的延迟峰值。

通过这种全面的方法，希望解决自动驾驶车辆通信中的关键挑战，提高 ROS2 的可用性，并显著优化协同驾驶系统的性能。我们的目标是提供宝贵的洞察和工具，推动自动驾驶和协同驾驶领域的进一步发展。

在自动驾驶和协同感知的范式中，依赖单一 ROS2 域来传输众多连接车辆间的传感器数据，并受限于参与者数量和主题数量是不现实的。因此，不同域通信是不可避免的，以支持更多的参与者和灵活数量的主题需求。本文首次对处于不同域的 ROS2 节点之间，通过有线和无线连接的通信性能进行了评估。评估涉及不同的物理设备和数据类型。通过评估，我们发现没有单一厂商的 DDS 实现方案在所有用例实验中表现最佳。在大多数情况下，同域通信的性能显著优于不同域通信。然而，在某些情况下，不同域通信在传输较大文件（更多数据包）时更为高效。对于所有数据类型而言，eProsima DDS 在不同域通信中的表现最差，无论是有线还是无线连接。我们的研究为机器人系统开发者和研究者在选择合适的数据类型、最小数据大小、连接媒介以及厂商特定的 DDS 实现方案提供了指导，以确保 ROS2 节点间的最佳通信性能。如果我们将无线介质上的不同域 ROS2 通信视为自动驾驶和协同驾驶范式中的基础通信方式，根据我们的实验结果，可以认为目前 ROS2 的厂商特定 DDS 实现方案尚不足以满足硬实时（hard real-time）需求。可能的原因是不同域通信中涉及的桥接服务性能存在瓶颈。为了在无限数量的 ROS2 节点或自动驾驶车辆之间实现通信，并确保实时系统的端到端延迟满足硬实时要求，所有厂商需要进行联合研究，开发新的机制并改进不同域通信性能。