企业官网建设流程全解析

扫地机器人这玩意，这几年几乎成了家庭标配。但你有没有想过，它凭什么能自己认路、自己扫完整个屋子还能回去充电？早几年的随机碰撞机型，和现在的“弓字形全覆盖+自动回充”机型，差距根本不在电机和吸力，而在导航系统。说白了，扫地机器人就是一台在地上跑的微型自动驾驶车，而它的“导航原理”，才是整个产品真正的技术分水岭。

这篇文章我想从一个做机器人算法的人的角度，把扫地机器人导航的底层逻辑掰开揉碎讲清楚。内容覆盖从传感器选型、SLAM建图、路径规划到仿真验证的完整链路，适合正在做机器人开发的工程师、想搞懂产品差异的硬件产品经理，也包括纯粹好奇“它怎么这么聪明”的普通用户。你不需要有数学基础，我会把关键原理用口语讲明白，但涉及参数和算法的地方，也绝不糊弄。

1. 扫地机器人导航的整体架构：从“盲人摸象”到“地图认知”

1.1 早期随机碰撞导航为什么会被淘汰

要说清楚现代导航原理，得先理解早期产品为什么那么“蠢”。随机碰撞导航的逻辑非常简单：机器人以随机方向直行，撞到障碍物后随机转向，继续前行。这个方案最大的问题是“效率不可控”，同一块区域可能反复扫十几遍，而另一个角落一次都没去过。

随机碰撞本质上是一种“无模型控制”，机器人对自身位置没有任何认知。你可以把它理解成蒙着眼睛在屋子里找钥匙，最坏情况下需要无限长时间才能覆盖全部区域。实测下来，随机碰撞机型的重复清扫率经常超过40%，漏扫率也在20%左右，而且清扫时长毫无规律，同一个户型今天扫50分钟，明天可能扫90分钟。

所以从工程角度看，淘汰随机碰撞不是“体验升级”，而是“成本刚需”。当机器人的传感器和算力成本降到一定程度，厂商自然会转向可建模、可规划的导航方案，因为这意味着更短的清扫时间、更低的功耗、更好的用户体验。

1.2 现代导航系统的三大模块：感知、建模、规划

现代扫地机器人导航系统可以拆成三个模块：感知、建模、规划。

感知层负责回答“我在哪、周围有什么”。传感器包括激光雷达（LDS）、视觉相机、超声波、ToF传感器、陀螺仪、轮式里程计等等。它们采集的是原始数据流，比如激光点云、图像帧、加速度和角速度。

建模层负责回答“这个空间长什么样”。核心是SLAM（同步定位与建图）。SLAM把传感器数据拼成一个统一的、一致的地图，同时估计机器人在地图中的位姿。这个环节的输出通常是二维栅格地图，每个栅格标记为空闲、占用或未知。

规划层负责回答“接下来怎么走”。包括全局路径规划（如弓字形全覆盖）和局部路径规划（如遇到拖鞋时实时绕行）。规划层还要对接运动控制，把路径转化为左右轮的转速指令。

三个模块是流水线关系，但实际工程中它们互相耦合。比如SLAM的地图质量严重影响路径规划的覆盖率，而运动控制的误差又直接反馈到SLAM的前端里程计。很多新手做导航开发时只盯着某一个算法调参，忽略了整条链路，结果就是单看每个模块都没问题，一跑整机就乱。

2. 感知层：传感器选型与数据融合的底层逻辑

2.1 激光雷达：TOF和三角测距的取舍

激光雷达是当前扫地机器人最主流的导航传感器，主要负责360度扫描房间轮廓，输出二维点云数据。市面上家用机器人用得最多的方案有两种：三角测距和ToF（飞行时间）。

三角测距的原理是：激光发射器投射一个光斑到物体表面，反射光被一个CCD/CMOS图像传感器接收。根据光斑在成像平面上的位置，利用三角形几何关系计算目标距离。它的优点是成本低、近距离精度不错，缺点是测量范围有限，一般有效距离在6米以内，而且受环境光干扰较大。

