單目SLAM在移動端應用的實現難點有哪些？

12-30

我來答吧，提綱如下：

1. 單目SLAM難點

2. 視覺SLAM難點

3. 可能的解決思路

圖片中非原創部分均已加引用，請勿盜圖，轉載請私信告知。

單目slam的障礙來自於理論和實踐兩個方面。理論障礙可以看做是固有的，無法通過硬體選型或軟體演算法來解決的，例如單目初始化和尺度問題。實踐問題包括計算量，視野等，可以依靠選型、演算法、軟體設計等方法來優化。不過在同等硬體水平下，優化也存在極限的。比如對O(1)的演算法不滿意從而設計O(1/n)的演算法似乎是不可能的……

---------------我是分割線-----------------

1. 單目SLAM難點

單目的優點是成本低，最大的局限性是測不到空間物體的距離，只有一個圖像。所以早期視覺SLAM也被稱為「只有角度的SLAM」（Bearing Only）。距離在定位中至關重要，雙目和RGBD相機的使用就是為了能夠計算（或測量）這個距離。上一個圖你們直觀體會一下距離的重要性：

很顯然，沒有距離信息，我們不知道一個東西的遠近——所以也不知道它的大小。它可能是一個近處但很小的東西，也可能是一個遠處但很大的東西。只有一張圖像時，你沒法知道物體的實際大小——我們稱之為尺度（Scale）。

可以說，單目的局限性主要在於我們沒法確定尺度，而在雙目視覺、RGBD相機中，距離是可以被測量到的（當然測量也有一定的量程和精度限制）。雙目視覺和人眼類似，通過左右眼圖像的差異來計算距離——也就是所謂的立體視覺（Stereo）。RGBD則是把（通常是紅外）光投射到物體表面，再測量反射的信息來計算距離的。具體原理分結構光和ToF兩種，在此不多做解釋，還是上圖直觀感受一下。

距離未知導致單目SLAM存在以下問題：

需要初始化
尺度不確定
尺度漂移

而一旦我們擁有了距離信息，上述幾條就都不是問題，這也是雙目和RGBD存在的意義。下面分別講一下以上幾條。

---------------我是分割線-----------------

1.1 初始化

單目SLAM剛開始時，只有圖像間的信息，沒有三維空間的信息。於是一個基本問題就是：怎麼通過兩張圖像確定相機自身運動，並且確定像素點的距離。這個問題稱為單目SLAM初始化問題。一般是通過匹配圖像特徵來完成的。

匹配好的特徵點給出了一組2D-2D像素點的對應關係，但由於是單目，沒有距離信息。初始化的意義是求取兩個圖像間的運動和特徵點距離，所以初始化完畢後你就知道這些特徵點的3D位置了。後續的相機運動就可以通過3D點-2D點的匹配信息來估計。後續的問題叫PnP（Perspective n Point）。

對，你想的沒錯，單目的流程就是：初始化——PnP——PnP——……

初始化的運動是通過對極幾何來求解的，結構是由三角測量得到的。初始化問題是一個2D-2D求運動和結構的問題，比3D-2D的PnP要難（信息更少，更不確定）。我不展開對極幾何求運動的原理，但是理解它，對理解單目局限性是很有幫助的。如題主感興趣，請看Multiple View Geometry第8章。如果在知乎上寫，會佔掉很大的篇幅。

對極幾何最終會分解一個本質矩陣（Essential Matrix）（或基本矩陣（Fundametal Matrix））來得到相機運動。但分解的結果中，你會發現對平移量乘以任意非零常數，仍滿足對極約束。直觀地說，把運動和場景同時放大任意倍數，單目相機仍會觀察到同樣的圖像！這種做法在電影里很常見。例用用相機近距離拍攝建築模型，影片看起來就像在真實的高樓大廈一樣（比如奧特曼打怪獸實際是兩個穿著特攝服裝的演員，多麼無情的現實）。

這個事實稱為單目的尺度不確定性（Scale Ambiguity）。所以，我們會把初始化的平移當作單位1，而之後的運動和場景，都將以初始化時的平移為單位。然而這個單位具體是多少，我們不知道（攤手）。並且，在初始化分解本質矩陣時，平移和旋轉是乘在一起的。如果初始化時只有旋轉而沒有平移，初始化就失敗了——所以業界有種說法，叫做「看著一個人端相機的方式，就知道這個人有沒有研究過SLAM」。有經驗的人會盡量帶平移，沒經驗的都是原地打轉……

