2、ROS2基础回顾：节点、话题、服务、动作、参数、命名空间、DDS通信模型

在进入micro-ROS嵌入式开发之前，必须先厘清ROS2的核心通信抽象。ROS2不是简单的进程间通信库，而是一套以DDS（Data Distribution Service）为底层总线、以“节点”为基本计算单元、以“话题/服务/动作”为交互模式的分布式机器人软件框架。理解这些概念之间的层级关系与数据流向，是后续将ROS2裁剪到MCU（微控制器）上、并通过micro-ROS桥接不同算力平台的前提。本章将系统回顾ROS2的六大核心概念，并重点剖析DDS通信模型与ROS2抽象层之间的映射关系。

上图展示了ROS2应用层与DDS底层之间的映射关系。在嵌入式场景中，micro-ROS通过 rclc 库在MCU上实现同样的抽象，但底层DDS实现被替换为更轻量的 Micro XRCE-DDS，通过Agent与上位机中的完整DDS网络桥接。理解这张图，是掌握micro-ROS架构的第一步。

2.1 节点与命名空间：ROS2的计算单元与逻辑隔离

核心原理

节点是ROS2中最基本的计算执行单元，每个节点负责完成特定的功能模块，例如读取传感器、处理激光数据、控制电机等。节点之间不直接通信，而是通过话题、服务等抽象进行交互。在ROS2中，节点具有以下特征：

• 独立性：每个节点可以独立编译、启动、停止，节点崩溃不会影响其他节点（前提是进程隔离）。
• 可组合性：多个节点可以组合成复杂的机器人系统，通过配置文件（如launch文件）统一管理。
• 生命周期：ROS2引入了managed node概念，支持配置、激活、停用等状态转换，便于系统级控制。

命名空间（Namespace）用于对节点、话题、服务等资源进行逻辑分组和隔离。例如，一个机器人有左右两个激光雷达，可以分别放在 /left_lidar 和 /right_lidar 命名空间下，话题名变为 /left_lidar/scan 和 /right_lidar/scan。命名空间避免了名称冲突，也方便在launch文件中进行批量重映射。

判断方法与操作流程

在实际开发中，判断节点是否正常工作的常用方法：

1. 使用 ros2 node list 查看当前所有活跃节点。
2. 使用 ros2 node info <node_name> 查看节点的订阅、发布、服务等详细信息。
3. 使用 ros2 topic list 和 ros2 service list 检查通信资源是否创建成功。

创建带命名空间的节点，在C++中示例：

// 创建带命名空间的节点
auto node = std::make_shared<rclcpp::Node>("lidar_node", "left_lidar");
// 此时话题名自动变为 /left_lidar/scan
auto pub = node->create_publisher<sensor_msgs::msg::LaserScan>("scan", 10);

案例拆解：多传感器命名空间规划

假设一个移动机器人平台配备2个2D激光雷达（前/后）、1个IMU、1个GPS。若不加命名空间，话题名可能为 /scan、/imu/data、/gps/fix，当需要同时运行两套算法（例如SLAM和导航）时，会产生命名冲突。通过命名空间隔离：

这样，SLAM算法可以只订阅 /front_lidar/scan，而导航算法可以同时订阅两个激光话题，互不干扰。在micro-ROS中，MCU上的节点同样可以设置命名空间，例如将电机控制器节点放在 /motor_controller 下，便于与上位机节点区分。

2.2 话题与服务：异步与同步通信的取舍

核心原理

话题（Topic）是ROS2中最常用的异步通信方式，采用发布/订阅模式。发布者（Publisher）向话题发送消息，订阅者（Subscriber）接收消息。话题适合高频、单向、持续的数据流，例如传感器数据、状态信息。服务（Service）则采用客户端/服务器模式，客户端发送请求，服务器返回响应，适合低频率、双向、需要确认的交互，例如“开启相机”“获取地图”等。

在DDS层面，话题直接映射为DDS的Topic和DataWriter/DataReader；服务则映射为DDS的Request/Reply模式，通常通过两个临时话题（service_name/request 和 service_name/reply）实现。

操作流程与代码示例

创建话题发布者（Python示例）：

import rclpy
from rclpy.node import Node
from std_msgs.msg import String

class Talker(Node):
    def __init__(self):
        super().__init__('talker')
        self.pub = self.create_publisher(String, 'chatter', 10)
        self.timer = self.create_timer(1.0, self.timer_callback)
    def timer_callback(self):
        msg = String()
        msg.data = 'Hello from ROS2'
        self.pub.publish(msg)

创建服务端（C++示例）：

#include "rclcpp/rclcpp.hpp"
#include "example_interfaces/srv/add_two_ints.hpp"

using AddTwoInts = example_interfaces::srv::AddTwoInts;

class AddServer : public rclcpp::Node {
public:
    AddServer() : Node("add_server") {
        srv_ = create_service<AddTwoInts>("add_two_ints",
            [this](const AddTwoInts::Request::SharedPtr req,
                    AddTwoInts::Response::SharedPtr res) {
                res->sum = req->a + req->b;
                RCLCPP_INFO(get_logger(), "Received: %ld + %ld", req->a, req->b);
            });
    }
private:
    rclcpp::Service<AddTwoInts>::SharedPtr srv_;
};

对比分析

