企业官网建设流程全解析

扫地机器人这行做了快十年，从最早的单目摄像头撞来撞去，到后来激光雷达普及，再到现在视觉+IMU逐渐成为中高端机型的标配，能明显感受到导航技术在一层层往深走。很多朋友问我的第一句话就是：视觉SLAM和激光SLAM到底差在哪？为什么非得加个IMU？路径规划又到底怎么配合定位数据工作？这些问题问得多了，我发现自己很难用几句话讲清楚。这篇就把这几年做扫地机器人视觉+IMU融合导航路径规划的经验整理出来，从传感器选型、标定、建图、规划到真机部署，尽量把每一个关键环节的“为什么”也讲明白，希望能给正在做机器人导航或者准备入行的朋友一些实实在在的参考。

1. 为什么扫地机器人需要视觉+IMU这套组合拳

1.1 单一传感器解决不了的问题

先回到最基础的问题：一台扫地机器人要真正做到自主清扫，至少得回答三个问题——我在哪？我要去哪？我该怎么去？这三个问题分别对应定位、建图和路径规划，而所有环节的第一步，就是传感器。

激光雷达是扫地机上用得最早也最成熟的方案，它测距准、抗干扰强，能直接给出二维平面障碍物分布。但激光雷达有个天然短板：它扫出来的是一个平面slice，扫地机遇到台阶、地毯边缘、桌腿下方的横梁这类低矮障碍，激光很容易漏检或误判。更麻烦的是，激光雷达对环境的几何结构依赖很强，在空旷的客厅或两面长走廊里，特征太少，匹配容易飘。

纯视觉方案呢？相机能看到丰富的纹理信息，理论上能识别物体、判断场景语义，但普通单目相机根本没有尺度信息——一张照片里你很难知道障碍物到底离你1米还是3米。而且相机帧率再高，遇到快速旋转、剧烈晃动时，图像模糊、特征丢失都是家常便饭。

IMU（惯性测量单元）能测量三轴加速度和三轴角速度，更新频率高，短期位姿推算非常平滑。但它最怕积分漂移——加速度计稍微有点零偏，积分两分钟位置就跑偏不少。用句行话说，IMU是“短期准、长期飘”，视觉和激光是“长期稳、短期容易丢”。单独拿任何一个出来，都撑不起一台稳定工作的扫地机。

1.2 视觉和IMU是怎么互相“补位”的

视觉+IMU融合，本质上就是让两种传感器互相兜底。视觉帧率一般30fps，IMU可以到200Hz甚至更高。当你快速旋转扫地机时，相机图像可能已经糊成一团，但IMU依然能精确输出两帧图像之间的旋转增量，帮助系统维持位姿估计。反过来，IMU的积分漂移，可以由视觉观测——比如图像里的特征点匹配——来持续修正，相当于用相机反复给IMU“校零”。

用大白话讲：IMU是那个闭着眼也能短时间内不乱脚步的人，视觉是那个睁着眼能告诉你“你现在在哪、周围长什么样”的人。但闭眼走久了一定会偏，睁着眼看的时候又怕眼前晃得太快看不清。两个人配合起来，一个负责连续、一个负责修正，才能走出长期稳定、短期平滑的轨迹。

这个配合一旦做好，扫地机就可以在没有明显几何特征的场景里继续定位，也能在地毯、门槛这种激光雷达容易出错的区域保持稳定。因此视觉+IMU融合不只是一个营销卖点，而是真正解决复杂家庭环境可靠性问题的工程方案。

2. 传感器选型与硬件搭建

2.1 视觉方案怎么选：单目、双目还是RGB-D

视觉方案的选择直接决定后续算法复杂度，我在不同项目里三种方案都试过，各自的取舍很明确。

单目相机成本最低，一个几十块钱的摄像头就能跑视觉SLAM。但单目有尺度的不确定性问题，也就是说算法知道轨迹的形状，却不知道具体是多少米。这个尺度如果靠融合IMU来估计，可以在初始化阶段慢慢收敛，但收敛过程中扫地机的定位是偏的，对于需要精确贴边清扫的场景影响很大。所以在量产扫地机上，纯单目+IMU的方案我更倾向于仅用于辅助避障，而不是主定位。

