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

Fri Jan 7 18:36:10 UTC 2011

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
>
>