📚 课程目录第3章 ROS2基础入门

3. ROS2基础入门

ROS2（Robot Operating System 2）是面向现代机器人系统的分布式通信中间件，其设计目标是在实时性、安全性、多机协同和产品化部署方面全面超越ROS1。对于嵌入式开发者而言，理解ROS2的架构与核心抽象，是打通STM32底层控制与上层智能决策的关键桥梁。本章将系统梳理ROS2的分层架构、节点/话题/服务/动作/参数五大核心概念，并重点演示命令行工具的实际操作流程，为后续STM32与ROS2的桥接开发奠定坚实的理论基础。

3.1 ROS2架构分层与设计哲学

ROS2的架构设计遵循"去中心化、实时优先、安全可靠"三大原则。与ROS1的Master中心化架构不同，ROS2采用完全分布式的DDS（Data Distribution Service）通信中间件，每个节点都内置了发现协议，无需中央调度器即可自主发现网络中的其他节点。这种设计从根本上解决了ROS1中Master单点故障导致整个系统瘫痪的问题，同时为多机器人协同提供了原生支持。

从分层角度看，ROS2自下而上分为四层：操作系统层（Linux/RTOS）、中间件层（DDS/RTPS）、ROS2客户端库层（rclcpp/rclpy）和应用层（机器人功能包）。其中，DDS层是ROS2最具革命性的设计——它负责数据的序列化、传输、发现和QoS策略管理。对于STM32开发者而言，理解DDS层至关重要，因为Micro-ROS正是通过精简的DDS实现（如Micro XRCE-DDS）让MCU能够直接参与ROS2通信。

架构层	核心组件	对STM32开发的意义
应用层	功能包、节点、launch文件	定义机器人行为逻辑，与MCU交互的入口
客户端库层	rclcpp (C++) / rclpy (Python)	提供API，STM32侧对应micro_ros_arduino库
DDS中间件层	FastDDS / CycloneDDS / RTI Connext	决定通信实时性，MCU需通过代理桥接
传输层	UDP/TCP/共享内存/串口	STM32通常使用串口或以太网接入

核心原理：ROS2的分布式发现机制基于DDS的SPDP（Simple Participant Discovery Protocol）和SEDP（Simple Endpoint Discovery Protocol）。每个节点启动时，会周期性地向组播地址发送存在公告，其他节点收到后建立点对点连接。这意味着在STM32通过串口桥接的场景中，桥接节点（如micro-ROS Agent）必须模拟完整的DDS发现流程，才能让MCU设备被上层节点感知。

3.2 五大核心概念深度解析

ROS2的通信模型建立在五个核心抽象之上：节点、话题、服务、动作和参数。这五种机制覆盖了机器人系统中从高频传感器数据流到低频控制指令、从一次性查询到长时间执行任务的全部通信需求。理解它们各自的适用场景和底层实现，是设计高效机器人软件架构的前提。

3.2.1 节点（Node）——通信的参与者

节点是ROS2中可执行的计算单元，每个节点负责特定的功能模块。在STM32开发场景中，一个典型的节点可能是"电机驱动节点"或"IMU数据采集节点"。节点通过rclcpp::Node类创建，可以同时拥有多个话题发布器、订阅器、服务端和客户端。节点名称在ROS2图中必须唯一，且支持命名空间（namespace）进行逻辑分组。

// C++ 节点创建示例
#include "rclcpp/rclcpp.hpp"
int main(int argc, char** argv) {
    rclcpp::init(argc, argv);
    auto node = std::make_shared<rclcpp::Node>("stm32_bridge");
    RCLCPP_INFO(node->get_logger(), "STM32桥接节点已启动");
    rclcpp::spin(node);
    rclcpp::shutdown();
    return 0;
}

3.2.2 话题（Topic）——异步数据流管道

话题采用发布/订阅模式，是ROS2中使用最频繁的通信方式。发布者向话题发送消息，订阅者接收消息，双方无需知道对方的存在。话题适合连续数据流，如激光雷达扫描、IMU姿态数据、编码器计数等。话题消息类型基于.msg文件定义，支持嵌套结构和数组。在STM32场景中，通常将底层传感器数据打包为自定义消息类型，通过串口桥接发布到ROS2网络。

