建图和定位算法研发心得：好的算法是被具体场景不断打磨出来的

开门点题：细节是魔鬼

很多人喜欢问别人你用的什么slam框架呀？ORB-SLAM，VINS，LOAM，Cartography还是什么？或者问你是用的开源的框架还是自己的算法？

其实我最终用的算法是所有开源框架的综合加上部分自己设计的算法。

其实哪个框架的选择并不重要，没有一个框架能够真正完全应对实际使用中的一个非常具体的场景，更不要说有应对所有场景的框架了。

比如你的用途是离线建图，然后较长时间之后再基于地图实时定位。那么orb-slam的回环检测可能就不太合适了，所以可以吧maplab里面的全局匹配功能加入进来。还比如你的数据都是一些很零碎的同一场景的数据，那么需要融合一些SFM的思想。或者你可以使用RTK，那么视觉里程计的精度其实就不那么重要。

所以各种开源框架可以作为研发的一个起点，然后你必须对各种算法模块的性能有很强的理解。才能根据具体的场景对选定的框架进行修改。对场景的匹配越高，对框架的改动也越大。最终一开始选定的框架可能只是你整个算法的一小部分。因为一个成熟的算法一定是复杂，需要不同情况用不同的方法处理。所以就算当初选了另外一个框架，但岁途同归。就像是优化中，虽然一开始初值不同，但是最都能达到一个最优点。算法的研究也是，选定一个开源框架作为初值，然后不断的优化。

关于全部重新设计算法的事情，个人觉得不太可能所有模块都自己去设计。还是那句话，一个成熟的算法一定是复杂的。你短时间重新设计的算法，一定是简单地。所有没必要去重新发明轮子，只要对轮子的性能足够了解，把别人的代码修改下自己能用就行了。

举我自己的一个例子，早些年做算法研究的时候，我一直觉得公司用的算法太挫，自己想要找到一个NB的算法框架。所以一天研究各种slam算法文章，最终什么也没做出来。其实当时的算法有很多明显的可以改进的点。比如定位track lost后就很难重新定位上。但我觉得这些小修补都解决不到问题，问题在于大的结构就不对。于是不愿意去解决这些细节问题。但现在看来，如果当时能够踏实的去解决一个个细节问题，我的算法能力肯定能进步得更快。

但是算法的大局思维还是要有，因为有的思路原理上就是解决不了目标场景的问题的，比如完全没有特征的场景要用点描述符去定位，再怎么修正细节也没用。这时候需要对整体流程进行重组。其实算法流程的重组可以做得很快，条件是你对每个算法模块额性能足够清楚。比如各种全局匹配算法的特点，这样就省去很多预言测试的时间。

所以总结来说，算法一定要在具体场景下不断打磨，需要对每个模块的性能都有很深的了解。