ToF的原理更直接：发射激光脉冲，测量反射光回来的时间，乘以光速除以2得到距离。它不依赖几何关系，所以远距离精度更好，抗环境光能力更强，但成本更高。在高大客厅、落地窗多、阳光直射的环境下，ToF传感器明显更稳。

扫地机器人选型时有个关键参数：扫描频率。低端激光雷达一般是5Hz~10Hz，高端能做到20Hz以上。扫描频率越高，机器人在快速移动时点云畸变越小，SLAM建图越准。如果你在拆机时看到雷达每分钟转速标识，比如300转/分，那么对应就是5Hz，这个级别做建图可以，但做高速运动避障会吃力。

还有一个容易忽略的点：激光雷达的安装高度。扫地机器人雷达一般装在机身顶部，安装高度决定它能探测到的障碍物尺度。比如雷达离地8cm，就能扫到大部分家具腿；如果离地太高，像电线、宠物粪便这类低矮物就扫不到，必须靠其他传感器补偿。

2.2 视觉导航：为什么有的机器不用激光雷达

视觉导航（VSLAM）是另一条技术路线。它用摄像头采集图像特征（角点、ORB特征、光流等），通过帧间匹配估算运动轨迹，再通过多视图几何构建地图。优点是硬件成本低、信息量大，能识别纹理和文字，但缺点也很明显：对光照敏感，暗光、强逆光下特征容易丢失，纯视觉方案在黑暗床底基本“失明”。

为了弥补这个短板，有些产品采用“视觉+结构光”的方案。结构光投射红外点阵到物体表面，相机根据点阵的形变来估算深度。它能在弱光环境下工作，但不耐强光，远距离精度差。所以现在多数视觉导航机器人实际上是多传感器融合的方案，而不是单纯依赖视觉。

视觉方案还有个天然优势：可以识别具体物体类别。比如识别出“这是充电桩标识”或“这是数据线”，能实现更智能的避障策略。而激光雷达只能告诉你“这里有个东西”，无法告诉你“这是什么东西”。所以近两年“激光+AI视觉识别”的组合越来越常见。

2.3 陀螺仪与轮式里程计：惯性辅助的关键作用

只靠激光雷达或视觉做导航是不够的，因为它们的采样频率有限，而且运动太快时会丢帧。这时候就需要惯性测量单元（IMU）和轮式里程计来填充。

IMU包含加速度计和陀螺仪，加速度计测量三轴线加速度，陀螺仪测量三轴角速度。通过对角速度积分可以得到角度变化，对加速度积分可以得到位移增量，但积分会累积漂移，所以IMU只在短时间内提供可靠的相对运动估计。

轮式里程计的原理更朴素：电机编码器记录轮子转过的圈数，乘以轮子周长，得到轮子前进的距离；左右轮转速差则可以推算转向角度。这个方案在平整地面很准，但在地毯、瓷砖门槛、打滑场景下误差会迅速放大。

真正工程上用的方案是将IMU、轮式里程计和激光/视觉数据进行松耦合或紧耦合融合。最常见的方法是扩展卡尔曼滤波（EKF）：预测模型用IMU和轮速计积分出的位姿增量，观测模型用激光匹配或视觉匹配的结果来修正累积漂移。这个过程就是常说的“航位推算+绝对修正”。

这里有一个关键参数：传感器数据的时间戳同步。很多DIY导航项目建图漂移严重，不是算法不行，而是IMU是50Hz、激光是10Hz，数据传输没有做时间对齐，融合时相位差导致坐标对不上。做多传感器融合，第一步永远是把时间戳对齐，否则后面全白搭。

3. SLAM建图：扫地机器人是怎么把家“画”出来的

3.1 前端里程计与扫描匹配

建图是导航的地基。扫地机器人用的SLAM和自动驾驶有差别，它以2D激光SLAM为主，代表算法是Gmapping、Cartographer。SLAM系统的前端叫“里程计”，作用是根据连续帧的激光点云估计机器人的相对运动。

