4、ROS2核心概念：节点、话题、服务、动作、参数的定义与通信机制

在STM32与ROS2通信实战中，理解ROS2的五大核心概念是搭建可靠机器人软件架构的前提。与ROS1相比，ROS2在通信中间件层面引入了DDS（Data Distribution Service），这使得节点间的通信不再依赖中心化的Master节点，而是采用分布式发现与点对点通信。本章将围绕节点（Node）、话题（Topic）、服务（Service）、动作（Action）和参数（Parameter）展开，重点剖析它们的定义、底层通信机制、适用场景以及在实际嵌入式联调中的选择策略。下图展示了ROS2中五大核心概念的关系与数据流向：

4.1 节点：分布式架构的最小执行单元

4.1.1 核心原理

节点是ROS2中实现特定功能的最小软件单元，每个节点负责一个相对独立的模块化任务。在STM32与ROS2通信场景中，节点通常运行在Linux主机（如树莓派、Jetson）上，通过串口或CAN与STM32交互。节点内部包含一个或多个DDS参与者（DomainParticipant），通过DDS的发现协议（SPDP/SEDP）自动发现网络中的其他节点，无需中心服务器。这种去中心化设计提高了系统的鲁棒性——即使某个节点崩溃，其他节点仍能继续通信。

4.1.2 判断方法与操作流程

在工程实践中，判断节点是否正常工作的常用方法包括：

• 命令行查询：使用 ros2 node list 查看当前活跃节点；使用 ros2 node info <node_name> 查看节点的订阅、发布、服务等详细信息。
• 日志输出：通过 rclcpp 或 rclpy 的日志系统（如 RCLCPP_INFO）输出节点心跳信息，便于定位异常。
• 可视化工具：使用 rqt_graph 动态查看节点间的连接关系，快速发现孤立节点或异常通信链路。

创建节点的标准流程（以C++为例）：

#include "rclcpp/rclcpp.hpp"
int main(int argc, char** argv) {
    rclcpp::init(argc, argv);
    auto node = std::make_shared<rclcpp::Node>("stm32_bridge_node");
    RCLCPP_INFO(node->get_logger(), "STM32 Bridge Node Started");
    rclcpp::spin(node);
    rclcpp::shutdown();
    return 0;
}

4.1.3 实战场景：STM32桥接节点的生命周期管理

在移动机器人底盘控制中，我们通常创建一个 stm32_bridge_node，负责与STM32的串口通信。该节点内部维护一个串口句柄，并周期性地向话题 /cmd_vel 订阅速度指令，同时将STM32返回的编码器数据发布到 /odom 话题。节点启动时需检查串口是否打开、参数是否合法；运行中若串口断开，节点应自动重连并输出告警日志；关闭时需释放串口资源。这种生命周期管理保证了系统的稳定性。

4.1.4 常见误区与复盘

正确做法：遵循“单一职责原则”，将不同功能拆分为独立节点，通过话题或服务解耦。例如，motor_controller_node 只负责电机PID控制，sensor_node 只负责IMU数据采集。这样每个节点都可以独立测试、升级和重启。

4.2 话题：异步数据流的骨干通道

4.2.1 核心原理

话题是ROS2中最常用的通信方式，采用发布/订阅模式，数据流向是单向的、异步的。发布者（Publisher）将消息广播到指定话题，订阅者（Subscriber）接收该话题的消息。DDS中间件负责消息的序列化、传输和反序列化，支持多种QoS策略（如可靠性、历史记录深度、时效性）。在STM32场景中，话题非常适合传输高频传感器数据（如激光雷达点云、IMU姿态、编码器里程计）和控制指令（如速度命令）。

4.2.2 操作流程与QoS选择

创建话题的流程包括：定义消息类型（.msg文件）、创建发布者/订阅者、设置QoS。关键QoS参数选择如下表：

例如，对于STM32发布的编码器数据，若使用RELIABLE策略，当网络拥塞时会导致数据积压，增加延迟；而使用BEST_EFFORT则可能丢失部分帧，但保证实时性。因此，里程计数据建议使用BEST_EFFORT，而电机使能指令必须使用RELIABLE。

4.2.3 案例拆解：/cmd_vel 话题的端到端延迟优化

在某差速驱动机器人中，cmd_vel 话题从导航节点发布到STM32桥接节点，再通过串口发送至STM32。初始测试发现，从发布到STM32执行存在约80ms延迟，导致底盘响应迟钝。通过分析，发现瓶颈在于：① 桥接节点使用RELIABLE策略，串口发送线程阻塞；② 串口波特率仅为115200，数据量较大时排队。优化措施：将 cmd_vel 订阅QoS改为BEST_EFFORT，并将串口波特率提升至460800，同时将串口写入操作放入独立线程。优化后延迟降至15ms以内，满足运动控制要求。此案例说明，话题QoS的选择直接影响端到端性能，需结合硬件链路综合考量。

4.2.4 常见误区与总结

另外，话题名称应遵循命名规范（如以 / 开头表示全局话题，使用 ~ 表示私有话题），避免命名冲突。在STM32联调时，建议使用 ros2 topic echo /topic_name 和 ros2 topic hz /topic_name 验证数据频率和内容。

4.3 服务：同步请求-响应机制

4.3.1 核心原理

服务采用客户端-服务器模型，客户端发送请求，服务器处理并返回响应，整个过程是同步的、一次性的。服务适用于需要即时确认的场景，如“开启/关闭电机”、“读取STM32固件版本”、“重置编码器”。服务通信基于DDS的请求-应答模式，底层使用临时话题实现，但用户无需关心细节。

4.3.2 操作流程与接口定义