双目相机通过左右目视差直接计算深度，尺度问题是天然解决的。它不需要发射红外光，户外强光下也能工作，室内暗光环境只要补光够就行。缺点是标定麻烦，两个镜头之间的小角度偏差都会影响深度精度，计算量也成倍增加。

RGB-D相机（比如结构光或ToF方案）能直接输出稠密深度图，对视觉导航最友好。扫地机上常见的是ToF，测距范围有限，一般5米内效果不错，超过就噪声很大。而且ToF在黑色物体、阳光直射下容易失效，选型时要搭配IMU做短时预测兜底。

我自己的经验是：如果是研发样机优先验证算法，RGB-D+IMU最容易起步；如果目标是量产降成本，双目+IMU更稳；单目+IMU则适合做低成本辅助定位层。千万别迷信参数表，关键看你的算法管道吃不吃得下这些数据。

2.2 IMU选型与安装要点

IMU的选型不是看单轴性能，而是看零偏稳定性、噪声密度和各轴正交误差。常见消费级IMU（比如ICM-42688、BMI270）零偏稳定性大概在几度每小时到十几度每小时之间，用在扫地机上已经够。工业级IMU（比如ADIS16470）贵很多，性能好一个量级，但扫地机这种场景未必需要。

真正影响融合质量的反而是安装。原则很简单：IMU的几何中心尽量靠近相机的光心，三轴方向尽量与相机坐标系对齐。原因也很实际，相机和IMU之间的外参（旋转和平移）需要通过标定获得，如果你的IMU装得离相机光心很远，平移外参会变大，同时振动时两边的运动差异也更明显，标定残差很难收敛。

还有一点往往被忽略：IMU一定要远离电机磁铁和电源大电流走线。扫地机底盘电机启动瞬间电流很大，磁场变化会干扰IMU读数。我们曾遇到过一开机YAW就漂的怪问题，最后排查半天发现是电池走线贴着IMU板。把IMU挪开几厘米，问题直接消失，这类教训很常见。

2.3 主控选型：rk3588为什么常见

很多人看到RK3588觉得大材小用，但扫地机内部其实很需要这类带NPU的SoC。视觉SLAM的前端特征提取、光流跟踪、语义分割都能用NPU加速，把CPU腾出来给路径规划和控制。

RK3588的优势在于四核A76加四核A55的大小核架构，既有高负载算力又有低功耗核，8K视频编解码模块对图像传感器的接入很友好，6 TOPS NPU跑轻量级神经网络足够。而且Rockchip在Linux生态上做了大量适配，OpenCL、RKNN、ROS2这些常见依赖都能比较容易地编译部署。

不过选RK3588也意味着板级设计要更用心，DDR带宽、散热、电源纹波都会成为瓶颈。如果你只是做算法验证，直接用开发板起步完全可行，真正量产时再考虑裁剪。别一开始就上定制主板，调试成本太高。

3. 视觉+IMU融合的核心：SLAM与状态估计

3.1 从视觉SLAM说起：特征点与光流

视觉SLAM的老祖宗思路是特征点法。每一帧图像提取ORB、SIFT这类关键点，描述子匹配相邻帧，然后通过多视角几何解算相机运动和地图点位置。特征点法稳健，适合基线变化大的场景，但描述子计算量大，在纹理稀疏场景容易空手而归。

后来光流法逐渐流行，它不计算描述子，而是直接跟踪像素块的运动。LK光流在帧间位移不太大的情况下又快又准，很适合扫地机这种低速平台。缺点是光流法怕模糊、怕剧烈光照变化，一丢就全丢。所以实际工程里，我倾向于前端用光流跟踪，后端定期做关键帧检测和重定位，两者结合既保证速度又保证鲁棒性。