举个直观例子。机器人走到某个位置扫描了一次，看到左边1米处有墙、前方0.5米处有桌腿；往前走了一点，再扫一次，发现墙变成了0.8米、桌腿变成了0.4米。那么算法就能通过特征点的几何变化反推出机器人走了多远、转了多少度。这个估算过程叫“扫描匹配”，常用方法有ICP（迭代最近点）和NDT（正态分布变换）。

ICP的思路很直接：找两帧点云中距离最近的点对，计算一个旋转和平移变换，让这两组点的距离和最小。NDT则是先把空间划分成网格，每个网格内统计点的概率分布，然后用优化方法寻找最优位姿变换。实际产品中NDT比ICP更稳健，尤其在点云稀疏、噪声大的场景下不容易陷入局部最优。

前端的输出是“相对位姿”，也就是每一帧激光相对于上一帧的平移和旋转量。但是相对位姿一帧帧累积起来，误差会不断叠加，这就是“漂移”。比如每帧匹配有1%的位置误差，走100帧之后累积误差就可能达到一帧距离的几十倍。所以前端必须配合后端优化来消除累积误差。

3.2 后端优化与回环检测

后端优化的作用是处理“累积漂移”。最常用的手段是图优化：把机器人的每个历史位姿当作节点，相邻位姿之间的变换当作边，构建一个图结构。图优化的目标就是调整所有节点的位姿，使所有边的误差总和最小。

但光靠相邻帧约束还不够，因为误差会沿着轨迹一路传递。真正的杀手锏是“回环检测”。回环检测的意思是：当机器人绕了一圈回到曾经到过的地方时，算法要能认出“这里我来过”，然后把当前位姿和历史位姿做一次匹配。

回环检测为什么重要？试想一个200平米的房子，机器人从客厅出发，经过走廊、卧室、厨房，最后绕回客厅。如果中间没有回环约束，客厅那端的位姿可能已经漂移了半米，地图上就会出现“两堵墙错位”的效果。一旦检测到回环，优化算法就会像“拉橡皮筋”一样把漂移量分摊到整条轨迹上，地图立刻变得闭合。

不过扫地机器人空间相对小，很多产品对回环检测的要求没有自动驾驶那么高，但依然需要。家里环境往往是“回”字形走廊，如果没有回环，你会发现地图上出现重影或者墙角闭合不上。

3.3 栅格地图与拓扑地图的选择

SLAM建出来的地图通常分为栅格地图和拓扑地图两类。扫地机器人绝大多数用二维栅格地图，简单来说，就是把房间划分成很多小格子，每个格子有三种状态：空闲、占用、未知。

栅格大小直接影响内存和精度。常见分辨率是5cm，也就是每格5厘米见方，一间100平米的房子大概需要40万个格子，内存占用可以接受。分辨率太高（如1cm）能看出桌腿的细轮廓，但内存和计算量会爆炸；分辨率太低（如20cm）则障碍物边缘模糊，机器人容易卡在窄缝里。

这里有个实用的避坑经验：扫地机器人的越障能力、机身宽度和栅格分辨率要联动考虑。比如机身宽度34cm，过道只有35cm，如果栅格分辨率为5cm，算法可能把一个34cm宽的通道判成“可通过”或“不可通过”取决于边缘栅格的占用状态。很多时候机器人卡在某个区域出不来，不是运动控制的问题，而是地图分辨率把可用通道“抹掉”了。

拓扑地图则更抽象，用节点和连线表示空间连通关系，适合做跨楼层导航或语义导航。但扫地机器人因为需要全覆盖清扫，栅格地图依然是最自然的选择。有些高端产品会同时维护栅格地图用于规划、拓扑地图用于语义交互（比如“去厨房”）。

3.4 动态物体干扰与地图更新策略

SLAM建图时最大的敌人不是传感器噪声，而是“动态物体”。激光雷达扫到的点云是瞬时快照，如果一个地方刚才没人、现在站了个人，就会形成一个“鬼影障碍”。

