4、诊断工具准备：ros2 topic hz、ros2 topic delay、ros2 bag record/play，以及系统级工具perf、htop
做延迟定位，最怕什么？
最怕你连问题在哪都不知道，就开始改代码。
我见过太多团队，一上来就怀疑算法太慢、模型太大，结果折腾半天，发现是某个节点的发布频率根本没对上。所以这一章，咱们先把家伙事儿备齐。说白了，就是给你一套「听诊器」和「手术刀」。
4.1 为什么先准备工具？
你想想看，Autoware 里几十个节点在跑，消息像流水一样在管道里穿梭。哪个节点慢了？哪个话题堵了？光靠肉眼盯屏幕，盯到下班也看不出名堂。
我个人习惯是：先测量，后优化。没有数据支撑的优化，都是瞎猜。
ROS2 自带的几个命令行工具，就是最直接的测量手段。再加上系统级的 perf 和 htop，基本能覆盖 90% 的延迟问题场景。
核心思路：用 ROS2 工具定位「哪个话题/节点有问题」，用系统工具定位「为什么有问题」。
4.2 ros2 topic hz —— 看频率稳不稳
这个命令，我几乎每天都会敲几遍。它的作用很简单：统计一个话题的发布频率。
# 查看 /planning/trajectory 话题的发布频率
ros2 topic hz /planning/trajectory
# 输出示例：
# average rate: 10.002
# min: 0.098s max: 0.102s std dev: 0.00123s嗯，这里要注意：平均频率 10Hz 不代表没问题。你得看标准差和最大间隔。
我在项目中遇到过一件事：某个规划节点平均频率 10Hz，但最大间隔到了 500ms。这意味着每过几秒，就会有一次明显的卡顿。对下游的控制节点来说，这就是灾难。
我的经验：如果 std dev 超过平均间隔的 10%，就要警惕了。比如 10Hz 的话题，平均间隔 100ms，标准差超过 10ms 就说明频率不稳定。
4.3 ros2 topic delay —— 看延迟大不大
hz 看的是「发布频率」，delay 看的是「端到端延迟」。这两个概念别搞混了。
delay 命令需要你指定一个「源话题」和一个「目标话题」。它会计算同一个时间戳的消息，从源话题到目标话题花了多久。
# 查看 /sensing/lidar/pointcloud 到 /perception/object_recognition/objects 的延迟
ros2 topic delay /sensing/lidar/pointcloud /perception/object_recognition/objects
# 输出示例：
# average delay: 0.045s
# min: 0.032s max: 0.089s说白了，这就是在测量「感知管线」的延迟。如果延迟超过 100ms，那车辆看到障碍物时，实际位置已经变了。这在高速场景下非常危险。
避坑指南：我曾经发现 delay 结果异常大，排查了半天，结果是两个节点的时间戳没有同步。一个用系统时间，一个用传感器时间。所以用 delay 之前，先确认时间戳来源一致。
4.4 ros2 bag record/play —— 回放现场
有些延迟问题是偶发的，跑在路上才出现。这时候就需要 ros2 bag 了。
它的作用就像行车记录仪：把现场数据录下来，回办公室慢慢分析。
# 录制所有话题
ros2 bag record -a -o my_bag
# 回放，并指定倍速
ros2 bag play my_bag --rate 0.5
# 只回放特定话题
ros2 bag play my_bag --topics /planning/trajectory /control/command我个人习惯是：录全量数据，回放时按需过滤。因为你不确定问题出在哪个环节，录少了回头还得补跑一趟。
小技巧：回放时用 --rate 0.5 放慢一倍，配合 hz 和 delay 命令，能更清楚地看到每个节点的响应时间。
4.5 系统级工具：perf 和 htop
ROS2 工具能告诉你「哪个话题慢了」，但说不清「为什么慢」。这时候就要看系统层面了。
4.5.1 htop —— 看资源吃紧
htop 是 top 的增强版。它能直观显示 CPU 占用、内存使用、每个核的负载。
# 安装
sudo apt install htop
# 运行
htop在 Autoware 场景下，我一般关注三点：
- CPU 总占用：超过 80% 就要警惕，说明系统快饱和了
- 单个核的负载：如果某个核 100%，其他核空闲，说明有线程绑定问题
- 内存占用：持续增长可能是内存泄漏
有一次我排查延迟问题，发现感知节点 CPU 占用只有 30%，但延迟很大。用 htop 一看，好家伙，它在跟另一个进程抢同一个核。加了 taskset 绑定核心后，延迟直接降了一半。
4.5.2 perf —— 看代码在干嘛
perf 是 Linux 自带的性能分析工具。它能告诉你 CPU 时间花在了哪个函数上。
# 采样 10 秒
sudo perf record -g -p <PID> -- sleep 10
# 生成报告
sudo perf report这个工具稍微有点门槛，但非常强大。我一般用它来验证自己的猜测：
- 如果怀疑是锁竞争，看
futex相关调用 - 如果怀疑是内存拷贝，看
memcpy占比 - 如果怀疑是序列化开销，看
serialize相关函数
注意：perf 需要 root 权限。另外，采样时间不要太短，至少 10 秒以上，否则数据不具代表性。
4.6 工具使用流程图
下面这张图，是我自己总结的排查流程。每次遇到延迟问题，我就按这个顺序来：
4.7 工具对比总结
最后，我把这几个工具的核心用途整理成一张表，方便你快速查阅：
| 工具 | 用途 | 输出指标 | 典型场景 |
|---|---|---|---|
| ros2 topic hz | 检查发布频率 | 平均频率、最小/最大间隔、标准差 | 发现节点丢帧、频率抖动 |
| ros2 topic delay | 检查端到端延迟 | 平均延迟、最小/最大延迟 | 感知管线延迟、控制指令滞后 |
| ros2 bag | 录制/回放数据 | 数据完整性、时间戳一致性 | 复现偶发问题、离线分析 |
| htop | 系统资源监控 | CPU占用、内存使用、核负载 | 资源争抢、内存泄漏 |
| perf | 函数级性能分析 | 热点函数、调用栈、锁竞争 | 代码级瓶颈定位 |
我的建议：别想着一次把所有工具都用上。先跑 hz 和 delay，确认问题范围。再用 htop 看资源，最后用 perf 深挖。一步一步来，效率最高。
好了，工具备齐了。下一章咱们就真刀真枪地干——用这些工具去抓一个真实的延迟问题。