?

說明：

• 介紹如何調整機器人上的ROS導航包

步驟：

(1) 機器人導航需要那些準備?

在調整新機器人上的導航包時遇到的大部分問題都在本地規劃器調諧參數之外的區域。機器人的里程計，定位，傳感器以及有效運行導航的其他先決條件常常會出錯。所以，我做的第一件事是確保機器人本身正在準備好導航。這包括三個組件檢查：距離傳感器，里程計和定位。

• 距離傳感器

如果機器人沒有從其距離傳感器（例如激光器）獲取信息，那么導航將不起作用。我將確保我可以在rviz中查看傳感器信息，它看起來相對正確，并以預期的速度進入。

• 里程計

通常我會很難使機器人正確定位。它將不斷迷失，我會花費大量的時間調試AMCL的參數，發現真正的罪魁禍首是機器人的測距。因此，我總是運行兩個健全檢查，以確保我相信機器人的里程計。

第一個測試檢查角速度是否合理。我打開rviz，將坐標系設置為“odom”，顯示機器人提供的激光掃描，將該主題的衰減時間設置為高（類似20秒），并執行原地旋轉。然后，我看看掃描出來的邊線在隨后的旋轉中如何相互匹配。理想情況下，每次掃描將剛好落在相互的頂端，會重疊在一起，但是有些旋轉漂移是預期的，所以我只是確保掃描之間誤差，不會超過一度或兩度以上。

第二個測試檢查線速度是否合理。機器人放置在與距離墻壁幾米遠地方，然后以上面相同的方式設置rviz。接著我將驅動機器人向墻壁前進，從rviz中聚合的激光掃描看看掃描出來邊線的厚度。理想情況下，墻體應該看起來像一個掃描，但我只是確保它的厚度不超過幾厘米。如果顯示掃描邊線的分散在半米以上，但有些可能是錯誤的測距。

• 定位

假設里程計和激光掃描儀都能合理地執行，建圖和調整AMCL通常并不會太糟糕。首先，我將運行gmapping或karto，并操縱機器人來生成地圖。然后，我將使用該地圖與AMCL，并確保機器人保持定位。如果我運行的機器人的距離不是很好，我會用AMCL的測距模型參數玩一下。對整個系統的一個很好的測試是確保激光掃描和地圖可以在rviz的“地圖”坐標系中可視化，并且激光掃描與環境地圖很好地匹配。

(2)代價地圖

• 一旦我的機器人滿足導航的先決條件，我想確保代價地圖的設置和配置正確。

• 如下建議可用來調整代價地圖：

  • 確保根據傳感器實際發布的速率為每個觀測源設置expected_update_rate參數。我通常在這里給出相當的容忍度，把檢查的期限提高到我期望的兩倍，但是當傳感器低于預期速率時，它很容易從導航中接收警告。

  • 為系統適當設置transform_tolerance參數。查看使用tf從“base_link”坐標系到“map”坐標系的轉換的預期延遲。我通常使用tf_monitor查看系統的延遲，并將參數保守地設置為關閉。另外，如果tf_monitor報告的延遲足夠大，我可能會隨時看看導致延遲的原因。這有時會導致我發現關于給定機器人的變換如何發布的問題。

  • 在缺乏處理能力的機器人上，我會考慮關閉map_update_rate參數。然而，在這樣做時，我考慮到這將導致傳感器數據快速進入代價地圖的延遲，這反過來會降低機器人對障礙物的反應速度。

  • 該publish_frequency參數是在rviz可視化costmap有用。然而，特別是對于大型全局地圖，該參數可能導致事情運行緩慢。在生產系統中，我考慮降低成本圖發布的速度，當我需要可視化非常大的地圖時，我確定設置速度真的很低。

  • 是否對代價地圖使用voxel_grid或costmap模型的決定在很大程度上取決于機器人具有的傳感器套件。調整代價地圖為基于3D-based代價地圖更多是涉及未知空間的考慮。如果我正在使用的機器人只有一個平面激光，我總是使用costmap模型的地圖。

  • 有時，它只能在里程坐標系中運行導航。要做到這一點，我發現最容易做的事情就是我的復制local_costmap_params.yaml文件覆蓋global_costmap_params.yaml文件并更改了地圖寬度和高度比如10米。如果需要獨立的定位性能來調整導航，這是一個簡單易行的方法

• 我傾向于根據機器人的尺寸和處理能力選擇我使用的地圖的分辨率。在具有很多處理能力并需要適應狹窄空間的機器人，如PR2，我會使用細粒度的地圖...將分辨率設置為0.025米。對于像roomba這樣的東西，我可能會以高達0.1米的分辨率去降低計算量。