家用环境里最常见的动态物体是：人、宠物、移动的椅子、被风吹动的窗帘。针对它们，产品一般有两套策略。第一套是“建图时静态假设”：在首次快速建图阶段，算法默认大部分物体是静止的，个别动态点当作野值滤掉。第二套是“运行中持续更新”：扫地机器人每次清扫都会用当前扫描和已有地图比对，一致性低的栅格标记为动态并降低置信度。

但过度更新也有风险。比如你为了通风把窗户打开，窗帘被风吹动，如果算法把窗帘区域标记为“动态可穿越”，机器人就可能一头撞上去。所以工程上一般会给动态栅格设置“最小保持时间”，只有连续多次观测到状态变化才允许更新地图。

4. 路径规划与运动控制：从“全屋覆盖”到“精准避障”

4.1 全局规划：弓字形清扫与分区覆盖

有了地图，下一步就是规划清扫路线。扫地机器人最经典的全局规划策略是“弓字形清扫”（Boustrophedon），也就是像牛耕地一样，沿直线来回往复，直到覆盖整个连通区域。

弓字形规划有两个关键参数：行距和前进方向。行距一般略小于吸尘口的宽度，通常设定为吸尘口宽度的80%左右。如果吸尘口宽25cm，行距就设置为20cm，保证相邻路径之间有一定重叠，避免漏扫缝隙。方向选择则优先沿墙壁方向，因为这样能减少转弯次数，同时与房间的主体走向对齐。

为什么全覆盖不直接用“蛇形从头扫到尾”？因为真实房间有墙、有家具，不是一个规则的矩形。所以算法要先做“分区”，把连通空间分割成若干子区域，比如客厅、卧室、走廊分别划分。分区常用方法有梯形分解和Voronoi图，扫地机器人一般用简化的梯形分解：找到障碍物造成的“分界线”，沿分界线的延长线把空间分成左右两边。

每个分区独立执行弓字形清扫，分区之间通过“衔接路径”连接。这里有个细节：清扫顺序如何确定？最简单的是贪心算法，每次都选距离当前车位最近、且未清扫的分区。更智能的方案会考虑回充路径和“脏污检测”，先扫大概率脏的区域。实测下来，贪心排序虽然简单，但在小户型里效果不比复杂算法差很多，大户型才有明显差距。

4.2 局部规划：DWA算法与动态避障

全局路径规划是静态的，但家里处处是意外：突然走过来的猫、掉在地上的拖鞋、从沙发上滑落的抱枕。所以还需要局部路径规划来实时躲避动态障碍物。

扫地机器人最常用的局部算法是DWA（Dynamic Window Approach，动态窗口法）。DWA的思想很巧妙：它不直接计算一条复杂曲线，而是在机器人当前速度空间里采样一组可能的“线速度和角速度组合”，然后模拟每条速度组合在未来一小段时间内的轨迹，再用评分函数选出一条最优轨迹。

评分函数通常包含三个指标：朝目标方向的程度（方位角评分）、与最近障碍物的距离（安全评分）、当前速度与目标速度的接近程度（速度评分）。最终轨迹是这三个评分加权求和的最大值。

DWA参数调起来很看经验。采样速度个数太多会增加计算量，太少又可能选不出安全轨迹。我见过不少翻车案例：把“与障碍物的最小距离”权重调太低，机器人贴着障碍物走，很容易刮擦；调太高，机器人在空旷区域也会扭扭捏捏，路径蜿蜒。好的做法是先固定安全距离阈值，再调速度评分，最后调目标朝向权重。

4.3 悬崖检测、碰撞缓冲与传感器融合避障策略

真正的避障不只是“绕过”，还包括各种补充传感器。扫地机器人有三大避障硬件：悬崖传感器、碰撞缓冲器、沿墙传感器。

