1. 为什么我要把扫地机器人的整条链路拆开讲扫地机器人这个品类看起来是个消费电子实际上它是一个把SLAM同步定位与建图、路径规划、运动控制、传感器融合全部塞进一个直径三十多厘米圆盘里的移动机器人平台。我接触过不少做ROS2的朋友他们学完官方教程之后最大的困惑就是TurtleBot3跑通了但换成自己搭的机器人雷达一装、底盘一接建图就开始飘导航就开始撞。问题往往不在某一个算法上而在整条链路的衔接处。这篇内容我打算把从点云到地图这件事完整走一遍从LiDAR和IMU的原始数据怎么进系统到SLAM节点怎么吐出栅格地图再到Nav2怎么拿着这张地图做全局和局部规划最后Gazebo里怎么验证。关键词覆盖SLAM、Nav2、ROS2、LiDAR、Gazebo我会尽量把每个环节的为什么这么选讲清楚而不是只丢一堆launch文件让你抄。适合谁看如果你已经装好了ROS2能跑通基础的talker/listener但一到建图和导航就卡壳那这篇就是给你写的。如果你连ROS2都还没装建议先把环境搞定再回来因为下面很多操作是建立在ROS2 Humble或者Jazzy基础上的。我实测下来Humble的生态最稳Gazebo和Nav2的配合也最成熟新手优先选它。整条链路我习惯分成四段来看感知层LiDAR、IMU、里程计、建图层SLAM算法输出地图、导航层Nav2的规划与控制、仿真层Gazebo提供闭环验证环境。这四层任何一层出问题最终表现都是机器人不听话但根因完全不同。下面我逐层拆。2. 感知层LiDAR、IMU和里程计到底谁说了算2.1 三种传感器各自的职责边界很多人一上来就纠结用激光还是用视觉其实在扫地机器人这个场景里2D LiDAR几乎是默认答案。原因很直接扫地机工作在平面房间结构以墙面、家具腿这类垂直特征为主2D激光雷达扫一圈就能拿到非常干净的轮廓计算量还小。视觉SLAM虽然信息更丰富但对光照、纹理依赖大地毯、白墙这种低纹理场景很容易丢。但光有LiDAR不够。LiDAR做scan matching扫描匹配时如果机器人原地旋转或者走过一段长走廊累积误差会很明显。这时候IMU就派上用场了它提供角速度和加速度能在两次扫描之间给出姿态变化的预测。而轮式里程计提供的是平移量的粗略估计。三者关系可以这样理解LiDAR提供环境结构的绝对观测精度高但频率低一般5到10HzIMU提供高频的姿态变化100Hz以上但会漂移里程计提供平移估计受轮子打滑影响大SLAM的核心工作就是把这些信息用一个滤波器或者图优化框架融合起来。我见过太多人只喂LiDAR给SLAM结果机器人一转圈地图就糊了就是因为缺少IMU的姿态约束。2.2 坐标系树是整条链路的骨架在ROS2里TF树是感知层的命脉。你必须搞清楚这几个坐标系的关系坐标系含义发布者map地图全局坐标系SLAM节点odom里程计累积坐标系里程计或SLAMbase_link机器人本体中心机器人状态发布器base_laser雷达安装位置静态TFimu_linkIMU安装位置静态TFmap到odom的变换由SLAM节点发布odom到base_link由里程计发布base_link到传感器由静态TF发布。这条链一旦断了或者有环RViz2里机器人就会闪烁甚至消失。我踩过的坑是静态TF的base_link到base_laser写反了方向结果雷达点云整体镜像建出来的地图左右颠倒排查了整整一个下午。提示用ros2 run tf2_tools view_frames生成TF树PDF一眼就能看出哪条链断了。这个命令比在RViz2里肉眼找快十倍。2.3 LiDAR和IMU的标定为什么不能省标题热词里出现了lidar imu标定这不是玄学。LiDAR和IMU之间存在外参安装位置和姿态的偏差和时间戳偏差。如果雷达和IMU的安装角度差了几度没标定融合时姿态就会系统性偏斜表现为地图缓慢旋转。标定分两步外参标定和时间同步。外参标定可以用手眼标定思路让机器人做特定运动通过观测一致性反推外参。时间同步更关键如果雷达和IMU的时间戳差了50毫秒机器人快速转向时融合结果就会错位。ROS2里可以用message_filters做时间对齐或者用硬件触发同步。我的经验是消费级扫地机上外参标定做到1度以内、时间同步做到10毫秒以内建图质量就有质的提升。别小看这几个数字它直接决定了你后面Nav2导航时地图和实际环境对不对得上。3. 建图层SLAM算法选型与点云到栅格地图的转换3.1 2D SLAM的两大流派滤波 vs 图优化SLAM算法大致分两派。滤波派以EKF-SLAM、FastSLAM为代表实时性好但地图规模大了之后一致性差。图优化派以Cartographer、SLAM Toolbox为代表把位姿和路标建成图用非线性优化求解回环检测能力强适合大场景。扫地机器人场景我推荐SLAM Toolbox它是ROS2生态里维护最活跃的2D SLAM方案支持在线建图和离线建图两种模式。Cartographer也很强但配置复杂调参门槛高。SLAM Toolbox的默认配置在大多数室内环境下开箱即用这对新手非常友好。选它的核心理由它基于Karto SLAM做了大量工程优化支持** lifelong mapping**长期建图也就是机器人可以分多次建图并合并这对扫地机第一次跑建图、之后一直用的使用模式非常契合。3.2 从点云到栅格地图的完整转换链路LiDAR吐出来的是LaserScan或者PointCloud2但Nav2需要的是OccupancyGrid栅格地图。中间发生了什么第一步扫描匹配。SLAM节点把当前帧激光和已有地图做匹配估计出机器人当前位姿。这一步用的是相关性扫描匹配或者ICP类算法。第二步位姿图优化。把历史位姿和约束建成图检测到回环时比如机器人绕了一圈回到起点优化整个轨迹消除累积误差。第三步栅格化。把激光点投影到二维平面标记为占据occupied、空闲free或未知unknown。这里有个关键参数叫分辨率一般设0.05米也就是每个栅格代表5厘米。分辨率太高地图文件巨大太低则细节丢失扫地机过窄缝时容易误判。第四步地图发布。SLAM节点通过/map话题发布OccupancyGrid同时发布map到odom的TF变换。我实测下来一个100平米的房子0.05米分辨率建出来的地图大概几MB完全可接受。如果你要做八叉树地图热词里提到的八叉树地图导航那是3D场景的需求2D导航用不上但如果你要处理多层建筑或者立体障碍OctoMap就是下一步。3.3 建图质量差八成是这几个原因建图糊、重影、墙壁变厚我总结下来无非几个原因里程计标定不准轮子直径、轮距参数错了导致平移估计系统性偏差。这个必须先用标定工具测准。雷达安装高度不当太低会扫到地面杂物太高会扫到桌面上方最佳高度是离地15到20厘米能扫到家具腿和墙脚。运动速度过快SLAM需要时间做匹配机器人跑太快两帧之间位移过大匹配就失败。建图时建议限速在0.2米每秒以内。环境动态物体太多走来走去的人、宠物会让地图出现鬼影。建图时尽量清场。注意建图阶段不要开导航两者同时跑会互相干扰。先建好图保存再切到导航模式加载地图这是标准流程。4. 导航层Nav2的插件化架构与规划器选择4.1 Nav2不是单个节点而是一套行为树驱动的系统很多人以为Nav2就是一个导航节点其实它是一整套架构。核心组件包括BT Navigator行为树导航器负责调度整个导航流程Planner Server全局路径规划从起点到目标点算一条路径Controller Server局部控制跟踪全局路径并避障Recovery Server恢复行为卡住时执行后退、旋转等动作Costmap 2D代价地图把障碍物膨胀成机器人可通行的代价这套架构的好处是插件化。全局规划器可以换NavFn、Smac、ThetaStar局部控制器可以换DWB、TEB、MPPI。扫地机场景我一般用Smac Planner做全局支持混合A*路径更平滑DWB或MPPI做局部MPPI对动态障碍响应更好。4.2 代价地图的膨胀半径是个技术活代价地图里有个参数叫inflation_radius膨胀半径它决定了障碍物周围多大范围被标记为高代价。这个参数设小了机器人贴着墙走容易刮蹭设大了窄门口直接过不去。计算逻辑是这样的膨胀半径至少要大于机器人内切圆半径。假设扫地机直径0.35米内切圆半径0.175米那膨胀半径设0.2米比较稳妥。但门口宽度如果只有0.4米膨胀后两边各占0.2米中间就只剩0.0米机器人判定不可通行。这时候要么减小膨胀半径要么用cost_scaling_factor调整代价衰减曲线让机器人愿意贴着障碍走。我的做法是先按内切圆半径设膨胀然后在实际门口测试如果过不去再微调。别一上来就设很大那样机器人会显得很怂到处绕路。4.3 全局规划和局部规划的配合逻辑全局规划器算出的路径是理想路径它假设环境静态。局部控制器负责跟踪这条路径同时用当前激光数据实时避障。两者通过局部代价地图衔接。这里有个常见误区全局路径穿过了一个动态障碍比如临时放的椅子局部控制器会尝试绕开但如果绕开幅度太大偏离全局路径太远就会触发重规划。Nav2里通过controller_server的failure_tolerance参数控制这个容忍度。我调参的经验是局部控制器的前瞻距离lookahead distance要跟速度匹配。速度0.3米每秒时前瞻0.3到0.5米比较合适。前瞻太短机器人会画龙太长则转弯迟钝。5. 仿真层Gazebo里把整条链路跑通再上真机5.1 为什么一定要先在Gazebo里验证真机调试的成本太高了撞一次可能就坏一个雷达电池续航有限调试时间碎片化。Gazebo能提供可重复、可加速、可观测的验证环境。你可以在Gazebo里把机器人速度调到真机的三倍快速验证SLAM和Nav2的鲁棒性。Gazebo仿真环境模型热词里提到的搭建核心是URDF/Xacro描述机器人SDF描述世界。URDF定义连杆、关节、传感器Gazebo插件负责把传感器数据以ROS2话题形式发布出来。常用的插件有libgazebo_ros_laser.so雷达、libgazebo_ros_imu_sensor.soIMU、libgazebo_ros_diff_drive.so差速驱动。5.2 仿真和真机的差异心里要有数Gazebo再真实也有几个坑雷达噪声模型默认雷达是理想无噪声的建图会异常干净容易让你误以为算法很稳。建议手动加高斯噪声模拟真实雷达。轮子打滑Gazebo里轮子几乎不打滑里程计过于完美。真机上地毯、门槛都会导致打滑所以里程计融合策略要留余量。物理引擎差异Gazebo的摩擦系数、碰撞模型和真实世界有偏差导航参数不能直接照搬。我的建议是Gazebo里把参数调到比真机更苛刻比如加噪声、加延迟这样上真机时反而会觉得比仿真还简单。5.3 从仿真到真机的迁移检查清单迁移前逐项确认TF树结构一致坐标系命名统一传感器话题名称和消息类型一致里程计标定参数按真机重新测量代价地图尺寸覆盖真机工作区域速度限制按真机电机能力下调急停和恢复行为在真机上实测有效这套流程走下来真机首次跑导航的成功率会高很多。我见过太多人仿真里跑得飞起真机一上就撞墙基本都是迁移时漏了某一项。6. 那些让我熬夜的坑以及怎么绕过去6.1 ROS2环境安装的公钥报错热词里反复出现由于没有公钥无法验证下列签名这个报错这是ROS2安装最经典的拦路虎。根因是apt的密钥环里没有ROS仓库的公钥。解决办法是重新导入公钥然后apt update。如果还不行检查系统时间是否准确时间偏差会导致签名验证失败。Ubuntu 22.04对应ROS2 Humble24.04对应Jazzy。别装错版本否则Gazebo和Nav2的包依赖会对不上。我建议新手直接用Humble社区资料最多遇到问题一搜就有答案。6.2 RViz2里地图不显示或机器人闪烁这个问题九成是TF问题。排查顺序先view_frames看树结构再ros2 topic echo /tf看变换是否在发布最后检查时间戳是否同步。如果机器人闪烁通常是map到odom的变换在跳变说明SLAM位姿估计不稳定回去检查传感器融合配置。6.3 导航时机器人原地打转或撞墙原地打转一般是局部控制器参数问题检查min_vel_theta和max_vel_theta是否合理以及代价地图里机器人 footprint 是否设置正确。撞墙则多半是膨胀半径太小或者雷达盲区没处理。扫地机雷达一般有360度覆盖但如果有遮挡要在代价地图里把盲区标记为未知。6.4 建图保存后加载地图和实际对不上这是地图原点问题。SLAM保存地图时地图原点对应建图起点的位姿。如果导航时机器人初始位姿和建图起点不一致又没做重定位地图就会错位。解决办法是用AMCL做粒子滤波重定位或者手动在RViz2里用2D Pose Estimate给初始位姿。7. 把这套链路复用到其他机器人上这套感知-建图-导航-仿真的链路其实不限于扫地机。你把底盘换成差速、阿克曼或者全向把雷达换成3D LiDAR或者深度相机整体架构不变。热词里提到的Panda机械臂Gazebo仿真、MoveIt2和RViz2同步那是机械臂领域的类似问题核心同样是TF树和插件化架构。我个人的体会是ROS2的学习曲线陡但一旦你把TF、话题、插件这三件事吃透后面换任何机器人都是换汤不换药。真正难的不是某个算法而是把整条链路的每个环节都调通、调稳。建图时多花一小时标定导航时就能少撞十次墙这个投入产出比非常划算。最后分享一个我常用的小技巧建图和导航切换时写一个launch文件用参数控制模式避免手动改配置。这样你可以在同一个终端里一键切换调试效率能提升不少。