• Rviz是驗證代價地圖正常工作的好方法。我通常從代價地圖中查看障礙物數據，并確保在操縱桿控制下驅動機器人時，它與地圖和激光掃描相一致。這是對傳感器數據以合理的方式進入代價地圖的合理檢查。如果我決定用機器人跟蹤未知的空間，主要是這些機器人正在使用voxel_grid模型的代價地圖，我一定要看看未知的空間可視化，看看未知的空間被以合理的方式清除。是否正確地從代價地圖中清除障礙物的一個很好的檢查方法是簡單地走在機器人的前面，看看它是否都成功地看到我，并清除我。

• 當導航包僅運行costmap時，檢查系統負載是一個好主意。這意味著提高move_base節點，但不會發送目標點并查看負載。如果計算機在這個時候陷入僵局，我知道如果我想要運行規劃器的話，我需要做一些CPU參數調整。

(3) 局部規劃器

如果通過代價地圖的操作令人滿意，我將繼續調整局部規劃器參數。在具有合理加速度限制的機器人上，我通常使用dwa_local_planner，對于那些具有較低加速度限制的機器人，并且可以從每個步驟考慮到加速限制的，我將使用base_local_planner。調整dwa_local_planner比調整base_local_planner更為愉快，因為它的參數是動態可配置的。為導航包添加dynamic_reconfigure也已經在計劃中。針對規劃器的提示：

• 對于給定的機器人最重要的是，正確設置了加速度限制參數。如果這些參數關閉，只能期望來自機器人的次優行為。如果我不知道機器人的加速度極限是什么，我會花點時間寫出一個腳本，讓電機以最大平移和旋轉速度命令運行一段時間，看看報告的里程計速度（假設里程會給出合理的估計），并從中得出加速度極限。合理設置這些參數可以節省很多時間。

• 如果我正在使用的機器人具有低加速度限制，我確保我正在運行base_local_planner，其中dwa設置為false。將dwa設置為true后，我還將確保根據處理能力將vx_samples參數更新為8到15之間的值。這將允許在展示中生成非圓形曲線。

• 如果我正在使用的機器人的定位并不是很好，我將確保將目標公差參數設置得比我想象的要高一些。如果機器人具有較高的最小旋轉速度以避免在目標點的振蕩，那么我也將提高旋轉公差。

• 如果我使用低分辨率的CPU原因，我有時會提高sim_granularity參數，以節省一些周期。

• 我實際上很少發現自己改變了path_distance_bias和goal_distance_bias（對于base_local_planner這些參數被稱為pdist_scale和gdist_scale）參數在計劃者上非常多。當我這樣做時，通常是因為我試圖限制本地規劃器自由，讓計劃的路徑與除NavFn以外的全局規劃器合作。將path_distance_bias參數增大，將使機器人更緊密地跟隨路徑，同時以快速向目標向前移動。如果這個值設置得太高，機器人將會拒絕移動，因為移動的代價大于停留在路徑上的位置。簡單來說就是讓實際移動更接近全局路徑還是本地路徑。

• 如果我想以聰明的方式介紹代價函數，我將確保將meter_scoring參數設置為true。這使得它在代理函數中的距離以米而不是單元格，也意味著我可以調整一個地圖分辨率的代價函數，并且當我移動到他人時期望合理的行為。此外，您現在可以通過將publish_cost_grid參數設置為true來顯示本地計劃程序在rviz中生成的代價函數。（這不管怎么說，從來沒有把它放入文檔，我會很快到那個時候）。考慮到以米為單位的代價函數，我可以計算出移動1米的成本與目標平衡的成本的折衷。這傾向于給我一個如何調整東西的體面的想法。

• 軌跡從其端點得分。這意味著將sim_time參數設置為不同的值可能對機器人的行為有很大的影響。我通常將此參數設置在1-2秒之間，其中設置更高可以導致稍微平滑的軌跡，確保乘以sim_period的最小速度小于目標的兩倍。否則，機器人將傾向于在其目標位置的范圍之外的位置旋轉，而不是朝向目標移動。

• 精確的軌跡模擬也取決于距離測距的合理速度估計。這來自于dwa_local_planner和base_local_planner都使用這種速度估計以及機器人的加速度限制來確定規劃周期的可行速度空間。雖然來自測距的速度估計不一定是完美的，但確保其至少接近得到最佳行為是重要的。

總結

以上是生活随笔為你收集整理的ROS与navigation教程——基本导航调整指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。