你把这些特征点输出给后端优化时，视觉SLAM才算真正进入状态估计阶段。后端要做的事情是滑窗优化或位姿图优化，把每一帧的位置调整到全局一致。扫地机面积不大，一圈下来地图闭环几次，全局误差已经能控制在厘米级。

3.2 IMU的作用：短时预测与尺度恢复

IMU在视觉SLAM系统里承担的不只是“备份”。当相机图像因为快速旋转或者被抹布遮挡而暂时失效时，IMU反馈的角速度和加速度可以持续推演位姿，保证定位输出不会瞬间跳变。这个功能在扫地机钻进沙发底、桌下等光线暗区域时尤其重要。

另一个关键任务是恢复单目视觉的尺度。纯单目SLAM解出的轨迹是归一化尺度下的结果，不知道真实米制。IMU能测到真实加速度，重力向量也能直接提供绝对俯仰和横滚参考，这些信息参与联合优化后，轨迹尺度就能被约束到真实值。这也是VINS-Mono这类经典视觉惯性系统能做单目版本的原因。

但在融合IMU时要注意一个隐性问题：IMU加速度计测到的是“比力”，包含重力，而视觉观测的又是纯几何运动。两个量融合过程中对重力方向的准确估计至关重要。如果初始化时挪动过快，重力向量收敛得不好，后面整个系统的俯仰横滚都会歪。

3.3 融合方式：松耦合与紧耦合

视觉和IMU融合从架构上看分松耦合和紧耦合两种路线。

松耦合的思路很直接：视觉SLAM先独立跑一套，输出位姿；IMU另外单独积分输出位姿；最后用一个滤波器（常见是误差状态卡尔曼滤波）把两个位姿合起来。这类方案实现简单，两个子系统可以分开调试，适合快速原型。缺点是没有共享原始观测，任何一个子系统的误差都会被直接带进融合结果，精度天花板有限。

紧耦合则把视觉特征、IMU测量值丢进同一个优化问题里同时求解。VINS-Mono、ORB-SLAM3的视觉惯性模式都是这个思路。紧耦合格局下，视觉和IMU相互约束，任一传感器的短时退化都能被另一方补偿，精度和鲁棒性都更高。代价是计算量大、初始化敏感、标定要求高。

扫地机器人量产项目普遍走紧耦合，因为家庭环境复杂，你没法保证每个房间光线、纹理都理想。既然紧耦合是主流，那就重点把相机与IMU的标定做扎实，标定做不好，融合精度再玄学也白搭。

3.4 相机与IMU联合标定：不能跳过的步骤

相机内参标定大家相对熟悉，棋盘格或Apriltag跑一遍就行。但相机与IMU之间的外参标定，很多人容易忽略，或者只是随手写个近似值。这里必须强调：外参错了，融合算法根本不可能收敛。

联合标定的做法是同时采集相机图像和IMU数据，让设备做充分的旋转、平移激励，然后用Kalibr这类工具离线优化出相机与IMU之间的旋转和平移。操作上有几个要点：标定场景光照稳定、纹理丰富；设备固定好后每转动一下停一停，让IMU充分激励；采集时长不要太短，一般要3-5分钟，让平移和旋转都覆盖。

还有时间同步问题。相机和IMU的时钟如果不一致，融合算法会有额外延迟误差。一般是让IMU硬件同步输出PPS信号给相机，或者在驱动层用系统时间戳近似同步。后者虽然简单，但误差有几个毫秒的话，在快速旋转时影响明显。量产出厂前必须跑一遍内参、外参、时间延迟的联合标定流水线，这一步省不了。

4. 地图构建与全局路径规划

4.1 地图形式：栅格地图、八叉树地图、拓扑地图

定位训好后，扫地机还需要一张可以“画路线”的地图。最常见的是二维栅格地图（Occupancy Grid Map），把环境切分成等大小格子，每个格子标记空闲、占据或未知。栅格地图直观、便于做路径规划，但也存在分辨率与内存的折中。一张100平米房间的5cm分辨率栅格地图大概就要几十万格子，内存和建图更新压力都不小。

