全栈拆解开源扫地机器人：STM32+ROS2从底层驱动到SLAM导航的完整实践

1. 一台扫地机为什么值得全栈拆解

扫地机器人这个品类，市面上从几百块到几千块的机器都有，但真正把它拆开、把每一层软件硬件都讲清楚的资料并不多。大多数人接触到的要么是厂商的宣传页，要么是某个单一模块的教程——比如只讲ROS2建图，或者只讲STM32驱动电机。但一台扫地机真正有意思的地方在于，它是一个完整的机器人系统：感知、决策、控制、执行，四层全都在一个几十厘米直径的圆盘里跑起来了。

我拿到这台开源扫地机器人的时候，第一反应不是“它能扫多干净”，而是“它的软件架构是怎么分层的”。因为对于做机器人工程的人来说，扫地机是一个极佳的参考平台——它足够复杂，有激光雷达、有IMU、有编码器、有碰撞传感器、有电池管理；但它又足够收敛，不需要考虑双足平衡、不需要考虑机械臂逆运动学，所有的算法都可以聚焦在“平面移动+环境感知”这个核心问题上。

这篇文章面向的是想系统学习机器人工程的人，不管你是刚学完STM32想找个综合项目练手，还是已经在用ROS2但没机会接触底层硬件，这台扫地机都能给你一条从寄存器到导航栈的完整链路。我会按照“整体架构→核心模块拆解→实操流程→问题排查”的顺序来讲，每个环节都会说清楚为什么这么做，以及我在实操中踩过的坑。

先给一个整体印象：这台机器的硬件核心是一块STM32主控板，负责所有实时性要求高的任务——电机PID控制、编码器读取、超声波测距、电池电压采集、碰撞检测。上层跑的是ROS2 Humble，负责激光雷达数据处理、SLAM建图、路径规划、导航决策。两层之间通过串口通信，STM32上传传感器数据和里程计，ROS2下发速度指令。这个架构和工业AGV、服务机器人是同一套逻辑，只是规模缩小了。

2. 整体架构设计与分层逻辑

2.1 为什么选STM32+ROS2的双层架构

很多人一开始会想：能不能只用ROS2跑在树莓派上，所有传感器都直接接树莓派？理论上可以，但实际做下来问题很多。树莓派跑的是Linux，是非实时系统，你让它以1kHz的频率去跑电机PID，调度延迟能到几毫秒甚至几十毫秒，电机控制直接抖成筛子。而且树莓派的GPIO数量有限，要接编码器、超声波、碰撞开关、电池检测，引脚根本不够用。

所以合理的做法是分层：STM32负责硬实时任务，ROS2负责高算力任务。这个分层的边界在哪里？我的经验是——控制周期在1ms级别、对抖动敏感的任务放STM32；需要大量内存和复杂算法的任务放ROS2。具体到这台扫地机：

这个表格是我实际调试后总结的，不是拍脑袋定的。比如速度指令为什么是20Hz而不是更高？因为STM32那边PID是1ms跑一次，但速度指令是设定值，不需要每毫秒更新。20Hz意味着每50ms更新一次目标速度，对于扫地机这种低速移动平台（通常0.2-0.3m/s）完全够用。再高就是浪费串口带宽。

2.2 通信协议的设计与取舍

STM32和ROS2之间走的是串口，波特率115200。为什么不用USB？因为STM32的USB协议栈调试起来麻烦，而且扫地机内部电磁环境复杂，USB线容易受干扰。串口虽然速率低，但稳定可靠，接线简单。

协议格式我采用的是自定义帧结构：

帧头(2字节) + 长度(1字节) + 命令(1字节) + 数据(N字节) + 校验(1字节) + 帧尾(2字节)

帧头用0xAA 0x55，帧尾用0x0D 0x0A。校验用异或和。这个格式看起来简单，但有几个细节要注意：

