我搞过不少机器人相关的项目，但说到Autonomous Mapping Rover（自主建图小车），哪怕放到现在，我依然认为这是性价比最高、最能让人把“感知-建图-导航”这一条完整链路吃透的入门题目。一个小车底盘、一块主控板、一颗激光雷达，用ROS把SLAM算法跑起来，几分钟内就能得到一张室内二维栅格地图，再往下还能接上自主导航、路径规划、避障这些进阶玩法。整个过程不玄学，每一条数据都能从硬件和代码里找到来源。
这篇文章适合正在做课程设计、想入门机器人SLAM、或者纯粹想给自己攒一台“仿真版扫地机器人”的开发者。我会把整台车的设计逻辑、硬件选型、软件驱动、建图导航实操、以及那些文档里不写但实测必踩的坑，全部按我自己的项目经验串一遍。
1. 整体设计：为什么从轮式底盘和激光雷达开始
1.1 先拆解“自主建图小车”到底包含哪些能力
“自主建图”这四个字拆开看，其实是一个收集环境信息、构建一致性地图、并让小车知道自己在地图中位置的过程。一台完整的Autonomous Mapping Rover至少要具备三部分能力：一是能够精确控制运动并感知自身位移，也就是底盘、轮式里程计、IMU这些；二是能够感知周围环境，激光雷达或者深度相机是主要来源；三是能运行SLAM算法，在运动过程中同步完成定位与地图构建。
我在设计时把优先级排成了“先能走路，再能感知，最后才谈智能”。所以整台车的方案顺理成章地变成了“轮式差速底盘 + 2D激光雷达 + IMU + ROS主机”。这套组合不是唯一的解，但在室内环境下是稳定性最高、调试周期最短的组合。扫地机器人、仓储AGV、商用服务机器人，绝大多数室内移动机器人底座都是沿用了这套逻辑。
1.2 方案选型：差速底盘、2D雷达、ROS主机
先说底盘。我选择两轮差速驱动，后面加一个万向轮支撑。和履带式相比，轮式底盘的轮式里程计近似线性，做航迹推算时更简单；和全向轮底盘的三个轮子解耦相比，它又不需要复杂的运动学解算。差速模型最简单，两个轮子转速不同就能转弯，一个合适的起始点，后面所有算法都能跑起来。
再说传感器。视觉方案（比如深度相机跑SLAM）听上去很酷，但在室内反光、低纹理、光线剧烈变化的情况下非常容易被干扰，而且对算力要求高。2D激光雷达虽然只能扫一个平面，但它提供的是精确的角度和距离测量，不受光照影响，数据格式稳定，配合Gmapping或者Cartographer这类算法，开箱可用。我选的是RPLIDAR A1，12米测距半径、每秒8000次采样，在小房间里建图完全够用。
最后说主控。我在项目里用了树莓派4B跑Ubuntu和ROS，电机控制单独交给一块STM32或Arduino。为什么把电机控制分离出去？因为机器人操作系统里的Linux不是硬实时系统，如果PWM控制直接由主控发，遇到高负载时容易丢脉冲、响应抖动，导致里程计数据异常。实时性要求高的底层控制放到MCU上，上层只通过串口发送目标速度，这样角色清晰又稳定。
1.3 能扩展的方向和技术收益
做完这辆车并不止于“得到一张地图”。后续能做的扩展包括：用AMCL算法实现重定位与自主导航，给底盘加上避障逻辑做成巡检小车，把2D栅格地图融合成拓扑地图做任务规划，甚至在换装更高性能雷达和迷你电脑之后接入Cartographer做回环优化，覆盖更大面积。我在做项目过程中体会最深的是，很多看似高深的机器人概念，最后落到代码和硬件上是可拆解、可验证的，这比看十篇论文都有效。
2. 硬件搭建：底盘、核心板、传感器缺一不可
2.1 底盘与电机选型：编码器就是小车的“内耳”
底盘是整台车的物理基础，我的建议是不要买那种纯玩具底盘，而是选择带编码器的金属直流减速电机底盘。编码器是电机后端的霍尔或光电码盘，它输出的脉冲能换算出轮子实际转了几圈，进而计算出小车的位移和转向角度，这就是轮式里程计（odometry）的原始信号。
常用的电机有两种：N20减速电机和370直流减速电机。N20体积小、重量轻，适合室内小场景；370扭矩更大，适合挂载更重的设备。我实际用的是带霍尔编码器的N20电机，减速比约1:30，轮径65mm，编码器每分钟输出的脉冲差不多在几千到一万量级。选型时要关注的是“每圈脉冲数”和“减速比”，这两项决定了里程计换算的分辨率。计算线速度的公式是：
v = (tick_per_second / ticks_per_wheel_revolution) * wheel_circumference也就是单位时间内的脉冲数除以车轮转一整圈对应的脉冲数，再乘以轮子周长。这里的tick数据必须稳定可靠，所以编码器在硬件上一定要接在连续的GPIO中断引脚上，不能靠轮询。
2.2 电机驱动与主控的配合方式
电机驱动板我选的是经典L298N，虽然它工作温度高、压降明显，但胜在皮实、文档量最大。如果你有预算，用TB6612FNG或DRV8833会更好，发热小，PWM响应也更线性。驱动板通过PWM+方向引脚控制两个电机，树莓派不会直接去驱动电机，而是通过串口或I2C把目标速度发给STM32，由STM32输出PWM送给驱动板。
我踩过最大的坑是供电问题。树莓派、STM32、电机驱动、雷达、IMU的电压各不相同：树莓派需要5V/3A，电机驱动需要单独的电池电压，雷达虽然也是5V但瞬时电流不小。最开始我把所有电源并在一起，结果电机一启动，雷达就开始丢数据、串口乱码。后来改成“电机独立供电 + 逻辑板独立供电 + 所有电源的地线共地”，整个系统才稳定下来。记住一个原则：功率回路和控制回路必须隔离，但地线必须相连，否则电平参考点不一致，串口通信全飘。
2.3 激光雷达、IMU的安装要点
RPLIDAR A1这类360度扫描雷达需要5V供电，典型电流约500mA，启动瞬间电流更大。建议从电池通过稳压模块单独给雷达供电，不要从树莓派的5V引脚取电，实测会导致雷达扫描异常甚至旋转电机停转。
雷达的安装位置也有讲究。要尽量安装在车身正中央且保持水平，高度在10~15厘米左右，既能扫到室内大部分墙角和家具，又不会被车前方的障碍物完全挡住。我第一版把雷达安在车头，结果车身左右两侧出现大块盲区，建图时老觉得房间变窄了，其实就是视场被车体遮挡。
IMU（惯性测量单元）我用的MPU6050，主要提供角速度和加速度，用来修正轮式里程计在快速转弯时的累积漂移。IMU必须刚性固定在底盘骨架上，不能放在减震或软垫上，否则振动会把噪声灌进去。安装后要做一次静态校准，把零点偏置记录下来，后续时间同步和频率统一都非常重要。
3. 软件环境与驱动实现：让小车先“认识自己”
3.1 系统与ROS环境搭建
小车主控端我用的是树莓派4B，运行Ubuntu 20.04 Server版本，配ROS Noetic。ROS 1的生态对2D SLAM建图最成熟，网上参考资料也最多，非常适合第一个项目。如果你想现在从ROS 2开始，Ubuntu 22.04配上Humble也是可以的，但很多老教程里的包和命令有小差异，入门阶段容易卡壳。我建议第一辆车先用ROS Noetic，跑通整条链路后再换ROS 2积累新特性。
准备好SD卡后，开机第一件事是配置Wi-Fi和SSH，为了调试方便。树莓派连接显示器不是不行，但在机器人上跑来跑去是很麻烦的，SSH远程操作是主流习惯。系统装好后安装ROS，然后用apt安装后面会用到的包：
sudo apt install ros-noetic-gmapping ros-noetic-cartographer \ ros-noetic-amcl ros-noetic-move-base ros-noetic-teleop-twist-keyboard雷达驱动、IMU驱动和底盘驱动如果手头硬件是常见型号，网上基本都有现成的ROS包，比如rplidar_ros、imu_filter_madgwick。装上后最先要做的是验证话题数据能否正常发布，用rostopic list、rostopic echo看一眼，如果数据为空或乱跳，后面一切算法都是空中楼阁。
3.2 串口权限与底层控制协议
树莓派通过USB转TTL或原生串口与STM32通信，Linux下设备名通常是/dev/ttyUSB0或/dev/ttyAMA0。开机后默认只有root可以访问串口，普通用户运行ROS节点会报Permission denied。解决方法是把当前用户加入dialout组：
sudo usermod -a -G dialout $USER如果系统里接了多个USB设备，ttyUSB0和ttyUSB1的编号可能每次开机都不一样，导致雷达或底盘驱动找不到设备。解决办法是写udev规则，根据设备ID固定别名。这一步在我自己项目里省了大量时间，尤其是调试时频繁插拔设备，固定别名的好处立竿见影。
底层MCU串口协议不需要太复杂。我自定义了一个简单文本协议，树莓派向STM32发送形如V 0.5 -0.2的命令，前一个数字是线速度（m/s），后一个是角速度（rad/s）；STM32解析后计算出左右轮转速，再通过PID控制PWM让轮子跟上。同样的，STM32会定期回传编码器累计脉冲、IMU姿态，树莓派订阅后计算出里程计话题发布到ROS中。
3.3 里程计计算与TF树配置
里程计计算在ROS里的实现在我的项目中用了不到50行Python，核心就是差速模型：
wheel_base = 0.30 # 左右轮距 ticks_per_m = 5000.0 # 每米脉冲数（由轮径和减速比换算） def compute_odom(delta_left, delta_right): dx = (delta_right + delta_left) / 2.0 / ticks_per_m dtheta = (delta_right - delta_left) / wheel_base / ticks_per_m return dx, dtheta每收到一次编码器计数，就累加一次位置增量，依次更新x、y、theta。这个过程叫航迹推算，本质上是一个积分过程，所以误差会随时间累积。这也是为什么后面要引入激光雷达和SLAM进行校正，单靠里程计走久了必然飘。
ROS中坐标变换（TF树）对于SLAM来说至关重要。最基础的TF树长这样：
odom → base_link → laserodom到base_link的变换由里程计发布，base_link到laser的变换是固定的，因为雷达安装在车体上有固定的偏移和姿态偏差，必须在URDF模型里声明。很多新手建图失败、地图扭曲，原因不是算法不行，而是雷达在TF树里的安装偏移写错了。我用尺子量过偏移，再配合水平尺确认雷达姿态，才把TF树配置正确。
4. 建图与导航：跑通SLAM闭环才是真正的开始
4.1 SLAM算法选型：Gmapping、Cartographer还是Hector
ROS生态里2D SLAM算法有好几种，我实际都测过，简单做了个对比。
| 算法 | 定位原理 | 特性 | 适用场景 |
|---|---|---|---|
| Hector SLAM | 扫描匹配，不依赖里程计 | 对传感器频率要求高，易漂移 | 快速原型验证 |
| Gmapping | 粒子滤波，依赖里程计 | 计算量小，地图干净 | 小面积室内建图 |
| Cartographer | 图优化，多传感器融合 | 支持回环，精度高 | 大面积或复杂环境 |
我的结论是：入门阶段优先Gmapping，因为它对里程计的依赖让底盘驱动和算法之间的配合关系非常直观，调试起来也容易定位问题。等跑通一遍之后，再换Cartographer做对比，感受一下图优化和回环检测带来的差异。千万不要一开始就追求“最强算法”，卡在配置和依赖上很容易劝退自己。
启动建图的命令一般分两步：第一步启动硬件驱动和底盘控制，第二步启动Gmapping算法，例如：
roslaunch my_rover_bringup bringup.launch roslaunch my_rover_bringup gmapping.launch4.2 建图实操：遥控走位不是随便乱转
建图阶段我通过遥控器给小车发速度指令，配合teleop_twist_keyboard这个节点，按键盘上的按键控制小车前后左右走。建图质量很大程度取决于行走策略。第一次我毫无章法地在房间里绕圈，回来一看图，墙是双层、房间重叠，根本没法用。
后来我总结了一套经验：第一圈先沿着外墙缓慢走一圈，速度控制在0.2m/s以内，让激光雷达把大的轮廓“锚定”下来；第二圈再进入房间内部，重点覆盖家具周围的空闲区域；走到门口或者回廊区域时，一定要有意识地走一个环形路径，让算法能够产生回环约束。Gmapping对回环路径尤其敏感，同一个房间绕一圈后，整个地图会被自动拉平，漂移的里程计误差被修正回去。
地图快建好时，用下面的命令保存地图：
rosrun map_server map_saver -f ~/maps/room_map保存后会生成room_map.pgm和room_map.yaml两个文件，前者是图像，后者包含栅格分辨率、原点坐标、占用阈值等元数据。这一步做完，建图环节就收工了。
4.3 自主导航：从静态地图到动态避障
有了静态地图，接下来要做的核心功能是定位和导航。定位我用AMCL，它通过粒子滤波器来估计小车在地图中的位姿；导航用move_base，它管理全局路径规划和局部路径规划。整体流程是：AMCL输出当前位姿，move_base在地图中规划路径并给底盘下发速度指令，同时让局部规划器实时检测障碍物，做到动态避障。
在运行导航前，第一步是设置初始位姿。我的调试心得是：把小车放在地图里一个特征明显的地方，手动指定初始位置和朝向，然后慢慢推动小车走一小段，观察粒子是否快速收敛、激光扫描点和地图轮廓是否贴合。如果粒子发散，多半是初始位姿给得不对，或者激光雷达的安装角度有偏差。
导航参数主要集中在代价地图的膨胀半径、机器人半径、最大线速度、加速度这些项。我在小房间里的常用取值是：机器人半径0.2m，膨胀半径0.1m，最大线速度0.3m/s，最大角速度0.8rad/s。开启动态避障后，小车遇到移动的人或临时放下的快递箱，会先减速、再重规划路径绕过去。这一整套跑通，我的感觉是“这台小车终于有了一点‘自主’的样子”。
5. 常见问题与排查技巧实录
5.1 启动报错与串口问题速查
项目做下来，我把踩过的坑和排查思路整理成一个速查表，希望对后来者有用：
| 现象 | 可能原因 | 排查与解决办法 |
|---|---|---|
| 打开串口提示Permission denied | 用户不在dialout组 | 执行usermod加入dialout组，重新登录 |
| 雷达节点能启动但没有数据 | USB设备编号变化 | 写udev规则固定设备别名 |
| 电机不转但驱动板灯亮 | 电源不够，或者PWM引脚配置错 | 先测电机电压，再用示例程序直接输出PWM |
| 里程计漂移很严重 | 轮径不准、编码器脉冲换算不对 | 推车直线走1米，对比里程计变化量，反向修正轮径 |
| 地图出现“鬼影”、墙体重叠 | 里程计累计误差大，缺少回环路径 | 降低行走速度，走环形回环路径，或加大Gmapping的粒子数 |
| TF树提示找不到odom→base_link | 底盘驱动节点没启动或崩溃 | rostopic list检查里程计话题是否存在 |
| AMCL粒子发散，定位失败 | 初始位姿给错、激光安装角度偏差 | 停到特征明显位置重新设初始位姿，检查TF树偏移 |
5.2 几个容易忽略的细节
串口通信乱码往往不是代码问题，而是电源干扰。尤其电机启动瞬间电流尖峰会导致串口电平毛刺。我把雷达和主控用独立稳压模块供电，并加了一个1000uF电解电容在电机电源两端，乱码问题基本消失。看似是软件问题，最后修在硬件上，这类教训在机器人项目里特别常见。
激光扫描频率和IMU发布频率如果不一致，建图会不稳定。建议让雷达以10Hz左右发布扫描数据，IMU以50Hz左右发布姿态数据，然后在启动文件里设置时间同步。有些算法要求扫描和里程计在同一时间戳。我之前因为雷达和IMU各跑各的，导致Gmapping报“消息时间戳差异过大”的警告，地图越建越乱。后来用sensor_synchronizer统一时间片，问题解决。
还有一个小点是地图的原点和分辨率。map_saver保存的yaml文件里，默认分辨率是0.05m/像素，也就是一格5厘米。如果你在更大区域建图，分辨率嫌低可以把参数调成0.02m/像素，但代价是地图文件变大、算法计算量上升，跑在树莓派上要注意发热和卡顿。
5.3 排查技巧：从“现象”反推“模块”
机器人项目调试最大的难度在于故障点可能出现在硬件、驱动、算法、参数任意一层。我会建议你养成一个习惯：每次遇到问题，先把整条链路画出来——底层MCU有没有输出正确的速度？底盘驱动发布的里程计话题数值对不对？激光雷达的扫描话题能不能显示轮廓？Gmapping有没有跑、TF树是否完整？然后在每个环节用rostopic echo、rviz直接观察，一步一步缩小范围，而不是凭感觉瞎改参数。
比如我遇到过一次“小车能走但地图完全空白”的问题。我先看雷达话题，发现扫描正常；再看底盘话题，发现里程计在累加；最后查TF树，发现base_link到laser的变换里x轴正负写反了，导致激光数据被倒置到墙体另一侧。如果用一句话总结排查思路：代码报错抓日志，算法不准看话题，地图不对查TF。这套方法论可以一直复用。
6. 写在最后：踩过几次坑之后的一些实在建议
如果让我重新装一台Autonomous Mapping Rover，我会把前期的“电源设计”和“固定安装”看得比算法选型还重。很多建图质量差、定位漂移、串口掉线的问题，归根到底不是算法不行，而是供电不稳、雷达没装平、编码器数据抖动这些基础环节没打好。机器人项目和纯软件开发最大的不同就在这里：每一层的误差都会层层传递，最后反映在地图上。先把硬件搞扎实，再让算法跑起来，你会少熬很多夜。
另外一个建议是，不要直接把别人的配置照搬过来。Gmapping的粒子数、move_base的速度上限、代价地图的膨胀半径，这些参数都和你自己的底盘尺寸、雷达安装高度、房间环境强相关。每改一个参数，都手动推着小车走一段，用rviz观察实际效果。这套“调参-观察-验证”的过程，才是做这个项目真正值回票价的地方。
