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

Fri Jan 7 20:16:07 UTC 2011

If the robot seems to rotate around a lot near the destination point (goal)
then you might want to look at your goal tolerance settings.  You can find
those documented here:

http://www.ros.org/wiki/base_local_planner#Goal_Tolerance_Parameters

Hope that helps,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
William Woodall
Graduate Software Engineering
Auburn University
w at auburn.edu
wjwwood at gmail.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Fri, Jan 7, 2011 at 12:36 PM, Steven Bellens <
steven.bellens at mech.kuleuven.be> wrote:

> 2011/1/7 Eitan Marder-Eppstein <eitan at willowgarage.com>:
> > 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
>
> Thanks Eitan,
>
> In the meantime, I managed to make some progress. The robot now finds
> plans using a static map, but still rotates a lot and sometimes
> doesn't get his final orientation right. When using a dynamic map, the
> costmap always pops up with this origin out of map warning.
> I'll try your suggestions on monday and let you know if it works out.
>
> Steven
>
> >
> >>
> >> 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
> >
> >
> > _______________________________________________
> > 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/f5b2f45a/attachment-0004.html>