宣告：軟體截圖為個人所有，嚴禁用於商業目的和其他盈利行為。

雲臺控制和鐳射點雲獲取軟體

第一階段：三維點雲採集視覺化

第二階段：MoblieSim模擬資料接入，sim_lms1xx_1鐳射。Gmapping建圖實現效果圖，感覺效果一般，估計有的引數還是要調整一下。

第三階段：滑鼠控制初步（沒有區域性避障和路徑規劃）

今天在機器人上真實環境測試了一下，首先滑鼠控制和運動到位置的服務都是可用的。問題：運動過程中老是撞到障礙，有室內太擁擠的原因，因此急需增加區域性避障功能。

同時考慮是不是機器人里程計提供的位姿飄的太厲害了，我看著地圖控制怎麼會撞呢？

機器人啟動之後即產生位姿（世界，機器人原點），當開始建圖時的機器人位姿（相對於機器人原點）已經不為0。但是建圖用的地圖原點產生了一個新的座標系。

第四階段：實現了VFF區域性避障演算法（Done 2017/6/6

第五階段：邊界探索 （初步完成，很多問題 2017/6/8）

　　完成一個簡單版本的自主探索，目前還有很多問題：

1.根據True Pose進行運算而非里程計 （Done）
2.控制根據True Pose相對方向運動 （Done，思考該方法是有問題的！）
3.自主探索開口點提取的太粗糙，需要精化 （未完成）

實際環境測試，出現問題：像木馬一樣震顫（2017/6/20）

 第六階段：服務優化，演算法優化

 　　（1）$t1$完成掃描匹配，得到真實位姿$T_{1}$，用$t1$時刻的真實位姿和里程計來更新$t_{2}, t_{3}, ... , t_{10}$時刻的里程計。則$t_{10}$時刻有，$T_{10}=T_{1}*Odom_{1}^{-1}*(Odom_{10})$

　　（2）伺服器端的旋轉都按照Heading方向相對運動，因為里程計偏差太大。根據TruePose計算的Map座標系下的目標方向，和Odometry中相差太大。

　　（1）（2）兩點都歸結為相對執行，相對於機器人前一時刻的Heading進行旋轉。

2017/6/26室外測試，沒有問題，只是走廊地板的摩擦力好大，旋轉不流暢，阻力很大！

2017/8/4修改：旋轉角度很大時，採用勻速旋轉；角度比較小時則採用旋轉到角度。

視訊地址：