2. ROS2核心概念
ROS2作为机器人操作系统的新一代中间件，其核心设计目标是在保留ROS1灵活性的同时，解决分布式系统、实时性、安全性以及多机协同等工程痛点。理解ROS2的通信原语（节点、话题、服务、动作、参数）以及图资源管理方式，是进行嵌入式端（如MCU、FPGA、Linux单板）开发的基础。本章将逐一拆解这些核心概念，并通过与ROS1的对比，帮助你在实际嵌入式项目中做出正确的架构决策。
2.1 节点与命名空间：嵌入式进程的边界
核心原理：节点是ROS2中可执行文件的最小计算单元。在嵌入式场景下，一个节点通常对应一个独立进程（Linux）或一个RTOS任务（FreeRTOS）。节点通过DDS（数据分发服务）进行通信，而命名空间则用于逻辑隔离不同机器人或不同功能模块的节点。例如，在差速驱动小车中，/robot1/imu_node 与 /robot2/imu_node 虽然使用相同的节点类型，但通过命名空间实现了数据隔离。
判断方法：在嵌入式开发中，判断节点划分是否合理，可依据以下三条准则：
- 资源独立性：每个节点应拥有独立的错误恢复能力，一个节点崩溃不应导致整个系统瘫痪。
- 通信频率匹配：高频传感器（如IMU 200Hz）与低频控制（如底盘50Hz）应分属不同节点，避免相互阻塞。
- 硬件外设归属：同一外设（如CAN总线）的驱动应封装在单一节点内，避免多节点竞争访问。
实战场景：假设你正在开发一款基于STM32的机器人底盘，通过串口与树莓派上的ROS2节点通信。此时，树莓派上的 stm32_bridge 节点负责解析串口协议，而 odometry_node 节点负责计算里程计。两者通过话题 /chassis/odom 连接。若将两者合并为一个节点，当串口数据阻塞时，里程计计算也会被延迟，导致控制周期抖动。
micro-ROS 将节点直接运行于RTOS中，但需注意内存池大小与DDS的QoS配置，避免因缓冲区溢出导致丢包。
2.2 话题与服务：异步与同步通信的选择
核心原理：话题是ROS2中最常用的异步通信方式，适用于持续数据流（如传感器数据、控制指令）。服务则采用请求-响应模式，适用于一次性任务（如校准传感器、读取固件版本）。在嵌入式系统中，话题的QoS（服务质量）策略至关重要，例如设置 BEST_EFFORT 以容忍丢包，或 RELIABLE 确保关键指令不丢失。
操作流程：在嵌入式Linux上创建话题与服务的基本流程如下：
- 使用
rclcpp或rclpy创建节点对象。 - 声明发布者或订阅者，并指定话题名称与QoS。
- 对于服务，需实现回调函数处理请求并返回响应。
- 在嵌入式交叉编译环境中，需确保DDS实现（如Fast DDS、Cyclone DDS）已正确移植。
// C++ 示例：创建话题发布者（适用于Linux单板）
#include <rclcpp/rclcpp.hpp>
#include <std_msgs/msg/float32.hpp>
class ImuPublisher : public rclcpp::Node {
public:
ImuPublisher() : Node("imu_publisher") {
publisher_ = this->create_publisher<std_msgs::msg::Float32>("/imu/temperature", 10);
timer_ = this->create_wall_timer(std::chrono::milliseconds(100), [this]() {
auto msg = std_msgs::msg::Float32();
msg.data = read_temperature();
publisher_->publish(msg);
});
}
private:
float read_temperature() { return 42.5f; }
rclcpp::Publisher<std_msgs::msg::Float32>::SharedPtr publisher_;
rclcpp::TimerBase::SharedPtr timer_;
};案例拆解：在AGV（自动导引车）中，安全急停信号必须使用服务而非话题。因为急停需要确认执行结果（是否成功制动），而话题是单向的，无法保证响应。下表对比了话题与服务在嵌入式场景中的适用性：
| 维度 | 话题（Topic） | 服务（Service） |
|---|---|---|
| 通信模式 | 异步、发布/订阅 | 同步、请求/响应 |
| 典型场景 | IMU数据、激光雷达点云 | 参数读取、舵机归零 |
| QoS要求 | 可容忍丢包（BEST_EFFORT） | 必须可靠（RELIABLE） |
| 嵌入式资源占用 | 低（无等待） | 高（需同步等待） |
2.3 动作与参数：长任务与动态配置
核心原理：动作（Action）是ROS2中用于处理长时间任务的通信原语，由目标（Goal）、反馈（Feedback）和结果（Result）三部分组成。例如，控制机械臂移动到指定位置可能需要数秒，期间需要持续反馈当前角度。参数（Parameter）则提供运行时配置能力，如调整PID控制器的Kp值，无需重新编译代码。
判断方法：当任务满足以下条件时，应使用动作而非服务：
- 任务执行时间超过1秒，且需要中途取消。
- 需要周期性反馈执行进度（如完成百分比）。
- 任务可能失败，需要返回详细的错误码。
实战场景：在无人机飞控中，/takeoff 动作包含起飞目标高度、实时高度反馈以及最终着陆状态。若使用服务，则无法在起飞过程中取消任务或获取中间高度数据。参数服务器则用于存储飞控的PID增益、最大加速度等配置，通过 ros2 param set 命令可在飞行中动态调整。
# 命令行操作参数
ros2 param list /control_node
ros2 param get /control_node Kp
ros2 param set /control_node Kp 0.85常见误区：初学者常将动作与话题混淆。动作底层虽然基于话题实现，但提供了客户端-服务器端的生命周期管理。在嵌入式端，动作服务器的实现需要额外维护状态机，若MCU资源紧张，可考虑将动作拆分为多个服务调用，但需自行处理取消逻辑。
2.4 图资源与ROS2/ROS1差异
核心原理：图资源是ROS2运行时所有节点、话题、服务、动作的实时拓扑视图。通过 ros2 graph 命令可以查看当前系统的通信关系，这对于调试嵌入式多机系统尤为重要。ROS2与ROS1的核心差异在于通信中间件：ROS1使用自定义的TCPROS/UDPROS，而ROS2基于DDS，实现了真正的分布式、去中心化通信。
对比表：下表总结了ROS2与ROS1在关键维度的差异：
| 维度 | ROS1 | ROS2 |
|---|---|---|
| 通信中间件 | TCPROS（中心化Master） | DDS（无中心节点） |
| 实时性 | 不支持硬实时 | 支持实时QoS策略 |
| 多机通信 | 需配置ROS_MASTER_URI | 自动发现（DDS Discovery） |
| 嵌入式支持 | 无官方MCU支持 | micro-ROS支持MCU |
| 安全性 | 无加密机制 | 支持DDS安全（加密/认证） |
| 进程间通信 | 仅限同一台机器 | 跨机器、跨网段 |
案例拆解：某仓储机器人项目需在三个树莓派和两个STM32上运行ROS2。在ROS1中，若Master节点宕机，整个系统瘫痪。而ROS2的DDS自动发现机制允许每个节点独立运行，即使某个单板离线，其他节点仍能继续通信。实际调试中，通过 ros2 doctor 检查网络发现状态，发现STM32上的micro-ROS节点因MTU限制无法与树莓派通信，最终通过调整DDS的 max_message_size 参数解决。