2010/11/29 Gonçalo Cabrita <goncabrita@gmail.com>:
> As far as the dwa_local_planner goes, I placed a bunch of ROS_INFO all over
> the code to get an idea of what was going on while the robot was moving.
> Turns out our xy goal tolerance was too small. Due to the Roomba's great
> odometry (notice the sarcasm) when the robot was turning in place to reach
> the goal heading it would sometimes become out of the xy goal, so it would
> try to reposition itself. This would lead to the robot going for a little
> trip in order to get back on the spot. Also, the EeePCs are so amazingly
> fast (sarcasm once again!) that sometimes when the robot was rotating in
> place to get to the goal heading we would have some glitches on the costmap
> update, which in turn would make amcl jump the robot a bit on the map, thus
> putting the robot out of xy goal.

There's a feature to be added, which I think Eitan and I have
discussed before: any time the xy goal tolerance is satisfied, latch
that fact, and thereafter only execute the final heading adjustment,
no matter what the apparent xy goal error is.  That would protect
against both odometry drift and amcl jumps that can happen during the
final heading adjustment.  This is how Player's 'wavefront' driver
works.  The downside is that you no longer guarantee that the goal
tolerances are satisfied after navigation says that it reached the
goal.  But I suspect that it would be a beneficial tradeoff in most
circumstances.  It should be easy to hack in, and could be made an
option.

	brian.