所以，從應用上來說，單目需要一個帶平移的初始化過程，且存在尺度不確定問題，這是它理論上的障礙。

員工：老闆你這樣移動相機不行啊，要有平移的……

老闆：我花20k請你來做slam，一個初始化都搞不定？

1.2 結構問題

由於單目沒有距離信息，所有特徵點在第一次出現時都只有一個2d投影，實際的位置可能出現在光心與投影連線的任意一處。只有在相機運動起來以後，才可能通過三角測量，估計特徵點的距離。

三角測量的應用範圍很廣，傳說高斯在十幾歲的時候就已經用最小二乘法測量山的距離，來吊打這些二十大幾還在水paper的博士們。現代天文學測星星的距離也使用三角測量。

然而三角測量的前提是——你得有三角啊。

高斯用三角測量是站在兩座山上去量另一座，這就構成了三角。雙目視覺左右兩個相機，存在一定的平移，和目標點也構成了三角。但在單目情形下，你必須移動相機之後，才可能去估計空間點的3D位置。換句話說，如果相機擺在那兒不動——就沒有三角了。這導致單目在機器人避障中應用存在困難，不過既然在談AR我們就先不說機器人吧。

1.3 尺度漂移

用單目估計出來的位移，與真實世界相差一個比例，叫做尺度。這個比例在初始化時確定，但單純靠視覺無法確定這個比例到底有多大。進而，由於SLAM過程中雜訊的影響，這個比♂例還不是固定不變的。當你用單目SLAM，會發現，咦怎麼跑著跑著地圖越來越小了……[1]？

這種現象在當前state-of-the-art的單目開源方案出亦會出現，修正方法是通過迴環檢測。但是有沒有出現迴環，則要看實際的運動方式。所以……

員工：老闆你這樣移動相機不行啊，要經常把它移回去……

老闆：我花20k請你來做slam，怎麼搞的地圖一會兒大一會兒小，這怎麼用？

---------------我是分割線-----------------

2. 視覺SLAM的困難

雙目相機和RGBD相機能夠測量深度數據，於是就不存在初始化和尺度上的問題了。但是，整個視覺SLAM的應用中，存在一些共同的困難，主要包括以下幾條：

相機運動太快
相機視野不夠
計算量太大
遮擋
特徵缺失
動態物體或光源干擾

2.1 運動太快

運動太快可能導致相機圖像出現運動模糊，成像質量下降。傳統捲簾快門式的相機，在運動較快時將產生明顯的模糊現象。不過現在我們有全局快門的相機了，即使動起來也不會模糊的相機，只是價格貴一些。

（你真以為啥圖都可以用來SLAM嗎？拿衣服啊，圖片來自TUM數據集）

（全局快門相機在拍攝高速運動的物體仍是清晰的，圖片來自網路）

運動過快的另一個結果就是兩個圖像的重疊區（Overlap）不夠，導致沒法匹配上特徵。所以視覺SLAM中都會選用廣角、魚眼、全景相機，或者乾脆多放幾個相機。

2.2 相機視野不夠

如前所述，視野不夠可能導致演算法易丟失。畢竟特徵匹配的前提是圖像間真的存在共有的特徵。

2.3 計算量太大

基於特徵點的SLAM大部分時間會花在特徵提取和匹配上，所以把這部分代碼寫得非常高效是很有幫助的。這裡就有很多奇技淫巧可以用了，比如選擇一些容易計算的特徵/並行化/利用指令集/放到硬體上計算等等，當然最直接的就是減少特徵點啦。這部分很需要工程上的測試和經驗。總而言之特徵點的計算仍然是主要瓶頸所在。要是哪天相機直接輸出特徵點就更好了。

2.4 遮擋

相機可能運動到一個牆角，還存在一些邪惡的開發者刻意地用手去擋住你的相機。他們認為你的視覺SLAM即使不靠圖像也能順利地工作。這些觀念是毫無道理的，所以直接無視他們即可。

2.5 特徵缺失、動態光源和人物的干擾

老實說SLAM應用還沒有走到這一步，這些多數是研究論文關心的話題（比如直接法）。現在AR能夠穩定地在室內運行就已經很了不起了。

