第二章：ROS2核心概念详解——节点、话题、服务与动作
各位同学，欢迎来到第二章。上一章我们把ROS2装好了，环境也跑通了。但说实话，装好环境只是万里长征第一步。真正要开始写机器人程序，你得先搞懂ROS2的“四根柱子”——节点、话题、服务、动作。
这四个概念，我当年刚接触时也绕了好一阵子。尤其是服务和动作，长得像，用起来却完全不同。今天咱们就一次性把它们掰开揉碎，讲明白。
核心一句话：ROS2的通信机制，本质上就是“谁（节点）通过什么方式（话题/服务/动作）和谁（另一个节点）交换什么数据（消息）”。
2.1 节点（Node）——机器人系统的“小工人”
节点是什么？说白了，就是一个独立的、可执行的任务单元。
想象一下你正在搭建一个机器人。一个节点负责读取激光雷达数据，另一个节点负责做路径规划，还有一个节点负责控制电机转动。每个节点各司其职，互不干扰。
节点的特点：
- 独立性：每个节点都是一个独立的进程。一个节点挂了，其他节点还能继续跑。这一点我在项目里吃过亏——早期版本用单进程架构，一个传感器节点崩溃，整个系统就瘫了。后来改成多节点，稳得很。
- 可组合性：你可以把多个节点组合起来，形成复杂的机器人系统。就像搭积木一样。
- 命名唯一：每个节点在ROS2网络中必须有唯一的名字。我习惯用“功能_模块”的命名方式，比如
lidar_driver、path_planner。
我的小习惯：写节点时，我会在初始化时打印一句“Node [节点名] started successfully.”。调试时一眼就能看出哪个节点没起来，省去不少排查时间。
2.2 话题（Topic）——异步的“广播站”
话题是ROS2里最常用的通信方式。它的工作模式，你想想看，就像电台广播——发送者只管发，接收者只管收，双方不需要知道对方的存在。
话题的特点：
- 异步通信：发布者发布消息后，不需要等待订阅者处理。订阅者收到消息后，也不需要回复。各干各的。
- 一对多/多对多：一个话题可以有多个发布者和多个订阅者。这在传感器数据分发时特别有用——比如激光雷达数据，同时被定位模块、避障模块、建图模块订阅。
- 数据流式：适合持续更新的数据，比如传感器读数、控制指令。
我曾经在一个AGV项目里，用话题传输激光雷达数据。一开始没注意消息频率，结果定位模块处理不过来，机器人直接撞墙了。嗯，这里要注意——订阅者的处理速度一定要跟上发布者的频率，否则数据会堆积。
2.3 服务（Service）——同步的“请求-应答”
服务和话题最大的区别是什么？服务是同步的，有来有回。
你发一个请求过去，必须等对方处理完，拿到回复，才能继续往下走。这就像你打电话问客服：“我的订单到哪了？”客服查完告诉你结果，你才能挂电话。
服务的适用场景：
- 需要即时响应的操作，比如“打开摄像头”、“重置里程计”
- 偶尔触发的任务，比如“保存地图”、“校准IMU”
- 需要确认结果的操作
避坑指南：千万不要用服务传输高频数据！我曾经见过有人用服务传激光雷达数据，结果系统卡成PPT。服务是同步阻塞的，高频调用会导致严重的性能问题。高频数据请用话题。
2.4 动作（Action）——带反馈的“长任务”
动作是ROS2里最“高级”的通信方式。它解决了一个实际问题：有些任务耗时很长，你既想知道它有没有完成，又想知道它进行到哪一步了。
比如让机器人从A点走到B点。这个过程可能需要10秒钟。你不想一直干等着，但又想知道它走到哪了。这时候，动作就派上用场了。
动作的三要素：
- 目标（Goal）：你要让机器人做什么（比如“走到B点”）
- 反馈（Feedback）：机器人实时告诉你进度（比如“已走30%”）
- 结果（Result）：任务完成后的最终状态（比如“成功到达B点”）
我个人觉得，动作是ROS2相比ROS1最大的改进之一。ROS1里要实现类似功能，得自己写话题和服务来回折腾，麻烦得很。ROS2直接内置了动作机制，省心不少。
2.5 可视化通信：rqt_graph
概念讲完了，怎么验证你理解得对不对？用rqt_graph。
rqt_graph是ROS2自带的图形化工具，能实时显示系统中所有节点和它们之间的通信关系。我第一次用这个工具时，真的被震撼到了——整个系统的通信拓扑一目了然。
使用方法：
# 启动你的ROS2系统后，在另一个终端运行
rqt_graph你会看到一张图，节点是椭圆框，话题/服务/动作是箭头。箭头方向表示数据流向。如果某个节点没有连线，说明它“孤立”了——这是排查问题的好线索。
下面是我用SVG画的一张简化版rqt_graph示意图，展示了一个典型机器人系统的通信结构：
你看这张图，lidar_driver通过话题/scan把激光数据发给localization。localization算完位姿后，通过话题/odom发给path_planner。path_planner既接收服务请求/save_map，又通过动作/navigate_to_pose和action_server交互，最后通过话题/cmd_vel把速度指令发给base_controller。
每种通信方式各司其职，整个系统井井有条。这就是ROS2的设计哲学——用最合适的工具解决最合适的问题。
2.6 如何选择？一张表说清楚
| 通信方式 | 通信模式 | 是否阻塞 | 适用场景 | 典型例子 |
|---|---|---|---|---|
| 话题（Topic） | 发布-订阅 | 否（异步） | 高频数据流 | 传感器数据、控制指令 |
| 服务（Service） | 请求-应答 | 是（同步） | 即时操作 | 打开摄像头、重置里程计 |
| 动作（Action） | 目标-反馈-结果 | 否（异步但有状态） | 长时间任务 | 导航、机械臂运动 |
我的选择原则：
- 数据一直在变，且多个节点需要？→ 用话题
- 偶尔触发，需要立即知道结果？→ 用服务
- 任务耗时较长，需要知道进度？→ 用动作
好了，这一章的内容就到这里。核心概念都讲透了，下一章我们会动手写第一个ROS2节点，到时候这些概念都会用上。你先把这张表记牢，写代码时就知道该选哪个了。