[ros-users] Navigation stack questions [WAS: Wifi communication getting slow]

Eitan Marder-Eppstein eitan at willowgarage.com
Fri Jan 7 16:15:25 UTC 2011


Steven,

On Fri, Jan 7, 2011 at 2:30 AM, Steven Bellens <
steven.bellens at mech.kuleuven.be> wrote:

> 2011/1/6 Steven Bellens <steven.bellens at mech.kuleuven.be>:
> > 2011/1/5 Brian Gerkey <gerkey at willowgarage.com>:
> >> On Wed, Jan 5, 2011 at 8:37 AM, Steven Bellens
> >> <steven.bellens at 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.
> >
> > When running all except the hokuyo_node on the groundstation (no
> > gmapping, only amcl), the network traffic is still about 8MB / s from
> > the robot to the ground  station. I didn't check which nodes are the
> > main consumers here yet, but the /scan topic only takes around 20kB /
> > s of this. This 8 MB / s is way too much as only laser scan data needs
> > to be send, right?
> > The ROS master is running on the groundstation.
>
> I've found this to be the odometry message publishing which was
> happening too fast (1kHz). Reducing it to 100Hz reduces the network
> traffic to 2MB / s and less.
>
> >
> >>
> >>> 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.
> >
> > This also happens when only running amcl. I found this to be a problem
> > of the map origin coordinates or something related, but might need
> > some help solving it. I've build a map using gmapping and saved it
> > with the map_saver functionality. The map.yaml file places the origin
> > of the map at [-50.0 , -50.0, 0.0], which is in the middle of the map.
> > However the costmap always complains:
> >
> > [ WARN] [1294326503.260648549]: The origin for the sensor at (-0.97,
> > 0.16, 0.00) is out of map bounds. So, the costmap cannot raytrace for
> > it.
> >
> > As the map building goes fine, I expect the tf frames to be OK (there
> > are no errors displayed). Do I need some more transformations to get
> > the sensor frame updated with this map origin values?
>
> I've read some more threads on this list about this, but didn't find
> an answer. Trying to run with a static map, rviz hangs when trying to
> display all (inflated) objects. The map I have is 1984 x 1984 at 0.05
> m / pixel. However, most of the map is unknown area, which is filled
> in as obstacles but never succeeds completely (rviz just hangs). Is
> there a way to shrink a saved map? Or to not care about the unknown
> area?
> I'm working an a Fedora system and installed ROS from svn
> (tags/cturtle). Is this still a good version to use for the navigation
> stack? The CMakeLists.txt in the navigation stack folder mentions
> rosbuild_make_distribution(1.2.3).
>

There are a few parameters in the costmap that you may want to look at.
First, you'll want to make sure that your costmaps are tracking unknown
space. Depending on whether you're using a voxel or costmap model for your
costmap that may involve different parameters. See:
http://www.ros.org/wiki/costmap_2d#Map_type_parameters. You'll also want to
make sure that when maps come in from gmapping, the unknown_cost_value is
set correctly to recognize unknown space as unknown, see:
http://www.ros.org/wiki/costmap_2d#Map_management_parameters. After this,
you may want to configure navfn, assuming you're using the default global
planner to allow the robot to make plans through unknown space. You can do
this by setting the allow_unknown parameter documented here:
http://www.ros.org/wiki/navfn#Parameters.

Hope this helps and navigation 1.2.3 should be fine for what you want to do,

Eitan


>
>
> Steven
>
> >
> > Steven
> >
> >>
> >>        brian.
> >> _______________________________________________
> >> ros-users mailing list
> >> ros-users at code.ros.org
> >> https://code.ros.org/mailman/listinfo/ros-users
> >>
> >
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110107/552a4897/attachment-0003.html>


More information about the ros-users mailing list