三维场景可以考虑八叉树地图（OctoMap）。它通过八叉树递归划分空间，只在有障碍物的区域细分，空旷地带用大节点表示，内存效率高很多。扫地机本身在二维平面移动，八叉树地图更多用于处理悬空家具、低矮障碍的空间信息，比如判断机器人能否从茶几下面钻过去。如果规划层只用二维栅格，那么八叉树地图可以作为语义避障辅助层。

拓扑地图则更适合大范围多区域的导航，它把房间抽象成节点和边，节点表示关键路口或充电座，边表示可通行路径。扫地机多楼层或超大平层时，先构建拓扑图，再在每个子区域内部跑栅格规划，综合效率和精度都可以兼顾。

4.2 全局路径规划算法：Dijkstra、A*、RRT

全局路径规划的任务是在已知地图上找一条从当前位置到清扫目标点的无碰撞路径。经典算法是Dijkstra，它从起点逐步向四周扩展，保证找到最短路径，但效率低，不适合大范围实时计算。

A是实际工程中用最多的全局规划算法，它加入了启发式函数，优先扩展估计总代价最小的节点，比Dijkstra快得多。扫地机产品里加一点改进，比如JPS（跳点搜索）或A的变体，在栅格地图上效果非常明显。要注意的是A*在障碍物密集环境容易产生贴墙或转折多的路径，所以规划出的原始路径往往还要做平滑处理。

RRT系列是采样类方法，适用于高维空间或者地图特别大的情况。扫地机这种平面低速平台上，A*基本够用，RRT的优势发挥不出来。不过如果你在做机械臂或者无人机路径规划，RRT就会成为主力。规划算法没有绝对优劣，关键看你平台的运动约束和地图规模。

4.3 导航地图的生产流程

地图不是建好就直接用的，机器人第一次扫全屋时会生成一张“原始地图”，这张地图往往带有噪声、动态障碍物残留和错误闭环痕迹。标准做法是让扫地机跑一遍“建图模式”，尽量缓慢地覆盖全屋，过程中不要出现移动的人和宠物，最后再通过回环检测修正全局一致性。

建完图后我还建议做两件事：一是给地图标记语义信息，比如房间、门槛、充电座位置；二是做障碍物膨胀。在栅格地图上，把障碍物周围指定半径内的格子标记为不可通行，这个半径至少要等于机器人半径加安全余量。膨胀半径太小，机身容易擦撞；太大，狭窄通道会被提前堵死。实测下来，扫地机直径约35cm时，膨胀半径设在20-25cm比较合适。

全局路径虽然规划完了，但扫地机真正跑起来还会碰到地图上没有的动态障碍，这时就需要下一层的局部路径规划上场。

5. 局部路径规划与动态避障

5.1 DWA、TEB这些经典局部规划器

局部路径规划是在全局路径引导下，根据实时传感器数据生成短时间内的速度指令。DWA（动态窗口法）是扫地机器人上最常见的局部规划器，它的思路是在当前速度空间采样一系列可能的线速度和角速度组合，模拟未来一段时间内的轨迹，再根据障碍物距离、目标朝向、速度大小等做加权评分，选最优速度执行。

DWA的优点是好调、运行稳定，但也存在容易陷入U形障碍物里的问题。TEB（时间弹性带）是另一类经典算法，它把局部路径看作一条有弹性的带子，在满足运动学约束和避障约束的前提下，通过优化让带子尽量靠近全局路径且时间最短。TEB在窄通道和复杂障碍场景下表现明显好于DWA，但调参复杂，计算量也大。

我个人的习惯是：量产扫地机用DWA做基础避障，在危险场景额外叠加一个安全策略，比如检测到近距离障碍强制减速甚至停车。千万别把DWA参数调到它性能极限，留出安全冗余才是家用产品该有的思路。

5.2 动态障碍物处理

