如果你正打算从零搭一台能自动建图、自主导航的移动机器人，或者手上已经有一台“能遥控、能出激光雷达数据”的开发平台，但一直卡在“地图怎么构建”“机器人怎么自己走到目标点”这一步，那lingbot-map这个项目值得你完整看一遍。它不是一个从零发明的全新技术，而是一整套把 2D 激光 SLAM 建图、AMCL 定位、路径规划与自主导航串起来的集成方案。名字里的“map”点明了整套系统的核心目标：让机器人先认识环境，再在环境里找到自己，最后安全地从 A 点移动到 B 点。
这篇文章会把这套系统的架构设计、核心原理、完整实操流程和我在调参过程中踩过的坑全部拆开来讲。适合正在做服务机器人、仓储 AGV、教学实验平台的开发者，也适合想把手上的差速底盘从“遥控玩具”升级成“自主移动平台”的业余爱好者。全文内容基于常见实践方案整理，你可以直接照着落地复现。
1. 项目整体设计与思路拆解
lingbot-map 这个名字很直白：它和 lingbot 这个机器人底盘配套使用，专门负责“地图”这一整条链路。我最初拿到这个项目时，最关心的问题只有一个：“它到底解决了我自己做导航时哪些脏活累活？”把方案跑通之后，我把整个项目拆成了三层来看，思路会清晰很多。
1.1 核心需求解析：导航链路缺的不是单点技术，而是拼装能力
很多机器人项目失败，不是因为传感器不先进，也不是因为算法论文没读够，而是死在“模块之间接不上”。做激光 SLAM 时，雷达话题和里程计话题对不上时间戳，地图建出来全是重影；做 AMCL 定位时，map、odom、base_link 这根 TF 树少了一条边，节点直接罢工；跑导航时，代价地图膨胀半径设置太小，机器人贴着墙走，一转弯就把自己卡死。
lingbot-map 的设计逻辑，就是先把这条链路里的每一个环节固定下来，做成一套可重复使用的系统。具体来说，它把整条导航数据流拆成了四个阶段：
- 环境感知：单线激光雷达扫描周围环境，得到 2D 点云数据，也就是激光雷达话题发布的
scan数据； - 姿态估计：底盘轮式编码器输出里程计数据，提供机器人短时间内相对运动的估计；
- 地图构建：SLAM 前端把扫描和里程计融合，实时拼接出环境栅格地图；
- 定位导航：加载离线地图，利用 AMCL 粒子滤波在已知地图上确定机器人全局位置，再由全局和局部规划器输出速度指令，驱动底盘到达目标点。
这四个阶段刚好形成一个闭环：建图需要里程计和激光，定位需要地图和激光，导航需要定位结果和代价地图。lingbot-map 的核心工程价值，就是把这个闭环里的所有接口定义清楚，让模块之间不需要“翻译”。
1.2 架构选择与方案取舍：为什么不用一家独大的方案
搭建这套系统时有几个明显的备选路线。第一条是纯视觉方案，用深度相机或者双目相机做 VSLAM，优点是室内特征丰富、能判断障碍物高度，但缺点是计算开销大、光照敏感，入门难度陡增。第二条是用 3D 激光雷达，精度高但价格直接劝退大多数预算有限的开发者和团队。
lingbot-map 最终采用的是“单线激光雷达 + 轮式里程计 + 2D 栅格地图”的经典组合。这么选不是因为它有多前卫，而是因为它足够稳。单线雷达在室内场景下的角度分辨率高，一帧扫描几百个点就够描述房间轮廓，栅格地图对计算资源要求极低，一块入门级开发板就能满足实时性要求。
关于框架选型，我还想多说一句。ROS 1 和 ROS 2 之间我做过一次比较，lingbot-map 在设计时保留了移植到 ROS 2 的空间。原因很简单：ROS 1 的生态成熟案例多，网上能搜到大量现成配置，适合快速验证；但 ROS 2 在多机通信、系统可靠性上有明显优势。如果你的团队后续要做多机器人协同，建议直接基于 ROS 2 的 Nav2 栈迁移，核心的 TF 树设计和地图格式是通用的，迁移成本主要在话题重映射和启动方式上。
1.3 系统组成与运行结构：一条数据流串起所有关键节点
用一个实际的运行场景来说明这套系统内部的信息流转：
- 雷达每 40ms 扫描一次环境，输出
base_scan话题，包含 720 个激光点的距离值； - 底盘驱动节点从编码器读取轮子转速，以 50Hz 频率发布里程计
odom，同时更新odom -> base_footprint的变换关系； - 建图阶段，Gmapping 节点同时订阅
scan和odom，执行粒子滤波，实时更新并发布map -> odom的变换； - 运行导航时，AMCL 节点订阅激光数据和地图数据，通过粒子传播估算机器人在地图中的位姿，发布
map -> odom的变换，整个计算循环替掉了原来的 SLAM 建图节点； - move_base 订阅 AMCL 给出的定位结果，在全局代价地图上规划一条到目标点的路径，再通过局部规划器把路径分解成一个个速度指令
cmd_vel，底盘收到后执行。
这套结构最让我感触的一点是，导航系统的问题排查，绝大多数时候就是沿着这条数据流往上回溯。哪个话题没数据，哪个 TF 断了，哪个节点的参数不对，顺着链路查一遍就能锁定问题区域。所以我在实际调试时，永远先rqt_graph看节点关系图，再rostopic list看话题列表，最后才翻具体参数，顺序不能乱。
2. 核心细节解析与关键工具选型
架构层面把链路想清楚之后，接下来要把每个环节落到具体工具和参数上。这一章会重点讲硬件怎么选、TF 树怎么设计、建图与导航算法各自适合什么场景，这几件事决定了你后续调试是顺利还是反复折腾。
2.1 硬件选型与传感器配置：决定精度的不是参数表，而是实际安装
硬件这条线看起来没什么技术含量，但我吃过亏。最早做项目时，我用了一套很便宜的某国产单线雷达，参数表上写着测距范围 12 米、频率 10Hz，实际装到机器人上一测，接近白色墙面时确实能到 12 米，但换个浅色反光地面，数据直接乱跳。后来换成成熟厂牌的雷达，同样装法，数据一下就干净了。所以我建议传感器预算不要压得太狠，选一款量产成熟、文档齐全的单线激光雷达，比后期反复处理脏数据划算得多。
雷达安装高度也要注意。装得太低，地面杂物和机器人自己的脚都会扫进地图，建出来的地图有很多噪点；装得太高，矮小的障碍物检测不到，导航时可能把桌子腿当成不存在。常见机器人平台的高度在 20~30cm，雷达中心装在这个区间偏上一点比较稳，同时要留意雷达帧率和每个分帧的角度分辨率是否匹配你的底盘最大角速度。
里程计这边，双轮差速底盘常见的编码器是增量式光电编码器，常见精度在 500 线到 1000 线之间。如果预算允许，选带霍尔编码器或磁编码器的电机驱动方案，因为增量式编码器在电机堵转时容易丢步，丢了步数就直接表现为里程计漂移，最终效果就是建图时墙体位置对不齐。
2.2 坐标变换树设计：ROS 导航的命脉，比算法本身更容易出问题
TF 树是 lingbot-map 这套系统里最容易被忽略又最容易出问题的部分。很多读者第一次自己写导航配置时，盯着代码里的参数反复调，但机器人就是不动，最后发现是 TF 树里少了一条静态变换。用一句话描述 TF 树的作用：机器人身上的每一个关键坐标点，都能通过一系列变换，换算到同一个世界坐标系下。
标准的三帧结构是：
map：地图坐标系，是建图和导航的全局参考系，原点通常设在机器人的初始位置；odom：里程计坐标系，是机器人连续运动估计的参考系，由轮式编码器推算，特点是局部准确但会缓慢漂移；base_footprint/base_link：机器人本体的坐标系，base_footprint是地面投影点，base_link是底盘中心，两者之间的变换是固定的。
这三帧之间存在两条必须保证连续的链路。第一条是odom -> base_footprint，由底盘驱动节点基于编码器数据实时发布，频率至少 20Hz 以上，否则轨迹推算不够平滑。第二条是map -> odom，在建图阶段由 SLAM 节点发布，在导航阶段由 AMCL 发布。这两条链路在逻辑上是串行的，谁断了都会导致控制端拿到错误的位置信息。
再加上雷达在机器人上的安装位置，我们需要一条静态变换base_footprint -> laser_link，数值就是雷达相对底盘中心的 x、y 偏置和 z 高度。这里有一个细节：很多底盘厂商给的模型描述文件里，laser_link的 z 值是 0，意味着雷达贴着地面，实际上只要雷达装得稍微高一点，这个变换就必须写对，否则导航时会把地面当成障碍物。
2.3 建图与定位算法选型：Gmapping、Cartographer 和 AMCL 的适用边界
建图算法我做过几组对比实验，先说结论：室内中小场景，Gmapping 是效率最高的选择；大范围或闭环较多的场景，Cartographer 有回环检测优势；而精度要求极高的场景，两个方案都需要配合更好的轮式里程计，算法本身不是瓶颈。
Gmapping 是基于粒子滤波的 2D SLAM 方案，它的核心思路是：用一组粒子表示机器人可能的位置和构图历史，每来一帧激光扫描，根据运动模型和观测模型更新粒子的权重，权重最高的那部分粒子代表的位置，就是机器人当前最可能的位置。它的问题在于，当环境变大时，所需粒子数会膨胀，消耗大量计算资源，而且它本身没有显式的回环检测机制，长走廊容易在走回来时出现拼不上的情况。
Cartographer 走的是图优化路线，把每一帧激光扫描当作一个节点，把节点之间的位姿关系当作边，后端用非线性最小二乘来优化整张图。由于它保留了过去所有帧的约束关系，回到曾经走过的地方时可以进行闭环修正，地图会更加一致。代价是内存占用和维护复杂度都上了一个台阶。
定位环节用的是 AMCL，全称是自适应蒙特卡洛定位。它本质也是一个粒子滤波器，但它的目标是“在已有地图上定位”，而不是“同时建图和定位”。所以它不再更新地图，只更新机器人在地图中的概率分布。启动时可以指定一个初始位姿（通常是在地图上手动给定大致位置），之后粒子会根据激光扫描与地图的匹配程度收敛。它的参数里有一个粒子数量上限，数量太少容易定位失败，数量太多帧率下降，常见室内场景取 1000~2000 个粒子即可。
3. 实操过程与核心环节实现
从环境搭建到完整跑通导航，我按“建图 → 保存地图 → 加载地图定位 → 导航测试”这条主线来记录。每一步命令和参数都可以直接抄作业，但真正值得关注的是每一步背后的校验点和容易掉进去的坑。
3.1 环境准备与依赖安装：先确保底盘、雷达、系统三方对齐
我在一台入门级工控机上做的验证，系统是 Ubuntu 20.04，配合 ROS Noetic。这个组合放弃了对 Ubuntu 最新发行版的支持，但换来的是所有常用 SLAM 和导航包都有官方预编译版本，不用自己编一堆依赖。如果你用的是 Arch 或 Fedora，光编译一套 Cartographer 的依赖就够折腾两天的。
安装核心依赖的步骤：
sudo apt update sudo apt install ros-noetic-slam-gmapping sudo apt install ros-noetic-amcl sudo apt install ros-noetic-move-base sudo apt install ros-noetic-map-server sudo apt install ros-noetic-teb-local-planner sudo apt install ros-noetic-ros-control ros-noetic-ros-controllers装完以后先别急着往下走，做一次“裸启动校验”：只启动底盘驱动节点，然后用rostopic echo /odom看一下有没有连续的数据发布，用rostopic hz /base_scan看雷达帧率是否稳定在 10Hz 左右。这一步非常关键，因为如果底盘驱动和雷达驱动本身就有问题，所有后续调参都是在错误的数据上打转。
3.2 模型描述与坐标变换配置：把每个关节的物理关系写进系统
接下来要为机器人创建一个 URDF 模型描述文件。这个文件的作用不仅是可视化，更重要的是它定义了 TF 树中所有静态变换的初始值。以下是一个最小可用的差分底盘 URDF 示例，里面包含了两个关键宏和五个核心 Link：
<?xml version="1.0"?> <robot name="lingbot"> <link name="base_footprint"/> <link name="base_link"/> <joint name="base_footprint_joint" type="fixed"> <parent link="base_footprint"/> <child link="base_link"/> <origin xyz="0.0 0.0 0.0" rpy="0 0 0"/> </joint> <!-- 雷达固定在底盘中心前方8cm、高20cm处 --> <link name="laser_link"/> <joint name="laser_joint" type="fixed"> <parent link="base_link"/> <child link="laser_link"/> <origin xyz="0.08 0.0 0.20" rpy="0 0 0"/> </joint> <!-- 左轮和右轮只是示意，实际驱动节点会计算轮速 --> <link name="left_wheel"/> <link name="right_wheel"/> </robot>写好 URDF 后，启动robot_state_publisher节点加载它，它会自动发布所有固定关节的静态变换。用下面的命令验证：
rosrun tf tf_echo base_footprint laser_link如果输出里的 Translation 和 Rotation 与你配置的数值一致，说明这棵树搭起来了。这里要强调一个经验：写laser_link的安装位置要拿尺子实测，不能凭感觉估，因为激光雷达的水平偏移值和高度误差，会被 SLAM 算法放大到整张地图里，最后体现在“墙体错位、墙角变圆弧”这些现象上。
3.3 手动建图全流程：从启动 SLAM 到保存地图的完整五步
建图的前提是底盘能遥控。我常用一个简单的手柄节点发布cmd_vel，你也可以用teleop_twist_keyboard来遥控。接着按下面五个步骤操作。
第一步，启动底盘驱动，让它发布odom和 TF：
roslaunch lingbot_bringup base_driver.launch第二步，启动建图算法。Gmapping 的参数我用下面这组：
roslaunch gmapping slam_gmapping.launch对应的slam_gmapping.launch文件核心配置：
<launch> <node pkg="gmapping" type="slam_gmapping" name="slam_gmapping" output="screen"> <param name="base_frame" value="base_footprint"/> <param name="odom_frame" value="odom"/> <param name="map_frame" value="map"/> <param name="map_update_interval" value="5.0"/> <param name="maxUrange" value="10.0"/> <param name="maxRange" value="12.0"/> <param name="particles" value="80"/> <param name="minimumScore" value="100"/> <param name="linearUpdate" value="0.2"/> <param name="angularUpdate" value="0.2"/> </node> </launch>重点解释几个参数背后的逻辑。map_update_interval=5.0表示每 5 秒用最新粒子更新一次地图，这个值不能设得太小，否则地图刷新太频繁，界面卡顿；linearUpdate和angularUpdate代表机器人至少移动 0.2 米或转动 0.2 弧度才做一次扫描匹配，太小会导致计算白耗、地图抖动，太大会导致关键帧丢失；particles=80已经能覆盖小房间建图，房间超过 100 平米再往上加到 120。
第三步，遥控机器人以低速扫遍房间。这里最关键的技巧是控制旋转速度。Gmapping 对旋转漂移的容忍度比平移漂移低得多，我实测把线速度限制在 0.15m/s 以内、角速度限制在 0.3rad/s 以内时，回环闭合效果明显更稳。扫图路径上，要先沿着房间外圈走一遍闭合一圈，再走内部走廊，最后回到起点附近，形成一个完整的闭环。不要边推边晃，也不要走一半快速掉头。
第四步，边建图边看rviz。订阅/map和/tf，然后切换视角看地图是否连续。有个小技巧：把rviz里激光点云的尺寸调小一点，透明度调高一点，能更容易看出墙体位置是否有交叠偏差。
第五步，确认地图没有明显变形后，保存：
rosrun map_server map_saver -f ~/map/lingbot_map运行后会生成lingbot_map.pgm和lingbot_map.yaml两个文件。这两个文件要同时保留，pgm是像素灰度图，yaml里记录了分辨率、原点和阈值等元信息。我见过有初学者把.pgm文件当普通图片用修图软件打开再另存，结果破坏了格式，加载地图时报错。这里明确说一下，不要对这两个文件做任何格式上的改动，要用直接拷贝、改名的方式操作。
3.4 加载地图并启动导航：从 AMCL 初始化到目标点测试
建图完成后，关掉 Gmapping 节点，启动导航链路。先加载地图：
roslaunch lingbot_navigation amcl.launch map_file:=/home/user/map/lingbot_map.yamlamcl.launch里的关键配置我拆成几个片段来说明。AMCL 核心参数如下：
<param name="min_particles" value="500"/> <param name="max_particles" value="2000"/> <param name="update_min_d" value="0.2"/> <param name="update_min_a" value="0.2"/> <param name="laser_min_range" value="0.1"/> <param name="laser_max_range" value="12.0"/>接下来是 move_base 的配置。我用的是 TEB 局部规划器，它比 DWA 更能适应窄通道和差速底盘的转弯特性。核心配置是代价地图的膨胀参数：
robot_base_frame: base_footprint update_frequency: 5.0 publish_frequency: 2.0 obstacle_range: 10.0 raytrace_range: 12.0 inflation_radius: 0.35 cost_scaling_factor: 3.0inflation_radius=0.35这个值需要单独解释。代价地图会把障碍物周围一定半径内的栅格都标成“代价区域”，半径越大，机器人越倾向远离障碍物，但太小又容易让规划路径贴墙导致执行困难。底盘宽度 40cm 左右时，膨胀半径 0.25~0.4 是常见区间，先从这个范围试，再观察导航时机器人扫过障碍物的距离来微调。
启动完成后，在 rviz 里用“2D Pose Estimate”给 AMCL 一个大概的初始位置，按Publish Point发布目标点，机器人就会开始规划路径并行走。
第一次导航测试不要直接下远程目标点，先把目标设在地图原点附近一两米处，观察机器人启动时的行为。如果它原地打转，说明定位还没收敛；如果它直冲障碍物，说明全局规划器的代价地图可能没把障碍物膨胀进去；如果它走半步就停，可能是局部规划器参数冲突。这些问题在下一章集中排查。
4. 常见问题与排查技巧实录
跑通一遍导航不算完事，真正磨人的是后续各种偶发问题。我把实际操作中遇到的高频问题、排查思路和最终解法整理成速查表，下面这些内容写代码文档时基本找不到，但每个问题我都亲手调过。
4.1 建图重影与地图不闭合：先怀疑数据源，再怀疑算法参数
建图时最让人崩溃的画面是：明明沿着房间走了一圈，回到起点后发现墙面错开了十几厘米，形成“重影”。第一次遇到时我以为是算法粒子数太少，把 particles 调到 200 也没有明显改善，后来才发现问题根本不在参数上。
我的排查顺序是：
先看里程计。把机器人沿直线推 2 米，然后用
rostopic echo /odom对比pose里的 x 是否接近 2.0，同时看twist里线速度是否在推进时回到接近 0。如果实际走了 2 米但 odom 只显示 1.6 米，说明轮径参数给小了，或者编码器分辨率写错。这类系统性误差会让整个地图在回环时呈现整体偏转或缩放，而不是局部抖动。再看雷达帧率。
rostopic hz /base_scan如果低于 8Hz，建图时的扫描匹配就会频繁跳到上一次的关键帧，导致墙体错位。常见原因是计算机负载过高，或者雷达串口数据被其他进程占用。最后检查 TF 的发布频率。
rosrun tf view_frames会生成一张 TF 图，你要看odom -> base_footprint的发布频率。如果这个变换低于 20Hz，建图效果会明显跑偏。
如果数据源都是干净的，再来调建图参数。地图不闭合时，优先把linearUpdate和angularUpdate下调，让算法更频繁地做匹配；如果地图整体扭曲，则留意底盘轮式里程计的轮距参数，轮距太小会导致转弯过度，轮距太大转弯不足，这两种情况在地图上会分别表现为“圆形墙壁变椭圆”和“直线墙变为弧度”。
4.2 定位失败与机器人“跑飞”：AMCL 初始化是重灾区
导航时机器人突然乱跑、屏幕上的定位点飘到墙外，基本上可以断定是 AMCL 的粒子分布出了问题。我遇到过的典型案例是：启动导航后没有给初始位姿，直接在 rviz 里发了目标点，AMCL 的粒子从零开始，短时间内无法收敛到一个合理的分布，于是定位结果在天上飘。
正确做法是每次重启 AMCL 后，都先在 rviz 里使用“2D Pose Estimate”指定一个大致正确的初始位置和朝向，然后让机器人原地缓慢旋转一两圈，让粒子快速收敛到地图匹配的位置。确认屏幕上的箭头（实测轨迹）与真实位置吻合，再发布目标点。
粒子数量配置不合理也会导致“跑飞”。我曾经在光线很暗、特征稀疏的长走廊里测试，把max_particles降到 500，机器人在走廊中段时粒子们四散开，各种错误假设都没法排除，定位直接丢失。后来把数量提高到 2000，并适当增加update_min_d和update_min_a的阈值以减少频繁更新带来的抖动，情况才稳定。
另外一个很容易忽略的细节是，AMCL 的base_frame参数必须和你 URDF 里底盘主坐标系完全一致。如果这里填成base_link，而你的 TF 树里主人是base_footprint，AMCL 会一直尝试找一条根本不存在的转换，最终输出"Failed to transform"直接罢工。
4.3 代价地图堵塞与规划路径奇怪：膨胀层参数能直接影响行为
导航时机器人明明离墙还有 30cm，却被规划器判定为“无路可走”，这是代价地图配置出了问题。代价地图的本质是把障碍物点云“涂”到一张栅格图上，再把障碍物周围区域标成不同等级的代价。如果obstacle_range设置得太小，远处的障碍物根本没被标记到地图上，路径规划会直接从障碍物上穿过去；如果inflation_radius设置得太大，走廊宽度稍窄的地方就变成无法通行的“高代价区”。
我的调试经验是，先用一组保守参数把系统跑通，再去缩参数。保守参数示例：
obstacle_range: 8.0 raytrace_range: 10.0 inflation_radius: 0.5跑通后，开启 rviz 里的Costmap显示，用半透明的紫色区域观察障碍物影响范围。如果机器人走到走廊中央就停下来，说明膨胀半径太大；如果机器人贴着墙壁走、转弯时蹭墙，说明半径太小。调参时每次只改一个参数，保存后重启 move_base 再看效果，不要同时改两个变量，否则失效后你不知道是哪一步导致的。
4.4 导航过程抖动与频繁计算失败：局部规划器和速度限制的博弈
导航中机器人出现高频左右晃动、走走停停，甚至卡在某个角落反复重规划，这通常是局部规划器参数和底盘速度限制没有对齐。TEB 局部规划器默认允许较大的速度变化，如果你的底盘最大线速度设置得比规划器默认值小很多，就会出现“规划器想快跑，底盘执行跟不上”的冲突。
我在teb_local_planner_params.yaml里做过一个稳定的配置：
max_vel_x: 0.35 max_vel_x_backwards: 0.15 max_vel_theta: 0.45 acc_lim_x: 0.2 acc_lim_theta: 0.3 min_turning_radius: 0.0这里有个关键点：差速底盘理论上可以原地旋转，min_turning_radius可以写 0；但如果你发现机器人为了调整角度频繁原地打转，就应该把它设成一个略大于 0 的小值，比如 0.1，让规划器尽量用平滑的弧线转弯，减少原地旋转造成的里程计漂移。
抖动还有一种可能，是底盘驱动节点的速度指令平滑处理没开。很多底盘驱动里带一个cmd_vel的滤波参数，比如controller_frequency和acceleration_limit。如果你的高频初始绿灯亮着但机器人依然抖，可以考虑在底盘侧做一层惯性滤波，在驱动节点里暂时加一个最大加速度限制，让实际输出速度变化更平缓。
4.5 问题速查表：最快定位问题区间
| 现象 | 优先排查点 | 常用补救手段 |
|---|---|---|
| 建图墙体错位/地图重影 | 轮式里程计精度、雷达安装偏移 | 校准轮径轮距、实测并修正 URDF 中的静态变换 |
| 地图有大量黑白噪点 | 雷达高度过低、地面反光 | 抬高雷达安装位置，启用雷达驱动里的去噪参数 |
| AMCL 定位飘移 | 初始位姿未设置、粒子过少 | 手动给定初始位姿，原地旋转收敛，提高粒子数 |
| 机器人导航时撞墙 | 膨胀半径太小、局部规划器参数不当 | 增大inflation_radius，降低max_vel_x |
| 机器人原地反复转圈 | 局部路径被高代价区包围 | 检查局部代价地图尺寸，调低膨胀系数 |
| 速度指令无响应 | cmd_vel话题不匹配 | 确认 move_base 输出话题名与底盘订阅话题名一致 |
| 系统整体卡顿掉帧 | 粒子数过多、地图分辨率过高 | 降低 AMCL 粒子数，把地图分辨率从 0.05 调整为 0.1 |
5. 一些我在实操中的体会
最后说几件零碎但很实用的体会。
第一件是关于调参的节奏。我见过不少人拿到项目就开始逐行改参数，结果越改越乱。正确的节奏应该是“先全默认跑通一遍，再砍冗余，再优化性能”。举例来说，第一次跑导航时，膨胀半径大一点、速度慢一点都没关系，目标是先看到机器人能走到目标点，哪怕它绕路或者慢到让人着急都行。跑通了，你就有了一个“参考基准”，之后每改一个参数都有对比对象，出了问题也能快速回退。
第二件是关于保存地图的习惯。地图文件不大，但每次重新标定雷达或修正底盘参数后，建出来的地图可能和原来差别很大。我习惯在每次建图前都把原来的pgm文件重新拷贝一份，加上日期后缀。有时候新地图不如旧地图，还能回退。这个习惯帮我在反复调参时省了很多次重推机器人扫图的体力。
第三件是关于扩展的方向。lingbot-map 这套链路虽然定位在 2D 室内导航，但它的工程框架可以平滑扩展：换 3D 激光雷达做 3D 感知、接入超声波传感器做近距防撞、加一个升降机构做跟随抓取，架构基本不用动。如果你后面要做多楼层导航，则可以考虑在 map 层之上引入拓扑节点地图，让机器人知道“怎么从一个房间去另一个房间”，这套底层建图定位系统依然可以复用。
做机器人导航就是这样，看起来是每个模块的单独技术，真正难的是把它们严丝合缝地拼在一起。希望这篇基于 lingbot-map 的拆解和实操记录，能帮你在自己的机器人上少走几趟弯路。