QoS策略选择：话题的QoS（Quality of Service）设置直接影响通信可靠性。对于STM32发布的传感器数据，建议使用SensorDataQoS（BEST_EFFORT可靠性，KEEP_LAST深度5），以保证实时性；对于控制指令，应使用ServicesQoS（RELIABLE可靠性），确保指令不丢失。

3.2.3 服务（Service）——同步请求/响应

服务用于一次性请求-响应交互，适合查询状态、触发动作等场景。服务由服务端（Server）和客户端（Client）组成，客户端发送请求并阻塞等待响应。服务类型基于.srv文件定义，包含请求和响应两部分。例如，STM32节点可以提供"读取电池电压"服务，上层节点调用该服务获取当前电压值。

3.2.4 动作（Action）——可取消的长时任务

动作是ROS2中处理长时间运行任务的机制，它结合了话题和服务的特点：客户端发送目标（Goal），服务端执行过程中通过反馈话题（Feedback）持续回报进度，完成后返回结果（Result）。动作支持取消和抢占，非常适合机械臂运动规划、导航路径跟踪等场景。动作类型基于.action文件定义，包含目标、反馈和结果三部分。

3.2.5 参数（Parameter）——运行时配置

参数是节点的运行时配置项，支持整数、浮点、字符串、布尔、数组等类型。参数可以在节点启动时通过命令行设置，也可以在运行时动态修改。对于STM32开发，参数常用于配置串口波特率、PID控制系数、传感器量程等。ROS2参数系统还支持参数描述符（ParameterDescriptor），用于声明参数的类型、范围和描述信息。

通信机制	通信模式	实时性	典型应用场景	STM32侧实现
话题	异步发布/订阅	高（取决于QoS）	传感器数据流、状态广播	micro-ROS发布器
服务	同步请求/响应	中	参数查询、指令触发	micro-ROS服务端
动作	异步+反馈	低	导航、机械臂控制	需上层节点代理
参数	键值对	低	配置管理	micro-ROS参数接口

3.3 命令行工具实战操作

ROS2提供了一套完整的命令行工具，用于调试、监控和操作运行中的系统。这些工具是开发过程中排查问题的利器。以下通过一个典型的STM32桥接调试场景，演示核心命令的使用方法。

3.3.1 环境准备与工作区配置

首先需要source ROS2环境，并创建工作区。假设使用Humble版本，在Ubuntu 22.04上操作：

# 设置ROS2环境
source /opt/ros/humble/setup.bash

# 创建工作区
mkdir -p ~/ros2_stm32_ws/src
cd ~/ros2_stm32_ws
colcon build
source install/setup.bash

3.3.2 节点与话题管理命令

当STM32通过micro-ROS桥接接入后，可以使用以下命令进行系统监控：

# 查看所有活跃节点
ros2 node list
# 输出示例：/micro_ros_agent /stm32_bridge /motor_controller

# 查看节点详细信息
ros2 node info /stm32_bridge

# 列出所有话题
ros2 topic list -t
# 输出示例：
# /imu_data [sensor_msgs/msg/Imu]
# /motor_cmd [std_msgs/msg/Int16MultiArray]

# 实时查看话题数据
ros2 topic echo /imu_data --once

# 查看话题发布频率
ros2 topic hz /imu_data

常见误区：初学者常混淆ros2 topic echo和ros2 topic hz的用途。echo用于查看消息内容，hz用于测量发布频率。在调试STM32数据链路时，应先使用hz确认数据流是否稳定，再使用echo检查数据内容是否正确。如果hz显示为0，说明发布端或桥接链路存在问题。

3.3.3 服务与动作调试命令

# 列出所有服务
ros2 service list

# 调用服务（以读取电池电压为例）
ros2 service call /stm32_bridge/get_battery std_srvs/srv/Trigger

