学习两年多，感觉SLAM太难了，大家对此有什么想法？ 第1页

== Update

我最近开源了一个部分之前的工作，定名为svso，旨在利用语义信息解决 稀疏slam的问题 希望大家支持下，后面还会和其他小伙伴持续更新，整合到一个更大的项目里做组件，希望大家支持下： https://github.com/yiakwy/SEMANTIC_VISUAL_SUPPORTED_ODEMETRY

目前工作中心也在朝DSO半稠密方向进一步拓展，感兴趣的朋友欢迎联系

== Motivation

我来分享下我经验，从实验室开始，我就密切关注行业动向，于17年定下从仿真入手的入局策略（彼时谷歌，百度等才刚刚开始做，这样我就能和一线专家保持进度，实现后发优势）。在为无人驾驶系统起草编写仿真软件系统时，我认为“定位”，“只需要模拟下GPS获取，并进行误差补偿就可以了”。起初觉得并不是困难。这一时间段我没有看过任何和SLAM相关书籍，并写了一组八叉树，KdTree为基础的网格瓦片搜索定位模拟组件；同时建图主要依赖主动观测激光雷达，比如位姿来自IMU，对84坐标系进行切平面空间转换，用ICP等方法融合，用推演出来的3D目标检测进行静态障碍物提取，完成地图要素构建。

后面由于和同行交流发现高精地图中很多同行只做定位，或者认为定位比建图更重要，基于视觉定位等。因为我本身就是视觉出身，就开始研究这方面。

== Research Method

我的研究方法很粗暴，把市面上能看到的源代码如ORBSlam VINS GTSAM G2O，还有诸多不知名到个人作品（代码即文档，我基本上可以做到看代码和看书一样；虽然这些程序十分不完善，但不少代码主逻辑更清晰）全部看一遍，然后统统忘掉，重新写一个。发现其实如果做过深度学习求解器，这东西并不复杂且听我分析，得道者必能传其道，我希望能助你豁然开朗。

我先分析同行不足，然后再总结核心理论，和工程代码结构和写法，最后就是自己动手写，其乐无穷。

在时间分配上，看文章一个下午（一篇到2篇足矣，不用让一些演化的细节来影响和左右你的主线，这里为推荐TUM ORBSLAM），阅读源码断断续续一周，筹备重写（进一步进行学术文献分析和更广泛的源代码收集，制定roadmap ， 给出合理定位以求创新 大约持续了两周，属于一边写系统，一边更新；系统实现一个月）

先分析ORBSLAM，主线程是没有语义视觉检测，只有ORB特征点提取，虽然引入了LocalMapping对Key frame做局部BA，有完整的状态机，但没EKF，光流等预测器。主程如果没有初始化，就通过随机最小二乘法求单应或者本质矩阵求解一次相机位资，和预估点云深度，再BA一次。 本质/单应矩阵求解看人品，算不出来就丢掉缺乏深入思考，但是其通过整合RANSAC+直接法求解提高了算法随机适应性，和SGD算法有异曲同工之妙。单开LocalMapping对晋升的关键帧，再做一次主程初始化的逻辑，只是关键帧因为不一定相邻，stereo disparity 会大一些，局部BA有机会更准确一些。原作者没有意识到匹配需要临近，三角化需要足够视差的矛盾事实，从而可以研究出更好的解法。最后，再单开一个线程用pangolin+openGL完成3D渲染。

再评价VINS，其引入了无人车系统pubsub到系统实现层面（借用了ROS的核心组件），视觉部分借力OpenCV本质和ORB并无区别，引入了EKF和IMU，算是理解了IMU可以高频更新，再借助视觉和优化技术低频矫正的思路，但仍然没有语义部分。重定位时还可以用到点云建图的ICP算法进行点云匹配，只需单开一个线程提取两个视差比较大的地图块匹配即可。

考虑到ORB多线程部分写得很一般，Ubuntu跑了几次就开始筹备重写了。一方面引入视觉检测的Landmark，使得 Covisibility graph复杂了不少，需要全新数据结构，重写势在必行；另一方面，无论才用protobuf 序列化地图块数据用GRPC（ROS采用xMLRPC非常慢，这是RoS 2 和百度发布新系统的核心原因之一，本质就是改这部分）传输，还是真正的提高单系统并发，并行能力（比如图像读取从是利用单线程异步内核IO事件完成）都有很大的提高空间。

当然瑕不掩瑜，以上都是完整的系统。

回到我们的Roadmap，一个完整的思路可以用一句话说明主要路线，有机会我会分享具体的结构图：

