[人工智能]自动驾驶单节点通信中间件探索

导读

该工作《Oops! It’s Too Late. Your Autonomous Driving System Needs a Faster Middleware》于2021年7月已经被IEEE Robotics and Automation Letters (RA-L)接收。

文章主要讨论了当前自动驾驶领域流行的通信中间件是否能够满足自动驾驶场景的通信需求，并且开源了一个自动驾驶端到端测试工具：ComP。

本博文内容为文章简单摘要，欢迎阅读原文

01

背景

过去的几十年，自动驾驶技术取得了飞速发展。但仍然有很多人对自动驾驶或者说完全的自动驾驶抱有悲观的态度。其中一个很重要的原因就是自动驾驶的鲁棒性和可靠性很难保证。对自动驾驶车辆来说，如何在复杂的行驶环境中实时地处理海量数据是一个巨大的挑战。目前的大部分工作主要关注如何通过算法（AI）和硬件（GPU、FPGA加速）来加速数据处理，随着处理速度变得越来越快（实验中，我们发现很多流行的AI模型的推理时间在硬件加速下能降低到10ms以下甚至更低），原本被忽略的通信延迟也进入了自动驾驶从业者的视野。本文选取了当前自动驾驶领域热度比较高的三个开源中间件：ROS1、ROS2、Cyber（百度Apollo），深入分析了它们的通信机制和在典型自动驾驶场景中的通信性能。

事实上，当前通信中间件主要有三种通信机制。第一种是进程内通信（IntrA-Process，IAP），即不同的线程直接通信，它能实现0拷贝；第二种是共享内存（SHared Memory，SHM）通信，这是一种高效的IPC方法；第三种则是基于socket的通信，它能够支持跨机器的通信。在我们选取的三个开源中间件中，ROS1支持IAP（nodelet）和基于socket的通信（TCPROS、UDPROS），ROS2同样支持这两种方法，Cyber相比于ROS1和ROS2还额外支持SHM。需要注意的是，ROS2和Cyber都通过DDS（基于socket）来实现跨主机通信。

02

实验设计

本文的实验主要分两个部分。第一个部分是micro测试，这部分测试中，我们首先总结了自动驾驶中常见的传感器的消息大小以及发送频率（见下表，CV即摄像头图片数据，LidarL和LidarH分别为不同密度的激光雷达数据），然后模拟这些传感器的数据特征对3个中间件进行了多场景测试。之所以选择感知场景的消息传输是因为这一部分的数据量很大，并且场景也非常复杂，对中间件的性能要求比较高。

第二部分是使用真实应用的端到端性能测试，如下图所示，ComP模型模拟了自动驾驶车辆中的一个简单的端到端的感知场景。首先摄像头捕捉图像数据，然后经中间件将原始图片交给Lane（寻线模块，负责从图片中提取车道信息）、Yolo(物体识别模块，负责识别图片中的车辆、行人等物体)和MOSSE（物体追踪模块，负责对识别出来的物体进行追踪），最后各个模块处理完数据后会将处理结果交给Fusion模块进行数据融合。ComP工具已经在Github上开源，分别有ROS1、ROS2以及Cyber三个环境的版本，我们希望能给自动驾驶社区的开发者提供简单易用且使用真实应用的端到端测试集。

03

实验结果摘要

这里我们简单展示部分文章发现。

一：1对1场景。

