http://wiki.ros.org/navigation/Tutorials/Navigation%20Tuning%20Guide
1.查看傳感器數據有無輸出，以及頻率
2.里程計測試：
（1）打開Rviz 設置frame為“odom”，display 激光， 設置topic的延時時間(decay time)為20s左右，然后原地旋轉。Then, I look at how closely the scans match each other on subsequent rotations. Ideally, the scans will fall right on top of each other, but some rotational drift is expected, so I just make sure that the scans aren't off by more than a degree or two
（2）對着牆面測試里程計的平移：The next test is a sanity check on odometry for translation. I'll set up rviz the same way with the robot a few meters away from a wall. Then, I'll drive the robot straight at the wall and look at the thickness of the wall as reported by the aggregated laser scans in rviz. Ideally, the wall should look like a single scan but I just make sure that it doesn't have a thickness of more than a few centimeters. If you drive a meter towards a wall and get scans spread out over half a meter though, something is likely wrong with the odometry
3.定位：
若里程計不是很准，可以參考amcl的里程計模型參數設置進行改進：I'll play around a bit with the odometry model parameters for AMCL
4.costmap：
（1）確保每個觀測源的期待更新頻率（expected_update_rate）是基於傳感器的發布頻率，通常要給予一定量的容忍度
（2）transform_tolerance：使用tf_monitor 檢查transform from the "base_link" frame to the "map" frame的時延，然后設置保守的參數
（3）map_update_rate
（4）publish_frequency 調低
（5）在里程計frame下測試導航獨立與定位：Sometimes, its useful to be able to run navigation solely in the odometric frame. To do this, I find the easiest thing to do is to copy my local_costmap_params.yaml file over my global_costmap_params.yaml file and change the the width and height of the map to be something more like 10 meters. This is a really easy way to get things up and running if you want to tune navigation independent of localization performance
（6）其他 看說明
5. local planner：
（1）一定要看機器人的加速度限制
（2）對於DWA：update the vx_samples parameter to something between 8 and 15 depending on the processing power available. This will allow for non-circular curves to be generated in the rollout
（3） 定位不准和避免震盪：localization for the robot I'm working with isn't great, I'll make sure to set the goal tolerance parameters a bit higher than I would otherwise. I'll also up the rotational tolerance if the robot has a high minimum rotational velocity to avoid oscillations at the goal point.
（4）CPU不夠 sim_granularity適當提高（采樣間隔增加，采樣數減少）
（5）Turning the path_distance_bias parameter up 更貼近路徑 但設置過高會導致機器人拒絕移動，因為移動的cost遠比待在路徑上的cost高
（6）如何整定cost function： If I want to reason about the cost function in an intelligent way, I'll make sure to set the meter_scoring parameter to true. This makes it so distances in the cost function are in meters instead of cells and also means that I can tune the cost function for one map resolution and expect reasonable behavior when I move to others. Furthermore, you can now visualize the cost function produced by the local planner in rviz by setting the publish_cost_grid parameter to true. (This somehow never made it into the docs, I'll get to that sometime soon). Given the cost function in meters, I can compute the tradeoff in cost of moving 1 meter towards the goal balanced against how far away I am from the planned path. This tends to give me a decent idea of how to tune things
（7）軌跡室友他們的終點endpoint打分的，這意味着設置不同的sim_time 將對機器人行為產生很大的影響，一般設置在1-2秒，設置較大時，軌跡會更加平滑；確保最小速度*sim_period （ minimum velocity × sim_period）小於我目的地容忍度的兩倍！否則機器人會更傾向於在目標位置外原地旋轉而不是到達目標點
（8）准確的軌跡simulation 也取決於合理的里程計的速度反饋估計，加速度限制和反饋速度決定了一個規划周期內合理的速度采樣空間！