1. 三条路线怎么选先想清楚你要的是玩具、工具还是平台很多人第一次动“自己搞一台扫地机器人”的念头都是被两件事勾起来的一是商用量产机越做越便宜但总有些地方不听话——边角扫不干净、地图偶尔丢、拖布洗不干净二是手头正好有块 STM32 或者装了 ROS2 的 Ubuntu 机器觉得“这不就是现成的底盘加脑子吗”。我当年也是这么想的结果第一台车在客厅里原地转圈转了三天才明白路线选错比代码写错更致命。先把话说在前面自己攒扫地机器人本质上不是“省钱”而是“拿回控制权”。你要的是能改算法、能换传感器、能接自己写的导航逻辑而不是买一台黑盒。所以路线选择的核心不是预算而是你愿意在哪个层面投入精力。我把它归成三条路线你可以对号入座。路线一纯 STM32 裸机方案。主控就是一块 STM32比如 F103 或 F407下面挂电机驱动、编码器、超声波、红外避障上面跑一个简单的状态机随机走、撞墙转向、沿墙巡航。这条路线的优点是便宜、实时性极好、没有操作系统开销一块板子几十块钱就能让车动起来。缺点是它几乎没有“智能”——没有真正的建图没有全局路径规划遇到复杂户型基本靠运气。适合谁适合想练电机控制、PID 调速、传感器融合入门的人把它当成一个会走的移动平台而不是扫地机器人。路线二STM32 做下位机 ROS2 做上位机。这是目前最主流、也最值得推荐的攒机路线。STM32 负责底层的电机闭环、编码器读取、IMU 数据采集、电池管理通过串口或 CAN 把里程计和传感器数据发给上位机上位机跑 Ubuntu ROS2用 SLAM 建图、用 Nav2 做导航。上下位机通过自定义的串口协议或者 micro-ROS 通信。这条路线的价值在于分工清晰实时控制交给单片机复杂计算交给 Linux。你既学到了嵌入式又摸到了机器人操作系统两头都不耽误。热词里那一堆 ROS2、SLAM、Nav2、STM32 的组合基本都指向这条路。路线三全 ROS2 上位机方案底盘直接用现成模块。如果你不想碰电机驱动和 PCB可以直接买一个带 ROS2 驱动的差速底盘或者用树莓派加电机扩展板把精力全部砸在 SLAM 和 Nav2 上。这条路线上手最快一两周就能看到车在房间里自己建图但你对底层的掌控最弱出了问题容易抓瞎。适合算法方向的人或者时间紧、只想验证导航逻辑的开发者。三条路线没有绝对优劣但我个人的建议很明确如果你是真想“拥有一台自己的扫地机器人”走路线二。它兼顾了学习深度和最终可用性而且社区资料最全踩坑时有人能拉你一把。下面这张表是我自己选型时整理的对比你可以直接拿去用。维度路线一 纯STM32路线二 STM32ROS2路线三 全ROS2上手难度低中高中硬件成本最低中等中等偏高建图能力无完整SLAM完整SLAM导航能力无Nav2全局规划Nav2全局规划实时性极好好分层一般可扩展性差强强适合人群嵌入式入门全栈学习者算法方向选完路线接下来才是真正的硬仗。我按攒机的实际顺序把整条链路拆成几个大块来讲每一块都会告诉你为什么这么做、坑在哪里。2. 底盘与下位机STM32 到底要干哪些活2.1 电机选型与驱动别一上来就上无刷扫地机器人的底盘最常见的是两轮差速加一个万向轮。电机选型上我强烈建议新手从带编码器的直流减速电机起步而不是无刷电机或者步进电机。原因很实在直流减速电机便宜、驱动简单、扭矩够用编码器能直接给你里程计。热词里出现的“五线四相步进电机 STM32”我也试过步进电机低速扭矩好、定位准但发热大、效率低、驱动复杂用在扫地机上属于杀鸡用牛刀除非你要做很精确的原地转向。驱动芯片方面小功率用 TB6612 或 DRV8833 就够了电流大一点可以上 DRV8323 这类带电流采样的驱动方便做堵转检测。这里有个细节一定要留出电流采样接口。扫地机撞到拖鞋、卡在地毯边缘时电机电流会飙升靠电流判断堵转比靠碰撞传感器更灵敏也更便宜。编码器我推荐霍尔编码器每转几百个脉冲那种。算里程计的时候轮子直径 D、编码器线数 P、减速比 R、四倍频计数每米对应的脉冲数就是pulses_per_meter (P * 4 * R) / (π * D)举个例子轮径 65mm编码器 13 线减速比 30四倍频后每圈脉冲是 13×4×301560周长是 π×0.065≈0.204 米那么每米约 7647 个脉冲。这个数字直接决定你里程计的精度算错了车走一米你以为是半米SLAM 建出来的图就是歪的。我第一台车就是轮径量错了 2mm建出来的房间是个平行四边形排查了一整晚。2.2 传感器布局超声波、红外、IMU 各司其职底层的传感器不用堆太多但要各有用处。超声波用来测前方和侧方的中远距离障碍热词里的“STM32 超声波测距”就是干这个的HC-SR04 便宜好用但要注意它的盲区和刷新率多个超声波之间还会互相干扰最好分时触发。红外避障负责近距离的悬崖检测和贴边装在底部朝下就是防跌落装在侧面就是沿墙。IMU是必须的MPU6050 或者 ICM42688 都行用来做航向角的短时估计弥补编码器打滑带来的角度漂移。这里有个经验IMU 和编码器要做融合不能只信一个。编码器在轮子打滑时角度会飘IMU 在长时间积分后也会漂两者用互补滤波或者简单的卡尔曼融合航向角会稳很多。我在 STM32 上跑一个一阶互补滤波代码不到二十行效果比单用任何一个都好。2.3 通信协议设计上下位机怎么对话STM32 和上位机之间最省事的是串口波特率 115200 或 460800。协议我建议自己定一个简单的帧格式比如帧头 0xAA 0x55、长度、命令字、数据、校验和。上位机发速度指令下位机回里程计和传感器状态。如果你用 micro-ROS可以直接把 STM32 变成一个 ROS2 节点省去自己写协议解析但 micro-ROS 对资源要求高一些F4 以上比较稳。注意串口通信一定要加校验和并且做超时保护。我遇到过上位机卡死、下位机还在按最后一条速度指令狂奔的情况车直接撞墙。后来加了 500ms 无指令就自动停车的逻辑再没出过事。热词里提到的“STM32 CAN 通信突然连不上”多半是终端电阻没接、波特率不匹配或者总线负载太高。CAN 在扫地机上不是必须的但如果你要挂多个节点比如独立的清扫模块CAN 比串口更抗干扰。3. 上位机与 ROS2从装系统到跑通第一个节点3.1 ROS2 版本选择与安装避坑上位机系统我推荐 Ubuntu 22.04 配 ROS2 Humble这是目前资料最全、最稳定的组合。热词里有人问“Ubuntu 26.04 安装 ROS2”我的建议是别追新ROS2 对 Ubuntu 版本卡得很死版本不匹配会出现各种依赖地狱。安装方式优先用 apt别一上来就源码编译除非你要改底层。安装时最容易卡在源的问题上热词里那个“获取 packages.ros.org 错误”我太熟了。通常是网络或者源配置的问题检查/etc/apt/sources.list.d/ros2.list里的发行版代号对不对Humble 对应的是 jammy。装完之后记得source /opt/ros/humble/setup.bash并且写进.bashrc不然每开一个终端都要手动 source新手经常在这里怀疑人生。3.2 工作空间与功能包C 还是 PythonROS2 的功能包我建议核心节点用 C工具和脚本用 Python。SLAM 和 Nav2 的接口都是 C 为主性能也好而数据处理、可视化、调试脚本用 Python 写起来快。创建一个 C 功能包的命令是ros2 pkg create --build-type ament_cmake my_robot --dependencies rclcpp std_msgs sensor_msgs热词里的“ROS2 创建 C 功能包”就是这个流程。建完之后package.xml和CMakeLists.txt要改对尤其是依赖项漏一个编译就报错。我的习惯是每加一个依赖就立刻编译一次别攒一堆再编不然报错都不知道是哪个引入的。3.3 话题、服务、动作三种通信方式怎么用ROS2 的通信机制是核心热词里“ROS2 话题服务动作”问的人很多。简单说话题是持续的数据流比如激光雷达数据、里程计用发布订阅服务是一次性的请求响应比如“保存地图”动作是带反馈的长任务比如“导航到某个点”Nav2 就是用动作接口的。理解这三者的区别你才能设计出合理的节点架构。我自己的架构是这样的STM32 驱动节点发布/odom和/imu激光雷达驱动发布/scanSLAM 节点订阅这些并发布/map和 TF 变换Nav2 订阅地图和传感器做路径规划最后把速度指令发回 STM32 驱动节点。整条链路清晰任何一个环节出问题都能单独调试。4. SLAM 建图让车真正“看懂”房间4.1 SLAM 方案选型2D 还是 3DSLAM 是扫地机器人的灵魂。热词里“SLAM 建图”“视觉 SLAM”“八叉树地图导航”都指向这个领域。对于扫地机我建议从2D 激光 SLAM起步用单线激光雷达配 slam_toolbox 或者 Cartographer。原因很简单2D 激光 SLAM 成熟、算力要求低、建出来的栅格地图直接能给 Nav2 用。3D 雷达和视觉 SLAM 更酷但点云处理、标定、算力都是坑新手很容易陷进去出不来。如果你确实想上 3D热词里“Nav2 导航使用 3D 雷达”是可行的但通常要把 3D 点云压成 2D 栅格或者用八叉树地图octomap做三维避障。八叉树的好处是能表达三维空间占用适合有高低差的环境但内存和计算开销大树莓派级别的机器跑起来会吃力。4.2 建图实操从启动到保存地图以 slam_toolbox 为例建图的流程大概是启动雷达驱动、启动里程计、启动 slam_toolbox、用键盘或者手柄遥控车走一圈、保存地图。启动文件里要配好 TF 树map到odom的变换由 SLAM 发布odom到base_link由里程计发布base_link到laser是静态变换。TF 树错了RViz 里地图就会乱飘。提示建图时速度一定要慢尤其是转弯。转太快激光雷达会有运动畸变建出来的墙是弯的。我一般把线速度控制在 0.15m/s 以内角速度 0.5rad/s 以内。保存地图用ros2 run nav2_map_server map_saver_cli -f my_map会生成.pgm和.yaml两个文件后者记录分辨率和原点。热词里“SLAM 时跟随焦点随意移动”说的是 RViz 的视角跟随建图时把视角固定在机器人上会方便很多。4.3 建图质量排查地图歪了、重影了怎么办建图最常见的两个问题地图重影和地图闭合不上。重影通常是里程计和激光匹配不一致检查轮径、轮距参数或者雷达安装角度。闭合不上多半是回环检测没生效slam_toolbox 里可以调回环参数或者走的时候多绕几圈让算法有机会闭合。我踩过最深的坑是雷达装歪了 3 度建出来的房间所有墙角都不是 90 度排查了半天才发现是支架没装正。所以机械安装的精度往往比算法参数更重要。5. Nav2 导航从地图到自主清扫路径5.1 Nav2 架构与核心参数Nav2 是 ROS2 的导航框架包含全局规划器、局部控制器、代价地图、行为树等模块。热词里“Nav2 导航”出现频率极高说明这是大家最关心的部分。Nav2 的核心是代价地图全局代价地图用于规划从 A 到 B 的路径局部代价地图用于实时避障。关键参数我列几个必须调的robot_radius或footprint决定机器人占用空间填小了会撞填大了进不去窄缝inflation_radius是障碍物膨胀半径一般设成机器人半径加一点余量max_vel_theta和max_vel_x限制速度别让车冲太快。这些参数在nav2_params.yaml里改改完重启节点生效。5.2 全局规划与局部控制两条腿走路全局规划器我常用 NavFn 或者 Smac前者快后者路径更平滑。局部控制器用 DWB 或者 MPPIDWB 调参直观MPPI 性能好但参数多。实际跑下来室内扫地场景 DWB 够用了。行为树负责调度比如“先规划、再跟随、卡住了就恢复”Nav2 自带的行为树基本能覆盖常见场景。这里有个实操心得局部代价地图的传感器源要配全。除了激光雷达最好把超声波和红外也作为障碍层加进去因为激光雷达扫不到低矮的拖鞋和电线而这些恰恰是扫地机最容易卡住的东西。5.3 自主清扫路径规划覆盖比导航更难Nav2 解决的是“从 A 到 B”但扫地机要的是“把整个房间都走一遍”这是覆盖路径规划问题。常见做法是分区加弓字形清扫或者用边界跟随。ROS2 生态里有 coverage_path_planner 这类包但成熟度不如 Nav2。我的做法是先让 Nav2 把房间分区每个区域用弓字形路径点序列再让 Nav2 依次导航过去。这块是目前自攒扫地机和商用量产机差距最大的地方。量产机的覆盖算法是核心竞争力开源方案还在追赶。但如果你只是想让车把客厅大致扫一遍弓字形加边界跟随已经能用了。6. 常见问题与排查技巧实录攒机过程中遇到的问题八成集中在通信、TF、参数这三类。我把踩过的坑整理成一张速查表你遇到问题时可以对照着查。现象可能原因排查方向车原地转圈里程计方向反了检查编码器极性、轮距符号地图重影里程计标定不准重新测轮径、轮距走直线验证RViz 里 TF 报错TF 树断裂或重复用ros2 run tf2_tools view_frames看树Nav2 规划不出路径代价地图全被膨胀调小 inflation_radius检查障碍层串口数据乱码波特率或校验错确认两端波特率检查帧格式建图闭合不上回环未触发调回环参数多绕圈车走一段就停看门狗超时检查上位机是否卡顿加超时保护除了表里的还有几个独家避坑技巧。第一先让车走直线再谈建图。很多人一上来就跑 SLAM结果地图歪了就怪算法其实是里程计没标定好。发一个固定速度让车走三米量实际距离反复调轮径参数直到误差在 2% 以内。第二TF 树是命根子。任何导航问题先看 TF 树对不对view_frames生成的 PDF 能一眼看出问题。第三参数改动要一次只改一个。我见过有人一次改十个参数结果车行为变了都不知道是哪个起的作用。热词里“STM32 GBK 转 UTF8”这种编码问题在串口打印中文时确实会遇到统一用 UTF8 就行别混用。“STM32 使用 ILI9341 读 ID 是 A1A1”是屏幕驱动的正常现象A1A1 就是 ILI9341 的 ID读到它说明 SPI 通信正常。这些细节看着琐碎但每一个都可能卡你半天。7. 攒机路线图从零到能跑的完整清单把上面所有内容串起来我给你一张可以直接照着走的路线图。按这个顺序推进每一步都有可验证的产出不会出现“写了一堆代码但车不动”的挫败感。第一阶段底盘动起来1-2 周。买电机、驱动、轮子、STM32 开发板搭好车架写 PWM 调速和编码器读取用 PID 让轮子按指定速度转。验证标准发指令让车走直线一米误差小于 3cm。第二阶段传感器和通信1 周。加 IMU、超声波写好串口协议上位机能收到里程计和传感器数据。验证标准在 RViz 里能看到里程计轨迹和传感器数据。第三阶段SLAM 建图1-2 周。装雷达配 TF跑 slam_toolbox遥控建图。验证标准建出一张闭合、墙角垂直的地图。第四阶段Nav2 导航2-3 周。配代价地图和规划器让车自主导航到指定点。验证标准给一个目标点车能绕开障碍到达。第五阶段覆盖清扫持续迭代。实现分区和弓字形路径加上清扫模块控制。验证标准车能自主覆盖一个房间的大部分区域。整个周期如果每天投入两三小时大概两到三个月能跑通前四阶段。第五阶段是长期优化没有终点。硬件成本上STM32 加电机驱动加传感器大概两三百激光雷达是最大开销便宜的几百好的上千上位机用旧笔记本或者树莓派都行。最后分享一个我自己的体会别追求一次做完美先让车动起来再让它聪明起来。我第一台车丑得不行线都是飞线但它能跑能建图那种成就感比什么都强。后面再慢慢换好雷达、优化算法、重新设计结构。攒扫地机器人这件事最大的乐趣不在于最后那台车多完美而在于每一个环节你都知道它是怎么工作的出了问题你能修。这种掌控感是买量产机永远给不了的。