企业官网建设流程全解析

扫地机器人这几年从"智商税"变成"真香"，最大的分水岭其实不是吸力大小，而是它到底会不会"自己认路"。市面上能自主建图、规划路径的机器，背后都是一整套机器人工程体系在支撑：感知、定位、建图、路径规划、运动控制、任务调度，一个都不能少。而"开源扫地机器人"这个方向之所以值得单独拿出来拆，是因为它把原本锁在商业公司里的这套体系，完整地摊开在你面前——你能看到激光雷达怎么把一圈点云喂给SLAM，能看到ROS2的节点怎么把"去客厅扫"翻译成一串轮速指令，也能看到STM32怎么在毫秒级把PWM波形打到电机驱动上。这篇内容就是围绕这样一台机器做全栈拆解，从上层算法到下层固件，把每个模块"为什么这么设计""实际怎么落地""哪里最容易翻车"讲透。适合已经玩过单片机、想往机器人系统方向进阶的开发者，也适合ROS2刚入门、想找一个完整项目练手的人。读完你至少能清楚：一台扫地机器人从开机到扫完一间房，中间到底发生了什么。

1. 先搞清楚一台扫地机器人到底由哪几层构成

很多人一上来就想直接跑SLAM，结果连雷达数据都读不出来，卡在驱动层好几天。问题就出在没有先建立"分层"的概念。扫地机器人本质上是一个典型的"感知-决策-执行"闭环系统，工程上通常切成四层，每层职责清晰、接口明确，这样任何一层出问题都能快速定位。

1.1 从"扫完一间房"倒推系统分层

我们不妨从最终目标倒推。用户按下"开始清扫"，机器要完成的事是：知道自己在哪、知道房间长什么样、决定先去哪、走过去、避开障碍、把地扫了、没电了回去充电。这一串动作对应到工程实现，就是四个层次。

最上面是决策与任务层，负责"去哪扫、按什么顺序扫、什么时候回充"，它不关心电机怎么转，只关心任务状态机。往下一层是感知与建图层，激光雷达、IMU、里程计的数据在这里融合，输出地图和位姿。再往下是运动控制层，把"向前走0.3米"翻译成左右轮的转速。最底层是执行与驱动层，也就是STM32这类MCU干的活：读编码器、输出PWM、采集电池电压、处理碰撞传感器。

这四层的划分不是学术洁癖，而是有非常现实的工程理由。上层算法跑在Linux上，用的是Python或C++，迭代快但实时性一般；下层固件跑在MCU上，用C语言，实时性强但开发慢。把两者解耦，你改路径规划算法的时候完全不用碰固件，刷固件的时候也不会影响上层逻辑。这就是为什么几乎所有开源扫地机器人项目都采用"上位机+下位机"的架构。

1.2 上位机与下位机的职责边界怎么划

边界划在哪里，是新手最容易纠结的问题。我见过有人把PID闭环放在树莓派上跑，结果控制周期抖动到几十毫秒，轮子走起来一顿一顿；也见过有人把SLAM往STM32上塞，那基本是自找苦吃。

比较稳妥的划法是：凡是要求控制周期稳定在1ms~10ms级别的，全部下沉到MCU。具体包括：

• 电机速度闭环（PID或PI），周期1ms~5ms
• 编码器脉冲计数与速度解算
• IMU原始数据读取与初步滤波
• 电池电压、电流采样
• 碰撞、悬崖、防跌落传感器扫描
• 与上位机的串口/USB通信协议解析

而凡是涉及复杂计算、需要大量内存、迭代频繁的，全部放在上位机：

• 激光雷达点云处理与SLAM
• 代价地图构建与路径规划
• 全局任务调度与状态机
• 与手机App或云端的通信
• 地图存储与回充路径计算

这条边界一旦定下来，两边的接口就非常清晰了：上位机往下发"目标线速度+角速度"，下位机往上回"当前实际速度+里程计增量+传感器状态"。就这么简单，别搞复杂。

