自动驾驶慢半拍,问题可能不在算法

15 秒导读

自动驾驶是一辆车，不仅仅是一台电脑

车速 64 公里/小时的时候，100 毫秒能跑多远？

答案是约 1.78 米。

在计算机系统里，100 毫秒看起来只是一个很小的时间尺度；但放到真实道路上，它对应的是一两米的行驶距离。对于自动驾驶系统来说，这一两米可能会影响车辆在复杂交通场景中的安全余量。

因此，自动驾驶系统需要解决的并不只是“能不能准确感知环境”，还包括另一个同样重要的问题：感知数据产生之后，系统能否及时完成处理并作出响应。

我们在讨论自动驾驶时，通常会首先想到摄像头、激光雷达、感知模型和规划算法。传感器性能、模型精度和规划能力当然很重要，但在完整的车载系统中，数据从传感器到算法模块之间的传输过程，同样会影响系统整体响应速度。

这项工作关注的正是这个问题：

传感器数据已经进入车载计算机之后，算法模块还需要等待多久，才能真正使用这些数据？

我们在一辆运行 Autoware.Universe 的 L4 自动驾驶车辆上进行了测试。

在原始 ROS 2 管线下，从感知到决策的平均端到端延迟约为 521.91 ms。其中，仅 ROS 2 发布/订阅路径就大约占 369.45 ms。

也就是说，在完整自动驾驶系统中，端到端延迟并不完全来自算法计算本身。数据在系统内部不同模块之间的传输，也会占据相当一部分时间。

这个结果说明了一个容易被忽视的问题：车辆反应慢半拍，不一定只是因为算法算得慢，也可能是数据在系统内部流转时已经消耗了大量时间。

对于自动驾驶系统来说，通信链路中的延迟不是一个孤立的软件指标。车辆在持续运动，环境也在持续变化。数据越晚被下游模块使用，下游模块看到的环境状态就越可能滞后于真实道路情况。

如果把 521.91 ms 放到道路上理解，在 64 公里/小时的车速下，它对应约 9.28 米的行驶距离；在 112 公里/小时的车速下，它对应约 16.24 米的行驶距离。

这也是我们提出 Sensor-in-Memory，也就是 SIM 的直接动机。

数据明明在车里，为什么还会“堵车”？

很多开源自动驾驶系统，例如 Autoware.Universe，建立在 ROS 2 和 DDS 这类通信机制之上。

这类机制的优势很明确。感知、定位、规划和控制等模块可以独立运行，并通过发布和订阅机制传递消息。这样的设计有利于系统模块化，也便于后续替换、调试和维护。

但对于高频、大规模的传感器数据，这一路径也会带来额外开销。

摄像头和激光雷达产生的数据量大、频率高。在传统 ROS 2/DDS 路径中，数据通常需要先转换为 ROS 消息，再经过封装、传输、解析，最后再转换为算法模块实际使用的数据结构。

这一过程在软件架构上是规范的，也适合构建模块化系统。但在同一台车载计算机内部，如果高频传感器数据仍然完整经过这一路径，就会引入额外的数据转换和通信开销。

更需要关注的是尾延迟 （Tail Latency）。

自动驾驶系统不仅需要大多数时候足够快，也需要尽量减少个别时刻突然变慢的情况。因为某一帧数据的延迟升高，可能会让下游模块基于更旧的环境信息进行判断。

因此，我们希望在保留 ROS 2 生态和模块化优势的同时，为同机内部的高频、低延迟数据链路提供一条更短的数据路径。

SIM 的核心思路：减少内部数据绕行

SIM 的基本思路是：当传感器数据和算法模块都位于同一台车载计算机内部时，可以将数据直接放入共享内存，让需要使用数据的模块直接读取，从而减少传统消息传输路径中的格式转换、封装和解析开销。

SIM 并不是为了取代 ROS 2。

跨设备、跨车载控制单元的通信，仍然可以由 ROS 2/DDS 负责；而在同一台车载计算机内部，例如相机到感知模块、激光雷达到定位模块这类高频数据流，则可以通过 SIM 降低传输开销。

换句话说，SIM 的目标不是重建整套自动驾驶通信系统，而是在最容易受到延迟影响的局部链路上，减少不必要的数据绕行。

SIM 做了哪些设计？

SIM 主要做了三方面设计。

首先，减少数据格式转换。

图像数据本来常以 cv::Mat形式被算法处理，SIM 就尽量按照 cv::Mat的形式组织和存放；点云数据本来常使用 PCL 相关数据结构，SIM 也尽量保持其原有布局。这样可以减少中间格式转换带来的额外开销。

其次，优先提供最新数据。

SIM 采用双缓冲机制。写入端先将新一帧数据写入后台缓冲区，写入完成后再进行缓冲区切换；读取端只读取已经完整写入的数据。如果读取端处理速度跟不上数据产生速度，中间的旧帧可能会被跳过。