定义服务接口使用.srv文件，例如：

# ResetEncoder.srv
---
bool success
string message

创建服务端（STM32桥接节点中）：

rclcpp::Service<custom_srvs::srv::ResetEncoder>::SharedPtr service =
    node->create_service<custom_srvs::srv::ResetEncoder>("reset_encoder",
    [](const std::shared_ptr<custom_srvs::srv::ResetEncoder::Request> req,
       std::shared_ptr<custom_srvs::srv::ResetEncoder::Response> resp) {
        // 向STM32发送重置指令
        bool ok = stm32_serial.send("RESET_ENC");
        resp->success = ok;
        resp->message = ok ? "Encoder reset OK" : "Serial send failed";
    });

4.3.3 实战场景：STM32参数读取服务

在调试阶段，我们需要远程读取STM32的PID参数。设计一个 get_pid_params 服务，请求包含空字段，响应返回Kp、Ki、Kd三个浮点数。该服务在桥接节点中实现，通过串口发送查询指令并解析返回数据。由于服务是同步的，调用方会阻塞等待响应，因此需设置合理的超时时间（如2秒），避免因串口无响应导致调用方挂起。

4.3.4 常见误区与注意事项

此外，服务调用失败时需处理异常（如超时、连接断开），建议使用 async 方式或设置超时回调，避免程序卡死。

4.4 动作：长时任务的异步管理

4.4.1 核心原理

动作（Action）是ROS2中用于处理长时任务的通信机制，它结合了话题和服务的特点：客户端发送目标（Goal），服务器执行过程中持续反馈（Feedback），最终返回结果（Result）。动作适用于导航、机械臂运动规划、自主充电等耗时操作。动作底层由三个话题和一个服务组成，但ROS2封装了这些细节，提供简单的API。

4.4.2 操作流程与状态机

动作通信包含以下关键步骤：

1. 发送目标：客户端调用 send_goal 发送目标值。
2. 接受/拒绝：服务器回调 handle_goal 决定是否接受。
3. 执行与反馈：服务器在 execute 回调中执行任务，并通过 publish_feedback 发布进度。
4. 结果返回：任务完成后，服务器返回结果，客户端在 result_callback 中处理。

动作状态机包括：PENDING、ACTIVE、SUCCEEDED、ABORTED、CANCELED等。在STM32场景中，动作可用于控制机械臂执行“抓取-放置”流程，期间持续反馈关节角度。

4.4.3 案例拆解：基于动作的STM32舵机控制

假设我们需要控制一个6自由度机械臂完成“抓取物体”任务。定义动作 ArmMove.action：目标为末端位姿，反馈为当前关节角度，结果为是否成功。服务器节点接收目标后，通过串口向STM32发送轨迹点，STM32执行插补运动并周期性返回关节角度。客户端可以实时监控反馈，并在必要时发送取消请求。此过程中，动作机制保证了任务的异步性，客户端界面不会卡顿，同时能处理中途取消等异常情况。

4.4.4 常见误区与复盘

另外，动作服务器应正确处理取消请求，在STM32执行过程中若收到取消，需发送中断指令并停止运动，防止机械臂失控。

4.5 参数：动态配置的键值存储

4.5.1 核心原理

参数是ROS2中用于存储节点配置的键值对，支持整数、浮点、布尔、字符串等类型。参数可以在节点启动时加载，也可以在运行时动态修改。参数服务器（Parameter Server）在ROS2中不再是独立进程，而是每个节点内置的参数存储，通过服务接口提供访问。在STM32联调中，参数常用于配置串口波特率、PID系数、控制周期等。

4.5.2 操作流程与动态调参

声明参数并获取值：

node->declare_parameter("serial_port", "/dev/ttyUSB0");
node->declare_parameter("baud_rate", 460800);
std::string port = node->get_parameter("serial_port").as_string();
int baud = node->get_parameter("baud_rate").as_int();

动态调参需设置回调：

rclcpp::ParameterCallbackType cb = [this](const std::vector<rclcpp::Parameter>& params) {
    for (auto& p : params) {
        if (p.get_name() == "baud_rate") {
            int new_baud = p.as_int();
            // 重新配置串口
        }
    }
};
node->set_on_parameters_set_callback(cb);

4.5.3 实战场景：PID参数在线整定

在电机速度闭环调试中，传统方法需要修改代码并重新编译。利用ROS2参数，我们可以将Kp、Ki、Kd设为参数，并通过 ros2 param set /stm32_bridge_node Kp 12.5 在线修改。桥接节点收到参数变更后，立即通过串口将新PID值下发至STM32。这样可以在机器人运行时实时调整控制效果，大幅提升调试效率。注意，参数修改后应验证STM32是否成功接收，并回读确认。

4.5.4 常见误区与总结

此外，参数应避免频繁修改（如每毫秒），否则会占用大量服务带宽。对于高频变化的配置，应使用话题传输。

4.6 通信机制对比与选型决策

为了帮助读者在实际项目中快速选择正确的通信方式，下表总结了四种通信机制的核心差异：

选型决策建议：若数据是连续产生的流（如IMU数据），选话题；若需要即时确认（如“是否开启电机”），选服务；若任务耗时且需反馈进度（如“移动到目标点”），选动作；若只是配置参数（如“设置PID”），选参数。

在实际开发中，还需注意DDS的发现延迟（通常1-2秒），在STM32上电后需等待节点发现完成再开始通信。同时，合理设置QoS的 depth 值，避免消息积压导致内存溢出。通过本章的学习，读者应能根据具体需求选择正确的通信机制，并理解其底层原理，为后续STM32与ROS2的实战开发打下坚实基础。