ETH ROS編程課程學習心得 vinbo2

ROS Melodic教程及機器人學開放課程整理匯總：https://blog.csdn.net/ZhangRelay/article/details/100086799

ROS系統很強大，學習起來坑很多，時間并不是花在寫代碼分析問題上面，多數時候都在baidu bug, 并莫名一臉懵逼。 經常一個bug解決完一天就過去了。所以學習ROS還是適合找幾個小伙伴一起研究分享效率更高。

ETH這5次作業，看起來似乎不難，但是。。。極其費時間。打個比方，前面我在python3.6下干了很長時間，各種不匹配的出錯，baidu上一個一個找權衡的辦法，后來火大了，干脆裝anaconda用python2.7, 然后發現，原來前面幾天都做了無用功，時間都白白打了水漂。

ETH的作業有個特點，就是不是光對照教材和視頻就能完成的，需要去查資料找各種細節，很多地方我是找到了相關細節的例程才知道具體怎么用的。不過做完了看著自己的無人車自己開車撞電線桿子，還是蠻有成就感的：）

關于課程主頁與題目本身，在這里http://www.rsl.ethz.ch/education-students/lectures/ros.html，relay zhang老師博客https://blog.csdn.net/ZhangRelay/article/details/79463689寫的也很詳細，懶得打字了。具體聊幾個小細節。

1. 關于畫圖工具與利用共享資源的意識

一個是第四題的畫圖，ros本身的3d建模和視覺效果非常強，但是畫曲線的功能卻比較弱，自帶的rqt幾個功能連曲線的橫坐標都沒得選，只能是時間。所以ETH課程推薦了multiplot package，但是坑就坑在這個包我用不了，不管上直接裝binary還是build 源碼，結果都是段錯誤，核心已轉存。搜索了很久都沒找到能解決的辦法，后來想算了不就是畫圖么，我自己移植其他的畫圖工具包不好么？有gnuplot，有opencv, 還有Python的matplotlib，都試了一遍，但是作為初學者，對ros之外的包的融合還是不能搞定，即便把cmakelist改了還是不能正常實現，都快要放棄了突然想起來，這么重要的功能肯定其他人做過了啊，于是去github還有ros.org下面搜，一下出來好多，挑了幾個發現一個plotJuggler非常好用，于是終于在這里解決了。一個教訓就是，有利用已有共享資源的意識，在ros中太重要了。

2. EKF與碼盤的理解

從第三題開始，題目開始引導著構建一個閉合控制回路,說實在的，題目出的好，才是我花時間做題的動力。作為一個純控制出身的，看著車子滿屏幕的跑，比整天對著的動態方程和曲線，有著不一樣的興奮，但是，新鮮過去了，只有車子沒有對比曲線顯然完全不能給人安全感，我連好壞都無從對比啊。于是會畫圖了之后，終于找到了熟悉的感覺。在畫出了和視頻中一樣的曲線后，就是下圖右下角

我在想，這個圖是ekf給出的軌跡，那準不準啊？沒對比哪知道？所以有了上圖其他幾條曲線，也就是用碼盤給出的odometry信息，和處理前的原始信息比終歸沒錯。然而，大吃一驚的是，這差的也太遠了。。。

然后我分析了一下，找到了ekf package的文檔，然后先把配置文件localization.yaml拷貝到自己目錄下，把里面初值改了，在最后加入了

initial_state: [28, 12, 0,

0, 0, 0,

0, 0, 0,

0, 0, 0,

0, 0, 0]

然后變成了這樣

初值對上了，然而曲線還是不對啊。事實上，我的初值顯然只給了位置的初始估計，姿態的初值依然是0，所以看到的軌跡連運動大方向都對不上了。當然，如果我連姿態初值也給的差不多，那么軌跡也就大體能對上了。然而我沒有這么做，因為這tm是大名鼎鼎的ekf啊，一個初值的影響都搞不定（雖然根據lindquist的理論結果，kf的初值對系統影響確實比較大，但是在初始位置都給的差不多的情況下，說初值差的遠已經說不過去了），肯定其他地方出問題了。然后我看到了配置文件的其他地方：

odom0: husky_velocity_controller/odom

#odom0_config: [false, false, false, # not estimate position, noly velocity, why? of course position estimation is needed

odom0_config: [false, false, false,

false, false, false,

true, true, true,

false, false, true,

false, false, false]