悬崖传感器通常用红外对射或ToF朝地面探测。当机器人在楼梯边缘，传感器检测到地面反射距离突变，就会判定为“前方是悬崖”，立即停止前进并转向。这里有个坑：黑色地毯会吸收红外光，导致传感器误判为“悬崖”，有些机器人在黑色地毯上会莫名倒退。解决办法是把红外传感器和轮子下沉检测融合起来，只有两个信号同时触发才判定为悬崖。

碰撞缓冲器是最后一道防线。机器人前面的缓冲条内一般有霍尔传感器或微动开关，撞到障碍物时触发反馈。但现代导航机器人应该是“尽量不碰撞”，如果经常触发碰撞，说明激光雷达没扫到低矮障碍物，或者局部规划的参数太激进。

沿墙传感器用于贴边清扫。多数产品用侧向的红外或ToF传感器，保持机器人与墙面固定距离，一般10~15mm。沿墙清扫最容易漏的是墙角，所以高端产品在墙角处会执行“扭屁股”动作：原地旋转一个小角度，把吸尘口对准墙角，先把墙角的灰尘吸掉再继续前进。

多传感器融合的避障策略本质上是一个“表决系统”：激光雷达负责测距、视觉负责分类、红外负责近距离、碰撞器负责兜底。一个优秀的产品会让这些传感器互相验证，而不是单靠某一个。比如视觉识别到“这里是数据线”，但激光雷达又显示可以通过，那机器人应该保守处理，减慢速度并降低吸力，而不是直接压过去。

4.4 脱困策略与多楼层地图管理

脱困是扫地机器人绕不开的项目。我实测过不少机型，最常见的被困场景有三类：一是机身卡在椅子腿之间，二是骑上地毯边缘打滑，三是被线缆缠住。

算法层面的脱困思路通常分三级。第一级是调整局部规划参数，比如缩小转弯半径、增大安全距离，尝试绕开障碍物。第二级是执行预设脱困动作：后退一段距离、原地旋转90度、继续前进。第三级是触发“返航重定位”：机器人回到最近已知位置，重新规划一条新路线。

多楼层地图管理也是近年来的标配需求。一台机器要扫楼上楼下，就不能只存一张图。工程上一般用“地图ID+重定位描述子”来管理：每层建一次图，保存为独立ID，机器人通过激光扫描匹配来判断自身在哪个楼层，然后自动加载对应地图。这里要注意楼层之间的相似布局容易误判，比如楼上楼下的卫生间位置一样，这时就要结合IMU判断是否经过了楼梯坡度变化。

5. 仿真训练与实测：用Mujoco验证导航算法

5.1 为什么要在仿真环境里训扫地机器人

看到热搜里有人问“扫地机器人用MuJoCo可以吗”，我的回答是：不但可以，而且是目前性价比最高的验证方式。MuJoCo（Multi-Joint dynamics with Contact）是一个高效的物理仿真引擎，原本主要用于机械臂和足式机器人研究，因为它对接触动力学、关节约束和摩擦模拟得非常精确。扫地机器人本质上是一个“带轮子的接触式系统”，轮子与地面之间的摩擦、撞到障碍物时的碰撞响应，正好是MuJoCo擅长模拟的部分。

在仿真里做导航算法开发有几个实打实的好处：第一，不用等样机，算法迭代速度提高一个数量级；第二，场景参数可控，想模拟大理石、木地板、短毛地毯、过门石都可以直接改摩擦系数；第三，可以批量跑测试，一个晚上跑几千次随机户型清扫，这在实机上是不可能完成的。

当然，仿真也有替代不了的短板。传感器噪声的建模再真实，也和真实激光雷达的反射特性有差异；扫地机器人实际遇到的灰尘扬尘、光线反射、线缆缠绕等复杂情况，很难完全复现。所以正确的姿势是：用仿真做快速迭代和回归测试，用实机做最终验收。

5.2 搭建MuJoCo扫地机器人仿真环境的步骤要点

用MuJoCo搭一个扫地机器人仿真环境，我建议按下面几步来做。不用一步到位，先跑通最小系统，再逐步加细节。

