前言：一个 SLAM 新人的折腾之路
大家好，我是一名接触 SLAM 半年左右的新人。
🗿首先，由于我不是做机器人行业，而是倾向于 XR 领域的，所以我所研究的方向起始更倾向于 XR 设备或者是普通安卓手机。并且也接触并体验了一些室内导览或 AR 文旅类的项目，大概对移动端的实现效果有了些许认知。
在最近的学习过程中，我拜读了很多大佬的文章，也看了一些论文，深受启发。
从我个人粗浅地对行业的观察来看，目前的视觉定位系统（VPS）大多依赖于云端服务📡（为了不出现厂商名，这里就不举例了），通过上传图像到云端进行检索和定位。这种方案虽然强大，但对于想要在本地设备上“折腾”点东西的开发者来说，门槛有点高，而且过度依赖网络。
而在本地端，能够实现地图持久化和重定位的方案（也就是扫完图存下来，下次还能接着用），往往都封装在各大厂的商业 SDK 里，代码较为封闭，想研究底层实现很难。
我就在想：作为一个初学者，能不能基于经典的开源框架，自己做一个简易版的“本地 VPS”？
于是，我“不知天高地厚”地对经典的 ORB-SLAM2 下手了。经过一段时间的摸索和修改，我弄出了一个 ORB-SLAM2s。
其中的小写 s 代表 智能·快速·小巧，强调此方案能够具有增强的智能（Smart）、更快的性能（Swift）和更轻的体积（Small）。
它是一个安卓端纯本地运行的点云/特征点扫描方案，能够在手机离线状态下建图、保存地图、加载地图并重定位。📲
这是一篇发给各位大佬的“交作业”文章，希望能分享一下我的思路，也欢迎大家指正。
一、为什么想要搞“纯本地”方案？
在学习时，我意识到目前手机端的定位技术主要分两类：
- 云端 VPS：适合城市级大场景。也就是“我在哪（全球坐标）？”
- 本地 SLAM/VIO：适合小范围跟踪。也就是“我相对于开机时候的那个点在哪？”
但作为 AR 爱好者，我发现单纯的 SLAM 有一个痛点：它很健忘。通常的这些移动端开源 SLAM 方案跑完就丢，下次打开程序，一切归零。如果你想在桌子上放一个虚拟手办，关掉 App 再打开，手办就没了。
想要实现那种“房间级 AR”体验——比如把虚拟画作“钉”在墙上，明天来看还在——就需要地图保存与重定位功能。目前国内很多方案都倾向于把这个功能做在云端（Cloud VPS），但我希望能在本地算力上实现。这不仅是为了离线可用，更是为了在这个“空间计算”的概念火热时，通过开源代码去真正理解底层的逻辑。
二、ORB-SLAM2s：我的魔改“作业”
ORB-SLAM2s 是基于大神们的 ORB-SLAM2 进行的修改。虽然我只有半年的经验，代码可能稍显稚嫩，但通过一部分 AI 的辅助，它基本实现了以下核心功能：
1. 完整的地图生命周期管理
原版 ORB-SLAM2 主要用于实时轨迹跟踪，而我重点打通了 建图 -> 保存 -> 读取 -> 重定位 的闭环。
- 扫描：利用手机摄像头对房间进行扫描，生成并优化稀疏点云。
- 保存：将构建好的地图（关键帧（后来发现这样存储空间会很大，所以就没用）、地图点、词袋向量等）序列化保存到手机本地存储。
- 加载：下次启动 App 时可以手动读取文件，并且如果之前保存地图时有添加 AR 物体，那么 AR 物体也会一并重新加载。
- 重定位：摄像头再次对准环境，系统会迅速找回之前的坐标系，恢复原有地图，如果有 AR 物体，也会一并复现在场景中。
2. 纯本地算力
不需要搭建服务器，不需要上传图片。所有的计算都在手机本地完成。虽然在大场景下不如云端方案，但目前的进度用来做单房间的 AR 互动基本足够。
3. 便携的空间计算基座
我希望将其定位为一个“轻量级基座”。基于它，开发者可以尝试开发一些需要“记忆”环境的 AR 应用。
由于我在实践过程中发现，即便是用现在评价最好的几个 AI IDE 来编写这种过于底层的逻辑的时候，很难能做到效果和效率并存，而且经常因为幻觉导致严重错误，所以目前的项目有相当一部分依然是手敲，AI 用来整理思路、写项目测试脚本和最最重要的——加注释。但也因此，个人代码水平有限，还望诸位大佬海涵。
而且目前还是 Demo 阶段，距离我所希望达到的目标还比较遥远。
三、为什么选择 ORB？而且还是 ORB-SLAM2？
作为一个新人，在面对 VINS、ORB-SLAM3 等众多优秀的开源方案时，我最终选择了 ORB-SLAM2，主要基于以下几点考量：
1. 为什么是 ORB？
- 速度快：ORB 特征提取和匹配的效率比较高，非常适合在移动端这种算力受限的设备上运行。
- 生态丰富：在安卓端实现 ORB-SLAM 方案的前辈大佬比较多，参考资料丰富。对于我这种刚入门的新人来说，这意味着遇到坑容易找到梯子，一步步研究起来更有信心。其他的优秀方案（如 VINS）未来我也会继续学习。
2. 为什么是 ORB-SLAM2 而不是 ORB-SLAM3？
虽然 ORB-SLAM3 是更新的版本，但在我的应用场景下，ORB-SLAM2 反而更合适：
- 轻量级设计：ORB-SLAM2 依赖更少，代码相对精简，在移动平台上的编译和部署难度更低，CPU 和 RAM 的资源消耗也更小。
关于 IMU 与 VIO 的“水土不服”
- 门槛高：ORB-SLAM3 官方实现的 VIO 是紧耦合的，对 IMU 的质量和 Camera-IMU 的时间戳同步要求极高。这在机器人领域可能不是问题，但在手机上却有可能是个大坑，这对于我一个新人来讲也不一定适合。
- 硬件现状：现有的 Android 设备大多是 Camera 与 IMU 异步采集，缺乏统一的硬件同步框架。虽然 Android 11 以后引入了 SENSOR_TIMESTAMP 方法，但在大量存量设备和消费级 IMU 上，噪声和漂移都很大。
- 效果反差：如果没有严格的标定和硬件同步，强行上 VIO 反而可能比纯视觉方案更容易发散，导致定位失败。当然我觉得一定有更优秀的算法。
- 实用效率：在我的目标场景（单目相机、日常环境）中，ORB-SLAM2 的纯视觉表现与 ORB-SLAM3 相当，但更省资源。
3. 为什么要死磕 SLAM？
可能有人会问，现在有那么多现成的 SDK，或是其他方案，为什么要从底层去啃 SLAM？
其实原因对我来讲也很简单：
只有自己亲手拆解过轮子，才知道车是怎么跑起来的。
不仅是为了做一个能用的工具，更是为了在这个过程中理解这一整套算法的精妙之处。同时还能做一个小 Demo，一举多得。
四、手机上的空间计算：我们可以拿它玩什么？
虽然我的方案还比较基础，但它一定程度上展示了手机作为“空间计算终端”的潜力。不需要云端支持，本地 AR 也能很好玩：
1. 房间里的“虚拟陈设”
利用 ORB-SLAM2s 的重定位功能，我们可以实现虚拟物体的持久化摆放。比如，你可以在书桌上放置一个小模型。今天种下，保存地图；明天加载地图，你会发现模型还在原来的位置。
这就是空间计算最基础的魅力——虚拟信息与物理空间的绑定。
2. 离线 AR 导航
在一个已经扫描过的办公室或展厅里，即使没有 GPS 信号，也没有网络，只靠手机摄像头匹配本地地图，就能知道用户走到了哪里，并在这个基础上叠加导航箭头。
这对于一些隐私敏感或网络不佳的室内场景非常有用。类似于 VPS 方案，但是是纯本地运行。（这个方向对于本地算力要求其实比较高，仅仅是我所希望的理想状态）
3. 互动体验
如果能够进一步优化，甚至可以做本地的多人对战游戏。只要大家加载同一份地图文件，就能拥有统一的坐标系，在现实的桌面上进行虚拟战斗。
五、写在最后
作为一个入坑才半年的新人，ORB-SLAM2s 肯定还有很多不足之处，比如在光照变化剧烈或纹理单一（大白墙）场景下的稳定性还有待提高。但我希望通过开源这个项目，能够以此为契机，打开一扇大门，通过开源的生态和思路，来和大家一起交流学习、一起完善。
目前的“空间计算”领域，国内有相当一部分方案都是云端 VPS 方案。希望我这个小小的本地化尝试，能给同样感兴趣的各种“折腾党”提供一点参考。
代码已经开源，欢迎 Star 和 Fork，也求各位大佬轻喷~