• 长度字段包含命令+数据+校验，不包含帧头帧尾。这样解析的时候先找到帧头，读长度，再读对应字节数，最后验证帧尾。
• 数据采用小端序。STM32是小端，ROS2跑在x86上也是小端，直接memcpy就行，不用转换。
• 校验用异或而不是CRC。115200波特率下，一帧最多几十字节，异或足够检测单字节错误。CRC16当然更可靠，但计算量大，STM32那边每1ms要处理多帧，能省则省。

注意：串口通信一定要加超时机制。我一开始没加，结果STM32死机的时候ROS2那边一直等，整个导航栈卡死。后来在ROS2的串口读取节点里加了50ms超时，超时就发零速度指令，安全多了。

2.3 电源管理与复位逻辑

扫地机的电源设计比想象中复杂。电池是4节18650串联，标称14.8V，满电16.8V，欠压保护点设12V。这个电压要分三路：一路直接给电机驱动（12V以上），一路降压到5V给STM32和传感器，一路降压到3.3V给激光雷达。

这里有个坑：电机启动瞬间电流能到2A，会把14.8V拉低到12V以下，如果5V降压芯片的输入范围不够宽，STM32就会复位。我试过用LM2596，输入范围4.5-40V，没问题。但后来换成MP1584，输入范围4.5-28V，也没问题。关键是输入电容要够大，我在电机驱动电源输入端并了470uF的电解电容，复位问题就解决了。

复位逻辑方面，STM32的复位引脚接了一个RC电路，上电复位时间约10ms。另外还有一个手动复位按键，方便调试。ROS2那边没有硬件复位，只能软重启节点。

3. 核心模块拆解与实操要点

3.1 STM32端的电机控制与编码器读取

电机控制是这台扫地机最核心的底层功能。我用的是两轮差速驱动，左右各一个直流减速电机，带霍尔编码器。电机驱动芯片是TB6612，支持PWM调速和正反转。

PWM频率选的是20kHz，为什么？因为低于20kHz人耳能听到啸叫，高于20kHz虽然听不到但开关损耗大。20kHz刚好在听觉阈值以上，同时TB6612的开关损耗可以接受。PWM分辨率用TIM1的ARR设成1000，也就是占空比精度0.1%，对于扫地机足够了。

编码器读取用TIM2和TIM3的编码器模式，4倍频计数。电机减速比是1:30，编码器是11线霍尔，所以轮子转一圈的计数是：

11线 × 4倍频 × 30减速比 = 1320计数/圈

轮子直径65mm，周长204.2mm，所以每个计数对应：

204.2mm / 1320 = 0.1547mm

这个值就是里程计的分辨率。实际调试的时候，我让机器走直线1米，看编码器计数，算出来是0.1543mm，和理论值差0.3%，在可接受范围内。如果要更精确，可以实测校准。

PID控制这块，我用的是位置式PID，但做了积分限幅和输出限幅。参数是：

#define KP 0.8f #define KI 0.15f #define KD 0.05f #define INTEGRAL_MAX 500.0f #define OUTPUT_MAX 1000.0f

调参的时候先调P，让电机能响应速度指令但不过冲；再加I消除稳态误差；最后加D抑制振荡。实际调下来，P=0.8的时候电机响应快但有点抖，加了D=0.05就稳了。I不能太大，否则积分饱和会导致电机启动时猛冲。

实操心得：PID调参一定要在负载下调。空载调好的参数，装上轮子、放到地上，完全不一样。我一开始空载调P=1.2很稳，装上去之后机器直接原地转圈。后来老老实实把机器放地上，轮子接触地面，重新调。

3.2 激光雷达与ROS2的SLAM建图

激光雷达用的是常见的2D雷达，串口输出，10Hz扫描频率，360度范围，分辨率1度。数据通过串口转USB接到ROS2主机上。

ROS2这边，雷达驱动节点发布sensor_msgs/LaserScan话题。SLAM用的是slam_toolbox，配置的时候有几个关键参数：

slam_toolbox: ros__parameters: resolution: 0.05 max_laser_range: 8.0 minimum_time_interval: 0.5 transform_timeout: 0.2 map_update_interval: 2.0

