【杂记】关于ROS1与ROS2通信方面的对比

【原文 链接】

ROS2测评—探索ROS2的性能

【重点摘抄】

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

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

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

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

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

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

传输数据大小的范围是256 B到4 MB，因为大图像数据（例如， 2 MB）和点云数据（.pcd）经常用于ROS应用，例如自动驾驶系统。

虽然每个节点以10 Hz执行，但实验重复最多4 MB。给出了每个数据大小的100次测量获得的箱线图和中位数。

我们比较了三种DDS实现，即Connext [29]，OpenSplice [25]和FastRTPS [14]。 Connext和OpenSplice是众所周知的商业许可证DDS实现。请注意，Connext还拥有研究许可证。

默认情况下，Connext使用UDPv4和共享内存来交换数据。

SCHED FIFO进程优先于任何非SCHED FIFO进程，即使用默认Linux调度的进程。使用mlockall，进程的虚拟地址空间在物理RAM中得到修复，从而防止将内存分页到交换区域。

ROS1和ROS2节点之间的通信需要一个ros_bridge [33]，这是一个转换DDS主题的桥接节点。

 请注意，在使用ros_bridge时，唯一使用的是besteffort策略，因为ros_bridge不支持QoS策略中的RELIABLE策略。

在“初始丢失”列中，ROS1无法在节点首次发送消息时获取初始消息，即使ROS1使用具有256 B等小数据的TCPROS并且在发布节点开始发送之前启动了订阅节点消息。

相比之下，即使使用4 MB等大数据，ROS2也不会丢失初始消息。这证明了DDS的可靠性。

对于大数据，ROS2具有显着的开销，具体取决于数据的大小，如图10所示。（2-b）中ROS2的开销归因于两个因素，即DDS的数据转换和处理DDS。

随着片段数据大小的增加，端到端的延迟会降低。 对于大的片段大小，DDS不需要将大数据分成许多数据报，这意味着更少的系统调用和更少的开销。

从3.3节开始，延迟是由DDS和DDS事务的两次数据转换引起的。 DDS端到端延迟是恒定的，直到消息数据大小低于最大数据包大小（64 KB），如图9所示。

另一方面，当一条大消息被分成几个数据包时，延迟会急剧增加，因为显示在图10和图18中，消息数据大小是否超过64 KB是一个重要问题，尤其是在DDS中，因为管理具有QoS策略的分割数据包需要大量处理时间和某些供应商提供的备用API。

我们应该了解分组数据包的影响，并在使用DDS时牢记这个问题。虽然DDS和ROS2抽象具有开销延迟，但OpenSplice比Connext更快地利用了许多线程和进程。