第一步是建立机器人模型。定义机身的惯性参数、左右驱动轮、万向轮、激光雷达安装位置。MuJoCo用的是MJCF格式的XML描述文件，里面可以给每个body加mesh、joint、geom。轮子和地面之间的接触模型是最关键的，要设置合适的摩擦系数（地板一般设为0.8左右，地毯可以设到1.2甚至更高）。

第二步是加入传感器模型。MuJoCo本身没有激光雷达传感器插件，但你可以通过ray-casting实现。具体做法是在每个仿真步长里，从雷达安装点向360度方向发射射线，记录命中的物体距离，加上高斯噪声，就得到了模拟的2D点云数据。射线数量一般设360根或者720根，角度分辨率1度或0.5度，和真实雷达保持一致。

第三步是运动控制接口。扫地机器人是差速驱动模型，控制量是左右轮速度。MuJoCo里可以通过velocities actuator或者位置控制去驱动轮子，但要注意轮子转速饱和限制和加速度限制，这样可以模拟真实电机不能瞬间加速的物理约束。

第四步是搭建环境场景。可以用obj文件导入真实户型图，也可以在MuJoCo里用几何体拼出家具。建议先拿一个简单的房间测试，比如4m×4m房间、两把椅子、一个沙发模型，跑通流程之后再换成复杂户型。

第五步是接入算法层。你需要一个控制循环：在每一个控制周期读取雷达点云和IMU数据，用SLAM算法建图定位，输出左右轮速度指令，再写入MuJoCo的actuator。SLAM和路径规划可以用Python实现，MuJoCo的Python绑定接口（dm_control或mujoco）足够支持实时控制。

我做仿真时踩过最大的坑是模拟步长。步长太大，轮子接触地面的瞬间容易穿透；步长太小，仿真速度太慢。对于扫地机器人这种低速轮式平台，建议仿真步长设置为1ms到2ms，跑起来不会太慢，物理效果也够真实。

5.3 从仿真到实机的“坑”：sim-to-real transfer

仿真做得再好看，最终都要回到实机验证。从MuJoCo转到真实扫地机器人，我最想提醒你的是三个“代沟”。

第一个是传感器噪声模型。仿真里加的高斯噪声太理想化了，真实激光雷达在不同材质、不同角度下测距误差完全不同。黑色哑光家具会“吃掉”激光信号，镜面会产生错误的反射点。建议在仿真阶段就加入“材质相关的噪声模型”，比如对不同表面设不同的标准差。

第二个是执行器的延迟和响应差异。仿真里你下达“左轮0.3m/s”，轮子立刻就到了这个速度。真实电机需要几百毫秒才能达到，而且存在控制死区。如果你不做延迟补偿，在仿真里调试好的避障参数，实机一变障就会频繁急转向。

第三个是地形的复杂性。仿真里地面是理想的平面，真实家里有地毯边、门槛、瓷砖缝。建议在仿真里增加一段“不平整地形”做压力测试，或者在实机测试阶段刻意从简单户型开始，逐步增加挑战。

5.4 实测视频怎么拍才能暴露真实导航问题

“扫地机器人视频”这个热词说明大家不光看参数，更爱看实际表现。作为开发者，拍实测视频不是为了好看，是为了暴露问题。我自己的实测流程分三步。

第一步固定机位拍全局视角，记录机器人完整清扫过程。全局视角能直接看出覆盖率、重复率、卡困行为。注意机位要能看到整个客厅，避免盲区。

第二步是跟拍视角，重点拍细节动作。比如机器人在桌腿附近怎么调整、在门槛前怎么越障、在悬崖边怎么反应。这些特写镜头才方便后续逐帧分析算法行为。

第三步是记录传感器数据。光拍视频不够，最好同时在电脑上录制雷达点云、地图构建过程、路径轨迹的实时可视化。视频和数据的叠加画面，调试效率远高于纯看视频。我当时做实测时，每次跑完都会把“地图+轨迹+传感器事件”合成一张长图，哪里漏扫、哪里重复、哪里停顿，一眼就能定位问题。