这种设计适用于自动驾驶中的一类典型场景：下游模块更关注最新的环境状态，而不是严格处理每一帧历史数据。对于感知、定位等实时链路而言，使用更新的数据通常比完整排队处理旧数据更符合系统需求。

第三，保留必要的数据状态检查。

SIM 中加入了序列号、写入端心跳以及可选校验机制，用于判断数据顺序、写入端状态以及共享内存内容是否异常。也就是说，SIM 在降低传输延迟的同时，仍然保留了必要的运行状态检测能力。

平台实验：传输延迟和尾延迟都有下降

我们首先在 NVIDIA Jetson Orin Nano 上进行了实验，对比对象包括 SIM、Fast DDS 零拷贝和 Zenoh。

以 640×480、30 FPS 的摄像头数据为例：

只有一个发送端、一个接收端时，SIM 的平均传输延迟约为 0.253 ms；Fast DDS 为 3.40 ms，Zenoh 为 3.984 ms。

当同一份数据同时提供给十个模块读取时，SIM 的平均传输延迟约为 0.709 ms；Fast DDS 约为 7.226 ms，Zenoh 约为 10.484 ms。

激光雷达数据也表现出类似趋势。对于 18 线激光雷达、20 Hz、单发送端到单接收端的场景，SIM 的平均传输延迟约为 0.226 ms；Fast DDS 约为 0.685 ms，Zenoh 约为 0.839 ms。

在 Orin Nano 平台上，与 ROS 2 零拷贝 DDS 路径相比，SIM 最高可以将最大传输延迟降低 98%，平均延迟降低约 95%，p95/p99 这类尾延迟收窄约 96%。

这些结果说明，SIM 不仅降低了平均传输延迟，也降低了延迟波动。对于自动驾驶系统而言，尾延迟的下降意味着系统在高负载或多接收端场景下，更容易维持稳定的数据传输时间。

当然，SIM 也引入了一定代价。为了让接收端更及时地获取数据，它会更频繁地检查共享内存状态；当多个模块同时读取同一份数据时，系统调度负载也会增加。从实验结果看，这部分 CPU 开销总体处于可控范围内。

因此，SIM 本质上是在传输延迟和系统调度开销之间做了一种取舍：通过增加少量运行时检查和调度负载，换取更短、更稳定的数据传输时间。

回到真车：SIM 对端到端链路有什么影响？

在真车测试中，我们首先将 SIM 应用到定位模块内部的数据传输。

替换之后，NDT 定位输出频率从 7.5 Hz 提升到 9.5 Hz，接近模块配置的 10 Hz 上限。

这说明，在该场景中，定位模块的输出频率此前受到内部数据传输路径的限制；替换为 SIM 后，模块能够更接近传感器和配置参数所允许的运行节奏。

进一步地，如果将 SIM 应用到预处理、感知、定位、规划等关键内部通信阶段，论文估算平均感知到决策延迟可以从 521.91 ms 降至 290.26 ms，平均减少约 231.65 ms。

231.65 ms 看起来还不到四分之一秒。

但在 64 公里/小时的车速下，它对应约 4.12 米的行驶距离；在 112 公里/小时的车速下，它对应约 7.21 米。

这意味着，车载软件系统中节省下来的几百毫秒，最终会对应到车辆在道路上的实际行驶距离。

适用边界与后续工作

SIM 关注的不是单个算法模块的计算速度，而是自动驾驶系统内部高频数据链路的传输效率。

在自动驾驶系统中，通用中间件仍然非常重要。模块化、可维护、可复用，是复杂车载软件系统必须具备的能力。SIM 的设计思路是保留 ROS 2 的整体生态，只在对延迟敏感的局部通信路径上采用共享内存机制。

也就是说，跨设备、跨控制单元通信仍然可以使用通用中间件；同机内部的高频数据传输，则通过更短的数据路径降低延迟。

这项工作目前仍有进一步扩展空间。后续还需要进行更严格的最坏情况分析，并在更多故障场景、复杂负载、多数据流、多生产者场景下进行测试。同时，SIM 也需要继续与CyberRT 等方案进行更系统的比较。

总结

自动驾驶系统的实时性不仅取决于传感器和算法，也取决于数据在系统内部能否高效、稳定地流动。

车辆不仅需要看得清，也需要反应得上。

SIM 的目标，是面向同一台车载计算机内部的高频传感器数据链路，减少格式转换和消息传输带来的额外开销，使数据能够以更短、更稳定的路径到达下游模块。

在高速行驶场景中，时间延迟最终会转化为车辆行驶距离。因此，降低通信链路中的毫秒级开销，对于自动驾驶系统具有明确的工程意义。

论文链接与引用方式

本文在今年6月IEEE 智能汽车会议 （IV2026） 上发表。

论文题目：A Faster and More Reliable Middleware for Autonomous Driving Systems作者：Yuankai He, Weisong Shi论文链接：https://arxiv.org/abs/2510.11448代码与实验材料：https://github.com/Croquembouche/DAVOS_SIM

正式会议版本上线后，我们也会同步更新 IEEE Xplore 链接和会议论文引用信息。