点不足时主要依赖初始化；初始化完成可以用3D点做PNP解算，同时开两个线程用BA调整局部坐标；视差过大重定位。

读者读到这里就明白了，SLaM标准实现并不是实时，是次实时的。即在线收集并提取特质（其实如果并行，异步做好，可以通过线程池分发任务，用异步方式阻塞住线程完成同步），非实时更新调整坐标数值。且依赖特征点 而非 真正的landmark 非常不鲁棒。因此引入深度学习势在必行。

有趣的是，接触了一圈做定位的朋友，发现大部分并不是非常懂深度学习，很少做出模型地现。大部分人都是测量，机器人，EE出身。反之亦是，很多做机器学习的并不知道，视觉SLAM中光溜法就是最小二乘估计，不知道视觉特征提取匹配，其本质可行基础原因是像素位移较小，从而不理解如何准确的搜索匹配。

进一步到图求解器G2O，分析源代码得出其无非就是把计算反投射误差包裹了一下，本质还是一个基于拟牛顿法（LM）但线性求解器。如果写过线性求解器，自然这部分只要求出雅可比矩阵即可，并做好wolf-Powell为基础的搜索和不可导点的SubOptimization，就可以开始求解目标函数了。通过世界坐标系，到相机坐标系；相机坐标系到像素；像素到地图点的反投射误差来构建目标函数。为了计算雅可比矩阵，利用李代数来进行梯度求解，非数学系出身都可以快速飞过，直接用图优化，因此容易。

== 结论

所以我说SLAM简单在于

理论篇：

1. 核心数学基本都是线性的。你只需要知道最小二乘法，便是不知道其和梯度下降等价，亦无妨。为了方便计算梯度引入李代数，这里主要应用在BA求解器里面；BA求解器以及可优化目标有不同名称
2. 核心目标函数反投射误差，线性表达式
3. 引入非监督学习方法如Ransac，ICP PCA等 可进行重定位，3D位姿态估计学习等

工程篇：

这里先批评很多技术专家的学习方法（学习方法很重要），做C++把注意力放在一些具体的技巧上（比如虚函数实现，脑子正常的人除非需要，根本不会关注这种花哨的问题，要分清主要问题和次要问题对工作很重要！），而忽略整个社区发展和项目发展。在同一个社区，如Linux社区，大家的技术基础并无区别，区别在于是否引入新的东西。

C++有成熟的编译系统，对操作系统的支持（可以通过阅读各种系统代码文件获知，请培养代码即文档能力！）方便使用内核（如IO mmap 异步内核处理等），有比较好的系统级线程支持，可以最大化系统性能，有数值代数（Eigen，Tensorflow已经可以使用C++ API 做数值计算有机会我会分享），有图（openCV，openGL）写代码前先阅读大量大码，在从中提取提高。

我们应该引入新的理念和技术，而不是引入没被测试过很多次的新的写法，大部分你想的东西有前任做过可以参考。如果不清楚自己在写什么不要乱写。

SLAM恰恰有很多人研究，只要有很多人花时间研究（例如深度学习），工程就不是问题。

在SLAM 我们应当有1.序列化层，提供统一的输入输出转换，在其基础上定义2.视图数据结构，如 Point3D，WorldPoint，CameraPoint，Pixel2D，Frame 和以上元素的集合 MapBlock。需要基于Covisibility 的图索引 和地图块索引。用于系统运行时的3. 追踪器和对应4.特征点及其深度特征向量提取器 5. 时差检索和位姿态估计器，深度估计器 6. BA优化器 9 并发任务模块 Parallel Tasking Scheduler 10. 图形学渲染器

以上模块都应当编译成单独的共享库，并设计单元测试务求单模块实现正确。

应用篇：

SLAM是次实时的，每个组件都可以离线跑，单独跑。所以实时不是必须。很多“专家”，把重点放在时间戳“对齐”，插值上。此所谓丢西瓜、抓芝麻。以相关独立应用系统高精地图来说，实现实时定位，离线建图的技术，就是为了获得更高精度，和更好准确度。 目前SLAM大部分是视觉，但是激光雷达的同样重要。他们的本质区别只在于获取深度图之前的处理流程，所以我们可以融合处理，深度图之后的处理流程是完全一致的。

因此从应用层面拓展，学视觉的自然可以做激光雷达，做激光雷达自然也可以做VSLAM。 在这个观点下 毫无违和感。做自动驾驶 视觉辅助定位 可 借鉴，做高精地图可借鉴。应用也算是十分靠近问题模型，这是十分利好的。

你需要的只是动手。