# 列出所有动作
ros2 action list

# 发送动作目标（以导航为例）
ros2 action send_goal /navigate_to_pose nav2_msgs/action/NavigateToPose "{pose: {position: {x: 1.0, y: 2.0}}}"

3.3.4 参数管理命令

# 查看节点参数
ros2 param list /stm32_bridge

# 获取特定参数值
ros2 param get /stm32_bridge serial_baudrate

# 设置参数（运行时动态修改）
ros2 param set /stm32_bridge pid_kp 1.5

# 保存参数到文件
ros2 param dump /stm32_bridge

3.4 实战案例：STM32桥接节点调试全流程

假设我们有一个基于STM32F407的移动机器人底盘，需要通过串口与ROS2系统通信。底盘固件使用micro-ROS库实现，发布编码器数据和IMU数据，同时订阅速度控制指令。以下是完整的调试流程。

背景与约束：STM32通过USART2（115200波特率）连接到一个运行ROS2的树莓派4B。系统需要实时传输电机转速（50Hz）和IMU姿态（100Hz），同时接收上层下发的线速度和角速度指令（20Hz）。由于串口带宽有限（约11.5KB/s），必须合理设计消息类型和发布频率。

初始现象：桥接节点启动后，ros2 topic hz /encoder_data显示频率仅为5Hz，远低于预期的50Hz。同时，ros2 topic echo /imu_data偶尔出现数据乱码。

分析判断过程：首先检查串口通信质量，使用stty -F /dev/ttyUSB0 115200确认波特率设置。然后通过ros2 topic hz和ros2 topic bw（带宽）命令分析数据流量。发现IMU消息类型定义过大（包含9轴原始数据+四元数+协方差矩阵），导致单条消息超过200字节，串口传输耗时过长。

实际操作步骤：

优化消息定义：将IMU消息精简为四元数+角速度（共7个float），消息大小从200字节降至28字节。
调整发布策略：在STM32端使用DMA+空闲中断接收，减少CPU占用；将编码器数据合并为批量发布（每5ms累积4个周期数据一起发送）。
修改QoS设置：将IMU话题的QoS从RELIABLE改为BEST_EFFORT，减少确认重传开销。
使用ros2 topic hz验证：修改后编码器话题稳定在50Hz，IMU话题稳定在100Hz。

结果对比与复盘：优化后系统整体通信延迟从平均15ms降至3ms，CPU占用率降低30%。关键经验是：在串口等低带宽链路上，消息设计应遵循"最小必要字段"原则，避免传输冗余数据。同时，QoS策略的选择需要根据数据特性和链路带宽综合权衡。

排障命令速查：当STM32桥接出现通信异常时，按以下顺序排查：① ros2 node list确认节点注册；② ros2 topic list确认话题创建；③ ros2 topic hz确认发布频率；④ ros2 topic echo检查数据内容；⑤ ros2 doctor进行系统级诊断。

3.5 常见误区与设计建议

在ROS2与STM32联合开发中，以下误区需要特别注意：

误区一：所有通信都使用话题。对于请求-响应型交互（如参数查询、状态读取），应使用服务而非话题，否则需要自行实现超时和错误处理机制。
误区二：忽略QoS兼容性。发布者和订阅者的QoS必须兼容，否则通信无法建立。例如，发布者使用RELIABLE，订阅者使用BEST_EFFORT，会导致连接失败。
误区三：在STM32上直接运行完整ROS2。STM32资源有限，应使用Micro-ROS或自定义轻量协议桥接，而非移植完整ROS2。
误区四：忽视参数动态修改的线程安全。当参数在运行时被修改时，需要确保回调函数中访问该参数的代码是线程安全的。

设计建议：在系统架构初期，应绘制一张通信拓扑图，明确每个节点发布/订阅的话题、提供的服务、使用的参数。这张图应包含消息类型、QoS策略、发布频率等关键信息，作为开发文档的核心部分。对于STM32侧，建议将所有通信逻辑封装在独立的通信模块中，与业务逻辑解耦，便于后续维护和复用。