动态障碍物的本质问题是：地图上不存在的东西突然出现在传感器范围内。扫地机遇到人脚、宠物、掉落数据线，都需要快速反应。这里视觉的作用就体现出来了：视觉能够识别障碍物类别，比激光单纯测距更有针对性。例如看到“人脚”时，策略是保持距离并暂停清扫，等障碍物移开后继续；看到“数据线”时，不能硬撞，要绕开避免吸入缠住。

动态避障的工程实现一般分多层：底层是紧急制动逻辑，由ToF或红外传感器触发，毫秒级响应；中层是局部规划器的动态障碍物代价层，把实时感知到的障碍物注入局部代价地图；上层是行为决策，决定是停车等待、绕行还是回归全局路径。三层配合，才能真正做到既安全又高效。

视觉动态障碍检测要避免误报。曾经有用户反馈扫地机对着墙上的装饰画绕来绕去，查下来是识别模型把画框边缘误判成了障碍物。后续在模型训练时增加了大量正样本和前后帧一致性校验，误报率才降下来。

5.3 覆盖清扫路径如何规划

扫地机器人跟配送机器人最大区别在于，它的路径规划目标不是“从A到B”，而是“覆盖整个区域且尽量不重复”。覆盖路径规划的主流做法是分块牛耕法：先把房间按凸划分成若干子区域，再在每个子区域内沿直线来回清扫。转90度左转或右转，形成高效的弓字形路径。

实现弓字形覆盖时，IMU的航向精度非常关键。直线清扫时扫地机需要保持航向稳定，一旦偏航，两条相邻路径之间会出现漏扫带或重叠带。视觉+IMU融合能提供低频稳定的航向角估计，配合轮式里程计，弓字形路径就能做得比较直。我们实测过，在5m长的房间里，如果只用轮式里程计，路径末端偏航能差到20cm以上，加入视觉+IMU后偏差能压到5cm以内。

覆盖面积最大化还依赖边界识别。扫地机贴着墙边走一圈，记录边界坐标，然后向内逐步覆盖。这个过程对贴边精度要求高，视觉能识别踢脚线、家具底部边缘，帮助机器人维持5-10mm的贴边距离，比激光雷达检测平面障碍的效果更细腻。

6. 基于ROS2与Nav2的落地实践

6.1 为什么从ROS1迁到ROS2

很多实验室和早期产品都是基于ROS1开发的，我也一样。ROS1的master中心化架构在单机原型阶段很方便，但一进入多机协同、长期运行，它的问题就暴露了：节点掉线后整个系统无主、通讯实时性差、安全机制薄弱。

ROS2引入了DDS（数据分发服务）作为通信底层，节点发现机制是分布式的，单个节点挂了不会拖垮全局，而且支持QoS策略，能针对不同消息配置不同的可靠性和时效性要求。对导航这种延时敏感任务，可以把局部代价地图和速度指令设成“尽力传输”，把地图、日志设成“可靠传输”。

在嵌入式平台上，ROS2的Daemon和发现机制带来额外资源开销，实机上要合理屏蔽不必要的Topic，并且选用轻量级RMW实现（比如CycloneDDS或FastDDS）并且做好网络配置。别直接在默认配置下上真机，延迟和丢包会让你怀疑人生。

6.2 Nav2的组成与配置要点

Nav2是ROS2下的导航框架，整个过程比我早期手写规划器要规范得多。它由几个核心模块协作：行为树服务器（Behavior Tree）负责任务流程控制，Planner Server跑全局路径规划，Controller Server跑局部轨迹跟踪，Costmap管理代价地图，BT Navigator则负责把这些串起来。

用Nav2跑扫地机，重点配置的是costmap层和规划器参数。全局代价地图分辨率可以低一点比如5cm，局部代价地图分辨率需要更高比如2.5cm，以便捕捉近距离障碍细节。静态层、障碍物层、膨胀层都必须开，动态障碍物如果要视觉感知，就再挂一个语义障碍物层。

还有一点容易踩坑：Nav2默认的机器人模型是差速轮，扫地机也是差速轮，运动学参数直接套用问题不大，但如果你用全向轮或者阿克曼底盘，必须自己实现符合运动学的控制器插件。别指望默认控制器能适配所有底盘。

