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

4. 命令行工具：ros2 node、ros2 topic、ros2 service、ros2 action、ros2 param 等常用命令

4.1 核心原理：ROS2 命令行工具的分层设计

ROS2 的命令行工具遵循“命令 + 动词 + 参数”的统一范式，其底层通过 ROS2 中间件（DDS）与运行中的节点进行通信。与 ROS1 不同，ROS2 的 CLI 工具不依赖中心化的 master 节点，而是直接通过 DDS 的发现协议（Discovery）在局域网内寻找话题、服务、动作等实体。这意味着即使在不同主机上运行的工具，只要处于同一 DDS 域（默认 domain ID 为 0），也能直接查看和操作远端节点。

理解 CLI 工具的关键在于区分四种通信原语：话题（Topic）是持续单向的数据流，适合传感器数据；服务（Service）是短时同步的请求-响应，适合查询或触发一次性任务；动作（Action）是长时间异步任务，支持进度反馈和取消；参数（Parameter）则是节点的可配置属性。CLI 工具正是围绕这四种原语提供了对应的查询与操作接口。

核心记忆点：所有 ros2 命令都可以通过 ros2 <command> --help 查看子命令列表，通过 ros2 <command> <verb> --help 查看具体用法。这是探索未知命令的万能钥匙。

4.2 方法流程：从查询到调试的完整命令链

在实际开发中，命令行工具的使用遵循一套典型的“先查后调”流程。下面以调试一个机器人底盘节点为例，展示完整的命令链。

4.2.1 节点与话题查询

首先使用 ros2 node list 查看当前运行的所有节点，再用 ros2 node info /node_name 查看节点的详细信息，包括其发布/订阅的话题、提供的服务等。对于话题，ros2 topic list 可以列出所有话题，ros2 topic info /topic_name 可以查看话题类型和发布/订阅者数量。

# 查看所有节点
ros2 node list
# 输出示例：
# /chassis_controller
# /odom_publisher
# /robot_state_publisher

# 查看节点详细信息
ros2 node info /chassis_controller
# 输出示例：
# Publishers:
#   /cmd_vel [geometry_msgs/msg/Twist]
#   /chassis_status [robot_msgs/msg/ChassisStatus]
# Subscribers:
#   /odom [nav_msgs/msg/Odometry]
# Services:
#   /chassis_controller/calibrate

# 查看话题实时频率
ros2 topic hz /odom
# 输出示例：
# average rate: 50.000
#   min: 0.019s max: 0.021s std dev: 0.00052s

4.2.2 服务与动作调用

当需要触发一次性操作时使用服务调用，当需要执行长时间任务时使用动作。动作命令需要指定目标值，并可以查询执行状态。

# 调用服务（校准底盘）
ros2 service call /chassis_controller/calibrate robot_msgs/srv/Calibrate "{}"

# 发送动作目标（移动1米）
ros2 action send_goal /chassis_controller/move robot_msgs/action/Move "distance: 1.0"

# 查看动作服务器列表
ros2 action list -t
# 输出示例：
# /chassis_controller/move [robot_msgs/action/Move]

4.2.3 参数动态配置

参数可以在节点启动时通过 launch 文件设置，也可以在运行时通过命令行动态修改。这在调整 PID 参数、切换算法模式等场景中非常实用。

# 获取当前参数值
ros2 param get /chassis_controller max_speed
# 输出示例：
# Double value: 1.5

# 动态修改参数（无需重启节点）
ros2 param set /chassis_controller max_speed 2.0
# 输出示例：
# Set parameter successful

# 导出所有参数到文件
ros2 param dump /chassis_controller --output-dir ./params

  调试黄金组合：在终端 A 运行 ros2 topic echo /odom 实时观察里程计数据；终端 B 运行 ros2 topic pub /cmd_vel geometry_msgs/msg/Twist "{linear: {x: 0.5}}" 手动发布速度指令；终端 C 运行 ros2 node info /chassis_controller 确认节点状态。三个终端配合即可完成大部分底盘调试工作。

4.3 案例/场景：多机协作中的命令实战

假设你正在调试一台配备激光雷达的移动机器人，需要验证雷达数据是否正常发布、SLAM 节点是否正确接收数据，并调整建图参数。以下是完整的命令操作流程。

步骤	命令	预期结果
1. 查看节点	`ros2 node list`	看到 `/lidar_node`、`/slam_toolbox`、`/rviz2` 等节点
2. 检查话题	`ros2 topic list \| grep scan`	输出 `/scan` 话题
3. 验证数据频率	`ros2 topic hz /scan`	显示约 10Hz（雷达额定频率）
4. 查看话题类型	`ros2 topic type /scan`	输出 `sensor_msgs/msg/LaserScan`
5. 检查节点连接	`ros2 node info /slam_toolbox`	确认订阅了 `/scan`，发布了 `/map`
6. 调整建图参数	`ros2 param set /slam_toolbox minimum_travel_distance 0.1`	参数设置成功，建图灵敏度提升
7. 保存参数	`ros2 param dump /slam_toolbox`	生成 `slam_toolbox.yaml` 参数文件

在步骤 3 中，如果 hz 显示频率远低于 10Hz，说明雷达数据存在丢帧或网络延迟。此时可以使用 ros2 topic bw /scan 查看话题带宽，判断是否是数据量过大导致传输瓶颈。

4.4 误区/复盘：常见错误与效率陷阱

误区一：混淆话题与服务的使用场景。新手常试图用话题实现请求-响应模式，或反过来用服务传输高频传感器数据。话题适合持续流数据（如里程计、图像），服务适合低频触发（如校准、查询状态）。若强行用服务传输 50Hz 的里程计数据，会导致大量同步阻塞，严重降低系统实时性。

误区二：忘记使用 -t 或 --type 参数。在 ros2 topic echo 或 ros2 topic pub 时，如果话题类型不明确，命令会报错。正确做法是先执行 ros2 topic type /topic_name 获取类型，再配合 --once 参数进行单次发布测试，避免持续发布干扰系统。

误区三：参数修改后未持久化。通过 ros2 param set 修改的参数仅在节点运行期间有效，节点重启后恢复默认值。正确做法是修改后立即执行 ros2 param dump 保存到 YAML 文件，并在 launch 文件中通过 --params-file 加载。

重要提醒：在运行 ros2 topic pub 或 ros2 action send_goal 时，务必确认目标话题/动作名称拼写正确。错误的话题名不会报错，而是会静默创建新话题，导致数据“发送到虚空”。建议先执行 ros2 topic list 或 ros2 action list 确认名称。

复盘：高效使用 CLI 的三个习惯。第一，善用 Tab 键自动补全，ROS2 命令支持话题名、节点名、服务名的自动补全，能显著减少拼写错误。第二，为常用命令创建 shell 别名，例如 alias nlist='ros2 node list'、alias tinfo='ros2 topic info'。第三，在调试多机系统时，始终使用 --domain-id 参数区分不同机器人，避免话题冲突。

最后需要强调的是，CLI 工具只是 ROS2 调试的起点。当系统复杂度提升后，建议结合 rqt_graph 可视化节点连接关系、ros2 doctor 检查系统健康状态、ros2 bag record 录制数据包进行离线分析。这些工具与本章介绍的 CLI 命令互补，共同构成完整的 ROS2 调试工具箱。