延迟测量方法论：使用ros2cli工具测量端到端延迟

聊到延迟测量，很多新手第一反应就是「加个打印时间戳不就行了？」。嗯，理论上没错，但实际做起来坑不少。我最早在项目里也这么干过，结果发现打印本身就有延迟，测出来的数据根本不准。

今天咱们就聊聊，怎么用ROS2自带的cli工具，干净利落地测出端到端延迟。

为什么需要专门的延迟测量工具？

你想想看，一个典型的自动驾驶系统里，消息从传感器发出，经过预处理、感知、规划、控制，最后到执行器，中间可能经过十几个节点。每个节点都在处理、转发、变换消息。

如果每个节点都自己打log，你会遇到几个问题：

时间不同步：不同机器上的时钟可能差了几十毫秒
测量开销：打印log本身会占用CPU，影响延迟
格式不统一：张三用微秒，李四用毫秒，对起来头疼

ROS2的cli工具就是来解决这些问题的。它基于DDS的底层机制，能拿到最真实的时间戳。

核心工具：ros2 topic delay

我个人最常用的命令就是这个：

ros2 topic delay /camera/image_raw

这条命令会做什么？它会订阅指定topic，然后计算每个消息的接收时间戳和消息内部时间戳的差值。说白了，就是看消息从发布到接收，到底花了多久。

输出大概长这样：

average delay: 12.345ms
min: 8.001ms
max: 45.678ms
stddev: 3.456ms
window: 1000 messages

这里要注意几个关键指标：

指标	含义	我关注的点
average delay	平均延迟	系统整体性能的晴雨表
max delay	最大延迟	这个比平均值更重要，决定了系统会不会丢帧
stddev	标准差	抖动情况，越大说明系统越不稳定

核心观点：平均延迟好看没用，最大延迟才是自动驾驶的命门。我曾经见过一个系统平均延迟只有5ms，但偶尔会跳到200ms，结果导致控制指令晚到，车辆直接冲过了停止线。

进阶用法：测量端到端延迟

单节点的延迟好测，但端到端延迟就复杂了。比如你想知道从摄像头采集到控制指令发出，总共花了多久。

我的做法是这样的：

在源头打时间戳：在摄像头驱动节点里，给每个图像消息打上采集时间戳
在终点打时间戳：在控制节点收到消息时，记录当前时间
用ros2 topic delay对比：订阅这两个topic，计算差值

具体命令：

# 先看源头topic的时间戳
ros2 topic echo /camera/image_raw --once --field header.stamp

# 再看终点topic的时间戳
ros2 topic echo /control/cmd_vel --once --field header.stamp

但这样手动对比太慢了。我一般会写个简单的Python脚本，订阅两个topic，自动计算延迟：

import rclpy
from rclpy.node import Node
from sensor_msgs.msg import Image
from geometry_msgs.msg import Twist

class LatencyMonitor(Node):
    def __init__(self):
        super().__init__('latency_monitor')
        self.sub1 = self.create_subscription(Image, '/camera/image_raw', self.cb_image, 10)
        self.sub2 = self.create_subscription(Twist, '/control/cmd_vel', self.cb_control, 10)
        self.image_time = None
        
    def cb_image(self, msg):
        self.image_time = msg.header.stamp.sec + msg.header.stamp.nanosec * 1e-9
        
    def cb_control(self, msg):
        if self.image_time is not None:
            now = self.get_clock().now().nanoseconds * 1e-9
            delay = now - self.image_time
            self.get_logger().info(f'End-to-end delay: {delay*1000:.2f}ms')

小技巧：测量端到端延迟时，一定要确保源头和终点的时间戳是同步的。如果跨机器，建议用PTP（精确时间协议）同步时钟。我在一个项目中吃过亏，两台机器差了30ms，测出来的延迟全是负的，排查了半天才发现是时钟没同步。

可视化延迟数据

光看数字不够直观。我习惯把延迟数据实时画出来，这样一眼就能看出问题。

ROS2自带的rqt_plot就能干这个：

ros2 run rqt_plot rqt_plot /latency_monitor/delay

但说实话，rqt_plot功能有限。我更喜欢用ros2 topic delay配合tee命令把数据存下来，然后用Python画图：

ros2 topic delay /camera/image_raw --csv | tee latency_data.csv

然后写个简单的matplotlib脚本：

import pandas as pd
import matplotlib.pyplot as plt

df = pd.read_csv('latency_data.csv')
plt.plot(df['delay'])
plt.xlabel('Message index')
plt.ylabel('Delay (ms)')
plt.title('End-to-end latency over time')
plt.show()

注意：--csv参数在ROS2的某些版本中可能不支持。如果遇到这个问题，可以用ros2 topic delay的标准输出，然后自己解析。我遇到过这个坑，后来干脆写了个launch文件，自动启动延迟测量并保存日志。

实战中的避坑指南

嗯，这里我要多说几句。用cli工具测延迟，有几个常见的坑：

消息频率太高：如果topic频率超过100Hz，ros2 topic delay可能会丢消息。我建议降低采样率，或者用专门的性能测试工具。
时间戳精度：ROS2的时间戳默认是纳秒级，但有些驱动只填了秒和微秒。记得检查一下，否则测出来的延迟会偏大。
网络延迟干扰：如果节点分布在多台机器上，网络抖动会影响测量结果。我一般会在同一台机器上先测一遍，排除网络因素。

我曾经在一个项目中，发现延迟数据忽高忽低，排查了三天，最后发现是WiFi信号不稳定导致的。从那以后，我所有延迟测试都在有线网络上进行。

知识体系总览

下面这张图总结了本章的核心逻辑：

这张图把本章的内容串起来了。从左到右，先掌握工具，再理解指标，最后学会方法。三者缺一不可。

好了，关于用ros2cli工具测量延迟，就聊这么多。记住一句话：测量是优化的前提，测不准等于没测。下次遇到延迟问题，别急着改代码，先把测量搞准了再说。

可可精品资料库

📚 课程目录

延迟测量方法论：使用ros2cli工具测量端到端延迟

为什么需要专门的延迟测量工具？

核心工具：ros2 topic delay

进阶用法：测量端到端延迟

可视化延迟数据

实战中的避坑指南

知识体系总览