这几年因为做智能车辆上的定位模块接触了不少视觉SLAM方案也踩了不少坑。VSLAM在手机上跑和车上跑完全是两个世界车上对实时性、功耗、长时间稳定性、光照突变容忍度的要求比实验室严苛得多。HOOFR-SLAM这个项目我拆过源码、改过板级配置、在实车上从头到尾跑通过算是比较有发言权。它最吸引我的不是算法又刷了几个榜单而是它从设计到部署都带着很强的“嵌入式意识”——特征怎么选、优化怎么切、数据在内存里怎么排每一步都在为有限算力做妥协和权衡。这篇文章就把这套系统的架构逻辑、关键细节、部署经验一次说清附带我实际调试时踩过的坑和排查思路适合正在做车载定位、嵌入式视觉或者准备把SLAM往板子上搬的工程师参考。1. 这套系统到底在解决什么问题1.1 智能车辆上的SLAM为什么难做先聊一个核心矛盾智能车辆需要一个持续稳定、厘米级到分米级精度的自定位能力但车端能提供的计算资源是极其有限的。有人会说现在车载芯片算力不是越来越强了吗还有各种NPU、GPU。但真实项目里GPU往往被感知模型吃掉了留给SLAM的只有几个CPU核加上一部分片上内存温度墙、功耗墙、实时调度墙全都卡着你。ORB这类传统方案在PC上跑得很欢搬到车端就频繁掉帧。更麻烦的是车辆环境的视觉退化。地下车库的重复柱面、园区道路的透视变化、隧道里的频闪灯还有雨夜地面反光任何单一视觉特征都可能在某个瞬间集体失效。系统必须在这些场景下保持不炸丢帧也不能丢定位。第三点是长时间运行。车辆一跑就是几个小时地图不断累积关键帧越来越多如果不对局部优化和回环做严格约束漂移会逐步放大最终定位地图整体变形。HOOFR-SLAM这套系统的价值就是把“嵌入式算力约束”和“长期鲁棒定位”这两个需求用一套完整的技术栈同时接住。1.2 HOOFR-SLAM的整体设计思路这个系统的设计思路可以概括为一句话用二进制特征的极致效率换取优化的冗余度用稀疏图结构换取全局一致性用软硬件映射把每一毫秒算力都花在刀刃上。具体拆开看它由五个核心模块组成前端特征提取与描述子生成、帧间跟踪与位姿估计、局部滑动窗口优化、回环检测与全局图优化、以及贯穿始终的嵌入式硬件适配层。前端负责把图像变成可供匹配的特征点中端负责计算相邻帧之间的相对运动优化部分维护一个局部窗口内的3D地图一致性回环部分在发现闭环时把累积漂移一次性掰回来。硬件适配层则决定了这些算法最终以什么粒度运行在CPU、NEON向量单元和DSP上。这套架构本质上走的是稀疏视觉里程计路线跟ORB-SLAM系列同源但有明显区别。ORB-SLAM的架构是通用性的在PC上表现很好却很少针对ARM平台的定制优化做深入。HOOFR-SLAM则从一开始就把“避免浮点密集计算”和“让数据流适配SIMD指令宽度”当成第一优先级很多看起来不起眼的细节如描述子位串的排列方式、金字塔每层的降采样顺序都是为了在嵌入式硬件上能少做几次访存、多并行几个像素。2. 核心细节拆解特征、优化、回环怎么配合2.1 HOOFR特征它和ORB的区别在哪说到二进制特征十个人里有九个第一反应是ORB。ORB的好处是成熟、有ORB-SLAM系列开源背书但真拿到车规级嵌入式板子上跑ORB有几个痛点。FAST角点的方向计算涉及区域矩得做多次浮点乘累加BRIEF描述子的采样点取像素灰度比较指令级上很难一次批量处理多个点的比较结果再加上金字塔多层构建访存开销非常大。HOOFR特征在这个基础上做了重新设计角点检测和FAST类似但方向估计和描述子生成的采样点排布是按“硬件优先”原则来的。比如方向估计HOOFR并没有完全抛弃角度信息而是使用最经典的强度质心法计算主方向但在具体实现上把图像块的积分计算做了SIMD化一次处理连续多行的像素累加减少在循环里的标量浮点操作。描述子生成是HOOFR的一个关键差异。它把[采样点对的灰度比较结果]直接打包成固定长度的位串每位代表一个采样点对的灰度大小关系。这个设计本身和BRIEF没有本质区别但采样点对的坐标并不是随意撒的而是经过优化选择的使得最终的比较结果分布更均匀、对光照变化更稳定。更重要的是这些采样点对的像素坐标被设计成在内存上尽量连续便于用向量加载指令一次性取出然后用位运算直接生成描述子。我实际测过在ARM Cortex-A系列的NEON环境下HOOFR描述子的生成耗时比同尺寸的ORB描述子大约低25%到40%这个差距在高帧率场景下会被放大。匹配环节是另一个优化点。ORB匹配用汉明距离本质上就是一连串的异或加popcnt操作。HOOFR把描述子按64位或128位对齐匹配时可以用NEON的向量异或指令一次性处理多个描述子再通过预计算的查表法快速统计位差异数。实测下来在匹配点对数达到几千对时这种批量处理比逐字节popcnt快上接近一倍。对于那些觉得“ORB已经够用”的人来说这个数字可能不刺激但在嵌入式平台上每一毫秒的节省都会直接反映到帧率上。2.2 前端里程计与退化场景处理前端里程计负责从连续图像帧计算相对位姿。HOOFR-SLAM采用了一套标准的“特征匹配 RANSAC剔除 运动估计”流程。特征点提取后在金字塔各层上做对应匹配然后用RANSAC鲁棒估计本质矩阵或单应矩阵。这一步在很多系统里都差不多真正能拉开差距的是对退化场景的处理。我举一个实际场景车辆从明亮的室外驶入地下车库入口光照在不到两秒内剧烈变化。大多数特征匹配在这个瞬间会大量失效如果系统没有处理机制就会直接跟丢。这套系统的做法是前端维护一个“特征质量状态机”。当匹配数量低于阈值时不会立刻宣告丢失而是暂时降低对特征数量的要求同时触发自适应直方图均衡化和金字塔层数切换尝试在对比度被拉开的图像上重新提取特征。这个机制在光照突变场景里能保证定位不中断但如果连续多帧匹配数都低于硬下限系统还是会判定跟丢并触发重定位不会硬撑着输出错误位姿。对于车辆功能安全要求来说及时上报“丢了”比提供错误轨迹更重要。另一个不得不提的是动态物体。车辆在路口等红灯旁边车道的车开过去行人在前面穿行这些动态区域的特征点会严重干扰位姿估计。HOOFR-SLAM的做法比较务实在特征匹配阶段用极线约束筛掉不符合几何关系的特征点在优化阶段通过鲁棒核函数降低高残差点的权重动态物体带来的误差会被自动削弱。这个方法理论深度不算高但在实践中非常可靠远比引入实例分割模型更划算。2.3 局部优化和回环检测的配合视觉SLAM的长期稳定性靠的就是局部优化和回环检测共同维持。HOOFR-SLAM并不做全局重投影大优化而是维护一个滑动窗口内的局部地图。具体来说当前活跃关键帧数量大约维持在10到15帧窗口内的3D地图点和这些关键帧的位姿会被捆绑成一个局部Bundle Adjustment问题用高斯牛顿法迭代求解。它的好处是把优化规模限制在一个可控范围单次优化耗时稳定不会像全局优化那样随着地图尺寸增长而膨胀到不可控。代价是精度在长时间运行后可能不如全局优化但回环检测恰恰补上了这块短板。回环检测用的是词袋模型本质上就是把每个描述子看作一个图像“词”把整帧图像统计成词频向量通过相似度打分找出历史中可能与之匹配的旧帧。这部分逻辑在很多系统里都有HOOFR-SLAM的特殊之处在于它非常强调几何验证即使词袋打分很高也必须经过特征点层面的匹配确认和本质矩阵校验通过之后才会把回环边加到全局图里。我一直在说图优化这里的图不是图像而是由关键帧位姿和它们之间的约束关系组成的拓扑图。图优化过程用稀疏非线性最小二乘求解维护的是关键帧位姿之间的相对约束修正的是累积漂移。整个过程并不处理稠密地图所以内存占用和耗时都可控。有一次我在一段单向2公里的地下车库里反复绕圈系统在第二次经过同一个区域时成功检测到闭环闭环前轨迹在终点位置已经漂了将近1.8米闭环修正后直接拉回到0.1米以内效果很直观。当然这个精度也跟IMU融合的程度有关如果系统接入轮速计或IMU预积分漂移本身就会小很多。3. 软硬件映射算法怎么在嵌入式平台上跑起来3.1 先定平台计算单元的取舍“软硬件映射”这个词听起来有点学术翻译成人话就是算法里的每个循环、每个矩阵运算、每块数据最终要在哪个硬件单元上执行以什么顺序、什么粒度执行把大任务切成多大等份分给多个核心。做这个事的第一步不是俯身写代码而是先画一张计算与数据流图。我把这套系统拆成六个核心部分图像金字塔构建、特征提取、描述子生成、特征匹配、局部BA、回环检测。其中金字塔构建和特征提取耗时占比能到60%以上描述子生成和匹配占20%左右优化部分占20%。这意味着如果只优化BA求解器对整体帧率的提升非常有限必须优先解决图像处理和特征提取这两个大头。这个结论其实反直觉很多人一上手就怼着优化算法猛调但性能瓶颈根本不在那儿。平台选型上这类系统最适合的是多核ARM处理器外加NEON向量单元或者带轻量级GPU的方案。如果GPU被感知模型占用纯CPU方案也能跑得不错但前提是多核调度得当。我比较推荐把特征提取和金字塔构建放在第一个核匹配和位姿估计放在第二个核优化部分放在第三个核回环检测作为低优先级任务放在后台线程。这个分配不是死的不同芯片的缓存层级不同会影响线程间共享数据的开销需要反复调。总体上这套系统能跑在四个核以内单核频率不需要太高但每个核的乱序执行能力和NEON位宽很关键。3.2 热点拆解与性能优化软硬件映射的直接产出是性能。那么性能在哪里体现我用一个常见配置举例640x480分辨率的灰度图金字塔5层每帧提取目标特征点800到1000个目标帧率30FPS。在一个主频1.8GHz的ARM处理器上这套配置对图像预处理和特征提取的时间预算大约就是每帧15到20毫秒整个SLAM前端加优化加起来要控制在33毫秒以内。第一刀砍向图像金字塔。传统做法是逐层高斯模糊再降采样计算量很大。HOOFR-SLAM的做法是降采样和模糊融合用一次缩放内核同时完成平滑与抽稀。在NEON上缩放运算被拆成对像素块的向量乘加比逐像素浮点卷积快得多。实际效果金字塔构建从原来的5毫秒降到了2毫秒左右。这一刀下去帧率直接提升一个台阶。第二刀砍向特征提取的候选点扫描。FAST角点检测本质是遍历像素比较以其为中心的圆周围像素与中心点的灰度差。这个逻辑天然适合向量化但前提是把图像数据读入NEON寄存器时做好边界处理。我们采用的方式是对图像做边padding填充让每个像素周围的16个点都能通过固定偏移量访问避免了大量分支判断。这听起来是小事但对循环效率的提升非常显著。第三刀是内存布局改造。SLAM系统里很多操作都是对单张图像反复访问如果每次都用标准图像指针步长的方式访问缓存命中率很低。我们把金字塔每一层的内存单独分配按行对齐到64字节这样每一次向量加载都能对齐并且相邻行在cache里尽量连续。做了一次这种改造之后整个特征提取模块的cache miss率下降了不少整体耗时再降了大约15%到20%。还有一个容易被忽略的点不要在算法内部频繁new和delete内存。嵌入式环境下的内存分配器性能有限频繁申请小块内存会造成严重抖动。我们的做法是在系统启动时一次性申请一个内存池把金字塔图像、描述子数组、匹配结果数组、优化临时矩阵全部从池里分配。这个改动带来的稳定性提升远大于速度提升至少能防止长时间运行后内存碎片的累积。3.3 数据并行多个核心怎么分活多核并行不是把代码拆成多个线程就完事难点在线程之间交换数据的开销。举个例子特征提取完成后的描述子数组匹配线程要立刻用到。如果每次都用锁保护共享队列线程切换和锁等待就会吃光优化带来的收益。这里可以用无锁队列或者双缓冲机制特征提取线程往buffer A里写匹配线程读上一帧已经写好的buffer B当两个线程都完成时再交换指针。代码层面多了一个乒乓切换的逻辑但实测确实把跨线程的等待时间压缩到了微秒级。局部BA的并行化则更复杂。BA求解本质上是一个稀疏矩阵的分解过程如果直接并行会导致比较高的通讯开销因为矩阵的填充和求逆是强相关的。我们在实践中发现小雅可比矩阵计算这个阶段特别适合并行每个地图点对各关键帧投影误差雅可比都是独立计算的可以轻松分给多个核心而之后的线性方程求解阶段保持单线程反而更稳定。这种“部分并行、部分串行”的混合策略是嵌入式SLAM多核优化的一个很实用的思路。并行化需要注意负载均衡。图像金字塔每一层的特征点数量差异很大如果简单按层分配线程很可能一层早做完、另一层还在忙线程空转。更合理的分法是按图像行区段划分。我把一帧图像横向切成多块每个线程处理一块每块内部独立完成金字塔和特征提取。这种方法处理速度快很多但会引入一个副作用就是图像块边界上的特征数量会减少。为了补偿我习惯把切分块重叠8像素最后合并特征时做去重。4. 智能车辆上的应用从实验室到车前4.1 三个典型场景这款系统在智能车辆上应用的场景我总结为三个典型类别。第一类是自主代客泊车。这个场景的特点是速度低、无GPS、环境封闭但视觉特征极度重复墙面、柱子、别的车看起来都差不多。HOOFR-SLAM在这里的发挥空间很大因为系统可以维护一张停车场专用地图车辆进入车库后通过视觉重定位直接确定初始位置。地下车库的光线普遍不好甚至有些区域是半黑状态这时候单纯靠灰度特征会失效。我在实际测试中发现配合主动红外补光或者车灯照明HOOFR特征在低照度环境下的鲁棒性明显优于ORB原因在于它的描述子采样点比较不是基于绝对灰度而是基于局部灰度关系光照整体变暗不会改变灰度关系自然更抗弱光。第二类是园区低速接驳。无人小巴、巡检车在产业园区、机场航站楼等封闭道路运行路线固定但不能靠预先铺设的磁条等基础设施。这类场景下的SLAM需求是长时间稳定和路径可重复。我曾经在一条往返2公里的园区道路上连续跑了8个小时HOOFR-SLAM全程没有跟丢回环检测把终点和起点的误差控制在0.5米以内。虽然没有达到某些融合高精RTK的系统那种厘米级精度但作为视觉参考已经能很好地支持车辆决策。第三类是高速公路的定位补盲。在高速上GNSS信号一般可靠但经过隧道、高架桥底、山区树林遮挡区域时GNSS会短暂失效。HOOFR-SLAM在这里的作用不是替代GNSS而是在GNSS失效的几秒到几十秒内提供一条连续可靠的位姿轨迹避免车辆在传感器层面出现“断点”。这个场景对实时性要求最高但对地图的长期积累要求不高系统甚至可以运行在只有前端里程计和局部优化的轻量模式下。4.2 传感器配置与部署流程参考一次相对完整的智能车辆部署传感器配置上我建议至少包含一个前向灰度相机、一个IMU和一个轮速计。相机建议选全局快门分辨率720p左右足够帧率30到60FPS镜头视场角尽量大一些这样特征覆盖更多。IMU和轮速计如果能接入系统做预积分和轮速约束对光照退化场景会有很明显的帮助。标定是整个系统能否跑通的前提这块我吃过亏。相机内参标定建议用经典棋盘格法采集不同角度和距离的标板图像用重投影误差小于0.1像素的标准去评估标定结果。相机和IMU之间的外参标定更加耗时需要做多个方向的旋转和平移激励采集时间至少二十分钟再通过离线工具联合优化。这套流程在整个项目中属于“不显眼但决定成败”的部分和优化器的参数相比标定误差对最终轨迹的影响要大得多因为它会产生系统性偏差优化器完全无法消除。部署时我会先把系统跑成离线分析模式把相机的每一帧图像和IMU数据记录成bag文件这样可以在开发环境反复回放查找问题。这一步看起来多写了代码但省下的调试时间远大于开发时间。在线部署时还要特别处理传感器时间戳对齐。相机曝光时间和IMU采样时间通常不在同一时钟下如果时间戳不同步超过5毫秒位姿估计就会引入明显的抖动。通用的解法是用锁相环思路对IMU时间戳做插值重采样把相机曝光时刻作为离散锚点再把IMU数据对齐到锚点时刻。4.3 关键参数配置参考参数配置是我在部署时花了最多时间的地方跟精度和实时性都直接相关。下面这张表是一个偏保守但稳定的配置参考适合城市道路和园区低速场景。每个系统的出厂默认值可以作为参考但真正上线前一定要基于自己的数据重新标定。参数项参考值影响说明图像分辨率640x480分辨率高则特征数量多但金字塔构建耗时线性上升金字塔层数5层数多则尺度鲁棒但耗时增加且底层特征贡献有限每帧目标特征数800太少则跟踪易丢失太多则匹配耗时、BA负担重局部窗口内关键帧数12窗口越大优化越准但单次优化耗时显著增加回环候选检索数量30检索太少容易漏检太多则几何验证耗时最小跟踪匹配数150低于此值进入退化处理流程直方图均衡开关仅在光照突变开启均衡化会降低特征区分度不能常开这张表不是从某个手册抄的是我根据项目里的实际数据和多次测试迭代调出来的。比如局部窗口12帧这个数我曾经试过20帧精度提升不到5%但优化耗时涨了差不多50%对于实时系统来说完全得不偿失。最后拿下这个值纯属权衡的结果。4.4 中心公式的形式化理解拆到这里我想顺便把SLAM的本质用一句话点透它是在已知观测约束下对“相机轨迹与地图点位置”的联合最大似然估计。说得更直白一点就是解一个大规模的最小化问题目标函数是最小二乘形式的重投影误差所有历史匹配点对通过相机投影模型得到的预测位置与实际观测位置之间的差值平方和。局部BA就是只取窗口内的这种约束来优化回环检测则把窗口外部的闭环约束也拉进来。数学上这个最小化问题用高斯牛顿法或列文伯格-马夸尔特迭代求解每轮迭代都会更新一个状态增量。纯视觉的BA问题在数学上等价于从图像中恢复场景结构和相机运动的过程深度不确定时会出现零空间这也是单目系统需要一个初始化过程的原因。理解了这一点就能明白为什么这套系统一定要维护好逆深度参数化它对数值稳定性至关重要。5. 实操复盘部署时要注意的几件事5.1 数据采集与回放流程数据采集是第一步也是最容易被低估的环节。我见过很多项目在实验室跑得好好的一到实车就翻车根源就是采集数据质量不行。一定要用正式部署的相机硬件和安装位置采集数据别用开发板临时固定装歪一点都会造成标定参数失效。采集时要有意识地覆盖多种光照条件、转向动作和车速区间。光绕着一个停车场兜圈子是不够的至少要包含从亮到暗的过渡、急转弯、颠簸路段、重复路径这几个要素这样后续才能验证系统的极限能力。采回来的数据要转成统一格式的bag或数据集目录结构。需要记录每一帧图像的系统时间戳、曝光时间、IMU的三轴角速度和加速度以及轮速脉冲。有了这些数据就可以在Linux环境下把整个系统跑成“感知-重建-定位-闭环”的完整离线管道每次改动参数后回放当前bag对比输出轨迹与真值轨迹的ATE和RPE。精度指标我一般会用绝对轨迹误差和相对位姿误差两个指标ATE看整体漂移RPE看局部稳定性。5.2 编译与部署参数调整记录编译这块其实不难但要注意交叉编译工具链版本与目标板GCC版本的一致性。先在目标板上用本机编译做一次全量构建确认环境变量和依赖库都对再用交叉编译优化NEON指令。如果直接用交叉编译器生成的目标文件在板子上跑出非法指令错误多半是编译选项里开了目标架构不支持的指令集比如编译时用了ARMv8.2可选指令但板子的CPU实际只支持ARMv8.0。配置过程通常从默认参数开始先别急着调精度的旋钮把最影响速度的几个参数图像分辨率、金字塔层数、每帧目标特征数调到一个能让帧率稳定在目标值的水平然后再去调优化窗口和回环阈值。我自己的经验是先保实时性再谈精度因为精度问题在离线回放阶段可以反复调实时性不满足在线阶段根本跑不起来。见过太多同事一开始就把特征数拉满了帧率掉到十几帧后面所有模块都跟着遭殃。5.3 从离线到在线为什么参数要重新调离线跑通只是万里长征第一步。离线模式下图像数据是提前录制好的系统不会遇到采集设备延迟、调度优先级抢占、内存不足等在线问题。真正上车后最明显的差异是CPU负载上来了系统会从“专职SLAM”变成“和感知、规划、车控同时抢资源”。这时候你会发现离线时很流畅的参数在线时就会出现周期性卡顿。解决方案基本就是在参数、线程优先级和资源隔离三个层面同时发力。比如把SLAM进程绑到固定核上给它设定一个较高的调度优先级把采集线程绑定到另一个专用核防止数据丢帧。在线部署最麻烦的是启动时机。车辆上电自检后SLAM模块需要快速完成相机曝光收敛、IMU零偏估计和初始位姿恢复。这个过程如果在车辆行驶中才触发很容易因为运动模糊导致初始化失败。我采用的方案是车辆上电但保持静止时先让系统完成IMU零偏估计和相机自动曝光等驾驶员挂挡起步前基本就绪。起步后的前1秒内用轮速计辅助完成视觉初始化避免系统在低速蠕动时初始化失败。6. 常见问题速查与避坑经验6.1 六类高频问题这套系统部署过程中我遇到的高频问题主要集中在六个方面。我整理了一个速查表基本覆盖了从算法到工程的所有常见坑。问题表现可能原因排查手段解决建议快速转弯时跟踪丢失运动模糊导致特征点过少查看丢失时刻的匹配点数与特征响应值提高图像曝光时间下限增大金字塔层数地下车库入口丢帧光照剧烈变化导致特征失效回放视频观察特征提取数量曲线开启直方图均衡切换低层金字塔重试长时间运行后轨迹漂移增大局部窗口约束不足闭环没有及时触发检查回环检索打分曲线降低回环候选阈值增加回环关键帧匹配约束嵌入式平台帧率达不到30FPS特征提取耗时超预算用性能分析工具逐模块计时限制特征数量启用NEON加速调小图像分辨率回环误检导致地图变形词袋相似度过高但没有几何验证检查几何验证通过率提高RANSAC置信度增加足够多的匹配对系统崩溃或复位内存分配失败或线程死锁打开日志查看崩溃点栈改内存池分配检查双缓冲切换流程这六个问题是项目上线前一定能遇见的。排障的通用心法是不要直接改参数碰运气先搞清楚失败原因在哪个模块再用日志和数据去验证。6.2 排障思路与日志设计一个好的SLAM系统必须把日志设计当成一等公民。我在部署时每帧都会记录图像ID、时间戳、提取的特征数、匹配数、内点数、优化耗时、当前线程状态、缓冲队列深度这些信息。一旦出问题回放日志就能知道是哪个模块先异常。比如我从日志里看到某帧特征匹配数骤降但提取数正常那就说明是光照或视角变化导致匹配失败如果提取数本身骤降那问题多半出在曝光或图像模糊上。日志的另一个作用是复盘长时间运行时的内存增长。系统还有一个容易被忽略的问题就是长时间运行后局部地图里产生了大量劣质地图点如果不做剔除优化时长会不断增长。这套系统有个地图点管理模块会周期性检查每个地图点的观测次数和平均残差把观测次数少、残差大的点及时删掉。我最初没有开启这个机制跑了两个小时地图规模就膨胀了将近一倍开启之后地图规模稳定了长期帧率也不再往下掉。6.3 我踩过的几个坑第一个坑是关于图像格式。采集摄像头直接输出YUV420格式我在测试时直接拿YUV的Y分量当作灰度图用结果特征提取效果非常差原因在于ISP没有做白平衡增益处理。后续改成先用ISP输出RGB再转灰度顺便做一次伽马校正特征质量立刻提升。这个经验其实很通用别把摄像头输出的原始数据当成可用数据。第二个坑是多线程同步的时间戳。两路线程分别读取相机和IMU数据我在处理时直接按接收顺序存进了队列结果发现里程计轨迹有周期性锯齿。后来排查发现相机的帧率实际是29.6FPSIMU是200Hz两个频率不成整数倍导致时间戳对不齐。最后是把IMU数据做线性插值对齐到相机曝光时刻的参考时钟锯齿消失。第三个坑是关于回环检测的误判非常典型。一段连续重复的园区道路系统每隔几百米就会把当前帧和上一次经过的帧判定为闭环结果地图被压出好几层重叠。排查后发现词袋模型里大部分视觉词汇来自道路边线的重复纹理而这些词汇的区分度太低。解决办法很直接在匹配时增加一个“至少30对匹配点”的硬阈值不满足的直接拒绝同时限制回环关键帧和当前帧之间的时间跨度防止同一区域在短时间内被反复触发闭环。这个调整之后地图终于稳定了。写在最后这套HOOFR-SLAM系统我最欣赏的一点就是它的实在。它没有堆砌花哨的端到端模型也没有依赖昂贵的传感器而是把一个经典问题在嵌入式平台上做扎实了把算法优化和硬件优化拧成了一股绳。如果让我给正在做类似项目的人一个建议那就是把软硬件映射放在和算法设计同等重要的位置去思考。算法选型时就要问自己这个操作在目标芯片上有硬件加速吗这个数据能不能在cache里放下这个循环能不能向量化等代码写完再去优化往往事倍功半不如在设计之初就把硬件特性考虑到。最后一个分享的细节每次上线实车前我都会在同一个数据集上把系统性能曲线运行三遍确定结果可复现再去动真车。SLAM系统是出了名的“这次好了下次炸”把测试流程固定下来能省下大量定位现场的时间。嵌入式视觉SLAM这条路没有银弹靠的就是一个个细节较真和一次次反复验证。
