📚 课程目录第4章 ROS2命令行工具

ROS2 命令行工具：常用命令如 ros2 node、ros2 topic、ros2 service 等

核心原理：一切皆图，命令皆查询

ROS2 的分布式通信架构将运行中的每一个可执行程序抽象为 节点（Node），节点之间通过 话题（Topic）、服务（Service）、动作（Action） 和 参数（Parameter） 进行数据交换。命令行工具的本质，就是一套用于观测、诊断和操控这张动态计算图的“仪表盘”。与 ROS1 不同，ROS2 的命令行工具基于 Python 的 argparse 重构，所有子命令遵循统一的 ros2 <功能模块> <动词> [参数] 语法结构。理解这一层级关系，是高效使用所有命令的前提。

核心设计思想在于：节点是实体，话题是数据流管道，服务是请求-响应通道。命令行工具并不直接“连接”节点，而是通过 DDS（数据分发服务）的发现协议，在同一个 ROS_DOMAIN_ID 网络域内查询实时拓扑信息。因此，所有命令的输出都反映了当前时刻的系统状态，而非静态配置。

关键认知：ROS2 命令行的输出是“活”的。当你运行 ros2 node list 时，它通过 DDS 的发现机制向网络广播查询请求，所有活跃节点都会响应。这意味着：如果节点崩溃或网络隔离，命令输出会立即变化，这是排查分布式系统故障的重要依据。

方法流程：从查询到诊断的标准操作路径

面对一个刚启动的 ROS2 系统，推荐遵循“先看节点，再看话题，后查服务，最后调参数”的排查流程。这套流程能帮助你快速建立系统全局视图，并定位异常环节。

节点发现：运行 ros2 node list 获取当前所有活跃节点名称。若预期节点缺失，检查启动命令或 ROS_DOMAIN_ID 是否一致。
话题检查：使用 ros2 topic list -t 查看话题及其消息类型。进一步用 ros2 topic info /话题名 查看发布者和订阅者数量，判断数据流是否单向断裂。
数据验证：执行 ros2 topic echo /话题名 --once 仅监听一次消息，确认数据内容和频率是否符合预期。若需统计频率，使用 ros2 topic hz /话题名。
服务调试：通过 ros2 service list 查看可用服务。使用 ros2 service type /服务名 获取接口定义，再以 ros2 service call /服务名接口类型 "参数" 手动触发一次请求，验证服务端响应逻辑。
参数调整：用 ros2 param list 查看节点参数，ros2 param get /节点名 /参数名 读取当前值，ros2 param set /节点名 /参数名值 动态修改（仅对当前会话有效）。

实用技巧：在 ros2 topic echo 和 ros2 service call 命令后追加 --once 选项，可以避免持续阻塞终端。对于话题消息类型较复杂的情况，先运行 ros2 interface show 包名/msg/类型名 查看字段结构，再构造 echo 或 call 参数。

案例场景：机器人相机-检测-显示链路排障

假设你正在调试一个视觉巡线机器人，启动三个节点后，display_node 画面无输出。按照上述流程逐步排查：

# 1. 查看节点是否全部注册
$ ros2 node list
/camera_node
/detect_node
/display_node

# 2. 查看话题连接情况
$ ros2 topic info /image_raw
Type: sensor_msgs/msg/Image
Publisher count: 1
Subscriber count: 0    # 问题！detect_node 未订阅

# 3. 检查 detect_node 的订阅关系
$ ros2 node info /detect_node
Subscribers:
  /parameter_events: rcl_interfaces/msg/ParameterEvent
  /image_raw: sensor_msgs/msg/Image   # 实际已订阅

# 4. 重新检查话题信息（可能时序问题）
$ ros2 topic info /image_raw
Publisher count: 1
Subscriber count: 1    # 现在正常了，说明是启动顺序导致的瞬时状态

进一步验证数据流是否畅通：

# 监听检测结果话题，确认 detect_node 是否在发布
$ ros2 topic echo /detected_img --once
header:
  stamp:
    sec: 1712345678
    nanosec: 123456789
  frame_id: camera_frame
width: 640
height: 480
encoding: bgr8
step: 1920
data: [0, 0, 0, ...]    # 有数据输出，说明 detect_node 工作正常

# 若需要调整检测阈值，先查看服务接口
$ ros2 service type /detect_node/set_threshold
std_srvs/srv/SetBool

# 手动调用服务，关闭检测功能（测试用）
$ ros2 service call /detect_node/set_threshold std_srvs/srv/SetBool "{data: false}"
waiting for service to become available...
response:
success: True
message: "Detection disabled"

命令	核心用途	常用选项
`ros2 node list`	列出所有活跃节点	无
`ros2 node info <节点名>`	查看节点的订阅、发布、服务、动作	无
`ros2 topic list`	列出所有话题	`-t` 显示消息类型
`ros2 topic echo <话题>`	监听话题数据	`--once`, `--field`
`ros2 topic hz <话题>`	统计发布频率	`-w` 窗口大小
`ros2 service list`	列出所有服务	`-t` 显示服务类型
`ros2 service call`	手动调用服务	需指定服务名+类型+参数
`ros2 param get/set`	读取/修改节点参数	需指定节点名和参数名

误区与复盘：常见操作陷阱

高频误区 1：混淆节点名与可执行文件名。 ros2 node list 显示的是节点在 ROS 图中的逻辑名称（通常由 NodeOptions 或启动文件中的 node_name 指定），而非可执行文件的路径。例如，可执行文件 camera_driver 启动后，节点名可能是 /camera_node。若用错名称，ros2 node info 会报“找不到节点”。

高频误区 2：忽略 ROS_DOMAIN_ID 导致“节点消失”。 当终端 A 的 ROS_DOMAIN_ID 为 0，而终端 B 设为 1 时，两个终端中的节点互相不可见。此时 ros2 node list 只能看到本域内的节点。排查网络通信问题时，务必先确认所有终端和节点的域 ID 一致。

复盘总结：命令行工具的价值不在于单个命令的记忆，而在于建立一套假设-验证-修正的调试循环。每次执行 ros2 topic echo 或 ros2 service call 前，先问自己：我期望看到什么结果？如果结果不符，下一步该查什么？这种思维模式比记住所有命令参数更重要。建议在日常开发中，将常用命令封装成 shell 别名或脚本，例如 alias nodelist='ros2 node list'，减少重复输入，提高调试效率。