1.3 为什么这套架构天然适合ROS2

ROS2相比ROS1最大的变化是去掉了Master节点，改用DDS做通信中间件。这个改动对扫地机器人这种"多传感器+多执行器+需要实时性"的场景简直是量身定做。

在ROS1时代，所有节点都要先连上roscore，一旦roscore挂了整个系统就瘫了。扫地机器人在运行中如果通信中枢出问题，机器可能直接失控撞墙。ROS2的DDS是分布式的，节点之间直接发现、直接通信，没有单点故障。而且DDS支持QoS（服务质量）配置，你可以给激光雷达数据配"尽力而为"策略（丢几帧无所谓），给电机控制指令配"可靠传输"策略（一帧都不能丢）。这种细粒度的通信控制，在ROS1里是做不到的。

另外ROS2原生支持实时内核和多线程执行器，配合ros2_control框架，可以把控制循环跑在独立线程里，避免被SLAM的大计算量阻塞。这些都是扫地机器人这种"既要算又要控"的场景非常需要的特性。

2. 感知层：激光雷达、IMU和里程计怎么拧成一股绳

感知层是整个系统的眼睛和耳朵。扫地机器人最核心的传感器就三个：激光雷达（LDS）、IMU、轮式里程计。单看每一个都不难，难的是把它们的数据在时间上和空间上对齐，否则SLAM出来的地图会重影、会漂移。

2.1 激光雷达选型与数据接入的坑

开源项目里最常见的雷达是RPLIDAR系列和思岚的A系列，价格从几百到上千不等。选型时别只看"测距范围"，真正影响扫地机器人体验的是扫描频率和角分辨率。扫地机器人移动速度一般在0.2~0.3m/s，如果雷达扫描频率只有5Hz，机器人在两次扫描之间已经移动了4~6厘米，建图时就会出现明显的"锯齿"。

我一般建议选扫描频率10Hz以上、角分辨率1度以内的雷达。这个规格下，机器人在典型速度下每帧之间的位移小于3厘米，配合里程计做插值，建图质量就够用了。

数据接入方面，雷达通常走串口或USB转串口。这里有个经典坑：USB转串口的芯片选型。CH340便宜但驱动在某些内核版本下不稳定，CP2102和FT232相对靠谱。如果雷达数据偶尔丢包、时间戳跳变，先怀疑是不是USB转串口芯片的问题，换个FT232的模块往往就好了。

雷达数据进ROS2后，一般通过urg_node或厂商提供的ROS2驱动包发布为sensor_msgs/LaserScan话题。这里要注意frame_id的设置，必须和URDF里雷达的link名字一致，否则TF树对不上，RViz2里什么都看不到。

2.2 IMU的作用被严重低估了

很多新手觉得扫地机器人在地上跑，IMU可有可无。这是大错特错。轮式里程计有一个致命缺陷：打滑。机器人在地毯边缘、门槛、或者急转弯时，轮子转的圈数和实际位移对不上，纯靠里程计推算位姿，几十秒就能漂出几十厘米。

IMU提供的是角速度和加速度，它的优势是短期精度高、不受打滑影响。把IMU的角速度和里程计的角度变化做融合，能显著抑制旋转方向的漂移。具体做法通常是用扩展卡尔曼滤波（EKF），ROS2里现成的包是robot_localization，配置好ekf_node，把odom和imu两个话题喂进去，它就会输出融合后的odom。

配置EKF时有几个参数必须调：

注意：IMU的安装方向必须和URDF里定义的一致，否则融合出来的yaw角会反向。装好后先静止看/imu/data的角速度是否接近0，再手动转动机器人看符号对不对。

2.3 里程计标定：一个被跳过的关键步骤

里程计标定是那种"不做也能跑，但做了精度翻倍"的步骤。核心就两个参数：轮子直径和轮距。这两个值如果和实际不符，机器人走直线会画弧，转90度会转成80度或100度。

