ROS2性能分析

news2024/10/5 19:14:42

文章：Performance Analysis of ROS2

作者：Deepak Charan Logavaseekaran, Rakshith Macha Billava

编辑：点云PCL

欢迎各位加入知识星球，获取PDF论文，欢迎转发朋友圈。文章仅做学术分享，如有侵权联系删文。未经博主同意请勿擅自转载。

公众号致力于点云处理，SLAM，三维视觉，高精地图等领域相关内容的干货分享，欢迎各位加入，有兴趣的可联系dianyunpcl@163.com。未经作者允许请勿转载，欢迎各位同学积极分享和交流。

背景介绍

ROS（机器人操作系统）是一个开源框架，用于促进机器人应用程序的开发。ROS有助于管理复杂性并促进应用程序的快速原型开发。使用ROS框架的主要优势之一是ROS提供的互操作性和模块化性。它支持多种编程语言，包括Python和C++，并提供即插即用的节点结构，甚至跨多个设备的网络环境中也可以使用。ROS1最初是由Willow Garage于2007年创建的，在爱好者中非常流行。然而，它也有自己的缺陷，为了满足需求，ROS2被开发出来。ROS2采用完全不同的架构，提供更好的模块化和平台无关的支持，ROS2承诺在不同编程语言之间提供类似的API，并通过分层实现加快新功能的部署速度，其中底层基础库对于所有编程语言都保持相同。ROS2还提供了一个集中化的系统，每个节点都能够发现其他节点，支持异步服务和动作，并且取消了对ROS主节点的依赖。ROS2使用DDS中间件，因此提供了所有相关的服务质量策略，它还提供了各种调试和可视化工具，并且还扩展了对Windows和macOS的支持。尽管ROS2被研究人员和爱好者广泛使用，但在实时环境中其性能仍存在一些问题。在本研究中，我们评估了ROS2的性能，并了解其在实时生态系统中的相关性。

本文任务是分析ROS2节点之间的通信性能，记录了执行分析的过程和所得结果。

解决方案描述

硬件说明

本评估的所有测试都是在NVIDIA Jetson Orin开发套件上进行的，该套件配备了12核ARM Cortex A78处理器和64GB eMMC固态硬盘。使用的是搭载Jetson Orin设备的Jetson JetPack SDK 5.1.1，运行着Ubuntu 22.04（Linux Kernel 5.10.X）操作系统，主要使用ROS2 Humble进行测试。

rclpy vs rclcpp

rclpy和rclcpp是ROS2的客户端API，用于设置/配置节点或与ROS2核心进行交互，它们分别是Python和C++的实现，大部分API及其使用方式相似。然而根据我们发现的一个问题ros2 latency repository，rclpy在发布大型数据时比rclcpp慢30倍至100倍。该问题已在ROS2 Foxy发布之前得到解决和合并。我们能够克隆展示该问题的存储库，并且能够以最小的更改运行测试，确认性能差异并非30倍的数量级。

为了评估rclcpp和rclpy之间的性能差异，我们创建了一个简单的测试，发布一块数据并测量这两种实现发布消息所需的时间。我们首先生成要发布的数据并实例化一个定时器，定时器在调用发布API之前启动，并在发布调用之后立即停止，在rclpy和rclcpp的实现中，方法保持一致，我们观察到，rclpy发布消息所需的时间始终比rclcpp多约6倍，如图1所示。

图1:rclpy与rclcpp发布时间

接着进行了测试，比较了rclpy和rclcpp实现的延迟，为了计算延迟，首先创建了具有所需字节数的消息，然后记录纪元时间并调用发布API，立即在发布时间之后，将纪元时间发送到订阅者，在订阅者节点中，我们在接收到消息时立即记录纪元时间，然后接收发布时间并计算差值以获取消息的延迟，此测试重复进行约15次，并将15个结果的平均值用于我们的评估。我们观察到，rclpy实现的延迟约为rclcpp实现的3倍，如图2所示。

图2:rclpy与rclcpp延迟

由于实验室中使用了多个设备上的多个ROS2版本，我们还评估了ROS2版本，以查看不同版本对结果是否有影响。我们在ROS2 Humble和Foxy版本上运行了相同的延迟测试，这个测试使用了rclcpp在Humble和Foxy版本上的实现，根据我们的观察，我们没有找到任何确凿的证据表明一个版本比另一个版本更好，如图3所示，尽管对于较大的消息，Foxy的表现稍好一些。

图3:ROS2 Humble与Foxy延迟

由于ROS2使用DDS中间件，它本身也提供了各种QoS策略，为了本研究的目的，我们想评估使用可靠和尽力QoS策略的影响。在前面的评估中使用的延迟测试也在这里使用，只是修改了QoS策略，同样地，我们无法找到一个相对于另一个的明显改进，如图4所示。由于测试是在只有两个节点的情况下进行的，因此没有网络流量，这意味着没有或几乎没有数据包丢失，因此，我们推断无论是最佳尽力还是可靠的QoS策略实现，都会发送类似的数据而无需重复，这可能是结果相似的原因。

图4:ROS2可靠与尽力QoS

专家建议

在ROS2方面的经验，Marc提出了以下建议：

* 在ROS2的C++实现中使用事件执行器（event executor）。

* 通过Linux操作系统关闭CPU的IDLE模式。

* 将CPU密集型任务固定在单独的CPU核心上。

* 将Linux调度程序更改为循环轮询（Round Robin）。

* 将多个节点编译到单个进程中，避免使用IPC，并利用共享内存。

在采纳这些建议后，我们发现对于我们特定的测试用例，这并没有显著改善延迟，此外，我们与Peter Gabriel Adamczyk教授及其学生Yisen Wang和Kieran Nichols取得了联系。尽管他们没有测试过以MB为单位发送大型消息的ROS2，但他们提到他们对ROS2的经验有些相似，他们还建议使用实时Linux内核，并在ROS2连接中使用UDP而不是TCP，由于我们的所有节点都在单个设备上运行，网络协议的选择对我们的实验并不适用，然而，我们希望在将来考虑使用Linux的RT PREEMPT补丁。

结束语

根据上述研究结果，可以明显看出ROS2的C++实现在速度方面优于Python版本，然而尽管ROS2开发人员努力改进实时性能，但该框架对于时间关键和实时系统仍然不够适用。我们的测试结果表明与ROS2在实时场景下所提供的优势相比，其引入的消息传输开销过大，因此，目前阶段不建议将ROS2用于实时应用。

以上内容如有错误请留言评论，欢迎指正交流。如有侵权，请联系删除