ROS2 常用命令工具：给系统做"体检"

01问题引入：程序跑起来就变成黑盒？ROS2 给了一个不一样的答案

先问一个几乎每个开发者都遇过的问题：程序一旦跑起来，你还剩多少手段看清它在干什么？

不管写 Java、Python 还是嵌入式 C，程序运行后的"可观测手段"翻来覆去就那么几样：

这四种手段有个共同的隐含前提：你得先知道内部结构，才能去观察它。于是出现一个尴尬局面——

ROS2 的答案：让"内部结构"本身变成可查询的公开信息

ROS2 之所以能跳出这个困境，是因为它在架构层面做了一件别家很少做的事：把"谁存在、谁和谁连着、连线上流什么"这件事，从程序内部搬到了系统层面，并规定所有组件都必须如实登记。

这份登记表就是上一课讲过的计算图（Graph）。它不是某个人画出来的文档，而是 DDS 在运行时实时维护的在场名单：每个节点一上线就自动登记自己的名字、开放了哪些话题、提供哪些服务——谁来问都一样，不区分是"自己人"还是"路过的工具"。

于是 ros2 这套 CLI 工具，本质上就是一批合法的"第三方观察者"：它以普通参与者身份加入这张图，把图里已经登记好的信息读出来给你看。

这就是 ROS2 相对传统开发方式最实质的一个优势：它把"可观测性"做进了架构，而不是靠开发者事后补日志。你可以对着一台完全陌生的机器人，不读一行源码，30 秒内问清"谁在线、谁给谁发数据、发的是什么、多快"。

横向对比：五种开发场景，各自怎么看运行中的系统

把话说准一点——不是 ROS2 在所有方面都更强。不同场景各有各的成熟手段，只是在"运行时结构可见性"这一项上，ROS2 的做法有天然优势。下面这张表按同一组维度横向摆开：

那具体怎么"看"？先认两个词

有了这两个概念，"30 秒看懂一个陌生系统"其实就是对着计算图连问四个问题：

02核心原理：ros2 的"名词域 × 动作"体系

ros2 CLI 和 git 一样是先说对象、再说动作的结构：ros2 <名词域> <动作>——先选名词域（操作什么），再给动作（怎么操作）。除六大命令族外还有 action 与执行入口一族，按职责分五组，各管计算图的一个侧面：

上表这些命令按下去，计算图里到底发生了什么？关键在于 echo / hz / info 并不侵入 talker 进程——它们以第三方订阅者/查询者身份加入计算图，拿的是 DDS 分发的同一份数据：

动画只示意了"命令如何挂到计算图上"这一步。命令敲下去究竟等多久、返回什么、失败了会怎样，得自己跑一遍才清楚。不过动手之前要先认清一个分岔：topic 与 service 用的是两种不同的通信模型——一个异步单向，一个同步等待应答。下一节用对比图把这两者讲透，再到第 04 节实操中心按四关依次练习。

03异步话题 vs 同步服务——两种通信模型的对比

不要把这节理解成"两条命令的使用技巧不同"。真正的差别在通信模型：topic 是异步单向的——发布者把消息扔进话题就完事，不关心谁收、收没收到；service 是同步一问一答的——客户端发请求后阻塞等待，直到服务端回一个响应才继续往下走。

用同一个场景对比：你想问 talker 节点"你的 use_sim_time 参数是什么"。两种模型各写一遍，看差在哪。

📋 同一个需求，两种写法对照

⏱️ 关于超时：一个无限等，一个限时等

这是初学者最容易踩的坑。同一段"等响应"的逻辑，写不写超时，行为是两回事——左边是 CLI 的做法（无限等），右边是你在程序里应该写的做法（限时等）：

if not cli.service_is_ready():
    cli.wait_for_service()
    # 服务永远不起 → 死等

ok = cli.wait_for_service(
        timeout_sec=2.0)
if not ok:
    # 2 秒后主动放弃，去处理
    return 'service 不在线'

rclpy.spin_until_future_complete(
    node, future)
# 服务不回包 → 死等

rclpy.spin_until_future_complete(
    node, future, timeout_sec=2.0)
if not future.done():
    # 超时了，主线程继续走

🧪 亲手验证：让"阻塞"和"不阻塞"肉眼可见

光看理论不会形成直觉。按下面三步做，你会亲眼看到两者的差别——这是本实验最值得做的一次对比：

# 准备：终端 A 跑 talker，终端 B 备用
ros2 run demo_nodes_cpp talker

# ① 先看 topic 的"发完就走"：终端 C
ros2 topic pub --once /chatter std_msgs/msg/String "{data: 'hello'}"
# → 瞬间返回。即使终端 B 的 listener 没开，这条命令也照样"成功"