标定方法很土但很有效：让机器人直走3米，量实际走了多少，算出比例系数修正轮径；让机器人原地转10圈，看实际转了多少度，修正轮距。ROS2里可以用ros2 topic echo /odom记录数据，也可以用现成的标定脚本。

我踩过的坑是：轮径标定和轮距标定会互相影响。如果先标轮径再标轮距，轮距标完后轮径可能又偏了。正确做法是迭代两到三轮，直到直行和转向误差都在2%以内。别嫌麻烦，这一步省下来的时间，后面调SLAM时会加倍还回去。

3. 建图与定位：SLAM在扫地机器人上的真实表现

SLAM是扫地机器人的灵魂，也是开源项目里最容易"看起来能跑，实际一塌糊涂"的部分。这里不堆公式，只讲工程上真正影响效果的东西。

3.1 为什么选Cartographer而不是Gmapping

ROS2生态里主流的2D SLAM方案有Cartographer、SLAM Toolbox和Gmapping（ROS2版本较少）。扫地机器人场景我一般推荐Cartographer或SLAM Toolbox，原因如下。

Gmapping是基于粒子滤波的，它的计算量随粒子数增长，而且没有回环检测，走一圈回到起点时地图会错位。扫地机器人在一个房间里来回扫，回环是必然发生的，没有回环检测地图就废了。

Cartographer用图优化，支持回环检测，而且有**子图（submap）**机制，适合大场景。SLAM Toolbox是ROS2原生方案，配置简单，支持在线和离线建图，对新手更友好。两者都能用，我的建议是：先跑通SLAM Toolbox，理解建图流程后再上Cartographer调优。

3.2 建图质量差，八成是这三个原因

建图出现重影、墙壁变厚、直角变圆角，别急着怀疑算法，先查这三项：

第一，时间同步。雷达和里程计的时间戳如果不同步，融合时就会错位。ROS2里可以用message_filters做时间对齐，或者确保所有传感器都用同一时钟源。如果雷达驱动的时间戳用的是雷达内部时钟，而里程计用的是系统时钟，两者差几百毫秒，地图必重影。

第二，TF树配置错误。TF树是ROS2里描述坐标系关系的核心机制。扫地机器人典型的TF链是：map -> odom -> base_link -> laser。其中map -> odom由SLAM节点发布，odom -> base_link由里程计发布，base_link -> laser由URDF静态发布。任何一环断了或方向错了，RViz2里地图就会乱飘。

第三，运动速度过快。前面说过，雷达扫描频率决定了最大安全速度。如果建图时机器人跑太快，两帧之间位移过大，匹配算法就找不到对应关系。建图阶段建议把速度限制在0.15m/s以内，建完图再放开。

3.3 定位丢失后的恢复策略

扫地机器人运行中定位丢失是常事，比如被人抱起来、被卡住后手动挪动。好的系统要能自动恢复，而不是直接罢工。

恢复策略分三步：检测、重定位、验证。检测靠监控SLAM输出的位姿协方差，协方差突然变大说明定位不确定。重定位可以用AMCL（自适应蒙特卡洛定位），在已知地图上撒粒子重新找位置。验证则是让机器人小范围移动，看新观测和地图是否匹配。

ROS2里AMCL是现成的包，配置好amcl节点，订阅/scan和/map，发布/amcl_pose。关键参数是initial_pose和粒子数，粒子数太少重定位慢，太多吃CPU。一般设500~2000个粒子比较平衡。

4. 导航与路径规划：从"知道在哪"到"知道怎么走"

有了地图和定位，下一步就是规划路径。ROS2的导航框架是Nav2，它把路径规划拆成了全局规划和局部规划两层，这个设计非常值得理解。

4.1 全局规划与局部规划的分工

全局规划负责"从当前位置到目标点，走哪条路最近最合理"，它用的是静态地图，不考虑动态障碍。常用算法是A*、Dijkstra或Smac。全局规划出来的是一条粗略的路径。

