3. 核心概念

ROS2 的本质是一套分布式通信中间件，它通过六个核心概念——节点、话题、服务、动作、参数和图（Graph）——将复杂的机器人软件系统拆解为可独立开发、动态组合、灵活部署的模块集合。理解这六个概念，是掌握 ROS2 编程范式的第一道门槛。它们并非孤立存在，而是围绕“进程间通信”这一核心问题，形成了从“静态描述”到“动态交互”的完整抽象体系。本章将逐一剖析每个概念的定义、作用、适用场景，并通过对比与案例，帮助你建立对 ROS2 运行时架构的整体认知。

上图展示了 ROS2 六大核心概念之间的逻辑关系。节点是系统的“细胞”，话题、服务、动作是节点间通信的“血管”与“神经”，参数是节点的“基因配置”，而图则是观察整个系统运行状态的“仪表盘”。下面我们逐一深入剖析。

3.1 节点（Node）：系统的基本计算单元

核心原理

节点是 ROS2 中可执行文件的最小模块化单元。每个节点负责一个相对独立的计算任务，例如读取激光雷达数据、处理图像、控制电机或执行路径规划。节点通过 ROS2 客户端库（如 rclcpp、rclpy）创建，并拥有全局唯一的名称。节点内部可以包含多个回调函数、定时器、通信端点（发布器、订阅器、服务服务器等）。节点的核心价值在于进程隔离与模块复用：一个机器人系统通常由多个节点组成，它们可以运行在同一进程（通过组件容器）或不同进程、不同机器上，实现分布式部署。

判断方法或操作流程

在工程实践中，判断一个功能是否应该拆分为独立节点，可参考以下标准：

• 功能内聚性：该功能是否具有明确的输入输出边界？例如，一个“里程计节点”只负责融合轮式编码器和 IMU 数据，输出 /odom 话题。
• 生命周期独立性：该功能是否需要独立启停、崩溃后不影响其他模块？例如，相机驱动节点崩溃不应导致导航节点退出。
• 资源需求差异：该功能是否需要独立的 CPU/GPU/内存资源？例如，视觉感知节点通常需要高算力，应独立部署。

创建节点的基本流程（以 Python 为例）：

import rclpy
from rclpy.node import Node

class MyRobotNode(Node):
    def __init__(self):
        super().__init__('my_robot_node')  # 节点名称必须唯一
        self.get_logger().info('节点已启动')

def main(args=None):
    rclpy.init(args=args)
    node = MyRobotNode()
    rclpy.spin(node)  # 保持节点运行，处理回调
    node.destroy_node()
    rclpy.shutdown()

案例拆解或实战场景

假设我们要开发一个“巡逻机器人”系统。初始设计时，我们将所有功能写在一个节点中：读取激光雷达、避障、电机控制、状态上报。随着功能增加，该节点代码量超过 5000 行，且任何一处异常（如电机驱动卡死）都会导致整个程序崩溃。重构后，我们拆分为四个节点：lidar_driver（雷达驱动）、obstacle_avoidance（避障算法）、motor_controller（电机控制）、status_reporter（状态上报）。每个节点独立运行，通过话题通信。当 motor_controller 因硬件故障崩溃时，lidar_driver 和 obstacle_avoidance 依然存活，系统可以上报“电机故障”并进入安全模式。这就是节点化设计的直接收益。

常见误区或总结复盘

3.2 话题（Topic）：异步数据流的骨干通道

核心原理

话题是 ROS2 中最常用的通信方式，采用发布/订阅（Pub/Sub）模式。发布者（Publisher）向指定话题发送消息，订阅者（Subscriber）接收该话题的消息。话题通信是异步、单向、多对多的：发布者不关心谁在接收，订阅者也不关心谁在发送。这种解耦设计使得系统扩展性极强——新增一个订阅者无需修改发布者代码。话题消息类型基于 ROS2 接口定义（.msg 文件），支持内置类型（如 std_msgs/msg/String）和自定义类型。