6. 常见问题与排查技巧实录

6.1 建图重影、地图偏移的原因排查

建图重影是最常见的导航问题，表现是地图中同一面墙出现两条影子，或者地图里有错位的轮廓。导致这类问题的原因多数是以下四个。

传感器数据时间戳不同步是最容易被忽略的。激光雷达、IMU、轮速计如果各发各的，融合算法拿到的是一堆“错位”的数据。排查方法很容易：打印出每个传感器最新数据的接收时间，看它们的时间差是否稳定在几个周期以内。

轮子打滑导致里程计积分异常也是常见原因。打滑时轮速计告诉算法“我走了20cm”，但实际只走了10cm。排查方法是观察机器人直线行走时，地图上的轨迹是否笔直，如果轨迹某段突然弯曲，说明轮子已经打滑。

激光雷达安装松动会造成更隐蔽的偏移。雷达罩固定不牢，机器人轻微晃动就会让雷达和机身坐标系之间产生相对运动，建出的地图会整体旋转或变形。排查方法很简单：开机后固定机身，旋转雷达看点云，正常情况点云应该稳定不跳变。

回环检测失效也会导致地图不闭合。如果机器人绕完一圈回到原点但地图没有首尾相接，说明回环检测模块没有正确触发。排查时先看回环候选帧的数量，如果为0，大概率是地图的相似度阈值设置太严格。

6.2 漏扫、重复清扫率高的调优方向

漏扫和重复清扫率高往往是一体两面，核心都要从规划和定位两方面去找。规划层面的原因是弓字形行距设置过大，或者分区顺序选择不合理。建议把行距调到吸尘口宽度的70%到80%，略减小覆盖密度，你的漏扫率能明显下降。

定位层面的原因是机器人的位姿估计不准确，走了几步之后实际位置和地图位置的偏差越来越大，导致弓字形轨迹斜着飘，中间留下一大片没扫的区域。解决办法一是检查IMU校准是否正确，二是检查轮速计的左右轮一致性。如果两个轮子的实际周长有差异，机器人会“跑偏”，需要做轮径校准。

重复清扫率高还有一个原因是重定位失败后触发了“回原点重扫”逻辑。有些产品在建图地图置信度不够时会保留原地图，但机器人已经不知道自己在哪了，于是选择“重扫整层”。这种情况要做的是加强回环检测，而不是调规划。

6.3 导航关键参数速查表

下面是一张我日常调试用的参数速查表，大家可以直接抄作业，不同产品参数略有差异，但思路通用。

6.4 一些日常使用和调教建议

最后说几个可能对非研发人员也有用的点。第一，家里的地面状态对导航影响非常大，扫地机器人建图前建议把地面上的零散物品收拾干净，先建一次“干净版”地图，之后再允许它在日常状态下清扫；第二，如果发现机器人总是卡在某个固定位置，可以先查看地图里那个位置的栅格占用情况，往往是有低矮障碍物没被建图扫到，直接在App里设置虚拟墙更省事；第三，多楼层用户一定确认每层地图独立保存，否则机器人到了二层还拿一层的地图规划，会发生“对着墙猛冲”的行为。

导航这件事，看起来只是“扫地”过程中的一个中间环节，但它决定了扫地机器人是“家电”还是“机器人”。我个人的体会是：把导航原理吃透，远比纠结某款吸力多少Pa更有价值，因为导航才是决定清扫效率、覆盖率和用户体验的根本框架。就算你是普通用户，下次再看到参数页上的“LDS激光导航”“视觉融合避障”这些词，也会知道它们背后意味着什么。

如果你正准备入坑机器人开发，MuJoCo仿真加一套小车的玩法确实是成本最低的起点。先跑通建图，再跑通避障，最后试试全覆盖路径规划，你就能理解为什么真实产品里导航系统的坑永远填不完——因为这个问题的本质，是如何在有限传感器和计算资源下，让一台不知道自己在哪的机器，搞清楚自己是谁、在哪、要去哪。