命令行调试利器：ros2 topic 命令详解
说实话，刚接触 ROS2 那会儿，我最头疼的就是话题通信出问题。节点起来了，但数据到底发没发？频率对不对？内容有没有乱码？
后来我发现，其实 ROS2 自带的命令行工具就能解决 90% 的调试问题。今天我就把这几个压箱底的命令——list、echo、info、hz、bw、delay——掰开揉碎讲给你听。
核心观点： 这六个命令覆盖了话题调试的完整链路——从「有哪些话题」到「数据长什么样」，再到「性能指标是否达标」。掌握它们，你就能在 5 分钟内定位 80% 的话题通信问题。
1. ros2 topic list —— 先看看有哪些话题
这是最基础、也最常用的命令。每次启动系统后，我第一件事就是跑一下 ros2 topic list，看看所有活跃的话题。
ros2 topic list
# 输出示例：
/parameter_events
/rosout
/turtle1/cmd_vel
/turtle1/pose嗯，这里要注意：默认只显示话题名称。如果你想看话题类型，加个 -t 参数：
ros2 topic list -t
# 输出示例：
/parameter_events [rcl_interfaces/msg/ParameterEvent]
/rosout [rcl_interfaces/msg/Log]
/turtle1/cmd_vel [geometry_msgs/msg/Twist]
/turtle1/pose [turtlesim/msg/Pose]我的习惯： 每次新开终端，先跑 ros2 topic list -t。这样既能确认节点是否正常发布，又能一眼看到话题类型，省得后面再查。
2. ros2 topic echo —— 看看数据到底长啥样
这个命令我用的频率最高。它能实时打印话题数据，帮你验证数据内容是否正确。
ros2 topic echo /turtle1/pose
# 输出示例：
x: 5.544444561004639
y: 5.544444561004639
theta: 0.0
linear_velocity: 0.0
angular_velocity: 0.0
---为什么会用 --- 分隔？因为每条消息之间用这个做标记，方便你区分不同时刻的数据。
我曾经在一个项目中，发现机器人导航总是不对。用 echo 一看，发现 /cmd_vel 话题的线速度一直为零。排查了半天，原来是某个节点把坐标系搞反了。你说要是没有 echo，这种问题得查到什么时候？
注意： echo 会持续监听话题，直到你按 Ctrl+C 停止。如果话题频率很高（比如 100Hz），终端会刷得飞快。建议先确认频率再决定是否使用。
3. ros2 topic info —— 查户口，看谁在发谁在收
这个命令用来查看话题的发布者和订阅者信息。我把它叫做「查户口」。
ros2 topic info /turtle1/pose
# 输出示例：
Type: turtlesim/msg/Pose
Publisher count: 1
Subscription count: 2你看，它告诉你三件事：话题类型、发布者数量、订阅者数量。这在调试时特别有用——比如你发现某个话题没有数据，用 info 一看，发布者数量为 0，那问题就清楚了：没人发数据。
| 场景 | info 输出 | 可能的问题 |
|---|---|---|
| 发布者 = 0 | Publisher count: 0 | 发布节点未启动或崩溃 |
| 订阅者 = 0 | Subscription count: 0 | 订阅节点未启动或话题名拼错 |
| 类型不匹配 | Type: 不一致 | 发布者和订阅者使用了不同消息类型 |
避坑指南： 我曾经遇到过一个诡异的问题——话题明明有发布者，但订阅者就是收不到数据。用 info 一查，发现发布者和订阅者的话题类型不一样！一个用 Twist，一个用 TwistStamped。从此以后，我每次调试都会先确认类型是否一致。
4. ros2 topic hz —— 测频率，看数据稳不稳
实时系统的命脉就是频率。如果话题频率不稳定，整个系统都会出问题。hz 命令就是专门干这个的。
ros2 topic hz /turtle1/pose
# 输出示例：
average rate: 62.500
min: 0.016s max: 0.016s std dev: 0.00000s window: 62它会告诉你平均频率、最小/最大间隔时间、标准差。我个人习惯先看标准差——如果标准差很大，说明频率抖动严重，可能是 CPU 负载过高或者节点调度有问题。
实用技巧： 加 -w 100 参数可以指定统计窗口大小。比如 ros2 topic hz -w 100 /turtle1/pose 表示统计最近 100 条消息的频率。窗口越大，结果越平滑，但响应也越慢。
5. ros2 topic bw —— 算带宽，看数据量有多大
这个命令我用的相对少一些，但在排查网络瓶颈时特别管用。它能计算话题的带宽占用。
ros2 topic bw /turtle1/pose
# 输出示例：
average: 0.12KB/s
mean: 0.12KB/s
max: 0.12KB/s
min: 0.12KB/s
window: 62你想想看，如果你的机器人有几十个话题，每个话题都占用带宽，加起来可能就很大了。用 bw 可以快速定位哪些话题是「带宽大户」。
注意： bw 计算的是序列化后的数据大小，不是内存中的大小。如果你的消息包含大数组或图片，带宽可能会很高。我曾经遇到过有人把 1080p 的图片以 30Hz 发布，结果带宽直接飙到 200MB/s，把网卡都跑满了。
6. ros2 topic delay —— 算延迟，看数据实时性
这个命令比较新，ROS2 Humble 之后才稳定。它计算从发布到接收的端到端延迟。
ros2 topic delay /turtle1/pose
# 输出示例：
average delay: 0.002s
min: 0.001s max: 0.003s std dev: 0.000s window: 62说实话，这个命令在分布式系统中特别有用。比如你的机器人本体在一台电脑上，导航算法在另一台电脑上，中间走网络。用 delay 就能测出网络延迟对数据实时性的影响。
核心总结： 这六个命令构成了一个完整的调试链路——list 发现话题，info 探查详情，echo 验证内容，hz 评估频率，bw 计算带宽，delay 测量延迟。我建议你把这六个命令记在脑子里，遇到话题通信问题，按这个顺序排查一遍，基本都能找到根因。
实战组合拳：一次完整的调试过程
最后，我分享一个真实案例。有一次，我的机器人导航系统突然变得很卡顿。我是这么排查的：
- list -t：发现所有话题都在，类型也对。
- info：确认发布者和订阅者数量正常。
- echo：数据内容看起来没问题。
- hz：发现
/scan话题频率从 10Hz 掉到了 2Hz！ - bw：
/scan的带宽正常，不是数据量的问题。 - delay：延迟从 5ms 飙升到了 200ms。
最终定位到：激光雷达驱动节点的 CPU 占用率过高，导致发布频率下降。优化了驱动代码后，一切恢复正常。
你看，如果没有这些命令，我可能还在盲目地重启节点、修改参数。有了它们，5 分钟就找到了问题所在。