resolution是地图分辨率，0.05m也就是5cm一个栅格。这个值越小地图越精细，但计算量越大。扫地机用5cm足够了，再小就是浪费。

max_laser_range设8米，但实际雷达有效距离也就6米左右，设8米是留余量。如果设太大，远处的噪声点会被当成障碍物，地图上会出现很多毛刺。

minimum_time_interval是两次扫描之间的最小时间间隔，0.5秒。这意味着如果雷达数据来得太快，SLAM会丢弃一些帧。对于扫地机这种低速平台，0.5秒足够。

建图的时候，我建议先用遥控让机器慢慢走一圈，速度控制在0.15m/s左右。太快了SLAM匹配不上，地图会重影。走的时候尽量走直线，转弯的时候慢一点，让雷达有足够的时间扫描。

注意：ROS2的transform_timeout一定要设够。我一开始设0.1秒，结果TF变换经常超时，RViz2里机器人模型一闪一闪的。后来改成0.2秒就稳了。这个参数取决于你的系统负载，负载高就设大一点。

3.3 八叉树地图与导航栈的配合

slam_toolbox输出的是2D栅格地图，但如果你要做3D导航或者避障，就需要八叉树地图。ROS2里用octomap_server可以把点云或者激光数据转成八叉树。

八叉树的好处是内存效率高，而且可以做3D碰撞检测。但扫地机是2D平面移动，八叉树其实有点大材小用。我试过用八叉树做避障，效果和2D代价地图差不多，但计算量大了一倍。所以最后我还是用2D代价地图做导航，八叉树只用来做可视化。

导航栈用的是nav2，配置了costmap_2d、planner_server、controller_server。全局规划用NavFn，局部规划用DWA。DWA的参数调了挺久：

controller_server: ros__parameters: controller_frequency: 10.0 min_vel_x: 0.0 max_vel_x: 0.3 max_vel_theta: 1.0 acc_lim_x: 0.5 acc_lim_theta: 1.5

max_vel_x设0.3m/s，这是扫地机的安全速度。再快的话，遇到障碍物刹车距离不够。acc_lim_x设0.5m/s²，意味着从0加速到0.3m/s需要0.6秒，这个加速过程比较平滑，不会让机器猛冲。

3.4 STM32与ROS2的串口通信实现

串口通信这块，STM32端我用的是中断接收+空闲中断检测帧尾。具体做法是：串口接收中断里把数据存到缓冲区，同时重置一个定时器；如果定时器超时（比如5ms没有新数据），就认为一帧接收完毕，置标志位让主循环处理。

ROS2端用pyserial库，开一个独立的线程读串口。读到的数据放到一个queue.Queue里，主节点从队列取数据解析。这样做的原因是串口读取是阻塞的，不能放在ROS2的回调里，否则会阻塞整个节点。

解析的时候要注意字节序和数据类型转换。比如STM32发过来的速度是int16，单位是mm/s，ROS2这边要转成float，单位是m/s：

speed_mm_s = struct.unpack('<h', data[0:2])[0] speed_m_s = speed_mm_s / 1000.0

<h表示小端有符号16位整数。这个格式字符一定要写对，写错了解析出来的数据完全不对。

踩坑记录：STM32的printf默认输出是GBK编码，如果直接往串口发中文，ROS2那边解析会乱码。解决办法是要么不用中文，要么在STM32端做GBK转UTF8。我后来干脆所有调试信息都用英文，省事。

4. 完整实操流程与关键环节

4.1 硬件组装与接线检查

拿到套件之后，第一步是核对物料。除了主控板、电机、雷达、电池，还要检查线材是否齐全。我遇到过少发编码器线的情况，所以这一步不能省。

接线顺序很重要，我的建议是：