判断方法或操作流程

选择话题通信的典型场景：

• 传感器数据流（激光雷达、相机、IMU）——高频、持续、单向。
• 状态广播（机器人位置、电池电量、任务状态）——需要多个模块同时获取。
• 日志与监控信息——无需响应，只做记录。

话题通信的关键配置参数包括：

案例拆解或实战场景

以“自动导航机器人”为例，lidar_driver 节点持续发布 /scan 话题（频率 10Hz），localization 节点订阅 /scan 和 /odom 计算位姿，planner 节点订阅位姿和目标点发布 /cmd_vel 速度指令，motor_controller 订阅 /cmd_vel 驱动电机。整个链路中，每个节点只关心自己订阅的话题，无需知道数据来源。如果我们需要增加一个“避障节点”，只需让它订阅 /scan 并发布 /cmd_vel（与 planner 竞争），或者通过优先级机制融合，无需修改其他节点。

常见误区或总结复盘

3.3 服务（Service）：同步请求-响应机制

核心原理

服务用于同步、一次性的请求-响应交互。客户端（Client）发送请求，服务端（Server）处理并返回响应。服务通信是一对多（一个服务端可服务多个客户端），但每次交互是同步阻塞的（客户端等待响应）。服务接口由 .srv 文件定义，包含请求和响应两部分。典型应用场景：查询机器人状态、触发拍照、执行一次性校准、设置参数等。

判断方法或操作流程

选择服务通信的判断标准：

• 交互是短时的（毫秒到秒级），不需要长时间反馈。
• 需要确认结果——客户端必须知道操作是否成功。
• 交互是低频的（例如每秒不超过几次）。

服务调用流程：

1. 客户端创建 ServiceClient，指定服务名称和类型。
2. 客户端调用 call() 方法发送请求，并阻塞等待。
3. 服务端收到请求，执行回调函数，返回响应。
4. 客户端收到响应，继续执行。

案例拆解或实战场景

考虑一个“机械臂抓取”系统。当视觉节点识别到目标物体后，需要请求“抓取服务”执行抓取动作。服务端 gripper_service 接收目标坐标，控制夹爪闭合，并返回成功/失败及夹取力度。由于抓取动作需要 1-2 秒完成，且客户端需要知道结果以决定下一步动作，因此使用服务通信是合适的。如果抓取过程需要持续反馈（如夹爪位置、力度变化），则应改用动作通信。

常见误区或总结复盘

3.4 动作（Action）：面向长时间任务的通信原语

核心原理

动作是 ROS2 为长时间运行、需要反馈、可取消的任务设计的通信机制。它基于话题和服务构建，但提供了更高级的语义：客户端发送目标（Goal），服务端返回反馈（Feedback）和结果（Result）。动作通信是异步的，客户端可以随时取消目标。动作接口由 .action 文件定义，包含目标、反馈、结果三部分。典型应用：导航到目标点、执行机械臂轨迹、执行房间清扫任务。

判断方法或操作流程

选择动作通信的判断标准：

• 任务耗时超过数秒，甚至数分钟。
• 需要周期性反馈（如进度百分比、当前速度）。
• 需要支持取消（如用户按下急停）。

动作服务器实现要点：

# 动作服务器回调结构
def execute_callback(self, goal_handle):
    self.get_logger().info('开始执行目标')
    for i in range(1, 11):
        # 执行任务步骤
        feedback_msg = Feedback()
        feedback_msg.progress = i * 10
        goal_handle.publish_feedback(feedback_msg)
        time.sleep(0.5)
    goal_handle.succeed()
    result = Result()
    result.success = True
    return result

案例拆解或实战场景