根據http://docs.ros.org/melodic/api/robot_localization/html/state_estimation_nodes.html#sensor-config，這是碼盤的配置矩陣，5行分別是位置，姿態，線速度，角速度，線加速度。我注意到ekf并不使用碼盤的位置信息做融合，三個值全都是false, 我想了一下我理解的ekf，從理論上我完全想不到有不用位置的理由，所以果斷改掉，改成3個true ! 結果是顯著的：

這下完全吻合了。好開心, 因為我似乎通過改配置文件，把軌跡的跟蹤精度大大提高了。然后我就去relay zhang老師的博客下面顯擺了一下。 然而，這并不是故事的結局。。。

在第五題的時候，顯然我做了同樣的事情，這次我嫌麻煩，連配置文件都懶得拷過來，直接去husky_control pkg里面用sudo強行改了原配置文件（幸虧我有備份原文件的好習慣），一勞永逸。改完之后，小車的軌線估計（只看top兩幅圖就好，中左的矩形波是手動service啟動停止的結果）從

變成了

看似跟蹤完美，然而，真相卻是殘酷的： 我的車什么時候跑到y軸負半平面去了？?。?！ 我的車在pid 負反饋下一直從來都是向著電線桿子走的直線啊?。。‰娋€桿子在第一象限?。。?！有gazebo圖為證：

這貨從來一直都在走直線?。。?！我差點沒崩潰了！那我的ekf估計的是啥啊。。。

反?。?/p>

經過多次仿真觀察，終于有了結果。

首先，事實一：gazebo的物理模型做的太好了，對真實世界的模型遠遠超出了幾個微分方程的刻畫。在汽車啟停和轉彎的時候，輪胎對地面的相對摩擦，是經常發生的。甚至車子有輪胎短暫騰空的時候，這些在gazebo里面也都會發生。這些時候，碼盤的讀數，并不是車體的真實位移。

事實二：我在設計控制器的時候，為了夸大視覺效果，加大了控制量，比例控制系數盡量給的比較大，以至于每次車體啟動，車身都會傾斜并騰空。。。出現這種情況的原因可能還有自帶的速度環husky_velocity_control做的不太好，我記得好像右轉的時候限制了右前輪是速度為0，所以后輪加速的情況下容易側翻。啟動側翻圖這樣：（截的效果不太好）

側翻時車體傾斜，以至于激光雷達掃到地面，并把掃到的地面最近點當成目標的rviz圖：（圖中紅線是激光在地面掃描點，綠柱子是最近的一個點，被誤認為是柱子。

由于以上兩點，在碼盤經常與地面相對滑動時候，不要依賴碼盤來讀位移，才是ekf的正確使用方法！所以，碼盤主要采用線速度，而陀螺儀主要采用角速度。所以husky control包既然被當成tutorial，這里的基本配置還是值得學習的。幸虧配置文件我備份了，趕緊改回去。

然后前面的正確的圖我再貼一遍。。。也就是說，這個圖

或者這個圖

才是對的，ekf給出了精確的跟蹤軌跡。

然后是時候回到第四題了，第四題是直接讀bag file信息，沒有gazebo的物理信息，所以本質上講無法判斷真實軌跡的樣子，但是上面的教訓告訴我，ekf給出的信息比碼盤可靠，也就是原視頻的軌線結果更接近真實值。為了在rviz中直觀顯示出來，我自己又單獨寫了一個節點，功能是把ekf和碼盤的給定當前坐標，作為path topic發布出去，然后在rviz里面添加topic顯示就可以了（這個節點以后在其他地方也可以用），效果如下：

綠色的是ekf給的路徑，青色的是碼盤路徑，顯而易見rviz采用的是ekf數據來顯示車體的位置，這一點從rqt graph可見：

3. 關于傾車現象

最后稍微說一點車體傾斜和翻車現象。目前出現的情況有：加速前進，急剎車，急轉彎，造成的傾斜，還有壓過電線桿并翻車，還有兩次一啟動就翻車的情況，好像是因為比例控制參數調的太大了，并不是每次都能重現。傾斜的后果就激光雷達照到地面，以為目標在眼前或者身后，造成車頭亂晃，所以我的曲線一般在啟動階段都會車頭亂顫(在身后時掃描最大角度是2.35弧度，即正負135度，我設的比例控制系數是P=2.5，所以2.35*2.5=5.85，所以才有圖上接近6的速度指令振蕩），想消除減小控制量就好了，或者其實應該通過分析掃描到的直線判斷這不是一個柱子，從而重新尋找遠方的柱子。另外這臺車的設計本身也由于車輪不能偏轉，感覺容易倒。

視頻

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。