SLAM应用的一些思考

　　关心SLAM技术的人有两种。一是像我这样的研究者，为了了解其中各种方法和模块的原理。二是机器人技术的开发者，旨在将SLAM技术用到他们自己的机器人上。从数量上来说，第二类人数远多于第一类，他们的需求也日益迫切。SLAM是许多机器人技术的基础。没有预计的位姿和地图，大部分任务都无法完成。这种需求，也是我们研究者应当认真思考、正面对待的，也是SLAM从实验室走向市场应用的第一步。

　　那么，阻碍这种应用的困难在哪儿呢？是SLAM原理还不够明确吗？是视觉里程计、特征匹配、回环检测的技术不够先进吗？事实上，有一个很重要的东西，是应用者们很关心，但研究者们经常忽视的：那就是SLAM方案的易用性。

　　反观当前多数开源SLAM方案，它们几乎都是研究者提出的。研究者做这些方案的目的，往往是为了实现自己某些新颖（但不一定可靠）的想法。实现出来之后，做几个实验，挑一部分漂亮的结果放在论文里去。这当然是无可厚非，甚至可以说，做研究本来就是如此的。但从应用者的角度去考虑，他们会花大量的时间配置程序的运行环境，为了看看效果是否和论文里相符（但通常失望的居多）。然后，他们会发现各式各样的问题。摄像头一快，匹配就跟不上了；地图里重复的东西一多，回环就测不对了；走廊的长度往往比真实的要短，等等。许多开发者都有这种经历，然而怎么办呢？只好去看源代码。接着他们又发现，一个实际的工程项目代码很庞大，阅读一遍还不如自己从头实现一遍。

　　这就是所谓的易用性问题。

　　为何要单独提这个问题呢？SLAM是众多机器人技术的基础。基础是什么？简而言之，“没有它不行，光有它没用”。试问现在为什么大家都想用SLAM？他们有各种不同的目的：想要机器人在房里自主运动啦，想要按顺序清扫整个地图啦，想要听到人的命令就跑去某个屋啦。如果机器人是一幢楼，开发者们更关心的是，如何在SLAM这个地基上建出高楼大厦。

　　对于地基，我们有什么要求？无非是：简单、有效、坚实。一个符合这样条件的SLAM方案是什么样子？它是不是像现在开源方案那样，应用一些先进的技术，（有时）跑出了华丽的效果？似乎不是这样的。我们应该把易用性加到设计SLAM方案的考虑中来。甚至，我们还应该设计一个极端强调易用性的方案：

• 请问你有什么传感器？       ——激光/单目/双目/RGBD/IMU等等。更可能同时有多个。它们应该是一种优雅地方式集成起来，容易配置。
• 你的位姿和地图需要什么形式？       ——2D/3D位姿，栅格图/拓扑图/路标图等。

　　然后，SLAM程序就自动决定用什么图像特征、闭环检测方法等等的东西，哗啦哗啦地运行起来了。开发者可以直接使用这些结果，也可以更进一步地调整：

• 偏向于速度还是精度？
• 是否使用GPU？
• 匹配丢失后如何处置？

　　当然，这些应该是有预设的。至于这个SLAM里头的参数，应该是由研究者事先调节好的。应用开发人员不需要，也不应该关心它们的具体的值。

　　如果做一个强调易用性的SLAM，会不会有吸引力呢？