以“酒店送物机器人”为例，机器人需要从服务台导航到客房。使用动作通信：客户端（调度系统）发送目标点（客房位置），动作服务器（导航节点）执行路径规划与跟踪，并每 0.5 秒反馈一次进度（如“已行驶 5 米，剩余 10 米”）。如果客人取消请求或机器人电量过低，客户端可以发送取消指令，动作服务器立即停止并返回当前状态。相比服务通信，动作提供了更丰富的交互语义，且不会阻塞客户端。

常见误区或总结复盘

3.5 参数（Parameter）：节点的运行时配置中心

核心原理

参数是节点的配置项，以键值对形式存储，支持整数、浮点、字符串、布尔、数组等类型。参数可以在节点启动时通过命令行或 YAML 文件设置，也可以在运行时动态修改。ROS2 参数系统基于服务实现（每个节点提供参数服务），但对外提供了更简洁的 API。参数的核心价值在于将配置与代码分离——无需重新编译即可调整节点行为。

判断方法或操作流程

参数使用场景：

• 传感器驱动节点的配置（如雷达扫描频率、相机曝光时间）。
• 算法参数（如 PID 增益、避障距离阈值）。
• 节点运行模式（如仿真模式/真实模式）。

参数操作流程：

1. 在节点中声明参数并设置默认值。
2. 启动时通过 --ros-args -p 参数名:值 覆盖。
3. 运行时通过 ros2 param set 命令或代码动态修改。
4. 使用 ros2 param dump 导出当前参数为 YAML 文件。

案例拆解或实战场景

考虑一个“视觉检测节点”，需要配置相机曝光时间、检测阈值、模型路径。我们将这些配置设为参数：

self.declare_parameter('camera_exposure', 20.0)
self.declare_parameter('detect_threshold', 0.5)
self.declare_parameter('model_path', 'models/yolov5.pt')

在调试时，我们可以通过命令行快速调整阈值，而无需修改代码：

ros2 run vision_detector detector_node --ros-args -p detect_threshold:=0.7

这大大提升了调参效率。同时，参数系统支持参数回调，当参数被修改时，节点可以自动响应（如重新加载模型）。

常见误区或总结复盘

3.6 图（Graph）：全局拓扑的实时映射

核心原理

图是 ROS2 运行时所有节点、话题、服务、动作、参数等实体的全局拓扑视图。ROS2 采用分布式发现协议（基于 DDS），每个节点启动时自动向网络广播自己的存在，并发现其他节点及其提供的通信端点。图的概念让开发者可以实时查看系统结构、诊断通信问题、监控节点健康状态。图不是独立运行的进程，而是由每个节点的参与者（Participant）共同维护的逻辑视图。

判断方法或操作流程

图的实用操作：

• ros2 node list：列出所有在线节点。
• ros2 topic list：列出所有话题。
• ros2 node info <node_name>：查看节点的发布/订阅/服务/动作。
• rqt_graph：可视化图形界面，显示节点与话题的连接关系。

图在排障中的关键作用：

案例拆解或实战场景

在一次多机器人协同实验中，我们启动了三台机器人，每台运行 5 个节点。通过 rqt_graph 发现，机器人 A 的 /scan 话题被机器人 B 的 localization 节点订阅了——这并非预期设计。原因是所有机器人使用了相同的 ROS_DOMAIN_ID（默认 0），导致不同机器人的节点互相发现。通过为每台机器人设置不同的 ROS_DOMAIN_ID（如 1、2、3），图拓扑立即隔离，问题解决。这个案例说明，图不仅是观察工具，更是理解分布式系统行为的关键入口。

常见误区或总结复盘

3.7 综合对比与选型决策

为了帮助你在实际项目中快速选择正确的通信方式，下表总结了六种核心概念的对比：

选型决策流程：

1. 如果数据是持续产生且不需要响应，选择话题。
2. 如果交互是一次性且需要确认结果，选择服务。
3. 如果任务耗时较长且需要反馈/取消，选择动作。
4. 如果只是配置节点行为，选择参数。
5. 始终使用图来验证系统连接是否符合预期。