[ros-users] Nav Stack with nonholonomic robots

Eric Perko wisesage5001 at gmail.com
Tue Sep 7 06:34:32 UTC 2010


Eitan,

Here's a quick summary of my current experience with the navigation stack.
I'll see if I can clean up some simulation that reproduces the behavior
later this week.

First off, my current platform is about 3 feet long by 2 feet wide (power
wheelchair base) with diff-drive. I've seen behavior that may be similar to
Christian's. Namely, parameters that were fine in an outdoor environment
where there was a lot of clearance fail horribly indoors. Even after
changing parameters around, indoor environments are still tricky. When there
is at least a foot of clearance between the robot and any obstacle,
navigation seems to work okay (minus poor choices of direction to rotate in
when spinning in place once in a while).

When attempting to navigate in a much more constrained space, the local
planner can be pretty bad. For example, one of the tasks our platform needs
to be able to do is navigate through tight doorways where clearance may be
at most 6-7 centimeters on either side and we've found base_local_planner to
have pretty poor performance in this situation. For example, we've seen the
robot get partway through the doorway and then be unable to get out of the
doorway (and that is when it even manages to get into the doorway at all).
After experimenting with the trajectory checking code, we found that the
costmap resolution needed to be increased to ensure that there would always
be a clear grid cell between the robot and doorway; at the default 5 cm
resolution and only 7 cm of clearance, we were encountering overlap due to
the mapping between continuous position coordinates and discrete map cells.
I haven't gotten a chance to play with updated cost scoring parameters for
this new resolution - the defaults failed pretty badly, most likely because
the costs are in map_cells, not meters, so they need updated each time the
map resolution is changed.

To address these problems with the base_local_planner and precision paths,
we're currently experimenting with a number of trajectory planning and path
following algorithms to achieve precise navigation in constrained
environments.

I believe there are also a few problems I've seen due to the global planner
(navfn) not planning very well for a rectangular bot, especially a
diff-drive one. A good example is the following: when I manually drove the
robot along the global path to get a feel for it, another guy watched and
said that at one point, the backend of our robot had only 1-2 cm of
clearance, which is a bit scary - and prolly something that would make the
base_local_planner unhappy. I did try the sbpl_global_planner briefly in
simulation a few weeks back, but couldn't get it working very reliably -
guess there is a good reason that it's unreleased :)

Well that ended up a bit longer than I originally planned, but hopefully it
will lead to some insights that will improve the navigation stack's
performance for everyone.

- Eric

On Tue, Sep 7, 2010 at 1:15 AM, Eitan Marder-Eppstein <
eitan at willowgarage.com> wrote:

> Christian,
>
> First off, its true that navigation is not fully "solved" for real world
> environments. We're trying to provide a system that improves the navigation
> capabilities of a large number of robots, but there's still a lot of work to
> be done. We do try to test the navigation stack as often as possible on our
> PR2, and have had mostly positive results, but that doesn't necessarily mean
> it will work well in all cases. As far as the problems you're having, I'd be
> curious to see the launch files that you're using to bring up the navigation
> stack on your robot. I've looked at those parameters a lot, and might be
> able to give some insight into what's going on.
>
> I'd also be curious to see if you experience the same problems with the
> navigation stack in simulation. If you can create launch files that show a
> simulated version of your robot having the problems you described, it would
> allow us to reproduce the behavior your seeing and give us a better shot at
> fixing things. We could even add these tough cases as tests for the
> navigation stack so that others with diff-drive robots don't have to
> experience the pain you've been through. If you want, you can check out the
> navigation_stage package for a template of how to run navigation in a
> simulated environment.
>
> I'm sorry that it hasn't been a pleasant experience so far, but hopefully
> we'll figure out what's going on.
>
> Are other diff-drive folks experiencing these kinds of problems with their
> setups?
>
> Hope all is well,
>
> Eitan
>
>
> On Mon, Sep 6, 2010 at 10:27 AM, Brian Gerkey <gerkey at willowgarage.com>wrote:
>
>> On Sat, Sep 4, 2010 at 12:12 AM, Christian Verbeek
>> <verbeek at servicerobotics.eu> wrote:
>> >  I am using move_base for driving a robot with non holonomic drive. I
>> > found the performance to be poor to wholly unacceptable. I played around
>> > with the parameters for quite a time and was not able to find a
>> > satisfactory setting. The problem with the parameters is that I most of
>> > the time I can not see a difference at all when changing something.
>> >
>> > My impression is that the navigation stack works in tidy and roomy
>> > environments. But in real world settings with narrow passages and stuff
>> > standing around performance drops dramatically. I tried this both woth
>> > boxturtle and latest cturtle and can not see any improvements. The
>> > navigation (which is in my eyes the most basic behaviour) is so to say
>> > still unsolved for real world environments.
>>
>> hi Christian,
>>
>> Hmm, that's a less than glowing assessment of the navigation stack.
>> I'd be interested to find out exactly what's going wrong.  We use the
>> navigation stack all the time on the PR2 in our office, which is
>> neither tidy nor roomy.  It frequently avoids many small obstacles,
>> and squeezes through tight openings.  Of course, the PR2 is an
>> omni-drive robot, and we test less often on differential-drive robots.
>>  But the navigation stack is intended to support differential-drive
>> robots, and there's no reason that it shouldn't work well in that
>> situation.
>>
>> Can someone who's had more success with the navigation stack on
>> differential-drive robots suggest a good set of parameters?
>>
>>        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/20100907/15dd8999/attachment-0003.html>


More information about the ros-users mailing list