[ros-users] Nav Stack with nonholonomic robots

Tue Sep 7 19:01:46 UTC 2010

Sachin,

Thanks for the info. I did get a chance to checkout sbpl_lattice_planner and
poke it a bit using the included launch files. I did see some really odd
behavior out of it though, as more than once it generated some really
suboptimal paths. I'm attaching a screenshot from nav_view of one example
from the launch file that loads up the WG map. The robot started at the
orientation marked by the red arrow and I gave it a goal orientation of the
blue arrow. You can see the planned path in green. Definitely not anywhere
close to the path I expected. Is this just due to needing to play with the
suboptimality bound for the anytime planning algorithms? I would have
expected suboptimal paths, but not quite as suboptimal as "the long way
around" :)

I'll see about getting it set up within my existing nav stack setup sometime
this week and let you know what problems (if any) I run into.

- Eric

On Tue, Sep 7, 2010 at 3:26 AM, Sachin Chitta <sachinc at willowgarage.com>wrote:

> Eric,
>
> I will let Eitan reply to your other questions about the navigation
> stack. My response is in particular about the sbpl_global_planner.
> There is a new version of the ROS interface for the planner in the
> sbpl_lattice_planner package which will soon supersede the
> sbpl_global_planner package. The underlying sbpl library is maintained
> by one of our collaborators. On that note, I am curious to get any
> feedback you have on the performance of that planner with the aim of
> eventually fixing the bugs and releasing it. There are a few
> (undocumented) modifications that can be made to the planner to help
> it function better that need to be flushed out into
> tutorials/documentation before a release can be made. So, any feedback
> you can provide will be useful.
>
> Regards,
> Sachin
>
>
> On Mon, Sep 6, 2010 at 11:34 PM, Eric Perko <wisesage5001 at gmail.com>
> wrote:
> > 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
> >>
> >
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users at code.ros.org
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> >
>
>
>
> --
> Sachin Chitta
> Research Scientist
> Willow Garage
> _______________________________________________
> 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/aab6dea9/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot-Nav View.png
Type: image/png
Size: 72567 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100907/aab6dea9/attachment-0005.png>