7.1 命令行工具进阶

7.1 命令行工具进阶

本节摘要：ros2 命令行是所有前六章排错现场的主角，本节把它从"会敲几条"提升到"成体系地用"：巡检类命令的标准动线、频率与带宽的实测方法、daemon 的脾气与重启时机。命令行是系统的听诊器——不需要改一行代码，就能给运行中的系统做一次完整体检。

把命令行当体检流程，而不是词典

多数人学 CLI 的方式是背命令：list、echo、info 各管什么。这种方式的天花板很明显——遇到故障时知道单词，不知道"体检顺序"。本节换一种教法：按一次标准巡检的动线组织命令，让它们从词典条目变成一套流程。流程练熟了，遇到任何陌生系统，你都有办法在五分钟内建立它的画像。

一、标准巡检动线：五步给系统画像

面对一台"不知道处于什么状态"的机器人，我按这五步走：

# 第一步：谁在跑（逻辑层全景）
ros2 node list
# /camera_driver  /lidar_driver  /planner_server ...

# 第二步：什么在流（数据层全景）
ros2 topic list
# /scan  /image_raw  /cmd_vel ...

# 第三步：流得健康吗（频率与带宽实测）
ros2 topic hz /scan
# average rate: 9.94   ← 说好 10 Hz，实测达标
ros2 topic bw /image_raw
# average bandwidth: 172.3 MB/s  ← 5.4 节的带宽算术在这里对账

# 第四步：接口与参数对不对（类型与配置查证）
ros2 interface show sensor_msgs/msg/LaserScan
ros2 param list /planner_server

# 第五步：能动能答吗（服务与动作存活检查）
ros2 service list
ros2 action list
​

五步的次序有讲究：从"存在性"（一、二步）到"健康度"（第三步）再到"正确性"（四、五步）。前两步回答"东西在不在"，第三步回答"活得好不好"，后两步回答"长得对不对"。第 6 章那个"导航没反应"的故障，用这条动线走一遍：node list 发现识别节点缺席——存在性问题，五步走了半步就收案。

图 7-1：命令行工具箱的巡检地图

二、从观察到干预：注入与顶替

巡检是被动观测，CLI 的另一半威力在主动注入——用命令行顶替真实节点，做隔离诊断。这套手法在第 1.3 与 6.2 节都露过面，这里把它总结成三条定理：

定理一：下游对注入反应正常，病灶在上游。 雷达驱动疑似没发数据时，手动 topic pub 一帧标准扫描给建图节点——地图正常生长，则建图无辜，围剿驱动。

定理二：上游健康而下游不收，病灶在中间层。 驱动正常发、下游收不到，用 2.3 节的 QoS 对照与 1.3 节的域检查断中间层。

定理三：注入要用"正确的形状"。 手动发布的消息类型、字段、QoS 都要与真实数据一致，否则你验证的是另一个系统。注入前先 interface show 确认字段，QoS 用命令行参数显式指定。

这套注入手法的价值在于把一个双变量问题拆成两个单变量问题。"驱动与建图配合不上"是双变量，任何一方都能推责；注入让双方分别单独受审，责任立刻清楚。

三、效率细节：值得养成的三个习惯

习惯一：alias 化常用长命令。把 ros2 topic hz、ros2 lifecycle get 这类高频长命令做成 shell 别名，巡检动线会快到不假思索。习惯二：--once 与 --no-arr 配合。echo 大消息（点云、图像）时加 --no-arr 折叠数组字段，加 --once 只看一帧，终端不刷屏。习惯三：关键巡检输出落盘。采样排查时段的 node list、topic hz 输出重定向进文件，与 7.4 节的 rosbag 录制一起构成"现场证据包"。

⚠️ 常见坑：daemon 缓存过期会让你在"查证问题"上浪费半小时——topic list 显示某节点还在，实际进程早死了。看到可疑的"幽灵话题"，先 ros2 daemon stop 再 start，排除观测工具自身的幻觉，再去怀疑系统。

四、巡检动线的实战演练：五分钟给陌生系统画像

流程讲完，值得带着它完整走一遍"接手陌生系统"的场景，把命令串成肌肉记忆。设想你接手一台前任留下的巡检机器人，文档缺失，只知"之前能跑"。

第一步 node list，输出里有驱动、定位、控制三类节点，但少了熟悉的建图节点——说明系统跑的是"定位复用已有地图"模式，不是建图模式，这个判断决定了后面所有检查的语境。第二步 topic list 与架构常识对照，发现 /scan 存在但 /map 不存在——静态地图话题缺席，第八步若黑屏先从这里查。第三步 hz 实测，scan 达标、odom 只有设计值的一半——底盘驱动或串口链路有问题，先记下。第四步 param list 抽查控制节点的限速参数，发现值被改成了实验性的高点——前任最后调的参数没回收，这往往就是"之前能跑"与"现在想跑好"之间的差距来源。第五步 service list 确认生命周期迁移服务健在，系统能被接管。

五步走完，系统的画像已经足够支持动手决策：恢复限速、补启地图服务、复测里程计。整个过程没有打开任何一行代码——信息全部来自系统自身的观测接口。这就是命令行动线的价值：它对任何 ROS2 系统通用，不依赖文档，不依赖前任的交接质量。

把这次演练压缩成一句话：巡检不是背命令，是带着假设去测量——每一步输出都在证实或证伪一个关于系统状态的假设。

本节要点回顾

• 巡检五步动线：存在性、数据面、健康度、正确性、能动性，次序即逻辑；
• hz 与 bw 是健康判据：频率对不上设计值、带宽超预算，都是指标级证据；
• 注入三定理把双变量问题拆成单变量：顶替上游、断中间层、用对形状；
• daemon 是观测工具也会生病，幽灵话题先重启它再查系统；
• 高频长命令做别名、大消息用折叠参数、关键输出落盘，是巡检效率的三件套。

逻辑层会巡检了。下一节给空间层装透视镜：RViz 不只是显示工具。