1. 先接电源线，但不装电池。用万用表测各路电压，确认5V和3.3V正常。
2. 接STM32的下载线，烧录一个LED闪烁程序，确认主控能工作。
3. 接电机驱动线，烧录电机测试程序，确认两个电机都能正反转。
4. 接编码器线，用手转动轮子，看串口输出的计数是否变化。
5. 接激光雷达，用官方工具确认雷达能出数据。
6. 最后接电池，整机联调。

这个顺序的好处是每一步只引入一个新变量，出了问题容易定位。如果一上来全接好再上电，万一短路了，可能烧一片。

4.2 ROS2环境搭建与依赖安装

ROS2 Humble安装在Ubuntu 22.04上。安装步骤官方文档很详细，我说几个容易出问题的地方。

首先是软件源。官方文档会让你添加packages.ros.org的源，但国内网络环境可能访问不了。如果遇到由于没有公钥，无法验证下列签名的错误，需要先导入公钥：

sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg

然后确认/etc/apt/sources.list.d/ros2.list里的源地址是否正确。如果apt update报错获取:1 http://packages.ros.org/ros2/ubuntu jammy InRelease 错误:1，多半是网络问题，换个时间再试或者换源。

安装完ROS2之后，还需要装一些额外的包：

sudo apt install ros-humble-slam-toolbox ros-humble-navigation2 ros-humble-nav2-bringup ros-humble-octomap-server

这些包不是ROS2基础安装自带的，需要单独装。slam_toolbox做建图，navigation2做导航，octomap_server做八叉树。

4.3 固件编译与烧录

STM32固件用Keil或者PlatformIO编译。我用的是PlatformIO，因为跨平台，而且库管理方便。platformio.ini配置：

[env:genericSTM32F103RC] platform = ststm32 board = genericSTM32F103RC framework = stm32cube upload_protocol = stlink monitor_speed = 115200

编译之前要确认芯片型号和下载器配置正确。如果用的是ST-Link，upload_protocol设stlink；如果用串口下载，设serial。

烧录的时候，如果遇到Error: flash download failed，检查BOOT0和BOOT1跳线。STM32F103正常运行时BOOT0接GND，BOOT1任意。如果BOOT0接VCC，芯片会进入系统存储器启动模式，不执行用户程序。

实操心得：烧录完成后，一定要按一下复位键，或者断电重启。我有一次烧录完直接跑，结果程序没运行，查了半天发现是没复位。

4.4 建图与导航的完整流程

建图流程：

1. 启动雷达驱动：ros2 launch rplidar_ros rplidar.launch.py
2. 启动串口通信节点：ros2 run扫地机串口节点
3. 启动SLAM：ros2 launch slam_toolbox online_async_launch.py
4. 启动RViz2：rviz2，添加LaserScan和Map显示
5. 遥控机器走一圈，直到地图完整
6. 保存地图：ros2 run nav2_map_server map_saver_cli -f my_map

导航流程：

1. 启动地图服务：ros2 run nav2_map_server map_server --ros-args -p yaml_filename:=my_map.yaml
2. 启动导航栈：ros2 launch nav2_bringup navigation_launch.py
3. 在RViz2里设置初始位置和导航目标
4. 观察机器是否按规划路径移动

这里有个细节：导航启动后，机器不动，先检查/cmd_vel话题有没有数据。如果没有，说明导航栈没配置好。如果有数据但机器不动，检查串口通信节点有没有收到速度指令。

4.5 参数调优与性能验证

建图完成后，要验证地图质量。好的地图应该是墙壁笔直、角落清晰、没有重影。如果墙壁是弯的，说明里程计有累积误差，需要校准轮距和轮径。

轮距校准方法：让机器原地转10圈，看编码器算出来的角度和实际角度差多少。如果实际转了3600度，编码器算出来是3500度，说明轮距设大了，需要按比例缩小。

轮径校准方法：让机器走直线2米，看编码器算出来的距离和实际距离差多少。如果实际2米，编码器算出来1.95米，说明轮径设小了，需要按比例放大。

这两个校准做完，里程计精度能到1%以内，建图基本不会重影。

5. 常见问题与排查技巧实录

5.1 串口通信类问题

