摘要: 原創博客:轉載請表明出處:http://www.cnblogs.com/zxouxuewei/
一。要求：
1.大家已經對ROS的基本概念（進程間通訊topic service 數據類型 msg）有了基本的了解.
2.有基本的C++/python編程技術，有基本的移動機器人技術概念。
3.需要的硬件平台：一個可以與你上位機（運行ROS linux）通過某種硬件總線通信的移動平台。（移動平台需要能接受上位機的速度指令，並且向上位機返回里程計數據，）.
4.一個RGBD-camera （kinect xition etc。。。）或者一個激光雷達（hokuyo rplidar ）.
二。地盤
一般來說，導航規划層，直接輸出都是一個topic “cmd_vel”, 里面的數據類型為 geometry_msgs/Twist 這個數據類型表示的是3d空間中的速度，2d的移動機器人只會用到三個值 linear.x linear.y 與 angular.z 分別表示水平分速度，垂直分速度，與角速度。
我們需要將一個描述一個平面剛體的三個分速度映射成驅動部分的速度，這里涉及到一個底盤運動學解算的問題，一般來說分為差動底盤和全向底盤這以及四輪萬向，不同的底盤對應的解算公式也是不同的。
與下位機通訊的手段多種多樣，則使用的編程接口也相應的不同。我用過串口與CAN總線，推薦使用c++ boost 串口與 python-can。
三。注意
1. 發送的頻率：這個要看嵌入式部分的要求。
2. 關於速度的平滑： 對於規划層而言，即使有加速度等一些參數的限制，它輸出的速度值可能還是對於下位機過於不友好（比如過大的加速減速，不定的發送頻率等等），那么就在速度接口這邊就要執行一個平滑的過程。流程就是訂閱 “cmd_vel”topic 然后將速度做處理，發送給下位機執行。
3.里程計接口：
一般導航都會要求一個里程計數據的輸入，這個可以解釋為“通過編碼器的轉動推測輪子在時間片中的位移，進一步算出機器人整體的位移與速度”。和速度接口類似，一般移動平台返回的是輪子轉角，需要做逆運動學解算，結果為機器人中心相對與計算開始的“原點”。
這個部分需要注意的地方主要就是發布頻率了。這個頻率涉及到之后的costmap更新與坐標系的訪問超時問題，之后會仔細講解。
4.傳感器接口：
一般rgbd-camera與激光雷達都有相應的sensor driver 提供，roslaunch相應文件就可以了。
傳感器一般在消息的 header中都需要相應的傳感器采集坐標系，對於固定的傳感器使用 tf中的static_transform_publisher 給定傳感器與機器人中心相對位姿就可以了。
四。SLAM 與 navigaion ROS 工具綜述：
ROS 中的重要相關部分部分：
tf ： 坐標轉換庫，提供實時的坐標轉換查詢與更改服務。 它將坐標轉換表示為樹形結構，而坐標轉換數據的更新速度直接影響 其他節點的實時性，進而導致整個系統的運行出錯，出問題大部分也是在這部分。
actionlib：提供動作的編程接口，提供動作執行時的查看狀態，終止， 搶占等一系列功能。ROS中的自主移動規划層向上的編程接口一般都是通過這個庫。
pluginlib ： 提供可配置的組件（配置文件就可以規定組件的添加與更換，提供了運行時改變組件的可能性）navigaion 中提供了對於多種planner的支持。
dynamic_reconfigure : 提供運行時改變算法（節點）參數的功能。
五。navigaion總體介紹：
這個圖絕對是最好的。我們可以清楚得看見之前說的navigation的輸入：里程計odometry， 激光雷達或者rgbd-camera的信息sensor_topics，還有已知的先驗地圖（可選），坐標系變換信息，輸出就是cmd_vel速度。從軟件架構角度來講move_base類 作為navigation的邏輯核心存在。
從移動機器人體系結構來說，move_base規定了整個規划層的行為流程。而如果要配置ROS navigation，重點就是move_base 與它組件的配置。定位與navigation meta package的關系：這一部分是論壇里面問得最多的。也是最不好搞清楚的部分。
ROS tf tree的知識。
base_link: 一般位於tf tree的最根部，物理語義原點一般為表示機器人中心，為相對機器人的本體的坐標系。
odom：一般直接與base_link 相鏈接，語義為一個對於機器人全局位姿的粗略估計。取名來源於odometry（里程計），一般這個坐標系的數據也是來源於里程計。對於全局位姿的估計方 法很多，比如在hector SLAM與導航體系中，就采用了imu數據估計全局位姿，還有很多視覺里程計的算法（visual odometry）也能提供位姿估計。原點為開始計算位姿那個時刻的機器人的位置。之
odom_combined 這個tf一般為好幾種位姿估計方法的信息融合后的數據。在navigation metapackage中有 robot_pose_ekf 這個包是用擴展卡爾曼濾波算法（EKF）融合不同傳感器的數據。
map: 一般與odom（或者odom_combined）相連，語義為一個經過先驗（或者SLAM）地圖數據矯正過的，在地圖中的位姿信息。與odom同為全局坐標系。原點為地圖原點（地圖原點在地圖相應的yaml文件中有規定）。
一個完整的ROS navigation 運行時的tf tree 如下：
在機器人定位與導航體系中，定位模塊作為規划層的輸入與參考數據所存在。而對於ROS navigation 體系而言，因為它先天的模塊間通訊方式實現了模塊間的完全解耦，所以對於導航規划層而言（具體就是move_base 這個node），什么定位方法，靜態還是動態的地圖，對於導航層內部幾乎沒有 區別。在這種思想指導下，navigation metapackage 中 就有了為仿真器環境下的定位工具包fake_localization： 用於把仿真器中的位姿（就是直接吧odom 變換成map）估計直接變換成關於全局地圖的定位，簡化定位部分；對於動態創建的地圖slam， gmapping 在ROS中提供從 odom -》map的 坐標轉換，也可以作為navigation 中 move_base 的輸入。
navigation 各個部分的解析：
move_base: 在之前說過了， move_base 部分作為navigation的邏輯核心。實現了一個供上層節點調用的action 接口（通過actionlib 實現），即給定坐標信息與相應坐標位置，執行相應的安全導航動作。對於下層控制器，之前說過了輸出為cmd_vel 2d速度。 它規定了這個navigation的行為。
ROS navigation： 導航規划層提供一個在良好的定位條件下，安全導航到指定目標坐標的功能。
行為層： move_base 綜合機器人狀態與上層指令，給出機器人當前行為：正常導航，執行恢復動作，給上層節點返回失敗，終止導航。其中恢復動作可以自己定義。
全局規划層：global_planner
局部規划層： local_planner
控制器層：一般就是之前自己寫的速度發送部分，下位機代碼
ostmap_2d ： 這一部分可看作為navigation的輸入處理器。不同的傳感器輸入的數據差異很大（激光雷達 & RGBD-camera）通過costmap_2d ， 不同的數據被處理成統一的格式：柵格地圖，權值用經過概率方法處理過的，表示空間中障礙物，未知與安全區域。生成出來的costmap則是 planner 的輸入。
global_planner ： 為navigation的全局規划器，接受costmap生成的 global costmap 規划出從起始點到目標點的路徑，為local_planner 作出參考。
local_planner ： 為navigation 的局部規划器，接受costmap 生成的local costmap 規划出速度。
recovery_behavior : 規定move_base 行為集合中處理異常情況的行為
要理解ROS navigation 最重要的部分是nav_core: 這個包里面就包含了global_planner ， local_planner 與 recovery_behavior的基類的頭文件。但是極其重要。
navigation 的配置
完成與嵌入式層的交互后，就可以着手配置navigation了。基本就是按照官網上這個教程把launch文件和相應的yaml文件配起來就好了。
對於導航規划層來說，制約表現好壞的最重要一部分就是costmap的生成。costmap會分別生成兩份，local_costmap 與 global_costmap 。這兩份的參數是完全不同的。先是local_costmap ，local_planner 要求的實時性還是挺高的（特別是你把速度調高的時候），而local_costmap 所依賴的 全局坐標系一般是odom，繪制costmap的時候會反復詢問odom-》base_link 坐標系的信息，tf數據延遲要是大了會影響costmap，進而導致機器人planner實時性降低，機器人移動遲緩或者撞上障礙物。所以有個參數 transform_tolerance一定要慎重。如果是使用靜態先驗地圖做導航，那么全 局的costmap可以選擇使用static_map選項，這 樣的話在move_base 創建之初就會根據先驗地圖生成一次，以后不會再更新了。這樣會節省一些計算量。
而如果采用動態地圖（實時slam出來的）或者根本不使用先驗地圖，那可以將全局的costmap所依賴的全局坐標系也改為odom， rolling_window選項代替static選項，這樣costmap就會實時更新，要注意的是這樣的話你上層程序給出的目標點就不能超過 rolling_window的范圍。
基本調試好這些navigation就可以初步的運行起來了，而之后就是針對不同環境與不同任務對規划器進行選擇與調試。