局部规划负责"沿着全局路径走，遇到障碍怎么绕"，它用的是实时传感器数据构建的局部代价地图。常用算法是DWA（动态窗口法）或TEB。局部规划输出的是实时的速度指令。

这个分工的好处是：全局规划保证"大方向对"，局部规划保证"不撞墙"。扫地机器人清扫时，全局规划负责覆盖路径（比如弓字形），局部规划负责避障。

4.2 代价地图的膨胀半径怎么定

代价地图（costmap）是Nav2的核心概念，它把地图上的每个格子标记为"可通行""有障碍""膨胀区"。**膨胀半径（inflation radius）**是最关键的参数，它决定了机器人离障碍物多远就开始避让。

膨胀半径设太小，机器人会贴着墙走，容易刮蹭；设太大，机器人会不敢进窄缝，很多地方扫不到。经验值是机器人半径加上5~10厘米的安全余量。比如机器人半径15厘米，膨胀半径设20~25厘米比较合适。

但扫地机器人有个特殊需求：它需要贴边清扫。所以实际项目中，膨胀半径往往设得比较小（比如18厘米），然后靠局部规划的避障来兜底。这就是为什么扫地机器人的导航参数和普通移动机器人不一样，不能照抄教程。

4.3 覆盖路径规划：扫地机器人的专属算法

普通导航是"点到点"，扫地机器人是"覆盖整个区域"，这是两个不同的问题。覆盖路径规划（Coverage Path Planning）的目标是用最短路径扫完整个可通行区域。

最常见的覆盖策略是弓字形（Boustrophedon），也就是来回平行的直线。它的优点是路径规整、重复率低、容易实现。实现思路是：把地图按房间分割，每个房间内生成一组平行线，用全局规划器连接这些平行线。

ROS2里没有现成的覆盖规划包，需要自己写。核心逻辑是：

1. 从地图提取可通行区域
2. 按房间或区域分割
3. 在每个区域内生成弓字形路径点
4. 用Nav2的NavigateThroughPoses动作依次导航

这里有个坑：弓字形路径的间距要略小于机器人清扫宽度，否则会有漏扫。一般设清扫宽度的80%~90%。

5. 下位机固件：STM32在扫地机器人里到底干什么

聊完上层，我们把视角拉到最底层。STM32这类MCU在扫地机器人里承担的是"手脚"的角色，它的代码质量直接决定了机器人动作是否顺滑。

5.1 电机控制：从PWM到闭环

扫地机器人一般用两个带编码器的直流减速电机做差速驱动。STM32要做的闭环控制流程是：

1. 定时器输出PWM驱动电机驱动芯片（如TB6612、DRV8833）
2. 定时器编码器模式读取编码器脉冲
3. 定时中断（1ms~5ms）里计算实际速度
4. PID计算输出新的PWM占空比

这里的关键是编码器读取方式。STM32的定时器有专门的编码器模式，可以硬件计数，不占CPU。用普通GPIO中断计数的话，高速时中断太频繁会丢脉冲。所以务必用定时器编码器模式。

PID参数整定我一般用"先P后I再D"的顺序：先把P调到电机能响应但不振荡，再加I消除稳态误差，最后加少量D抑制超调。速度环的P一般给到几百，I给到几十，具体看电机和负载。

5.2 传感器采集与实时性

扫地机器人的传感器不少：碰撞开关、悬崖传感器（红外或ToF）、电池电压、电流。这些都要在MCU里采集。

采集策略上，碰撞和悬崖必须用中断或高频轮询，因为它们关系到安全，响应慢了机器人就撞了或掉下台阶了。电池电压电流可以用ADC低速采集，几百毫秒一次足够。

STM32的ADC多通道采集有个坑：切换通道后第一次转换的数据不可靠，需要丢弃或延时。如果发现某个通道读数总是偏，先检查是不是通道切换后没等稳定就读了。

5.3 上下位机通信协议设计

