简介：基于ROS的激光雷达SLAM建图与路径规划C++项目，提供完整源码与配套文档，面向需要完成课程设计、期末大作业或入门机器人自主导航的开发者。内容覆盖SLAM建图、定位、路径规划三大核心模块，并附算法介绍与主要注意事项，适合已有ROS基础的学习者直接参考或二次开发。压缩包共109个文件，包含16个cpp源文件、14个h头文件、16个launch启动脚本、18个yaml参数配置，以及rviz可视化配置、urdf模型、pgm地图、md说明文档等，包体仅6.05MB，目录结构清晰。该项目曾获导师指导并评定97分，下载后无需修改即可运行，能帮助读者快速搭建完整导航流程，理解gmapping、amcl等典型算法在实际机器人上的集成方式，也可作为答辩展示与实验报告的强有力支撑。目前已有1170人学习，适合需要高效完成高质量大作业或系统学习ROS导航栈的人群。
1. 项目整体设计方案与关键技术选型
1.1 项目背景与解决的核心问题
做机器人导航开发的朋友应该都有同感：SLAM建图、定位、路径规划这三件事，单独拎出来任何一个都能写好几篇论文，真要把它们串成一个完整的、能在真实机器人上跑通的系统，才是真正磨人的地方。我这次整理的项目，就是一套基于ROS（Robot Operating System）的完整导航解决方案，源码全部用C++实现，覆盖了从激光雷达数据采集、SLAM建图、实时定位到路径规划与避障的全链路流程。
这个项目解决的核心问题很直接：让一台搭载激光雷达的移动机器人，在未知环境中自主构建地图、确定自身位置，并规划出一条安全可行的行驶路径。对于刚入门ROS机器人开发的同学来说，最大的痛点往往是资料零散，知道Gmapping能建图、move_base能导航，但不知道这些模块之间怎么配合，TF树怎么搭，参数怎么调。这个项目提供的就是一套可以直接跑的参照实现，配套文档把算法原理和关键实现都讲清楚了，适合正在学习ROS导航栈、准备做毕设或参加机器人竞赛的同学参考。
1.2 为什么选择ROS搭配激光雷达的SLAM方案
关于SLAM的方案选型，业内其实讨论很多。视觉SLAM用相机做输入，优势在于信息丰富、成本低，但受光照影响大，对算力要求也高。激光雷达SLAM则是直接用激光点云做匹配，精度高、稳定性强，在室内等结构化环境中表现非常可靠。我做这个项目时选择激光雷达，主要是看中它对环境的几何描述直接且准确，配合ROS中成熟的导航框架，调试起来心智负担小很多。
ROS之所以是机器人开发的“事实标准”，是因为它把传感器驱动、算法模块、通信机制都做成了标准化的节点（Node）和话题（Topic）。建图、定位、路径规划这些功能可以拆成独立模块分别调试，最后通过TF坐标变换和话题通信组装起来。对开发者来说，这种松耦合架构最大的好处是：哪一环出了问题，直接盯那一个节点就行，不用把整个系统推倒重来。
1.3 整体系统架构中各模块的职责划分
这套系统的架构用一句话概括就是：传感器数据进，速度指令出，中间过程全是标准ROS组件在协作。底层是激光雷达驱动节点，负责发布原始scan数据；中间层是SLAM建图节点和AMCL定位节点，一个负责构建地图，一个负责在地图上实时估算机器人位姿；上层是move_base导航框架，它接收目标点，结合地图、定位结果和代价地图，最终输出/cmd_vel速度指令给底盘。
各模块协作关系如下表所示：
| 模块 | 输入 | 输出 | 职责 |
|---|---|---|---|
| 激光雷达驱动 | 雷达原始数据 | /scan（sensor_msgs/LaserScan） | 扫描环境，提供距离数据 |
| 里程计 | 轮式编码器数据 | /odom（nav_msgs/Odometry） | 推算机器人运动增量 |
| Gmapping/SLAM | /scan + /odom + TF | /map（nav_msgs/OccupancyGrid） | 增量式构建栅格地图 |
| AMCL | /scan + /map + TF | /amcl_pose（geometry_msgs/PoseWithCovarianceStamped） | 基于粒子滤波的全局定位 |
| move_base | /map + 定位结果 + 目标点 | /cmd_vel（geometry_msgs/Twist） | 全局规划+局部规划+避障 |
熟悉ROS导航栈的朋友看到这个列表应该会有感觉——这基本就是官方navigation stack的标准架构。但我实际做下来有一个很重要的体会：标准架构只是起点，真正决定系统好不好用的是参数调优和异常处理。比如Gmapping的粒子数、move_base的膨胀半径、代价地图的更新频率，这些参数在仿真环境里跑得很顺，一上真机就暴露问题。后面我会专门讲这些坑。
2. SLAM建图模块的核心原理与实现细节
2.1 激光SLAM建图的两大流派与选型理由
目前激光SLAM的主流方案可以分为滤波器和图优化两大流派。滤波器派的代表作是Gmapping，核心思想是RBPF（Rao-Blackwellized Particle Filter），用粒子滤波器同时估计机器人轨迹和地图，每个粒子携带一幅地图假设。图优化派的代表作是Cartographer，它把扫描匹配问题建模成位姿图优化，通过回环检测消除累积误差。
我在这套项目中默认用的是Gmapping，原因很实际：Gmapping对计算资源的需求低，在中小型室内场景下精度和实时性都能兼顾，代码结构清晰，适合学习研究。但它的局限也很明显——没有回环检测，长走廊和大场景下容易地图漂移。如果你的应用场景超过几百平米，或者对地图一致性要求很高，建议换成Cartographer。我在项目文档里也补充了Cartographer的移植说明，方便有需要的同学自行切换。
2.2 Gmapping节点的工作流程与关键参数解读
Gmapping的运行流程可以拆成三步：运动更新、扫描匹配、地图更新。运动模型预测粒子位置，然后每个粒子根据当前激光扫描与已有地图的匹配程度分配权重，权重低的粒子会被淘汰，高权重粒子通过重采样增殖。这个过程每一帧激光数据都在重复，持续修正机器人的位姿估计。
关键参数方面，最需要关注的是这几个：
particles：粒子数，默认30。室内小场景20-30足够，粒子太多CPU吃紧，太少建图质量下降。minimumScore：扫描匹配的最低得分，默认0.0。如果建图时经常出现地图错位，试着调到0.3左右，低于这个分数的帧会被拒绝，防止烂数据污染地图。updateInterval：地图更新间隔，默认5.0秒。周期太长地图刷新滞后，太短则CPU满载。linearUpdate/angularUpdate：触发扫描匹配的位移/角度阈值。机器人移动距离或转角超过设定值才做匹配更新，这个值设小一点匹配更频繁，但CPU开销大。
2.3 建图实操流程与建图质量把控技巧
实际建图过程中，我总结了一套固定的操作流程，按这个顺序走，地图质量基本有保障：
- 手动遥控或程序控制机器人遍历环境，速度控制在0.2-0.3m/s以内，转弯时尽量原地旋转，避免急打方向导致里程计打滑。
- 建图路径规划要从环境边界开始，由外向内绕圈。先沿墙走一圈让Gmapping确认环境轮廓，再逐步填充内部区域，减少累积误差。
- 同一区域至少经过两遍，这样扫描匹配有更多约束，地图一致性更好。
- 建图完成后执行
map_saver保存地图，生成pgm图片和yaml配置文件。
建图质量有一个很重要的判断标准：看地图的墙线是否笔直，宽度是否与真实环境一致。如果墙壁出现重影或双层轮廓，通常是扫描匹配失效或里程计漂移。此时检查最小得分参数、降低机器人速度，或者检查雷达安装是否牢固。
注意：Gmapping建图对雷达安装位置敏感。雷达必须水平安装且与机器人底盘中心轴对齐，倾斜超过2-3度就会导致建图严重畸变。用ROS的rqt_tf_tree工具查看TF树时，base_link到laser的坐标变换必须与实际物理位置一致。
3. 定位模块的工程实现与调参经验
3.1 AMCL粒子滤波定位的工作原理
地图建好了，机器人怎么知道自己在地图上的哪个位置？这就是定位模块要回答的问题。我选用的AMCL（Adaptive Monte Carlo Localization）是ROS导航栈中的标准定位方案，它用一组带权重的粒子来表示机器人位姿的概率分布。初始时粒子随机撒在地图上，每帧激光数据进来后，通过对比粒子位置的虚拟扫描与实际扫描来计算权重，权重高的粒子存活，低的被淘汰并重采样到高权重粒子附近。
这套思路最大的优点在于多峰追踪能力——即使初始位姿不确定（比如机器人被放到一个陌生位置），粒子也能分散在地图上多个可能的假设，最终收敛到正确位置。实际项目中有个很常见的场景：机器人被抱起来挪了个地方，AMCL能通过重定位（re-localization）机制找回真实位姿。
3.2 AMCL参数调试的关键维度与建议值
AMCL的参数比Gmapping更琐碎，但核心就三个维度：粒子数量、运动模型噪声、激光模型噪声。
基础参数上，min_particles和max_particles决定粒子上限和下限，默认分别是100和5000。动态调整的原理是：机器人定位越确定，粒子数越少，CPU占用越低；定位越不确定，粒子数自动增加，加快收敛。需要注意粒子数量太小时，在小空间快速移动的机器人容易“跟丢”，表现为定位突然跳变或地图坐标系漂移。
运动模型参数odom_alpha1到odom_alpha5描述的是里程计噪声模型。简单说，这四个值越大，意味着系统越不相信里程计读数，粒子运动会更加发散。真机调试时如果发现定位漂移，可适当增大odom_alpha1（旋转噪声）和odom_alpha3（平移噪声）。但也不宜过大，否则粒子收敛速度会变慢。
激光模型参数laser_z_hit、laser_z_rand等描述激光数据的噪声特性。其中laser_z_hit权重越高，系统越信任实际激光命中，定位越紧贴环境结构；但调太高时，动态障碍物（如行人经过）会造成定位跳动，一般建议0.9左右。
3.3 定位异常时的排查思路与实测对比
我调试过程中碰到最典型的问题是：建图时很正常，导航过程中机器人定位突然“飞”出地图。排查下来，绝大多数原因是AMCL的odom坐标系和实际底盘的里程计不一致。这里需要理解TF树中两个关键坐标关系：map -> odom -> base_link -> laser。odom->base_link由里程计提供，map->odom由AMCL维护。
定位飘移时，先用rviz同时显示TF坐标轴和激光点云。如果激光点云与地图边缘“错开”，先看odom->base_link的TF是否有跳变（跳变说明里程计异常），再检查雷达安装的laser->base_link坐标值是否正确。这两个坐标关系只要错一个，后续全错。
另外一个小经验：调试定位时，记得把initial_pose设置在地图已知位置再启动。否则AMCL需要时间从全局粒子发散中收敛，在这期间机器人移动越远，定位误差越大。工程实用中，很多团队会在机器人启动时做一次“初始位姿校准”，比如对着某个特征明显的墙壁，然后手动设定初始位姿，效率比让AMCL自己找要高得多。
4. 路径规划模块的实现、选型与避坑指南
4.1 move_base框架下全局规划与局部规划的协作逻辑
路径规划在ROS中由move_base节点统一管理，内部又细分成全局规划器（global_planner）和局部规划器（local_planner）。全局规划器在静态地图上算出从起点到目标点的大致路径，用的是A*或Dijkstra算法，地图是静止的costmap。局部规划器负责在机器人实际行驶过程中实时避障，它只关注机器人周围一小块代价地图，根据当前位置、目标方向、全局路径和实时传感器数据，输出实际的速度指令。
为什么需要两层规划？打个比方：全局规划是看地图决定“走哪条路”，局部规划是看路面决定“怎么走”。全局路径可能规划出一条经过走廊的路线，但走廊里突然出现一把椅子，全局规划器不知道，局部规划器会在靠近椅子时生成平滑的绕行速度指令。两层协作，既保证了长距离的路径最优性，也保证了短距离的行驶安全。
4.2 全局规划器选型：A*、Dijkstra与ROS默认行为
ROS的global_planner插件支持两种搜索算法：A*和Dijkstra。简单区分一下：
- Dijkstra：从起点向外均匀扩展，直到找到终点。保证最优解，但搜索范围大，耗时较长。
- A*：在Dijkstra基础上加了启发函数（通常用欧几里得或曼哈顿距离），优先扩展距离目标点更近的节点，搜索效率更高，多数情况下也能得到最优解。
我的项目默认使用A*，配置方式是：
GlobalPlanner: use_dijkstra: false use_grid_path: false use_quadratic: true其中use_quadratic启用二次函数插值，让规划出的路径更平滑，避免出现尖锐折线。use_grid_path如果为true则严格沿栅格中心行走，路径会呈现锯齿状，一般设false。
4.3 局部规划器：TEB算法实测与参数调整心得
局部规划器我选的是teb_local_planner（Time Elastic Band），相比ROS默认的DWA，TEB能显式考虑时间最优、路径平滑和动态约束，在窄通道和动态环境下表现明显更好。TEB的核心思路是把路径和速度当成一条“橡皮筋”，通过图优化在满足约束的前提下让橡皮筋绷紧到最优。
TEB最关键的参数是max_vel_x和max_vel_x_backwards，分别控制最大前进和后退速度。我项目中的初始配置是前进0.5 m/s，后退不启用。acc_lim_x影响加速快慢，太大容易造成底盘打滑和定位丢帧。min_obstacle_dist是避障安全距离，不小于机器人半径+激光雷达盲区对应的距离。对60cm直径的底盘，我的建议值是0.3-0.4m，太小会刮蹭，太大则窄门过不去。
有个容易踩的坑：TEB优化时，如果代价地图配置了很高的膨胀层，TEB会绕很远的弯。因为膨胀代价会让“靠近障碍物”的路径得分很高，优化器倾向于远离障碍物。这时需要合理设置inflation layer的cost_scaling_factor，默认10.0，可尝试调到3.0-5.0，让代价衰减更平缓，路径不会过于保守。
4.4 代价地图三层结构与膨胀半径设置
代价地图（costmap）是路径规划感知“哪里能走哪里不能走”的基础。ROS的标准costmap由三层组成：
- static_layer：加载静态SLAM地图，标记已知障碍物。
- obstacle_layer：实时接收激光雷达scan数据，标记动态障碍物。
- inflation_layer：对障碍物做“膨胀”处理，生成从致命代价（栅格被占据）到安全代价（远离障碍物）的梯度场。
三层的职责划分，简单理解就是：哪来的墙（静态）、哪来的新障碍（动态）、该离它们多远（膨胀）。
膨胀半径参数inflation_radius必须根据机器人尺寸调整。机器人半径15cm，那膨胀半径至少设0.3-0.5m，因为规划器把机器人当质点处理，真实底盘是有宽度的。膨胀太小机器人会擦墙甚至卡住，膨胀太大则无法通过窄门。实际经验是：先量好机器人最窄可通过宽度，再反推膨胀半径上限。
5. 常见问题速查表与项目二次开发建议
5.1 高频故障场景与解决方案对照
我整理了这个项目在实际运行中最常见的几个问题，摘录如下，供大家排查时对照：
| 故障现象 | 可能原因 | 解决措施 |
|---|---|---|
| 建图重影、地图墙壁双层 | 里程计打滑/雷达安装松动 | 降低车速，检查TF坐标值，检查雷达固定 |
| 定位突然跳变 | AMCL参数不合理或初始位姿差 | 增大粒子数，检查odom噪声系数，手动校准初始位姿 |
| 规划路径异常绕路 | 膨胀半径过大或cost_scaling_factor过高 | 调小inflation_radius，降低cost_scaling_factor |
| move_base一直报“全局规划失败” | 目标点在障碍物内或地图与真实不一致 | 检查目标点合法性，重新建图或膨胀区域 |
| 机器人导航时剧烈抖动 | TEB权重参数冲突或底盘响应延迟 | 降低max_vel_x，增大加速度限制，检查底盘PID参数 |
| CPU占用过高 | 粒子数过多或代价地图更新频繁 | 减少AMCL粒子数量，调低代价地图update_frequency |
5.2 文档中强调的三大注意事项回顾
文档说明里反复强调的“主要事项”，我用自己的实践总结一下，大致是这三条：
第一，TF坐标变换是整个系统的“血管”。建图要TF，定位要TF，规划输出速度指令也要TF。任何节点的数据错乱，先查TF树，再查代码逻辑。用tf_monitor或rqt_tf_tree定期检查，能省下大量排查时间。
第二，传感器的标定不可跳过。激光雷达与底盘中心存在安装偏移，必须在URDF模型或静态TF发布中如实反映。雷达角度偏移1度，5米外的误差就将近9cm，会直接影响建图精度和避障安全。
第三，参数不是越多越好，理解比堆砌更重要。很多同学拿到别人的参数文件直接套用，结果在自己的机器人上各种问题。每个参数控制什么、为什么这样设，一定要结合自己的底盘和雷达重新推导。
5.3 从“能跑”到“好用”的二次开发建议
如果你的目标是把这个项目用在真实场景中，下面几个方向值得关注：
- 升级SLAM算法：把Gmapping替换为Cartographer，获得回环检测能力，支持更大场景和更复杂环境。
- 融合多传感器：加入IMU（惯性测量单元）与轮式里程计的融合（如robot_localization），提高里程计精度，尤其适合粗糙地面和上坡场景。
- 接入动态避障策略：在TEB基础上引入行人轨迹预测或深度相机点云，让机器人在人流中也能安全穿行。
- 优化底盘控制：用MPC（模型预测控制）替代传统PID速度环，让运动控制更平滑，减小对定位的干扰。
代码层面，我会推荐将各个模块封装成独立功能包（package），通过launch文件统一启动参数。这样后期修改模块时不用改动其他部分，也方便整个工程移植到新的机器人平台上。
我在实际使用中的体会是：ROS导航栈本身是一套非常成熟的框架，难的不是把节点跑起来，而是理解每个节点在“替你做什么假设”。比如Gmapping假设环境是静态的，AMCL假设地图是可信任的，move_base假设底盘能响应速度指令。当你把每一个假设都验证过一遍，这套系统才算真正是你的。希望这份项目总结能让你在调通的路上少走几个弯路。
本文还有配套的精品资源，点击获取