首先，下图展示了在1对1通信场景中，面对不同数据大小和发送频率时，三个中间件的不同通信机制的性能表现。消息的发送频率实际上对通信性能的影响不是很大，而数据大小才是最主要的影响因素（显而易见）。而三个中间件的IAP机制都有着0拷贝的特性，所以它们基本不受消息大小的影响。而SHM方法因为也避免了数据拷贝，所以受数据大小的影响也不大。只不过SHM仍然需要进行数据序列化和反序列化操作，所以性能不如IAP类型的方法。基于socket的方法在传输大消息时是性能最差的，而有一点比较反直觉的是UDP反而性能不如TCP。这主要是因为UDP在传送大消息时有一个额外的拆包和重组的过程，导致很高的性能损失。另外ROS1的UDP机制仅支持最大1500Byte的数据报，而DDS（基于UDP）则支持最大64KB的数据报，所以ROS1 UDP的性能会有额外的损失。同时我们也看到Cyber的几种通信方法对比同类型的ROS里的方法都存在一定差距，可见Cyber还是引入了一些额外的开销，不如ROS来得轻便。小结一下，在传输的消息大小较小时，各种通信机制差距不大，而在消息较大时，部分传输机制将无法满足自动驾驶的实时性需求。我们将这三个中间件的通信机制性能排序如下：ROS2 IAP > ROS1 IAP > Cyber IAP > Cyber SHM > ROS1 TCP > ROS2 DDS > ROS1 UDP > Cyber DDS。

二：自动驾驶典型通信场景。

除了最简单的1对1通信，我们从自动驾驶应用场景中抽象出两个常见的通信场景：1对多（多个模块使用同一个数据源的消息）、多对1（消息融合）。先看1对多场景，Cyber对1对多场景做了特别的优化，它消除了多余的数据拷贝。而对于ROS1和ROS2，每当多一个订阅者订阅消息，发送的数据都需要多拷贝一份，这导致了在一对多场景下，随着订阅者数量的增加，系统的负载会跟着增加，进而导致明显的性能下降。

再看数据融合的场景，Cyber和ROS1、ROS2采用了不同的融合策略。Cyber的策略是以第一个channel的消息为基准来融合，即每当第一个channel中发现有新数据时则对当前所有需要融合的channel进行一次消息汇总。ROS1和ROS2则都采用了自适应算法来同步消息，它的好处是保证了较好的公平性。参考下图的实验结果，我们的建议是在做数据融合时需要综合考虑融合策略和所需融合的channel的消息发送频率，并且结合实际应用的需求来选择。比如在我们的端到端场景ComP中，物体追踪模块需要图片原始数据以及物体检测结果数据，但需要实时处理的主要是图片原始数据，那么我们就可以选用Cyber的融合策略并把图片原始数据作为第一个channel，这样就能保证需要实时处理的channel数据的延迟最低。另外需要说明的是，现在很多自动驾驶解决方案都会刻意避免直接进行数据融合，以避免不可控的消息延迟。但我们认为，如果中间件能够直接提供原生的比较丰富合理的融合策略，那么就能够大大减少开发者的工作。

三：端到端真实应用场景。

最后我们简单分析一下ComP实验得到的发现。通过在不同算力平台（Server-PC, AGX）运行ComP，我们对比了数据传输延迟和数据处理延迟。如下表所示，可以看到如果使用不合适的中间件通信机制，数据传输延迟甚至能远远超过数据处理延迟。而且这个现象在算力越强的平台越明显，因为强大的算力对数据处理速度的提升效果要远好于对数据传输速度的提升效果。

04

总结

本文对自动驾驶中间件技术的发展现状做了介绍，并对三个常见的开源自动驾驶中间件的性能和通信特征做了实验分析。我们的实验有很多有趣的发现，能够为自动驾驶从业者以及通信中间件开发者提供参考。同时，我们也开源了一个端到端的测试模型，自动驾驶研究人员能方便地使用它进行实验。

原文中还讨论了QoS策略、计算平台资源、实时内核、V2X等主题，欢迎阅读。

论文：

https://weisongshi.org/papers/wu21-RAL.pdf

BibTex引用格式：

@ARTICLE{9488177, author={Wu, Tianze and Wu, Baofu and Wang, Sa and Liu, Liangkai and Liu, Shaoshan and Bao, Yungang and Shi, Weisong}, journal={IEEE Robotics and Automation Letters}, title={Oops! It’s Too Late. Your Autonomous Driving System Needs a Faster Middleware}, year={2021}, volume={6}, number={4}, pages={7301-7308}, doi={10.1109/LRA.2021.3097439}}