---------------我是分割線-----------------

3. 可能的解決思路

前邊總結了一些單目視覺可能碰到的困難。我們發現大部分問題並不能在當下的視覺方案能夠解決的。你或許可以通過一些工程技巧加速特徵匹配的過程，但像尺度、遮擋之類的問題，明顯無法通過設計軟體來解決。

所以怎麼辦呢？——既然視覺解決不了，那就靠別的來解決吧。畢竟一台設備上又不是只有一塊單目相機。更常見的方案是，用視覺+IMU的方式做SLAM。

當前廣角單目+IMU被認為是一種很好的解決方案。它價格比較低廉，IMU能在以下幾點很好地幫助視覺SLAM：

IMU能幫單目確定尺度
IMU能測量快速的運動
IMU在相機被遮擋時亦能提供短時間的位姿估計

所以不管在理論還是應用上，都出現了一些單目+IMU的方案[2,3,4]。眾所周知的Tango和Hololens亦是IMU+單目/多目的定位方式。

（用Tango玩MC，缺點是蓋的房子尺寸和真實世界一樣。蓋二樓你就得真跑到樓上去蓋——這怎麼造圓明園？）

（這貨就是靠後邊這魚眼+IMU做跟蹤的）

（Hololens圖就不上了吧……橫豎也不是自己的）

[1]. Strasdat, Montiel, A.J.Davison, Scale drift-aware large scale monocular SLAM, RSS 2006.

[2]. Leutenegger et. al., Keyframe-based visual-inertial odometry using nonlinear optimization, IJRR 2015.

[3]. Huang Guoquan, Kaess and Leonard, Towards Consistent Visual-Inertial Navigation, ICRA 2014.

[4]. Li Mingyang and Mourikis, High-precision, consistent EKF-based visual-inertial odometry, IJRR, 2013.

我目前做的項目是類似於Android手機端SLAM，具體目的是什麼不便透露，作為過來人，分享下經驗，避免後來人走彎路，手機端最難以解決的問題從難到易排序如下：

1.手機處理速度

2.手機捲簾相機

3.人體移動速度

4.手機移動方向

5.多款相機參數難以統一

目前市面上的android手機多種多樣，硬體越來越強大，使用人數也是最多，同時也有前人經驗將orb-SLAM2移植到手機上的經驗，移植過的人因該都知道，使用的時候，載入詞袋模型需要花費7-8分鐘時間，變成二進位文件也是緩慢，然後出來效果是每秒1-2幀（記不太請），慢的可以，然後果斷放棄了。

然後開始在手機端重寫幾乎所有演算法，框架仿照ORB-SLAM2，以用來更加容易的適用手機的所有的特性，若是想要達到實時效果或者稍有延遲，只有兩種路可以選擇 1,降低圖像的採樣率 2,增加手機處理速度，面對需要用在實際中的項目，只有採用謙前者，果斷採用每秒10幀採樣，並對圖像進行壓縮，並使用多線程處理，結果效果不好，採樣率只有再降～，採樣降低勢必造成一些精度損失，只能使用其他感測器進行彌補，所以走到了多感測器融合的道路。

然後就是手機相機了，捲簾相機，確實是個頭疼的問題，走快了，圖像花的不行，發生嚴重畸變，所有自己就寫了個演算法對可以用和不可用進行處理，並完善採樣過程中的不足，但是依然沒有徹底解決，但是解決了不少。

手機移動方向，手機移動方向是個大問題，實際用的時候不能總是手拿著相機不動吧，不現實，Tango不知道怎麼做到的，一直研究。

要注意：迴環檢測一定要適合自己系統重寫！！，識別不同場景，目前開源的所有演算法幾乎都嘗試過，不是前期庫載入太慢，就是效率太低，無法使用！！

優化演算法可以研究後進行移植，適合自己的，我用的是g2o。

再就是手機花費最多的時間是mapping過程，這個過程是將手機形成的三維點進行對幀之間的對照，也就是說是尋找一個三維點被那幾個幀看到了，從而進行優化，一定要注意！！！

這裡最好解決的就是手機參數了，簡單粗暴，每個手機都校準一下唄，然後寫到資料庫中，這裡就懷念iphone了，就那麼幾種型號，怪不的好多做視覺的都使用iphone，唉！！

