4. ROS2核心概念精讲
在micro-ROS嵌入式机器人开发中，理解ROS2的通信架构是构建可靠系统的前提。与ROS1相比，ROS2不再依赖单一的Master节点，而是采用基于DDS（Data Distribution Service）的分布式通信机制。这种架构上的变革使得节点、话题、服务、动作、参数、命名空间与QoS策略成为开发者必须掌握的核心抽象。本章将逐一拆解这些概念的本质、适用场景与工程实践方法，并结合micro-ROS在MCU上的资源约束，给出可落地的设计建议。
4.1 节点：功能模块的载体
核心原理：节点是ROS2中最基本的计算单元，每个节点负责一个相对独立的职能，例如电机驱动、激光雷达数据采集、里程计解算或路径规划。在micro-ROS中，一个节点通常对应MCU上的一个FreeRTOS任务或一个逻辑线程。节点通过节点句柄（Node Handle）与DDS全局数据空间交互，发布或订阅话题、提供或调用服务。节点的生命周期管理（创建、配置、激活、销毁）直接影响系统的资源占用与稳定性。
工程实践要点：
- 粒度控制：在嵌入式端，节点数量不宜过多。每个节点会占用一定的内存（micro-ROS中约2-4KB RAM），建议将功能内聚的模块合并为一个节点，例如将IMU数据读取与姿态解算放在同一节点内。
- 节点命名：使用
/namespace/node_name的完整路径形式，便于在多机器人系统中区分不同设备。 - 生命周期：micro-ROS提供可编程的生命周期节点（Lifecycle Node），适用于需要明确状态机的硬件驱动，例如相机模组的初始化-激活-休眠流程。
micro_ros_init()之后检查节点句柄是否为空。由于MCU堆栈有限，节点创建失败是常见问题，建议预留至少8KB的堆空间给DDS与micro-ROS运行时。
4.2 话题：异步数据流的骨干
核心原理：话题是ROS2中最常用的通信方式，采用发布-订阅模式，支持一对多、多对一和多对多的数据分发。话题通信是异步的，发布者不等待订阅者确认，适合传感器数据流（如激光雷达点云、摄像头图像、IMU数据）等周期性或高频数据。在micro-ROS中，话题消息通过CDR序列化后经串口或WiFi传输至Agent，再由Agent桥接到DDS网络。
判断方法：当数据流是单向、持续、且不需要即时应答时，优先选择话题。例如，电机速度指令从控制器发布到执行器，编码器反馈从执行器发布到控制器，均使用话题。
| 特性 | 话题 (Topic) | 服务 (Service) | 动作 (Action) |
|---|---|---|---|
| 通信模式 | 异步发布-订阅 | 同步请求-响应 | 异步+反馈+取消 |
| 适合场景 | 传感器流、周期数据 | 一次性调用（如读取参数） | 长时任务（如导航到目标点） |
| 实时性 | 高（取决于QoS） | 中等（需等待响应） | 低（适合秒级任务） |
| MCU资源占用 | 低-中 | 低 | 高（需维护状态机） |
4.3 服务：同步请求-响应机制
核心原理：服务采用客户端-服务器模型，客户端发送请求并阻塞等待服务器返回响应。这种模式适用于需要确认结果的交互，例如“读取当前电池电压”、“重置电机编码器”、“切换传感器采样率”。在micro-ROS中，服务调用会占用当前任务直到响应返回或超时，因此必须设置合理的超时时间（通常100-500ms），避免因Agent断连导致任务永久阻塞。
操作流程：
- 在
.srv文件中定义请求与响应数据结构。 - 在节点中创建服务服务器（
create_service）或客户端（create_client）。 - 客户端调用
send_request()后，使用spin_some()或spin_until_future_complete()等待响应。 - 检查返回值与错误码，处理超时或通信失败。
4.4 动作：长任务执行的利器
核心原理：动作（Action）是ROS2为长时间运行任务设计的通信原语，它由三部分组成：目标（Goal）、反馈（Feedback）和结果（Result）。客户端发送目标后，服务器持续执行并周期性地发送反馈，最终返回结果。动作支持取消操作，适合导航、机械臂轨迹规划、自动充电对接等任务。在micro-ROS中，动作的实现需要额外的状态机管理，对MCU的RAM和Flash占用较大，建议仅在必要时使用。
案例拆解：假设我们使用micro-ROS控制一个差速驱动机器人执行“移动到指定坐标”的任务。初始现象是机器人无法在移动过程中响应急停指令。分析发现，若使用服务，客户端会阻塞等待移动完成，无法处理急停。改用动作后，服务器在移动循环中持续发布反馈（当前坐标、剩余距离），客户端可以随时发送取消请求。实际操作中，我们在feedback_callback中检测急停按钮状态，一旦触发立即调用cancel_goal()。结果对比：机器人平均响应急停时间从2.3秒降至0.2秒，且系统资源占用仅增加约6%的RAM。复盘经验：动作适用于任何需要“执行中可干预”的场景，但需注意反馈频率不宜过高（建议1-5Hz），否则会挤占话题通信带宽。
4.5 参数：运行时动态配置
核心原理：参数是ROS2中用于存储节点配置的键值对，支持整数、浮点、布尔、字符串、字节数组等类型。参数可以在节点启动时从YAML文件加载，也可以在运行时通过ros2 param set命令或服务动态修改。在micro-ROS中，参数存储在MCU的Flash或RAM中，修改后需调用set_parameters()回调函数来应用变更（如调整PID系数、修改话题发布频率）。
常见误区：很多开发者将参数用于高频变化的数据（如实时速度），这是错误的。参数适合低频配置（启动参数、校准值），高频数据应使用话题。此外，micro-ROS的参数服务默认不持久化，重启后恢复默认值，如需持久化需自行实现Flash读写。
4.6 命名空间与节点名称解析
核心原理：命名空间用于对节点、话题、服务等资源进行逻辑分组，避免多机器人或多模块之间的名称冲突。例如，机器人1的激光雷达话题为/robot1/scan，机器人2的为/robot2/scan。在micro-ROS中，命名空间通过rmw_init_options中的namespace字段设置。节点名称解析遵循ROS2的图资源命名规则：以/开头为路径，否则为相对路径。
操作流程：
- 在
micro_ros_init()前设置rmw_init_options的namespace字段。 - 创建节点时使用相对名称（如
motor_controller），系统会自动拼接为/robot1/motor_controller。 - 在Agent端配置
--ros-args -r __ns:=/robot1进行重映射。
4.7 QoS策略：通信质量的保障
核心原理：QoS（Quality of Service）策略是ROS2区别于ROS1的关键特性，它允许发布者和订阅者协商通信的可靠性、时效性和历史数据保留策略。QoS参数包括：可靠性（RELIABLE保证送达，BEST_EFFORT不重传）、持久性（TRANSIENT_LOCAL保留最近数据给后加入的订阅者）、历史记录（KEEP_LAST保留N个样本，KEEP_ALL保留全部）、截止时间（DEADLINE最大消息间隔）等。
判断方法：
- 传感器数据（IMU、激光雷达）：使用BEST_EFFORT + KEEP_LAST(1)，因为最新数据比历史数据更重要，且允许丢帧。
- 控制指令（电机速度）：使用RELIABLE + KEEP_LAST(1)，确保指令不丢失，但只保留最新指令。
- 地图数据（静态栅格）：使用RELIABLE + TRANSIENT_LOCAL，保证后连接的节点能获取完整地图。
4.8 综合设计建议与复盘
在micro-ROS项目中，合理组合上述通信原语是系统稳定运行的关键。以下是一套经过验证的设计模式：
| 通信需求 | 推荐方案 | QoS配置 | 理由 |
|---|---|---|---|
| 高频传感器（IMU 100Hz） | 话题 | BEST_EFFORT, KEEP_LAST(1) | 低延迟，允许丢帧 |
| 低频控制（电机 10Hz） | 话题 | RELIABLE, KEEP_LAST(1) | 保证指令到达 |
| 一次性配置（PID参数） | 参数 | — | 运行时修改 |
| 设备状态查询（电池电压） | 服务 | — | 同步响应 |
| 导航到目标点 | 动作 | — | 可取消、有反馈 |
常见误区总结：一是将服务用于高频数据，导致任务阻塞；二是忽略QoS匹配，发布者与订阅者策略不兼容时通信静默失败；三是在中断中调用通信API；四是节点命名不含命名空间，导致多机器人系统冲突。建议在项目初期绘制一张通信拓扑图，明确每个节点的话题、服务、动作和参数列表，并标注QoS等级，再开始编码。