# ② 再看 service 的"必须等到回包"：终端 C
ros2 service call /talker/get_parameters rcl_interfaces/srv/GetParameters "{names: ['use_sim_time']}"
# → 立刻返回 response: values=[false]（服务端在线，所以很快）

# ③ 关键对比：把终端 A 的 talker 杀掉，再执行 ②
# → 卡住了。屏幕停在 "waiting for service to become available..."
# → 此时 ① 依然瞬间返回。这就是异步与同步的鸿沟
# → 只能 Ctrl+C 中断：CLI 没有超时参数，它不会自己放弃

🛡️ 命令行也能限时：用 shell 的 timeout 包一层

上面第 ③ 步你只能 Ctrl+C 手动脱身。但命令行并非没有办法限时——既然 ros2 service call 自己不带超时参数，就让外层的 shell 定时器替它掐断。这是 Linux 上处理"可能卡死的命令"的标准做法，不只用于 ROS2：

# 语法：timeout [选项] 秒数 命令...
# ③ 的改进版：最多等 3 秒，超时自动杀掉
timeout 3 ros2 service call /talker/get_parameters rcl_interfaces/srv/GetParameters "{names: ['use_sim_time']}"
# → 3 秒后进程被终止，提示：Terminated
# → 终端立即回到提示符，不用手动 Ctrl+C

# 想知道"到底是超时了，还是命令自己失败"？用 --preserve-status 区分退出码
timeout --preserve-status 3 ros2 service call ...
echo $?      # 124 = 超时被杀；0 = 正常返回；其他 = 命令自身报错

# 常用选项
#   -s SIGINT   超时后发 SIGINT（相当于替你按 Ctrl+C，更温和）
#   --preserve-status  保留命令自身的退出码，便于脚本判断
#   -k 2        如果 SIGINT 不管用，2 秒后补一个 SIGKILL 强制杀

04实操中心：四关打通命令工具（点哪关练哪关）

四关按难度递进编排：第一关先在仿真终端把 02 节表格六行逐条验证（只点按钮，零门槛）；第二关学会读懂单个节点的"户口本"；第三关动手注入消息、热改参数；第四关录制回放闭环，完整带走一次现场。按顺序解锁：

# 终端 C：
ros2 node info /talker
# Publishers:
#   /chatter            ← 它往外说的话题
#   /parameter_events   ← 参数变更广播（每个节点都有）
#   /rosout             ← 日志话题（每个节点都有）
# Subscribers:
#   /parameter_events /rosout
# Service Servers:
#   /talker/describe_parameters   ← 自带参数服务器！
#   /talker/get_parameters  /talker/set_parameters ...

# 终端 C：观察
ros2 topic list -t
# /chatter [std_msgs/msg/String]  /parameter_events  /rosout
ros2 topic hz /chatter                  # average rate: 1.000 · min/max 软实时统计

# 终端 D：动手改系统
ros2 topic pub --once /chatter std_msgs/msg/String "{data: 'injected'}"
# 验证点：终端 B 的 listener 多打印一行 I heard: [injected] —— 发布者是谁它根本不关心

# 参数组三连（终端 C）
ros2 param list /talker                  # /talker  use_sim_time
ros2 param dump /talker > talker.yaml    # 导出快照（生成了 yaml 文件即成功）
ros2 param set /talker use_sim_time false # 返回 Success 即热改生效

# 终端 D：录制（跑着的 talker/listener 会一起被录下来）
ros2 bag record -a -o exp02_test        # -a=all  10~20 秒就 Ctrl+C
ros2 bag info exp02_test
# Files: exp02_test_0.db3        Duration: 12.3s
# Topic /chatter: 12 msgs    Serialization: cdr

# 关键验证：先杀掉终端 A 的 talker，再回放
ros2 bag play exp02_test                # 时间戳原样 → 终端 B 恢复打印 Hello World
ros2 bag play exp02_test --rate 2.0    # 2 倍速回放，调试效率翻倍

四关全部通过后，去下一节对照验收清单核对一遍，再到最后的命令选配台做一次反向自测（给任务 → 选命令）。

05注意事项与验收清单

• 至少开 3 个终端（talker / listener / CLI 观察位），全部正确 source
• ros2 node info /talker 能指出 Publishers / Service Servers 两大区
• topic echo、topic hz（≈1.000）、pub --once 三项全部见输出
• service call get_parameters 返回 bool_value: false type: 1
• bag record → info → play 完整闭环，回放期间 listener 持续打印

06互动：命令选配台（综合自测）

最后做一次反向自测：前三关都是"给你命令，验证输出"，这里反过来——只给排查任务，你自己挑命令。七个任务覆盖本实验全部命令组，看看还记不记得选：

07实验总结与思考题