補充: 注意尺度問題，我推薦使用IMU進行對尺度補充，可以降低計算成本！！

都是實際中遇到的問題，給大家避免一些坑，說的不對的地方請大家勿噴.

我就是那個出20K並且不願意把相機移回去的人。

實現難點前面幾位答主都羅列得差不多了，這裡分享其中一些難點的解決思路。
1. 計算量大：我們從優化演算法（採用FAST+SSD提取特徵點），使用simd指令集，通過內存換時間這三方面來提升。
2. 單目初始化：我們結合了IMU來解決，首先找到一個平面，然後再從這個平面上來構建地圖，這樣就不需要平移相機了。
3. 純旋轉：單目通過演算法可以解決一部分，可參考《Robust Keyframe-based Monocular SLAM for Augmented Reality 》，裡面寫得很詳細。
4. 遮擋和動態物體，特徵缺失、動態光源和人物的干擾：首先把屏幕分成區域，使跟蹤的特徵點均勻分布在這些區域里，再在演算法裡面進行檢測，那麼一直在運動的特徵點就會被排除掉。
5. 迴環檢測：類似ptam處理，為每一個關鍵幀創建了一個Small Blurry Image，在迴環檢測線程里，隨時比對兩個SBI是否一致，來判斷是否迴環。
6. 尺度問題：我們採用的是相對尺度，單目+IMU可以解決這個問題，ARKit的絕對尺度做得很不錯，目前我們還沒有想出什麼好辦法，要不要來討論一下 @半閑居士 @王小新 @栗子

參考資料：

《ORB-SLAM: a Versatile and Accurate 》

《Monocular SLAM System》

《Monocular Visual-Inertial State Estimation for Mobile Augmented Reality 》

《A Multi-State Constraint Kalman Filter for Vision-aided Inertial Navigation 》

《Robust Keyframe-based Monocular SLAM for Augmented Reality 》

《Parallel Tracking and Mapping on a Camera Phone 》

其實有閉環了drift之類問題都不大，特徵點之類的用FAST+lsd那一套也能玩，CMU做的極低drift+極高實時性的工作也有，在小型ARM處理器上跑的很歡快的結果也有（SVO，還有做lsdslam那個b最近也搞了一個和SVO差不多思路的玩意）。技術上的最大問題還是初始化不可靠以及某些看上去很美的組件實際效果約等於廢物，本質上的問題還是AR目前的錢景不是很明朗。

高博已經從理論角度分析的非常清楚了，小弟我就從實際體會談下我的感受吧。

題目是說移動設備，姑且先認為是手機吧。去年花了半個月的時間，和學長一起移植了LSD SLAM for Android。將LSD-SLAM移植到Android

從實際效果來看，旋轉和平移（運動軌跡）在大體上是對的，具體精度沒有測試。彩色的深度圖比較不準。

程序在啟動的時候，需要手持手機平穩緩慢移動，才可以完成初始化。運動速度稍微大一點，程序就會卡死、崩潰。

主要原因有：單目演算法的本身的誤差；手機上攝像頭的視野範圍太窄；手機硬體的缺陷；甚至工程的架構都有關係(我是用java調用jni)。

解決思路有：利用手機上的陀螺儀和加速計；增加重定位功能；在移動平台設置雙目等等

我們知道最終的AR一定要運行在移動設備上，要不然AR沒有意義(不可能只增強特定區域的現實)。那麼我相信SLAM也會朝著提高移動平台上的穩定性和準確性的方向發展。

推薦一篇浙大CAD實驗室的綜述

剛開始接觸，做本科畢業設計，我筆記本跑orb-slam起來很吃力啊，動不動就迷失了，所以我覺得演算法需要優化，移動端硬體計算能力也需要提升。高博說的直接輸出特徵點的感測器不錯。

整理了自己學習SLAM時用到的開發資源與方法發布在Github上：GeekLiB/Lee-SLAM-source

很贊同高博的回答。

另外也誠邀大家前往本周slam的線上分享

線上分享|SLAM及在機器人領域中的應用

https://zhuanlan.zhihu.com/p/23659397

如果要切題的話，那麼就是演算法優化吧。

蘋果顯然已經優化好了。

估計Android也不遠了。

到時候直接用就行了。

over。