网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

我们还测量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配置，因为有许多供应商特定的配置选项。