關心slam技術的人有兩種。一是像我這樣的研究者，為了了解其中各種方法和模組的原理。二是機械人技術的開發者，旨在將slam技術用到他們自己的機械人上。從數量上來說，第二類人數遠多於第一類，他們的需求也日益迫切。slam是許多機械人技術的基礎。沒有預計的位姿和地圖，大部分任務都無法完成。這種需求，也是我們研究者應當認真思考、正面對待的，也是slam從實驗室走向市場應用的第一步。
那麼，阻礙這種應用的困難在哪兒呢？是slam原理還不夠明確嗎？是視覺里程計、特徵匹配、回環檢測的技術不夠先進嗎？事實上，有乙個很重要的東西，是應用者們很關心，但研究者們經常忽視的：那就是slam方案的易用性。
反觀當前多數開源slam方案，它們幾乎都是研究者提出的。研究者做這些方案的目的，往往是為了實現自己某些新穎（但不一定可靠）的想法。實現出來之後，做幾個實驗，挑一部分漂亮的結果放在**裡去。這當然是無可厚非，甚至可以說，做研究本來就是如此的。但從應用者的角度去考慮，他們會花大量的時間配置程式的執行環境，為了看看效果是否和**裡相符（但通常失望的居多）。然後，他們會發現各式各樣的問題。攝像頭一快，匹配就跟不上了；地圖裡重複的東西一多，回環就測不對了；走廊的長度往往比真實的要短，等等。許多開發者都有這種經歷，然而怎麼辦呢？只好去看源**。接著他們又發現，乙個實際的工程專案**很龐大，閱讀一遍還不如自己從頭實現一遍。
這就是所謂的易用性問題。
為何要單獨提這個問題呢？slam是眾多機械人技術的基礎。基礎是什麼？簡而言之，「沒有它不行，光有它沒用」。試問現在為什麼大家都想用slam？他們有各種不同的目的：想要機械人在房裡自主運動啦，想要按順序清掃整個地圖啦，想要聽到人的命令就跑去某個屋啦。如果機械人是一幢樓，開發者們更關心的是，如何在slam這個地基上建出高樓大廈。
對於地基，我們有什麼要求？無非是：簡單、有效、堅實。乙個符合這樣條件的slam方案是什麼樣子？它是不是像現在開源方案那樣，應用一些先進的技術，（有時）跑出了華麗的效果？似乎不是這樣的。我們應該把易用性加到設計slam方案的考慮中來。甚至，我們還應該設計乙個極端強調易用性的方案：
然後，slam程式就自動決定用什麼影象特徵、閉環檢測方法等等的東西，嘩啦嘩啦地執行起來了。開發者可以直接使用這些結果，也可以更進一步地調整：
當然，這些應該是有預設的。至於這個slam裡頭的引數，應該是由研究者事先調節好的。應用開發人員不需要，也不應該關心它們的具體的值。
如果做乙個強調易用性的slam，會不會有吸引力呢？
SLAM應用的一些思考
關心slam技術的人有兩種。一是像我這樣的研究者，為了了解其中各種方法和模組的原理。二是機械人技術的開發者，旨在將slam技術用到他們自己的機械人上。從數量上來說，第二類人數遠多於第一類，他們的需求也日益迫切。slam是許多機械人技術的基礎。沒有預計的位姿和地圖，大部分任務都無法完成。這種需求，也是...
linux實際應用的一些思考
一般來講，桌面使用者首選 ubuntu 伺服器首選 rhel 或 centos 兩者中首選 centos 根據具體要求 有哪些方面的因素會導致 訪問慢？2 伺服器負載過大，導致響應不過來 可以從兩個方面入手分析 3 資料庫瓶頸 4 開發 沒有優化好 針對 訪問慢，怎麼去排查？怎麼去解決？怎麼預防 c...
回溯的一些思考
堆疊中有元素abcdef，每次出棧可以選擇乙個或者兩個元素棧，當有兩個元素出棧時可以選擇其中乙個重新入棧，當棧為空時，總共有多少種出棧方法？對於本題目的一些思考，對於回溯問題，要記得恢復現場。include include include using namespace std queue vect...