上位机和STM32之间的通信，最简单的是串口，复杂点用USB CDC或CAN。协议设计要遵循几个原则：

• 定长帧+帧头帧尾，方便解析和校验
• 带校验和，防止误码
• 双向心跳，一方掉线另一方要能检测到
• 控制指令和状态上报分开，避免互相阻塞

一个典型的帧结构是：0xAA 0x55 | 长度 | 命令字 | 数据 | 校验和。上位机发速度指令，下位机回里程计和传感器状态。通信频率一般50~100Hz，太高了串口带宽不够，太低了控制不流畅。

注意：串口通信一定要处理粘包和半包问题。别假设一次read就能读到完整一帧，要用状态机逐字节解析。

6. 那些让我熬夜的坑：真实排错记录

理论讲完了，说几个我实际踩过的坑，这些是文档里不会写的。

6.1 雷达数据正常但地图不动

现象：RViz2里能看到激光点云，但地图一直不更新。排查过程：先看/map话题有没有数据，有；再看TF树，发现map -> odom这一环没有发布。原因是SLAM节点启动了但没接收到里程计数据，因为里程计的frame_id写成了odom_frame而不是odom。改过来就好了。TF的frame_id是大小写和拼写敏感的，一个字母都不能错。

6.2 机器人走直线画弧

现象：发直行指令，机器人走出一条弧线。原因：两个电机的PID参数不一致，或者轮径标定不准。解决：先确认两个电机在相同PWM下转速一致，再重新标定轮径。如果硬件上两个电机特性差异大，可以给每个电机单独一套PID参数。

6.3 建图时地图突然旋转

现象：建图中地图突然整体旋转一个角度。原因：IMU数据跳变，导致EKF融合时yaw角突变。解决：检查IMU的安装是否牢固，是否有振动干扰；在EKF配置里降低IMU角速度的权重，或者加一个低通滤波。

6.4 回充时对不上充电座

现象：机器人能找到充电座方向，但总是差几厘米对不上。原因：回充最后阶段靠红外信号引导，红外接收角度有限。解决：在回充阶段降低速度，增加微调次数；或者用视觉标记辅助对准。这个问题的本质是最后几厘米的精度靠里程计保证不了，必须靠专门的对接传感器。

7. 从这台机器能学到什么：一套完整的机器人工程方法论

拆完这台扫地机器人，你会发现它其实是一套浓缩的机器人工程课程。它把机器人开发中最核心的几个能力都串起来了。

第一是分层思维。任何复杂机器人系统都要分层，每层职责单一、接口清晰。这个思维不只适用于扫地机器人，机械臂、无人机、自动驾驶都是同样的套路。

第二是接口设计能力。上位机和下位机之间、节点和节点之间，接口设计得好，系统就稳；设计得差，到处是耦合和bug。ROS2的话题、服务、动作三种通信方式，分别对应"持续数据流""请求响应""长任务"三种场景，用对了事半功倍。

第三是调试方法论。机器人系统出问题，永远遵循"从底层往上查"的原则：先确认硬件正常，再确认驱动正常，再确认数据流正常，最后才怀疑算法。我见过太多人一上来就调SLAM参数，结果发现是串口线松了。

第四是实时性意识。哪些任务必须实时，哪些可以容忍延迟，心里要有一杆秤。控制环路必须实时，建图可以慢一点，日志上报更可以慢。把实时性要求高的任务下沉到MCU，是这套架构的精髓。

如果你正打算做一个自己的扫地机器人，我的建议是分阶段来：第一阶段先让轮子能按指令动起来，跑通上下位机通信；第二阶段加上雷达和里程计，跑通SLAM Toolbox建图；第三阶段上Nav2做导航；第四阶段再搞覆盖规划和回充。每个阶段都能独立验证，别想着一步到位。这套东西真正难的不是某个算法，而是把这么多模块稳定地集成在一起，而集成能力恰恰是靠一个个项目磨出来的。