On Wed, Jan 5, 2011 at 8:37 AM, Steven Bellens
<steven.bellens@mech.kuleuven.be> wrote:

> I've figured out the problem occurs the moment I start running the
> navigation stack. I've been able to build a map using gmapping
> (running the gmapping mode on the groundstation), and the ping
> responses were constantly okay. When I start up navigation without a
> pre-build map (amcl - move base - gmapping), the ping responses
> suddenly increase (from 2 - 8 ms to 1000+ ms). When I try the same
> with a static map, everything goes well. Am I doing something wrong in
> this setup, e.g. can I run amcl and gmapping at the same time? If not,
> how should I run the navigation stack without a prebuild map?

You should not run amcl and gmapping simultaneously.  They're both
estimating the map->odom transform, and you only want one source of
that information.  If you want to run without an a priori map, you
should use only gmapping, not amcl.  If you save the map produced by
gmapping (e.g., using the map_server/map_saver tool), you can then
localize against that map with amcl, and not run gmapping.

But the gmapping / amcl transform conflict shouldn't cause network
latency.  Instead, I would suspect that it's the bandwidth being
consumed by sending the updated map from gmapping to move_base;
move_base subscribes to the map, which gmapping publishes as a latched
topic.  Maps can be big, and the map produced by gmapping is
automatically something like 4000x4000 cells, regardless of how much
space has actually been observed by the robot (there's an opportunity
to optimize gmapping's behavior, to be sure).  An experiment to try:
increase the gmapping/map_update_interval parameter.  Then the map
will be published less often, and soak up less bandwidth.  The
tradeoff, of course, is that move_base will receive updated maps less
frequently.

> Another problem I face is about the navigation: the holonomic robot
> localizes itself OK, but the goals I send with rviz only manage to let
> it rotate (there is never a translational velocity command), so the
> robot starts rotating, but never gets anywhere close where I want him
> to go :). Any ideas on that?

This is probably caused by the tf conflict between amcl and gmapping.
When you bring up the navigation stack on top of gmapping, don't run
amcl.

	brian.