一、消息延迟的度量指标：延迟、抖动、吞吐量

各位同学，咱们今天聊点实在的。

做自动驾驶系统，尤其是用 Autoware 做感知、规划、控制这条链路，你迟早会遇到一个问题：消息到底慢在哪？

我刚开始接触 Autoware 那会儿，车在路上跑着跑着突然急刹，排查了半天，发现是某个节点的消息延迟从 10ms 跳到了 200ms。嗯，这种问题不靠指标量化，光靠肉眼盯日志，根本抓不住。

所以今天咱们先把度量指标讲透。说白了，就是三把尺子：延迟、抖动、吞吐量。

1.1 延迟（Latency）—— 最直观的“慢”

延迟的定义很简单：从消息被发布，到消息被订阅者接收并处理，中间经过的时间差。

在 ROS2 里，这个时间差通常用纳秒或微秒来算。我习惯把它拆成三段：

• 发布延迟：节点内部处理完数据，到数据真正写到 DDS 传输队列的时间。
• 传输延迟：数据在 DDS 层序列化、网络传输、反序列化的时间。
• 接收延迟：订阅者从 DDS 队列取到数据，到回调函数开始执行的时间。

你想想看，如果这三段里有一段突然飙高，整个系统的实时性就崩了。

1.2 抖动（Jitter）—— 比延迟更隐蔽的杀手

延迟高不可怕，可怕的是延迟忽高忽低。

抖动，就是延迟的标准差。它衡量的是延迟的稳定性。

举个例子：

• 系统 A：延迟稳定在 50ms，偶尔跳到 55ms。抖动很小。
• 系统 B：平均延迟也是 50ms，但有时 10ms，有时 200ms。抖动很大。

哪个更危险？我告诉你，系统 B 更危险。因为控制算法通常假设延迟是稳定的，突然的抖动会导致控制指令滞后，车就会“抽风”。

1.3 吞吐量（Throughput）—— 能扛多少数据

吞吐量，说白了就是单位时间内能处理多少消息。

在 ROS2 里，吞吐量通常用 msg/s（每秒消息数）或者 MB/s（每秒数据量）来衡量。

比如 LiDAR 点云，一帧可能有 1MB 数据，如果系统吞吐量只有 5MB/s，那每秒最多处理 5 帧。但 LiDAR 通常以 10Hz 或 20Hz 发布，如果吞吐量跟不上，队列就会积压，延迟自然就上去了。

指标	定义	典型值（Autoware）	影响
延迟	端到端时间差	10~100ms	控制实时性
抖动	延迟的标准差	< 10ms	控制稳定性
吞吐量	单位时间处理消息数	10~100 msg/s	系统容量

1.4 如何定义端到端延迟？

这个问题其实没有标准答案，因为不同场景下“端”和“端”不一样。但我个人习惯用下面这个定义：

端到端延迟 = T_control_output - T_sensor_capture

其中：

• T_sensor_capture：传感器硬件采集完成的时间戳（比如 LiDAR 的 header.stamp）
• T_control_output：控制节点发布最终指令的时间戳（比如 ackermann_cmd 的 header.stamp）

注意：这两个时间戳必须来自同一个时钟源。在 Autoware 里，我通常用 系统时钟（CLOCK_REALTIME） 统一打时间戳，并且确保所有节点都使用 rclcpp::Clock(RCL_SYSTEM_TIME)。

1.5 知识体系图

下面这张图帮你理清这三个指标的关系：

这张图你看懂了吗？三个指标不是孤立的——延迟高了，抖动往往也大；吞吐量上不去，延迟就会积压。我一般先看延迟，再看抖动，最后看吞吐量，三步定位法。

1.6 小结

今天咱们把三个核心指标讲清楚了：

• 延迟：端到端的时间差，直接反映系统快慢。
• 抖动：延迟的波动，影响控制稳定性。
• 吞吐量：系统能扛多少数据，决定是否过载。

端到端延迟的定义，我建议统一用传感器时间戳到控制输出时间戳的差值，并且确保时钟同步。这是后续所有定位工作的基础。

好了，这一章就到这里。下一章咱们聊聊如何用 ROS2 内置工具测量这些指标，到时候我会手把手教你怎么搭一个延迟监控系统。