咱们先聊一个很多人上来就会踩的坑：做无人机避障，第一反应是去买激光雷达，结果一看价格、重量、功耗，直接劝退。另一个极端是随便找个SLAM装上去跑demo，结果户外光线一变、飞得快一点，位姿直接飞了，避障自然变成了“乱撞”。我自己折腾了快两个月，在NUC上同时部署了VINS（VINS-Mono/VINS-Fusion）和ORB-SLAM3，用自采的飞机数据和公开bag轮流跑，把两个方案在避障场景下的表现摸了个透。
这篇文章就把这次对比的完整过程写下来，包括原理差异、Ubuntu 20.04上的部署细节、实测的精度和耗时数据，以及在真实飞行中遇到的丢跟踪、初始化失败、时间戳不同步这些经典问题。无论你是正在做毕设的学生，还是负责无人机自主导航的工程师，只要是想在视觉避障里选一个开源SLAM方案，这篇文章应该能帮你省下我当初那两个月的弯路。
1. 为什么无人机避障绕不开这两个开源方案
1.1 避障的本质是“看见并躲开”，不是“定位并画图”
先厘清概念。无人机避障要看的是障碍物在哪里、离自己多远、接下来该往哪飞，但几乎所有视觉避障方案的第一步，都绕不开“我现在在哪、朝哪个方向看”——这就是SLAM要解决的事。VINS和ORB-SLAM3能成为这个领域被提到最多的两个名字，不是因为它们论文引用量高，而是因为它们在开源领域真的能落地：代码能编译、能跑真机、能接自己的相机和IMU。
避障和单纯建图的最大区别在于：避障对实时性要求极高。你可以接受SLAM的轨迹在离线优化后变得很精确，但避障必须在每一帧图像到达后的几十毫秒内给出当前位姿和障碍物的相对位置。这就意味着，一个SLAM方案在无人机避障里好不好用，不只看最后精度多高，更要看它的计算效率、鲁棒性和输出接口是否适合直接对接避障规划器。
1.2 VINS和ORB-SLAM3在开源社区的地位
VINS-Mono和VINS-Fusion出自港科大，核心思路是光流跟踪特征点加IMU预积分，然后丢进滑动窗口优化。VINS-Fusion在Mono基础上增加了双目和GPS融合能力，也是我这次主要测试的版本。它的特点是整个系统对计算资源要求相对友好，而且由于用了光流，特征点不需要每次重新提取，在纹理中等偏弱的环境下也能勉强维持。
ORB-SLAM3是萨拉戈萨大学的作品，走了另一条路：全程使用ORB特征点提取和匹配，配合词袋模型做回环检测，还加入了多地图系统（Multi-Map）。在特征丰富的场景里，ORB-SLAM3的精度和回环能力非常强，甚至能在跟踪丢失后重新定位。
说白了，VINS是“优化传感器融合”的思路，ORB-SLAM3是“优化视觉几何”的思路。这两条路线放到无人机避障里，表现差异非常明显。
1.3 这次测试的目标与方法
我的测试目标很具体：在同样的硬件平台、同样的飞行路径和同样的障碍物布置下，对比两个SLAM系统输出的位姿精度、单帧处理耗时、CPU占用、初始化速度，以及在弱纹理、快速旋转、光照突变这三种避障高发场景下的稳定性。测试平台是自组四旋翼，机载电脑是Intel NUC i5 第10代，相机是双目模组（全局快门，640x480@30Hz），IMU是BMI088，通过串口接入。所有测试均通过回放rosbag完成，保证两个系统拿到完全一致的输入数据。
2. 原理对比：光流流派和特征点流派的分野
2.1 VINS：光流跟踪 + IMU预积分 + 滑动窗口
VINS-Fusion的核心流程，一句话概括就是：用光流法去跟踪上一帧的特征点，再用IMU做帧间的姿态预测，最后把视觉和IMU的残差一起丢进一个滑动窗口的图优化里求解。
这里有一个关键设计——为什么用光流而不是每帧重新提取特征？因为光流跟踪只需要在上一帧特征点位置的邻域内寻找到当前帧的对应位置，计算量远小于全图重新提取再匹配。无人机避障时相机一直在动，这种连续跟踪的方式天然适合“小位移”场景。代价是光流跟踪是纯视觉的，遇到遮挡、光照突变或快速旋转时，跟踪点会大量丢失。VINS的设计逻辑是，我有IMU兜底，短期视觉丢失也能扛住，但如果视觉长期失效，IMU的漂移就开始累积。
滑动窗口优化也是VINS降低计算量的一个关键。它不会把历史上所有帧都拿来做全局优化，而是只保留最近的N帧（通常是10到15帧）在窗口里反复优化，窗口外的旧帧直接边缘化掉。这种做法在机载电脑这种算力有限的环境下特别重要，能把单帧处理时间压到20毫秒附近。
2.2 ORB-SLAM3：ORB特征 + 多地图 + 词袋回环
ORB-SLAM3做事的方式完全不同。每一帧图像进来，它先通过ORB特征提取算法在整张图里找关键点（角点和一些纹理变化明显的区域），然后与当前局部地图里的特征点做匹配，再用PnP求解相机位姿。由于ORB特征带有方向和尺度信息，它在面对旋转、尺度变化时的鲁棒性要优于普通的光流跟踪。
ORB-SLAM3最引以为傲的多地图系统，解决的是“长时间跟踪丢失后无法重新回归”的问题。以前的SLAM方案一旦跟踪彻底丢了，整个系统基本就崩了；ORB-SLAM3允许当前帧与之前所有地图进行重定位，如果能匹配上，系统会恢复原来的地图继续跑。这对无人机飞行来说是个重大优势——飞机被树枝挡一下相机或者做大幅度甩尾时，VINS可能已经疯掉了，ORB-SLAM3还有机会自己找回来。
词袋回环检测则是ORB-SLAM3精度的保障。无人机如果多次飞过同一区域，系统能识别出“这个地方来过”，然后做一次全局位姿修正，把累积漂移拉回正轨。VINS也有回环检测，但相对较弱，更依赖本身滑动窗口的低漂移特性。
2.3 技术路线差异对避障的直接影响
这两条路线的差异，直接决定了它们在避障任务里的优劣。
首先看输出。VINS-Fusion因为用的是光流法，可以较容易地利用跟踪的稀疏特征点传播深度信息，并输出半稠密或稠密点云（在实际使用中常用VINS-Fusion配合depth map或稀疏点云），这对避障算法是极为友好的——你直接拿点云做障碍物聚类就行。而ORB-SLAM3输出的是稀疏的地图点，数量少，分布散，很难直接用来做障碍物检测。你拿ORB-SLAM3的稀疏地图点云做避障，大概率会漏掉细小的障碍物。
再看鲁棒性。ORB特征在光照变化大的环境里表现更好，因为它用金字塔提取特征，对明暗变化有一定的尺度不变性。但它的代价是特征提取时间较长，在低纹理环境（比如白墙、天空）里，ORB点数量急剧下降，甚至少于能求解位姿的最低数量（一般需要至少15到20个匹配点）。VINS的光流法虽然也存在同样问题，但由于是跟踪方式，对特征点的绝对数量要求宽松，再加上IMU辅助，在弱纹理场景下的维持能力反而更强。
这两点差异，构成了这次实测的核心关注维度。
3. Ubuntu 20.04下的部署与数据集复现实操
3.1 环境准备：ROS Noetic + 依赖库版本的红线
部署ORB-SLAM3和VINS-Fusion，我建议直接在Ubuntu 20.04 + ROS Noetic下进行，这套组合目前社区支持最好。系统装好之后，有几个依赖库的版本是硬约束，不对齐的话后面编译各种报错。
Eigen建议装3.4.0或3.4.0以上版本，注意不要用系统自带的3.3.7，ORB-SLAM3编译时对Eigen的模板支持有要求。OpenCV版本不要超过4.2，如果编译ORB-SLAM3用的OpenCV是4.5以上，第三方的DBoW2库会出现函数签名不匹配的问题。Ceres Solver建议装1.14.0版本，VINS对Ceres的依赖比较轻，新版Ceres也能编译过，但2.x版本改了一些接口，保险起见用1.14.0。Pangolin是ORB-SLAM3用来做可视化界面的库，装最新版就行，但注意它会拉入很多图形依赖（libgl1-mesa-dev、libglew-dev这些），提前装好省得后面报错。
一个绕不开的坑是Python版本。Ubuntu 20.04自带Python 3.8，但ROS Noetic的cv_bridge默认绑定的是Python 3.8的OpenCV版本，如果你后续想用Python读取bag里的图像话题做数据分析，会发现cv_bridge import一直报错。解决办法是单独编译一个cv_bridge的Python 3版本，或者干脆所有数据分析都用C++写，我图省事就直接用Python的rosbag库读图像原始数据，再用OpenCV的numpy接口自己解码，绕过了cv_bridge的问题。
3.2 编译过程中的三个高频报错与处理
第一个必踩的坑是ORB-SLAM3编译到最后链接阶段报错：undefined reference to cv::Mat::Mat(cv::Mat const&)。这个报错表面上是OpenCV链接失败，实际原因是Pangolin在编译时自动链接了自己内置的一套OpenCV，而ORB-SLAM3又链接了系统OpenCV，两个库的ABI冲突了。解决办法是在Pangolin的CMakeLists里关掉内置OpenCV支持，或者设置环境变量Pangolin_DIR指向自编译的Pangolin路径，同时用-DCMAKE_BUILD_TYPE=Release重新编译ORB-SLAM3。
第二个坑是VINS-Fusion编译时报No rule to make target '/usr/lib/x86_64-linux-gnu/libGLU.so'这类链接错误。原因很简单，缺少图形库的符号链接。执行sudo ln -s /usr/lib/x86_64-linux-gnu/libGLU.so.1 /usr/lib/x86_64-linux-gnu/libGLU.so就能解决。
第三个坑是运行ORB-SLAM3时终端提示Need Eigen, but Eigen not found，但Eigen明明装好了。这时候检查一下CmakeLists.txt里Eigen3_INCLUDE_DIR是否写的是/usr/include/eigen3，有些版本会默认找/usr/local/include/eigen3，做个软链接就能过。
3.3 用bag文件让两个系统跑同一份数据
要横向对比两个SLAM系统，最公平的方式就是先录制一份rosbag，然后分别回放给两个系统跑。我录制了一份约8分钟的bag，包含双目图像、IMU数据、GPS（用于生成真值参考）。录制时要注意：相机的频率设在20到30Hz，IMU设在200Hz附近，这接近真实无人机使用场景。
VINS-Fusion自带的run_offline工具可以直接输入bag路径跑离线模式，但更方便的方式是启动vins_estimator节点，然后通过rosbag play回放bag数据，这样系统实时运行，能真实反映机上延迟。ORB-SLAM3的Ros版也类似，启动ros_stereo_inertial节点的同时，回放bag数据。
这里有个容易忽略的点：bag里的时间戳决定了整个系统的时间基准。如果你的相机和IMU时间戳不同步，VINS的表现会非常差，甚至无法初始化。下面第5节我会详细说时间同步的问题，这里先给一个建议：录bag之前，确保用imu_utils和cam_imu_calib工具做过相机IMU联合标定，并且给bag录一个校准后的话题对齐步骤。
运行bag回放时，还有一个延迟节奏的问题。ROS bag记录的是真实时间间隔，但回放时如果电脑性能跟不上会导致丢帧，回放速度自然变慢。建议用rosbag play --clock --hz=100 -r 1.0 your.bag，开--clock把bag时间作为ROS时间基准，--hz设置主题发布的最高频率限制，防止VINS的IMU订阅回调堵塞。
4. 实测数据：精度、耗时与资源占用横向对比
4.1 硬件平台与测试场景说明
先说测试环境，保证数据的可信度。机载电脑是NUC i5-10210U处理器，四核八线程，16G内存，无独显。相机是双目模组，输出640x480@30Hz的灰度图像，IMU是BMI088，固定在飞机中心附近，经过外参标定。整个测试在室内一个有落地窗的实验室进行，场地面积约12m x 10m，地面有少量反光材质，墙面白墙与设备柜交错，布置了若干纸箱作为障碍物。
飞行路径设定为：起飞以后绕场地进行8字飞行，中间穿插两次悬停、一次快速偏航（机身原地旋转90度）、一次向白墙区域直飞减速。每条路径一共飞3次，取最好的一次结果进入最终统计。真值轨迹使用OptiTrack动捕系统提供，精度在2mm以内，足以用来评估两个SLAM方案的轨迹精度。
4.2 轨迹精度：ORB-SLAM3常规领先，VINS也不拉胯
下面这个表是我在室内8字飞行路径上统计的ATE（绝对轨迹误差，计算方式是估计位置和真值位置之间差值的均方根）结果：
| 指标 | VINS-Fusion (双目) | ORB-SLAM3 (双目+IMU) |
|---|---|---|
| ATE均方根误差 | 0.142 m | 0.098 m |
| 最大单点误差 | 0.421 m | 0.236 m |
| 最终漂移量（闭环后） | 0.185 m | 0.072 m |
| 初始化耗时 | 约2.8 s | 约1.6 s |
| 单帧平均处理耗时 | 21.4 ms | 34.2 ms |
这个结果符合预期：ORB-SLAM3的全局优化和词袋回环确实让它在中低速飞行的轨迹精度上比VINS高出一截。尤其是最终漂移量，ORB-SLAM3因为有回环修正，在飞完完整一圈回到起飞点附近后，位置误差控制得非常好。VINS的滑动窗口优化优势是局部平滑，它不会突然出现跳变，但是在大范围路径上累积误差一定会比有回环的系统大。
不过要注意一点，在悬停阶段（无人机几乎静止，相机视野基本不动），两个系统的表现非常有意思。VINS因为光流加IMU融合，在静止时定位非常稳定，输出位置漂移几乎为零。ORB-SLAM3在静止时偶尔会因为特征点匹配数量变化出现微小的位姿抖动，幅度在1到2厘米，对避障来说完全够用，但能感受到差异。
4.3 计算资源消耗：VINS更轻，ORB-SLAM3更吃CPU
计算资源是无人机避障绕不过去的另一个指标。机载电脑不仅要跑SLAM，还要同时跑障碍物检测、路径规划和控制回路，留给SLAM的CPU预算往往只有30%到40%。
| 指标 | VINS-Fusion | ORB-SLAM3 |
|---|---|---|
| CPU平均占用率 | 27% | 36% |
| 内存峰值占用 | 780 MB | 1.1 GB |
| 单帧最大处理耗时 | 32 ms | 51 ms |
| 是否适合30Hz相机 | 是 | 临界 |
| 是否需要GPU | 否 | 否 |
ORB-SLAM3在单帧处理耗时上的劣势很直观：由于每帧都要做新特征点提取和词袋计算，它的耗时天然比光流跟踪+滑动窗口高。而且如果相机是30Hz，一帧的处理极限是33.3毫秒，ORB-SLAM3的34.2毫秒平均耗时已经非常逼近这个上限，意味着在算力更弱、图像分辨率更高或者同时负载更多任务时，很容易出现处理不过来导致丢帧。
我这里有几个实测值供参考：在640x480分辨率下，ORB-SLAM3的单帧特征提取耗时约8到12毫秒，特征匹配约10到15毫秒，优化约5到8毫秒。VINS的光流跟踪只需3到5毫秒，特征管理约2到3毫秒，滑动窗口优化约10到15毫秒。换句话说，VINS把计算量的大头集中在优化上，而ORB-SLAM3在视觉前端就消耗了大量时间。
4.4 鲁棒性场景对比：三种“致命场景”的存活率
比精度更重要的，是SLAM系统在避障中遇到极端场景时的存活率。我实测了三种场景，每种场景让飞机主动去“找死”，看看两个系统的表现：
| 场景 | VINS-Fusion | ORB-SLAM3 |
|---|---|---|
| 白墙直飞（弱纹理） | 勉强维持约5秒后漂移 | 1秒内丢失跟踪 |
| 快速90度偏航 | 丢掉约1/3光流点，但靠IMU撑住 | 特征重匹配，能扛住 |
| 光照突变（灯全开变半暗） | 光流点大面积消失，约1秒恢复 | 特征点减少，但恢复较快 |
| 动态障碍物（行人从相机前走过） | 偶发位姿跳动，总体可用 | 位姿跳动更大，有时产生错误地图点 |
白墙直飞这个场景是最残酷的。VINS在弱纹理下因为还有IMU预积分的支撑，跟踪不会瞬间崩掉，位置误差会随着时间慢慢增大，在你反应过来之前不会突然发散。ORB-SLAM3则不同，一旦ORB特征点数量低于安全阈值，跟踪线程直接宣告丢失，系统进入重定位模式，重定位需要时间，这段时间避障算法拿到的是过期位姿，非常危险。
快速偏航场景反而是ORB-SLAM3更从容，因为ORB特征自带旋转不变性，即使图像内容相对上一帧旋转了90度，依然能提取到可匹配的特征。VINS的光流点在快速旋转时容易跟丢，只能靠IMU预测顶住，视觉观测基本失效，位姿误差瞬间增大。
动态障碍物场景两个系统的表现都不算完美。行人走过相机视野时，ORB-SLAM3会把行人身上的特征点当成静态地图点，一旦行人移动，这些地图点就变成了“错误观测”，导致局部位姿被带偏。VINS的问题类似，但由于它的图优化对异常观测量有更强的鲁棒性（具体来说使用了Huber核函数），位姿跳动的幅度会小一些。
5. 避障实战：那些丢跟踪、撞墙的瞬间
5.1 弱纹理环境：光流和ORB都得跪，但跪姿不同
在真实飞行里最容易触发SLAM崩溃的，不是高速飞行，而是白色墙面和大面积天空。实验室的白墙区域是我故意设计的测试点，飞机直飞向白墙，两个SLAM系统的表现差异非常典型。
VINS在逼近白墙的过程中，光流跟踪点会逐帧减少，但IMU在短时间内还能维持一个相对稳定的位姿。此时尽管视觉观测基本失效，VINS的位姿输出依然平滑，不会突然跳变，只是累积误差开始缓慢增长。如果你的避障算法不要求高精度定位，只要求障碍物距离信息，VINS还能撑几秒钟让你有机会执行刹车。
ORB-SLAM3则是另一种表现：当ORB特征提取到的点少于15个时，跟踪线程会直接退出当前帧的位姿估计，进入一个“跟踪丢失”的状态。此时系统停止输出新的位姿，直到重新检测到足够特征点后才能恢复。对避障算法来说，这意味着SLAM输出突然冻结，如果此时正对着墙壁高速飞行，后果可想而知。
我的改进做法是：白墙环境下给ORB-SLAM3补充一个来自深度相机的额外信息源，或者在编码器层面对弱纹理区域做一次超像素分割，强制提取更多角点。这些方法能缓解问题，但治标不治本。所以在纯室内白墙环境里做避障，我的优先级是VINS-Fusion > ORB-SLAM3。
5.2 快速机动：偏航率超过40度每秒时的生死局
无人机在避障过程中经常会做大幅度转弯或甩尾动作，这时候SLAM的鲁棒性直接影响飞行安全。我在测试中让飞机以大约60度每秒的角速度做原地偏航，持续2秒。
VINS的表现是：光流跟踪点在快转瞬间大量丢失，但IMU预积分提供了连续旋转的角速度估计，系统在短暂失去视觉约束后，依靠IMU预测位姿，然后在旋转停止后重新建立视觉匹配。整个过程的位姿误差会增大到10到20厘米，但不会完全崩溃。
ORB-SLAM3的表现是：由于ORB特征自带旋转不变性，它在转得快时依然能提取特征并匹配，但每帧提取的特征会有一部分落在动态模糊区域（快速旋转时图像容易模糊），导致匹配质量下降。实际观察到的结果是，ORB-SLAM3在快速偏航时的位姿输出比VINS更平滑，尤其是在旋转前后没有明显的位姿跳变。
但有一个细节要提：ORB-SLAM3在快速偏航后容易触发“关键帧插入”风暴，因为旋转造成视角变化大，系统会频繁插入关键帧，这会短暂占用优化线程资源，导致几帧的处理耗时会暴涨到60毫秒左右。虽然不至于丢跟踪，但实时性会受影响。
5.3 动态物体干扰：人从相机前面走过，位姿会跳吗
在实验室环境里，避障测试难免有人员走动。我专门做了几组测试：让一个行人从相机前方两米处横穿走路，连续走5次，观察SLAM输出的位姿是否发生跳动。
VINS的跳变幅度在最开始的1到2帧比较明显，位置误差增加约3到5厘米，随后在0.5秒内恢复。原因是VINS对动态物体有某种程度的抵抗力，光流点在行人穿越期间匹配会发生错乱，但系统通过滑动窗口优化时残差太大，直接降权了这些异常的观测量。
ORB-SLAM3的表现更差一些，位姿跳变幅度约5到8厘米，而且行人身上的特征点被错误地加入了局部地图，形成了一些“动态地图点”，在行人离开视野后，这些错误的点还会在局部地图里存在一段时间，持续影响位姿精度，直到下一次局部BA（Bundle Adjustment，光束平差）把它们剔除。这个问题在ORB-SLAM2时代就有，ORB-SLAM3做了改进但仍不完美。
给做避障的朋友一个实用建议：如果在动态物体较多的环境里飞行，尽量使用双臂双目或RGB-D相机，并且在后端添加outlier rejection机制（VINS有默认的，ORB需要自己加），或者在SLAM输出位姿前加一个简单的异常跳变检测，一旦检测到位姿跳动幅度超过阈值，自动切换为IMU预测模式。这个补丁实现起来简单，但对避障安全提升巨大。
5.4 时间同步：容易被忽略却影响巨大的大坑
录bag时最容易犯的错误是直接把相机时间戳和IMU时间戳混在一起，不做任何对齐。两个SLAM系统对时间同步的要求不同，但都有严格的下限。
VINS对时间同步极其敏感。它内部有一个严格的时间对齐模块，如果IMU时间戳和相机时间戳之间的偏差超过2毫秒，系统会在初始化的最早期就报错，或者输出一个严重漂移的轨迹。我在测试中曾故意把IMU时间戳偏移10毫秒，VINS的表现是初始化后轨迹立刻发散，完全不可用。
ORB-SLAM3对时间同步的容忍度稍高，在10毫秒级别的偏差下还能跑，但精度会明显下降。因为它的视觉和惯性融合是紧耦合的，时间戳不精确意味着IMU积分和相机位姿之间的插值不对齐，等效于给系统添加了额外的噪声。
时间同步的正确做法是：使用硬件同步信号（PPS或PWM同步线）让相机曝光时刻和IMU采样时刻对齐，如果不能做硬件同步，至少要在软件层面使用“最新观测时间”对齐策略，并做一次时间延迟估计校准。我在测试里用的方案是：通过imu_utils和kalibr标定得到相机和IMU间的固定时间延迟，然后在bag回放时用tf的TimeSynchronizer或者ROS的message_filters来做软同步，这样误差控制在2到3毫秒以内。
6. 避障方案选型建议：别只盯着精度数据
6.1 如果你的重点是“看得见障碍物”，VINS-Fusion更合适
回到博文标题里最核心的问题：无人机避障到底该选谁？我的结论是，如果你的避障需求是“在同一片区域连续飞行，需要持续感知前方障碍物”，VINS-Fusion的工程落地难度更低，因为它能做稠密或半稠密的深度估计，并且计算量小，留给避障算法和规划器的资源更多。
实际使用中，我建议采用VINS-Fusion双目模式，再接一个深度估计模块（比如在左右目匹配后用SGM或者简单的视差计算得到深度图），通过稠密点云直接做障碍物栅格地图。这个方案的延迟可以做到从图像输入到避障指令输出不超过80毫秒，对大多数避障场景已经足够。
另一个加分项是VINS-Fusion支持GPS融合。户外飞行时，你很容易获得GPS或RTK信号，VINS-Fusion可以直接把GPS观测纳入优化，得到全局稳定的位姿，这在户外大树和建筑物遮挡严重的环境里尤其重要。ORB-SLAM3目前不支持GPS融合，需要自己写接口，工程量大不少。
6.2 如果你的重点是“高精度回环”和“长时间飞行”，ORB-SLAM3更有优势
反过来，如果你的飞行场景特征点丰富（比如在森林、建筑群、室内厂房里），并且你需要长时间工作后位姿还能保持很小的漂移，ORB-SLAM3的精度优势就体现出来了。在特征丰富的工厂车间里，ORB-SLAM3的ATE可以做到5厘米以内，回环修正后位置误差基本复零，这对无人机在狭小空间里的精确避障非常关键。
但你要承担两个代价：第一，计算量更大，机载电脑至少要预留35%以上的CPU；第二，输出只有稀疏地图点，无法直接做稠密障碍物检测。我的方案是让ORB-SLAM3只负责定位，另外接一个RGB-D相机或双目深度相机专门做障碍物检测，两者独立运行，通过时间戳同步。这个方案在避障的鲁棒性上最大化，代价是增加了系统复杂度和重量。
6.3 一个小众但实用的配置：两者结合的架构
最后分享一个我最近试出来的玩法：同时运行VINS-Fusion和ORB-SLAM3，把两个系统的位姿输出做一个简单的加权融合。具体做法是，用VINS-Fusion的位姿作为主定位源，用ORB-SLAM3的回环检测结果作为“发现闭环时的绝对位姿修正”，在ORB-SLAM3检测到回环时，计算它与VINS的轨迹相对变换，用这个变换在线修正VINS的累积漂移。
这个方案的灵感来自一个朴素的观察：VINS的短时间局部精度好，ORB-SLAM3的长时间全局精度好，两者在频率上互补。实测下来，融合后的轨迹精度在长飞行场景下能提升到ORB-SLAM3的水平，而计算量只增加了大约20%（因为VINS本身比较轻量）。当然这需要写一定量的中间代码，适合有一定源码阅读能力的朋友尝试。
另外提醒一句，不管最终选哪个方案，先把数据标定和bag录制规范搞定。这一步做不好，后面所有对比和结论都没有意义。我花了将近两周才把相机内参、相机IMU外参和时间延迟标定稳定，这直接决定了后面每一个实测数据的可靠性。
最后说点个人体会：SLAM选型很像找对象，没有绝对的好坏，只有适不适合你的场景。别被论文里的Benchmark精度数字骗了，也别因为别人说“VINS漂移大”就直接排除，自己在真机上跑一遍，拿自己场景的数据看结果，才是做避障系统最靠谱的路线。
