1. 从一堆散乱点云到一张能用的地图中间到底发生了什么扫地机器人能自己规划路线、绕开拖鞋、钻进沙发底下再自己出来靠的不是什么黑魔法而是背后一整套SLAM同步定位与建图加Nav2 导航的链路在支撑。我前后折腾过好几台基于 ROS2 的移动机器人从最便宜的二维雷达小车到带三维激光的底盘踩过的坑能写满一个笔记本。这篇就把“从点云到地图”这条链路完整拆一遍讲清楚 SLAM 怎么把一帧帧点云拼成地图Nav2 又怎么拿着这张地图把机器人从 A 点送到 B 点中间 LiDAR、IMU、Gazebo 仿真、RViz2 可视化这些环节各自扮演什么角色。如果你刚开始接触 ROS2或者已经能跑通 TurtleBot3 的官方 demo 但一到自己搭车就懵那这篇基本就是给你写的。我会尽量把每个参数为什么这么设、每个坐标系为什么这么连讲透而不是甩一堆命令让你照抄。毕竟照抄能跑通一次但换个雷达、换个底盘就又歇菜了只有搞懂链路才敢接私活。整条链路我习惯分成两大段来看前端是 SLAM负责“我在哪、周围长啥样”后端是 Nav2负责“我该怎么走过去”。中间靠一张地图、一套 TF 坐标变换、一堆话题和服务把它们缝在一起。下面按这个思路一层层剥。2. 整体链路设计与方案选型为什么是这套组合2.1 先想清楚二维 SLAM 还是三维 SLAM很多人一上来就问“用哪个 SLAM 算法好”其实这个问题问反了。应该先问你的雷达是二维还是三维你的场景是单层还是多层。二维激光雷达比如常见的 RPLIDAR、思岚系列扫出来的是一个平面上的距离点SLAM 出来的是一张二维栅格地图每个格子标记为“占用/空闲/未知”。这种方案算力需求低一张地图几 MBNav2 直接就能用扫地机器人绝大多数走的就是这条路。三维激光雷达比如 16 线、32 线扫出来的是空间点云能感知高度信息适合多层建筑、有坡道、有悬空障碍的场景。但三维 SLAM 出来的地图要么是点云地图几 GB 起步要么得投影成二维栅格或者八叉树地图才能给 Nav2 用。八叉树地图OctoMap就是把三维空间切成一个个小立方体每个立方体记录被占用的概率既能表达三维结构又能压缩体积是三维导航里很常见的一环。我的建议很直接扫地机器人这种贴地跑的老老实实二维 SLAM 加二维 Nav2别给自己找麻烦。三维雷达留给无人机、机械臂、多层巡检机器人。热搜里那个“nav2导航使用3d雷达”确实能做但通常是把三维点云压成二维代价地图再用本质还是二维导航。2.2 SLAM 算法怎么挑Cartographer、SLAM Toolbox 还是别的ROS2 生态里能直接用的二维 SLAM 主要有两个Cartographer和SLAM Toolbox。Cartographer 是谷歌开源的回环检测强建大场景地图不容易漂但配置项多、调参门槛高而且 ROS2 版本维护节奏不如以前活跃。SLAM Toolbox 是 ROS2 原生生态里更主流的选择支持在线建图、离线建图、地图续建和 Nav2 配合得也顺配置文件相对好懂。我现在的默认选择是SLAM Toolbox理由有三个一是它原生支持 ROS2 的生命周期节点管理启停干净二是它能把建好的地图直接序列化成.posegraph和.data文件下次可以接着建不用从头来三是它的参数文档清楚遇到问题好排查。Cartographer 我一般只在客户明确要求、或者场景特别大几百米以上走廊的时候才上。2.3 仿真先行为什么一定要在 Gazebo 里先跑通真机调试 SLAM 有个致命问题你分不清是算法错了还是硬件错了。雷达装歪了、IMU 没标定、轮子打滑、时间戳对不上任何一个都能让建图飘得一塌糊涂而你在真机上排查这些成本极高。Gazebo 仿真的价值就在这它给你一个理想但可配置的环境。雷达数据是干净的轮子不打滑时间戳是同步的你可以先把算法链路跑通确认 TF 树、话题、参数都没问题再上真机。真机上再出问题那基本就是硬件和标定的锅排查范围一下子缩小了。我一般的流程是Gazebo 里跑通建图 → Gazebo 里跑通导航 → 导出地图 → 真机复现。热搜里那一堆“gazebo仿真环境模型”“gazebo 参数”“gazebo教程”说明大家卡在仿真环境搭建上的不少后面我会专门讲。2.4 整条链路的数据流先把数据流画清楚后面每个环节才好对号入座LiDAR发布/scan二维或/points三维话题内容是距离点。IMU发布/imu/data提供角速度和加速度帮 SLAM 判断转向。里程计发布/odom来自轮子编码器提供粗略位移。SLAM 节点订阅上面这些输出/map栅格地图和map→odom的 TF 变换。Nav2订阅/map结合/scan生成代价地图规划路径输出/cmd_vel控制轮子。RViz2订阅所有话题把点云、地图、路径、机器人模型画出来给你看。关键就在TF 树map → odom → base_link → laser这条链必须完整且不断裂断了 RViz2 里机器人就飘Nav2 直接罢工。这是新手最容易翻车的地方后面单独讲。3. 核心细节解析TF、标定与那些要命的参数3.1 TF 坐标树整条链路的骨架TF 是 ROS 里描述“谁在谁的坐标系下、什么姿态”的机制。整条 SLAM 导航链路里至少要有这几层坐标系含义谁发布map全局地图坐标系原点固定SLAM 节点odom里程计坐标系随机器人漂移里程计节点base_link机器人本体中心静态 TF 或 URDFlaser雷达安装位置静态 TFimu_linkIMU 安装位置静态 TFmap → odom由 SLAM 发布odom → base_link由里程计发布base_link → laser是固定的安装关系用静态 TF 发布。为什么要有 odom 这一层因为里程计短期准、长期漂SLAM 短期可能跳、长期准两者结合才能既平滑又不漂。SLAM 通过不断修正map → odom来抵消里程计的累积误差这就是“定位”的本质。新手最常见的错误是雷达的静态 TF 没发或者发错了方向。记住一个口诀父坐标系在前子坐标系在后。base_link是父laser是子因为雷达装在机器人身上机器人动雷达跟着动。3.2 LiDAR 与 IMU 标定别跳过这一步真机上雷达和 IMU 的安装位置、朝向必须标定准否则 SLAM 出来的地图会扭曲。标定分两部分外参标定确定雷达、IMU 相对base_link的平移和旋转。平移好量拿尺子量安装位置就行旋转麻烦因为雷达的 0 度朝向、IMU 的轴向不一定和机器人正前方一致。我一般用tf2的静态发布工具先填一个估计值然后在 RViz2 里看激光扫描和地图是否对齐不对就微调 yaw 角。IMU 内参标定主要是零偏和噪声。IMU 静止时会输出一个非零的角速度这就是零偏不扣掉的话 SLAM 会以为机器人在慢慢转。标定方法很简单把机器人放平静止几分钟采集数据算平均值写进配置。噪声参数影响滤波权重一般用厂商给的 datasheet 值起步。提示二维 SLAM 对 IMU 的依赖其实没那么强很多纯激光 SLAM 不用 IMU 也能跑。但一旦场景里有长走廊、特征少IMU 能显著提升鲁棒性。三维 SLAM 则基本离不开 IMU。3.3 SLAM Toolbox 关键参数怎么设SLAM Toolbox 的配置我挑几个最影响效果的讲max_laser_range雷达最大有效距离。设太大远处噪声点会污染地图设太小地图建不全。一般设成雷达标称量程的 80% 左右。resolution地图分辨率单位米/格。0.05 是默认值也就是 5 厘米一格。扫地机器人用 0.05 够了太小地图文件爆炸太大细节丢失。minimum_travel_distance/minimum_travel_heading机器人移动多少距离/转多少角度才插入一帧新数据。设太小地图糊设太大细节丢。一般 0.5 米和 0.5 弧度起步。transform_timeout等 TF 的超时时间。仿真里可以设小真机上雷达和里程计有延迟得设大点否则频繁报 TF 超时。这些参数没有万能值得根据你的雷达频率、机器人速度、场景大小调。我的经验是先按默认跑一遍看地图哪里糊、哪里飘再针对性调。3.4 Nav2 的代价地图导航的“路况图”Nav2 不是直接拿 SLAM 的栅格地图规划路径的它要先转成代价地图Costmap。代价地图分两层全局代价地图基于整张地图用于全局路径规划算得慢但看得远。局部代价地图基于雷达实时数据用于局部避障算得快但只看眼前。每个格子有个代价值0 是自由通行255 是致命障碍中间值表示“离障碍多近”。机器人规划路径时会尽量走代价值低的格子这样自然就远离了墙壁和障碍物。代价地图里有个关键参数叫inflation_radius膨胀半径它把障碍物往外“撑大”一圈让机器人不会贴着墙走。这个值一般设成机器人半径加一点余量。设太小机器人会蹭墙设太大窄门过不去。扫地机器人半径通常 15-20 厘米膨胀半径设 0.25-0.3 米比较合适。4. 实操过程从零把链路跑起来4.1 环境准备与 ROS2 安装我用的环境是 Ubuntu 22.04 加 ROS2 Humble这是目前最稳的组合。热搜里那个“ubuntu26.04安装ros2”目前还不现实26.04 还没正式发布别折腾。ROS2 安装走官方 apt 源最省心sudo apt update sudo apt install curl gnupg lsb-release sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(lsb_release -cs) main | sudo tee /etc/apt/sources.list.d/ros2.list /dev/null sudo apt update sudo apt install ros-humble-desktop装完记得 source 环境写进.bashrc省得每次手动echo source /opt/ros/humble/setup.bash ~/.bashrc source ~/.bashrc热搜里那个“获取:1 http://packages.ros.org/ros2/ubuntu jammy inrelease 错误”是典型的源没配好或者网络问题检查一下lsb_release -cs输出是不是jammy以及 key 有没有导入成功。4.2 Gazebo 仿真环境搭建Gazebo 和 ROS2 的集成现在叫gazebo_rosHumble 里装ros-humble-gazebo-ros-pkgs就行。仿真环境我一般自己搭因为官方 world 文件太简单测不出问题。一个能用的仿真 world 至少要有地面、几面墙、几个障碍物箱子、柱子、一个能跑的机器人模型。机器人模型用 URDF 或 SDF 描述里面要挂上雷达和 IMU 的插件让它们能发布话题。雷达插件配置里几个关键参数plugin namelaser filenamelibgazebo_ros_ray_sensor.so ros remapping~/out:scan/remapping /ros output_typesensor_msgs/LaserScan/output_type frame_namelaser/frame_name min_range0.1/min_range max_range12.0/max_range samples360/samples /pluginsamples是每圈采样点数360 就是每度一个点够用了。max_range要和 SLAM 配置里的max_laser_range对得上否则地图边缘会出问题。注意Gazebo 里雷达的frame_name必须和 URDF 里定义的 link 名一致否则 TF 树接不上RViz2 里啥都看不到。4.3 启动 SLAM 建图SLAM Toolbox 的启动分在线异步和在线同步两种模式。异步模式对算力要求低适合实时建图同步模式精度高但吃 CPU适合离线建图。扫地机器人用异步就行。启动命令ros2 launch slam_toolbox online_async_launch.py params_file:./my_slam_params.yaml启动后打开 RViz2添加 LaserScan、Map、TF 三个显示项。用键盘遥控机器人ros2 run teleop_twist_keyboard teleop_twist_keyboard在环境里走一圈你会看到地图一点点长出来。建图时有个技巧走慢点转弯时更慢。走太快雷达帧之间位移大匹配容易失败地图就糊了。转弯时角速度大如果 IMU 数据跟不上地图会扭。我一般把线速度控制在 0.2 米/秒角速度 0.5 弧度/秒以内。4.4 保存地图并切换到导航模式建完图先保存ros2 run nav2_map_server map_saver_cli -f ./my_map这会生成my_map.pgm图片和my_map.yaml元数据两个文件。yaml 里记录了分辨率、原点、占用阈值Nav2 靠它加载地图。然后关掉 SLAM 节点启动 Nav2ros2 launch nav2_bringup bringup_launch.py map:./my_map.yamlNav2 启动后会发布代价地图、路径、控制指令。在 RViz2 里用“2D Pose Estimate”给机器人一个初始位置再用“2D Goal Pose”点一个目标点机器人就应该自己规划路径走过去了。4.5 参数调优的实操记录第一次跑 Nav2 大概率不完美我记录几个典型调参过程问题一机器人贴着墙走蹭墙。这是膨胀半径太小。把inflation_radius从 0.2 调到 0.3机器人就离墙远了。问题二窄门过不去。膨胀半径太大门被“堵死”了。这时候要么减小膨胀半径要么调cost_scaling_factor代价衰减因子让膨胀代价衰减快一点门中间还能留出低代价通道。问题三机器人原地打转。多半是局部规划器参数问题或者 TF 有延迟。检查controller_frequency和transform_tolerance前者是控制频率后者是 TF 容忍时间。问题四路径规划失败。检查全局代价地图里目标点是不是被标记成障碍了或者机器人当前位置在代价地图里是未知区域。用 RViz2 的代价地图显示项一看便知。5. 常见问题与排查技巧实录5.1 TF 相关问题的排查套路TF 问题占了新手故障的一大半。排查顺序ros2 run tf2_tools view_frames生成 TF 树图看链路全不全。ros2 run tf2_ros tf2_echo map base_link看两个坐标系之间的变换能不能查到。RViz2 里 Fixed Frame 设成map看机器人模型和激光是否对齐。常见症状对照表症状可能原因解决RViz2 里机器人飘map→odom 没发布检查 SLAM 节点是否启动激光和机器人错位静态 TF 方向反了检查父子坐标系顺序报 TF timeout时间戳不同步检查 use_sim_time 设置地图扭曲雷达外参不准重新标定安装角度提示仿真里一定要把所有节点的use_sim_time设成true否则 Gazebo 时间和系统时间对不上TF 直接乱套。这是仿真环境最隐蔽的坑之一。5.2 建图飘移的几种典型原因建图飘移表现为地图上墙壁重影、走廊弯曲、回环对不上。原因通常有里程计标定不准轮子直径、轮距参数错了走直线实际走成弧线。用卷尺量实际走的距离和里程计读数对比算比例修正。雷达安装角度偏雷达 0 度没对准机器人正前方建图整体旋转。在静态 TF 里调 yaw。场景特征太少长走廊、大白墙激光匹配没特征可抓。这种场景要么加反光板要么靠 IMU 撑。移动太快前面说过慢点走。5.3 Nav2 导航失败的排查清单导航失败时按这个清单过一遍地图加载了吗ros2 topic echo /map --once看有没有数据。代价地图正常吗RViz2 里看代价地图显示项障碍物位置对不对。初始位置设了吗没设初始位置AMCL 不知道机器人在哪规划必失败。目标点可达吗目标点在障碍物里或者地图外规划器直接放弃。控制指令发了吗ros2 topic echo /cmd_vel看有没有速度输出。5.4 仿真与真机的差异坑仿真跑通不代表真机跑通几个典型差异雷达噪声仿真雷达是理想的真机有噪声、有盲区、有反射干扰。真机上要把 SLAM 的max_laser_range调小滤掉远处噪声。轮子打滑仿真轮子不打滑真机在地毯、门槛上会打滑里程计漂移大。这时候 IMU 的权重就要调高。计算延迟真机算力有限SLAM 和 Nav2 抢 CPU导致控制频率下降。该降分辨率降分辨率该关可视化关可视化。6. 几个能省下大量时间的实操心得折腾这套链路我最大的体会是别一上来就追求完美地图和丝滑导航先把最小闭环跑通。Gazebo 里一个方块机器人、一个简单房间、一张糊地图能跑通建图和导航就说明链路是通的。剩下的都是调参和优化是体力活不是脑力活。第二个心得是善用 ros2 bag 录数据。真机调试时把雷达、IMU、里程计话题全录下来出问题可以反复回放分析不用每次都重新跑一遍机器人。录数据命令ros2 bag record /scan /imu/data /odom /tf /tf_static回放的时候注意用--clock参数让 bag 里的时间驱动整个系统。第三个心得是参数文件一定要版本管理。SLAM 和 Nav2 的参数动辄几十个改来改去很容易忘了哪个版本好用。我习惯每个能跑通的配置存一个 yaml命名带上日期和场景比如slam_room_20240115.yaml。下次换场景直接复制一份改比从头调快得多。最后一个RViz2 的配置也存下来。每次重新配显示项很烦RViz2 可以把当前配置存成.rviz文件下次直接加载。把常用的显示项——地图、激光、代价地图、路径、TF——都配好存一份能省下大量重复劳动。这套链路我从第一次跑通到现在前后迭代了七八个版本从二维雷达小车到三维雷达底盘都趟过。核心逻辑其实一直没变SLAM 负责把点云变成地图和位姿Nav2 负责拿地图和位姿规划控制TF 把两者缝在一起。把这三件事的关系理清楚剩下的就是耐心调参。真机上的问题永远比仿真多但每解决一个你对整条链路的理解就深一层。