2.3 动作与参数：长任务与动态配置

动作（Action）机制

动作是ROS2中用于处理长时间任务的通信模式，它结合了话题和服务的特点。动作由三部分组成：目标（goal）、反馈（feedback）、结果（result）。客户端发送目标请求，服务器执行任务并周期性地发送反馈，最终返回结果。动作适合导航、机械臂运动控制等需要实时反馈的任务。

在DDS层面，动作通过三个话题实现：action_name/goal、action_name/feedback、action_name/result，以及一个用于取消动作的服务。在micro-ROS中，动作支持相对有限，通常需要手动实现或使用简化版本。

参数（Parameter）机制

参数是ROS2中用于节点动态配置的键值对。每个节点可以声明自己的参数，并允许在运行时修改。参数底层通过服务实现（get_parameter、set_parameter），但ROS2提供了更高级的API封装。参数适合PID系数、传感器偏移量、通信波特率等需要在线调整的配置项。

参数操作示例：

# 声明参数
node.declare_parameter('pid_kp', 1.0)
node.declare_parameter('port', '/dev/ttyUSB0')

# 获取参数
kp = node.get_parameter('pid_kp').value

# 设置参数（运行时）
node.set_parameters([rclpy.parameter.Parameter('pid_kp', value=2.5)])

案例拆解：电机PID参数在线调优

在micro-ROS驱动的直流电机控制节点中，PID参数需要根据负载变化实时调整。传统做法是修改代码重新编译烧录，效率极低。通过ROS2参数机制：

1. 在MCU节点中声明 pid_kp、pid_ki、pid_kd 三个参数。
2. 上位机通过 ros2 param set /motor_controller pid_kp 2.5 动态修改。
3. MCU节点监听参数变化事件，立即更新控制算法中的PID系数。

实际效果：电机响应时间从原来的200ms缩短至80ms，且无需重新烧录固件。但需要注意，参数修改后应写入非易失性存储（如Flash），否则掉电丢失。

2.4 DDS通信模型与QoS策略

核心原理

DDS（Data Distribution Service）是OMG组织制定的分布式实时通信标准，采用以数据为中心的发布/订阅模型（DCPS）。DDS的核心优势在于：

• 全局数据空间：所有参与者共享一个逻辑上的数据空间，通过Topic标识数据。
• QoS策略：提供超过20种服务质量策略，如可靠性、持久性、生命周期、资源限制等。
• 自动发现：DDS内置发现协议，节点启动后自动发现彼此，无需手动配置IP。

ROS2选择DDS作为底层通信中间件，但为了统一API，ROS2封装了 rmw（ROS Middleware Interface）层。常见的DDS实现包括Fast DDS、Cyclone DDS、RTI Connext等。在micro-ROS中，由于MCU资源限制，使用Micro XRCE-DDS作为客户端，通过Agent与完整DDS网络桥接。

QoS策略关键参数

案例拆解：激光雷达数据QoS配置

某机器人使用2D激光雷达，扫描频率10Hz，数据量约40KB/s。在WiFi环境下传输，偶尔出现丢包。初始配置使用默认QoS（RELIABLE + KEEP_LAST(10)），导致网络拥塞时延迟增大，SLAM建图出现漂移。

优化方案：

// 设置BEST_EFFORT + KEEP_LAST(5)
rclcpp::QoS qos(rclcpp::KeepLast(5));
qos.best_effort();
auto sub = node->create_subscription<sensor_msgs::msg::LaserScan>("scan", qos, callback);

优化后，延迟降低40%，虽然偶尔丢帧，但SLAM算法本身具有容错性，整体建图质量反而提升。在micro-ROS中，由于串口带宽有限，强烈建议对高频传感器使用BEST_EFFORT策略。

2.5 常见误区与总结复盘

误区一：话题和服务混用

初学者容易在需要同步响应的场景使用话题，导致需要额外实现确认机制。正确做法：需要返回值或确认时使用服务；需要持续数据流时使用话题。

误区二：忽略命名空间对DDS的影响

命名空间在ROS2层面是逻辑隔离，但在DDS层面，话题名会拼接完整路径（如 /front_lidar/scan）。如果两个节点使用不同的命名空间但相同的相对话题名，在DDS中实际是两个不同的Topic，不会互相干扰。

误区三：QoS设置一刀切

所有话题都使用默认QoS会导致性能下降。应根据数据类型和实时性要求分别设置。例如：

• 传感器原始数据：BEST_EFFORT + KEEP_LAST(1)
• 控制指令：RELIABLE + KEEP_LAST(1)
• 地图数据：RELIABLE + TRANSIENT_LOCAL

误区四：micro-ROS中直接使用完整DDS

MCU无法运行完整DDS实现，必须使用Micro XRCE-DDS客户端。这意味着并非所有QoS策略都支持，且通信延迟比以太网环境高。在设计系统时，应预留足够的时序余量。

总结复盘

本章回顾了ROS2的六大核心概念，并建立了与DDS的映射关系。在后续micro-ROS开发中，你将反复用到这些概念：节点是代码的载体，话题是数据的高速公路，服务是可靠的指令通道，动作是复杂的任务流程，参数是灵活的配置接口，而DDS则是这一切的通信基石。理解这些抽象如何映射到MCU资源受限的环境，是掌握micro-ROS的关键。