好久好久都沒有寫博客了，總感覺博客的編輯不好使，喜歡寫到文檔裏面，不過還是寫到博客裏面會有個監督的感覺...
好吧，把最近做的一些東西寫出來吧～保持寫博客的習慣吧。目前在用的是baxter機器人，雖然他公司已經倒閉了，但是在做研究的時候，還是挺好用的。
前一段日子，有個問題很怪異，關於real baxter&moveit的問題，問題是，在仿真環境gazebo&moveit的時候，拖拽和規劃一切都順利，定製生成的ikfast解算插件也能夠正好正常工作，但是使用真實baxter驗證的時候，拖拽總是出現問題提示
這個提示意思是關節產生了自碰撞，翻牆查找問題，說是修改moveit配置文件夾中的opml_planning.yaml文件，修改其中longest_valid_segment_fraction參數，默認0.05，但是改小了就提示解算不出來解，即使加大計算時間，也不行，改大了有解但是提示自碰撞，根本找不到一個合適的數值滿足條件。很納悶爲什麼仿真時候自碰撞不會提示問題，但是真實機械臂就會提示碰撞。
經過一天半，已經解決，我的流程是，考慮gazebo仿真和實際機械臂連接moveit的結構入手，參考之前的圖
可以看出其實gazebo和realworld與moveit鏈接的時候都是通過兩個相同的接口結構，可以分爲機械臂端和moveit端，
- 考慮仿真和實際，在參數服務器中的URDF文件不同
因爲不論是仿真還是實際，moveit都需要機器人的URDF文件，以此爲依據，結合機械臂端反饋回來的位置數據，來計算是否有碰撞，考慮是不是URDF文件的不同導致的碰撞檢測不同？但是使用命令
rosparam get -p /robot_description | tail -n +2 > baxter_urdf.xml
從參數服務器中抽取URDF，不論是否是在仿真還是真實環境下，URDF文件都相同。
2.考慮moveit端
因爲在兩種環境中啓動的moveit的launch指令相同，經過查看moveit的系列launch文件，準根溯源，沒有發現有根據環境進行切換的語句。排除這個問題。
開頭的地方出現的問題，實際上終端窗口給出過警告，但是隻是警告，不是錯誤，所以沒有在意
類似於上圖中的情況提示起始位置超出了界限，無論怎麼求解都無解，調大參數longest_valid_segment_fraction: 0.02，提示有解，但是經查看提示baxter上臂和頭部會發生碰撞，查看moveit源文件中拋出警告的那個源文件kinematic_constraint.cpp，
http://docs.ros.org/jade/api/moveit_core/html/kinematic__constraint_8cpp_source.html 發現啓動的時候，會檢查各個關節的起始位置是不是超出了規劃要求的關節界限，上面提示，超出了界限。
所以原因在於，在gazebo中仿真的時候起始狀態如下圖所示，關節處於限制之內，因此會有正常解。
而在實際機械臂運行時，執行使能機械臂命令rosrun baxter_tools enable_robot.py -e
之後，機械臂會呈現如下狀態
這種狀態中關節s0，s1處於極限位置之外，需要執行：
rosrun baxter_tools tuck_arms.py -u到工作狀態，之後再啓動moveit，這樣才能保證找得到解。
是不是很蠢的問題... 以後要注意呀