3、ROS2核心概念实战：Node、Topic、Service、Action、Parameter
说实话，很多新手学ROS2，上来就被一堆术语砸晕了。节点、话题、服务、动作、参数……听着像是一堆散落的零件。但你别怕，这些东西说白了就是机器人程序之间互相沟通的几种方式。我做了这么多年导航项目，可以负责任地告诉你——搞懂这五个概念，你就掌握了ROS2的命脉。
一句话总结：ROS2的五个核心概念，就是机器人世界里五种不同的“说话方式”。
3.1 节点（Node）—— 机器人的每个“小脑”
节点是什么？说白了，节点就是ROS2里的一个可执行程序。每个节点负责一件事。比如在导航里，有专门负责定位的节点，有专门负责路径规划的节点，还有专门控制电机转动的节点。
我习惯把节点想象成公司里的员工。每个员工只干自己那摊活，但大家配合起来就能完成一个大项目。你想想看，如果让一个节点既做定位又做规划还控制电机，那代码得多乱？
💡 我的经验：刚开始写ROS2程序时，我总喜欢把所有功能塞进一个节点里。后来项目一复杂，调试起来简直想哭。记住：一个节点只做一件事，做好一件事。
创建一个节点其实很简单。用Python的话，几行代码就搞定：
import rclpy
from rclpy.node import Node
class MyNavNode(Node):
def __init__(self):
super().__init__('my_nav_node')
self.get_logger().info('导航节点已启动！')
def main(args=None):
rclpy.init(args=args)
node = MyNavNode()
rclpy.spin(node)
node.destroy_node()
rclpy.shutdown()
3.2 话题（Topic）—— 广播式的“喊话”
话题是ROS2里最常用的通信方式。它的模式是“发布-订阅”。一个节点发布消息，其他节点订阅这个消息。就像广播电台一样，谁想听谁就打开收音机。
举个例子。在Nav2里，/odom话题发布里程计数据，/scan话题发布激光雷达数据。你的定位节点订阅/odom和/scan，就能知道机器人现在在哪、周围有什么障碍物。
⚠️ 注意：话题通信是单向的、实时的。发布者只管发，不管有没有人收。我曾经在调试时发现机器人不动了，查了半天才发现是话题名拼写错了——/odom写成了/odomtry。这种坑，踩过一次就记住了。
发布话题的代码示例：
class TalkerNode(Node):
def __init__(self):
super().__init__('talker')
self.publisher = self.create_publisher(String, 'chatter', 10)
timer_period = 0.5 # 每秒发两次
self.timer = self.create_timer(timer_period, self.timer_callback)
def timer_callback(self):
msg = String()
msg.data = 'Hello, Nav2!'
self.publisher.publish(msg)
3.3 服务（Service）—— 一问一答的“打电话”
服务和话题不一样。话题是“发了就不管了”，服务是“你问我答，答完挂断”。它是同步的、一次性的。
什么时候用服务？比如你让机器人“去拿一下桌子上的水杯”。你发出请求，机器人执行完任务后给你一个回复：“拿到了”或者“没找到水杯”。这就是典型的服务模式。
在Nav2里，/navigate_to_pose就是一个服务。你告诉它目标位置，它告诉你能不能去、去了没有。
| 通信方式 | 特点 | 适用场景 |
|---|---|---|
| 话题（Topic） | 单向、实时、多对多 | 传感器数据、状态发布 |
| 服务（Service） | 双向、同步、一次应答 | 触发任务、查询状态 |
| 动作（Action） | 双向、异步、可反馈 | 长时间任务、导航、机械臂控制 |
3.4 动作（Action）—— 带进度条的“长跑”
动作是服务的升级版。服务只能给你一个最终结果，但动作可以在执行过程中不断给你反馈。比如导航到某个点，动作会告诉你“走到一半了”、“还有3米就到了”、“遇到障碍物正在绕行”。
我个人觉得，动作是ROS2里最优雅的设计。为什么？因为导航本身就是个长时间的任务，你不可能让程序卡在那里等结果。动作的“目标-反馈-结果”三件套，完美解决了这个问题。
核心机制：动作由三部分组成——Goal（目标）、Feedback（反馈）、Result（结果）。客户端发送目标，服务端执行并持续反馈，最终返回结果。
Nav2里最常用的动作就是/navigate_to_pose。你给它一个目标点，它就开始导航，一路上不断告诉你当前位置、剩余距离、预计时间。
3.5 参数（Parameter）—— 不用改代码的“旋钮”
参数是什么？就是你可以随时调整的配置项。比如机器人的最大速度、加速度、避障距离等等。你不需要改代码、重新编译，只需要在启动时或者运行时修改参数就行。
我记得有一次在现场调试，机器人跑得太快了，差点撞到人。我赶紧通过命令行把最大速度从1.0降到0.3，问题立刻解决。要是没有参数机制，我得改代码、重新编译、再烧录……想想都头大。
声明和使用参数的代码：
class ParamNode(Node):
def __init__(self):
super().__init__('param_node')
self.declare_parameter('max_speed', 0.5)
self.declare_parameter('robot_radius', 0.2)
def get_params(self):
max_speed = self.get_parameter('max_speed').value
radius = self.get_parameter('robot_radius').value
return max_speed, radius
💡 实用技巧：在Nav2里，所有参数都可以通过YAML文件配置。我习惯把不同场景的参数写成不同的文件，比如warehouse.yaml、office.yaml、outdoor.yaml。切换场景时，改个文件名就行，不用动代码。
3.6 实战：把它们串起来
光说不练假把式。我们来看一个简单的导航场景：
- 节点A（传感器节点）：发布激光雷达数据到/scan话题
- 节点B（定位节点）：订阅/scan，发布机器人位姿到/pose话题
- 节点C（导航节点）：订阅/pose，通过动作接口/navigate_to_pose接收目标点
- 节点D（控制节点）：订阅导航指令，控制电机转动
- 参数服务器：存储max_speed、goal_tolerance等配置
你看，五个核心概念全用上了。每个节点各司其职，通过话题、服务、动作、参数互相配合。这就是ROS2的设计哲学——分布式、模块化、可复用。
⚠️ 避坑指南：我曾经在项目中把所有节点都写在一个Python文件里，结果调试时根本分不清是哪个节点出了问题。后来老老实实按功能拆成多个节点，每个节点一个文件，问题定位快多了。记住：模块化不是花架子，是真能救命的。
好了，这一章的内容就到这里。ROS2的五个核心概念，说白了就是五种通信方式。你只要记住：节点是执行者，话题是广播，服务是问答，动作是带反馈的长任务，参数是可调的旋钮。搞懂这些，后面的导航实战你就有了坚实的基础。