6.3 相机/IMU里程计接入Nav2的流程

在Nav2里，位姿来源是里程计（odom）和定位系统（amcl或SLAM节点）。我们用的视觉+IMU融合结果，本质上就是一套视觉惯性里程计（VIO），它输出的是odom话题。把VIO节点输出的transform和odometry消息接入Nav2流程：

首先确保VIO节点发布的frame_id是“odom”，child_frame_id是“base_link”，并且频率至少达到20Hz以上，Nav2的costmap更新和控制器执行都比较依赖高频里程计。其次AMCL或SLAM建图节点接收到VIO位姿后，需要融合激光或视觉观测做全局修正，否则长时间运行还是会缓慢漂移。

我遇到过最多的情况是，VIO本身精度没问题，但Timestamps不同步导致Nav2的transform树频繁报错。排查口诀很简单：rostopic hz检查频率，tf tree检查坐标树完整性，rqt_bag检查时间戳偏差。这三大件查完，90%的接入问题都能定位。

7. 仿真与部署经验

7.1 用MuJoCo训练和验证导航策略

这几年强化学习在机器人导航里越来越热，MuJoCo因为物理仿真精度高、速度快，成为很多人训练扫地机导航策略的工具。用MuJoCo训练扫地机器人导航，最大的优势是可以大规模生成随机场景——随机布置障碍物、随机起点终点，让策略学会在未见过环境中泛化，这在真机上是不可想象的。

但仿真训练也有明显的坑：Sim-to-Real的差距。MuJoCo里摩擦系数、电机响应、传感器噪声都太干净，策略在仿真里无敌，搬到真机可能第一步就撞墙。我的建议是训练时对IMU和视觉观测加入高斯噪声、随机时间延迟、随机传感器缺失，做一些domain randomization，逼着策略学习鲁棒行为。

MuJoCo的定位其实更适合验证底层运动规划和避障策略，整个系统的SLAM、全局路径规划还是建议在Gazebo或者真实数据回放上调试，不同仿真器各有适用场景，别指望一个工具全包。

7.2 真机调试的坑

真机调试是整个项目里最考验耐心的阶段。第一个坑就是振动。扫地机底盘电机和滚刷振动会把IMU信号污染，融合轨迹出现高频抖动。解决办法除了物理上加减振泡棉，还可以在IMU驱动里加陷波滤波器，专门滤掉电机基频附近的噪声。

第二个坑是光照变化。相机在夕阳西下时照进客厅，整个画面的白平衡剧烈变化，特征点跟踪很容易崩。工程上一个是让相机尽量工作在自动曝光区域内，同时在VIO前端做亮度归一化；另一个是配置IMU的权重，光照突变时适当提高IMU的影响，等图像恢复后再拉回来。

第三个坑是地毯和深色地板。RGB-D在黑色长毛地毯上基本失效，双目也经常匹配失败。这时候必须依靠IMU和轮式里程计短时间维持位姿，等相机恢复。视觉+IMU融合的价值在这类场景体现得最明显。

7.3 常见问题排查速查表

我见过不少人把大量时间花在算法调参上，最后发现是标定或者时间同步这种基础问题没解决。做融合导航，先保证数据干净，再谈算法优化，顺序不能反。

说到时间同步，想再提醒一个容易被忽略的细节：如果在系统里同时跑视觉SLAM和IMU，并且还有激光雷达参与建图，三个传感器之间的时钟偏差会在长时间运行后慢慢累积。量产产品建议用硬件级别的同步信号把所有传感器锁在同一个时钟源上，别指望软件时间戳对齐能长期稳定，这是我们从多次翻车中总结出来的教训。

最后分享一个我们团队一直沿用的原则：视觉+IMU融合导航不是某一个算法的胜利，而是传感器标定、状态估计、路径规划和系统工程的综合结果。每次调试只改一个变量，记录一组数据，保持耐心，问题总会浮出水面。希望这篇整理能让你在扫地机器人导航这条路上少走一些弯路。