问题：ROS2收不到STM32的数据

排查步骤：

1. 确认串口设备号：ls /dev/ttyUSB*或ls /dev/ttyACM*
2. 确认波特率一致：STM32和ROS2都设115200
3. 用minicom或screen直接看串口输出，确认STM32在发数据
4. 检查ROS2节点的串口权限：sudo chmod 666 /dev/ttyUSB0
5. 检查协议解析：用print打印原始字节，看帧头帧尾对不对

问题：数据偶尔丢帧

原因通常是串口缓冲区溢出。解决办法是加大STM32的发送缓冲区，或者在ROS2端提高读取线程的优先级。

5.2 电机控制类问题

问题：电机不转

排查：

1. 用万用表测电机驱动输出，看有没有电压
2. 检查PWM信号：用示波器看TIM1的CH1和CH2有没有波形
3. 检查使能引脚：TB6612的STBY引脚要拉高
4. 检查电机线：有时候线断了但外皮看不出来

问题：电机转但方向反了

解决办法：要么在代码里把PWM占空比取反，要么把电机线对调。我建议改代码，因为改线容易搞混。

问题：电机啸叫

原因通常是PWM频率太低。把PWM频率从1kHz提到20kHz，啸叫就消失了。

5.3 SLAM与导航类问题

问题：建图重影

原因：里程计精度不够。解决办法：校准轮距和轮径，或者降低建图速度。

问题：导航时机器原地转圈

原因：局部规划器找不到可行路径。检查代价地图，看障碍物是不是把机器人包围了。如果是，调小inflation_radius。

问题：RViz2里机器人模型闪烁

原因：TF变换超时。把transform_timeout从0.1秒改成0.2秒。

问题：导航目标点无法到达

原因：全局规划器规划失败。检查目标点是不是在障碍物里面，或者目标点离机器人太远。把目标点设近一点试试。

5.4 常见问题速查表

独家避坑技巧：调试的时候，一定要把STM32的调试串口和通信串口分开。我一开始用同一个串口，结果调试信息把通信数据冲了，查了一天才发现。后来STM32用USART1发调试信息，USART2和ROS2通信，互不干扰。

6. 从这台扫地机延伸出去的学习路径

这台扫地机拆完、调通之后，你手里就有了一套完整的机器人开发环境。接下来可以往几个方向延伸：

第一个方向是换传感器。把2D雷达换成深度相机，做视觉SLAM。ROS2里用rtabmap或者orb_slam3，建出来的就是3D地图。这个方向适合想学视觉的人。

第二个方向是换底盘。把两轮差速换成四轮麦克纳姆轮，做全向移动。STM32端的PID要改成四个电机独立控制，ROS2端的运动学模型也要改。这个方向适合想学运动控制的人。

第三个方向是加机械臂。在扫地机上装一个小的机械臂，做“扫地+抓取”的复合机器人。这个方向涉及MoveIt2和手眼标定，适合想学机械臂控制的人。

第四个方向是多机协同。搞两台扫地机，用ROS2的DDS通信做多机建图和协同导航。这个方向涉及多机通信和分布式SLAM，适合想学多机器人系统的人。

我个人在实际操作中的体会是，这台扫地机最大的价值不是它本身能扫多干净，而是它提供了一个“最小完整机器人系统”的参考。你在这个平台上踩过的每一个坑——串口丢帧、PID振荡、SLAM重影、导航失败——在工业机器人、服务机器人、AGV上都会以类似的形式出现。把这些问题搞明白，再去看那些更复杂的系统，就不会觉得无从下手了。

最后再分享一个小技巧：调试的时候，养成看日志的习惯。ROS2的日志用ros2 run rqt_console rqt_console看，STM32的日志用串口助手看。两边的时间戳要对齐，这样出了问题才能定位是哪个环节的锅。我习惯在STM32的日志里加一个递增的帧号，ROS2收到之后打印出来，如果帧号不连续，就知道丢帧了。这个办法帮我省了很多排查时间。