Revision history [back]

In no particular order:

• test in simulation (even without physics, just in RViz). If you are observing similar behaviors in simulation, you know that the issue doesn't have to do with slip or other hardware related issues. It will also make it more repeatable and you can tune faster. This way you can start with the most simple scenario (straight line paths with no obstacles) and work your way up to see what is making it misbehave. Are narrow pathways getting in the way? Or does it work perfectly in simulation? If so, what is different with the real robot?
• look at the code and wiki page and make sure you mostly understand how it works, or at least what all parameters do. Once you understand that, tuning becomes a bit easier, or you'll realize that dwa doesn't fit your situation and you want to switch to something like TEB (which has a LOT more tuning parameters)
• visualize visualize visualize. Make sure you can see the paths it generates and how it compares to the global navFn paths. Visualize all costmaps and sensor data to see if it's seeing noisy data that aren't obstacles
• Turn things on and off one by one: If you make values extreme, does it affect the specific behavior you're trying to solve? Use your intuition from 2) to do this. Use dynamic reconfigure for this rosrun rqt_reconfigure rqt_reconfigure
• Turn off recovery behavior during debugging so the only behavior you're seeing comes from the controller.
• Double check the physical values of your robot. How fast can it actually move, how much error is introduced when it does so?
• Make sure your odometry is as good as it can be. This is often overlooked. I wrote an in-depth blog about that here