[ros-users] Nav Stack with nonholonomic robots

Wed Sep 8 03:55:10 UTC 2010

Sachin,

The path makes more sense now. It was definitely not the behavior I
originally expected though :). It might be a good idea to have an easy way
for the user to express preferences in this situation. If just changing the
scaling factor and inflation radius of the global costmap is good enough,
that might do (along with a ; otherwise, a way for the user to modify
different terms in the heuristic might be useful (similar to the scoring
gains in the base_local_planner cost function). For example, in my use case,
I would prefer a path that took the shorter, but higher obstacle cost route
over a much longer, lower obstacle cost route. On the other hand, other
users may prefer the current behavior, so it would have to be configurable.

- Eric

On Tue, Sep 7, 2010 at 10:03 PM, Sachin Chitta <sachinc at willowgarage.com>wrote:

> Hi Eric,
>
> Mike (Phillips) pointed out to me that this actually is the "optimal"
> solution (given the costmap). The narrow hallway is expensive to go
> through since the cost from the inflated obstacles is pretty high
> there so a path that goes all around (in pretty much free space) will
> have a lower cost than a path that goes through such a high cost
> region.
>
> Sachin
>
> On Tue, Sep 7, 2010 at 12:30 PM, Eric Perko <wisesage5001 at gmail.com>
> wrote:
> > Sachin,
> > It is tricky to get through there, but the planner can do it. I moved it
> > using the sbpl_lattice_planner from the default starting point through
> that
> > narrow hallway to the red arrow pose, but have to do it with a halfway
> point
> > in the the hallway or it just goes all the way around (most likely due to
> > running out of time).
> > Here's the console output for a run reproducing the problem:
> >>
> >> [ INFO] [1283887074.606435759, 208.900000000]: [sbpl_lattice_planner]
> >> getting fresh copy of costmap
> >>
> >> [ INFO] [1283887074.610865752, 208.900000000]: [sbpl_lattice_planner]
> >> robot footprint cleared
> >>
> >> [ INFO] [1283887074.612990975, 208.900000000]: [sbpl_lattice_planner]
> >> getting start point (28.1542,30.7675) goal point (17.6406,21.6356)
> >>
> >> env: setting start to 28.154 30.768 0.023 (1126 1230 0)
> >>
> >> planner: setting start to 83014
> >>
> >> X=1126 Y=1230 Theta=0
> >>
> >> env: setting goal to 17.641 21.636 1.591 (705 865 4)
> >>
> >> planner: setting goal to 2815354
> >>
> >> the state is a goal state
> >>
> >> X=705 Y=865 Theta=4
> >>
> >> planner: forceplanfromscratch set
> >>
> >> [ INFO] [1283887074.783733829, 209.100000000]: allocated:5.000000, init
> >> eps:3.000000
> >>
> >> planner: search mode set to 0
> >>
> >> [ INFO] [1283887074.783796810, 209.100000000]: [sbpl_lattice_planner]
> run
> >> planner
> >>
> >> planner: replan called (bFirstSol=0, bOptSol=0)
> >>
> >> 2D search with sliding buckets and term_factor=0.500
> >>
> >> # of expands during 2dgridsearch=810061 time=250 msecs
> >> 2Dsolcost_inmm=83105 largestoptfval=164175 (start=1126 1230 goal=705
> 865)
> >>
> >> 2dsolcost_infullunits=207762
> >>
> >> search exited with a solution for eps=3.000
> >>
> >> eps=3.000000 expands=1913 g(searchgoal)=288955 time=0.010
> >>
> >> search exited with a solution for eps=2.800
> >>
> >> eps=2.800000 expands=41 g(searchgoal)=288316 time=0.000
> >>
> >> search exited with a solution for eps=2.600
> >>
> >> eps=2.600000 expands=13 g(searchgoal)=288316 time=0.000
> >>
> >> search exited with a solution for eps=2.400
> >>
> >> eps=2.400000 expands=16 g(searchgoal)=288316 time=0.000
> >>
> >> search exited with a solution for eps=2.200
> >>
> >> eps=2.200000 expands=98 g(searchgoal)=288310 time=0.000
> >>
> >> search exited with a solution for eps=2.000
> >>
> >> eps=2.000000 expands=157 g(searchgoal)=288298 time=0.000
> >>
> >> search exited with a solution for eps=1.800
> >>
> >> eps=1.800000 expands=42 g(searchgoal)=288030 time=0.000
> >>
> >> search exited with a solution for eps=1.600
> >>
> >> eps=1.600000 expands=8 g(searchgoal)=287652 time=0.000
> >>
> >> search exited with a solution for eps=1.400
> >>
> >> eps=1.400000 expands=279 g(searchgoal)=277977 time=0.000
> >>
> >> search exited with a solution for eps=1.200
> >>
> >> eps=1.200000 expands=28424 g(searchgoal)=220488 time=0.090
> >>
> >> expands so far=100000
> >>
> >> expands so far=200000
> >>
> >> expands so far=300000
> >>
> >> expands so far=400000
> >>
> >> expands so far=500000
> >>
> >> expands so far=600000
> >>
> >> expands so far=700000
> >>
> >> expands so far=800000
> >>
> >> expands so far=900000
> >>
> >> expands so far=1000000
> >>
> >> expands so far=1100000
> >>
> >> expands so far=1200000
> >>
> >> search exited because it ran out of time
> >>
> >> eps=1.200000 expands=1205210 g(searchgoal)=220488 time=4.630
> >>
> >> MaxMemoryCounter = 327575612
> >>
> >> solution is found
> >>
> >> total expands this call = 1236201, planning time = 5.000 secs, solution
> >> cost=218924
> >>
> >> Solution is found
> >>
> >> [ INFO] [1283887079.275728992, 213.600000000]: size of solution=484
> >>
> >> checks=1139182
> >>
> >> [ INFO] [1283887079.276301971, 213.600000000]: Plan has 4347 points.
> >
> > Looks like it ran out of time to keep searching. I shoulda looked at the
> > console output before :). I'll play around with the planning time
> parameter
> > a bit once I get it up and running on my own bot, since I definitely need
> it
> > to be able to go through narrow doorways.
> > Thanks for taking a look at that.
> > - Eric
> > On Tue, Sep 7, 2010 at 3:13 PM, Sachin Chitta <sachinc at willowgarage.com>
> > wrote:
> >>
> >> At first glance:
> >>
> >> The little hallway that you would expect the robot to go through is
> >> actually quite narrow. If you look in the static map, there are noisy
> >> obstacles right in its entrance. Since the planner lays down a full
> >> footprint it may not be finding a feasible path through that area, Its
> >> also a function of the kind of motion primitives used. Can you send me
> >> the text output that you see from the sbpl planner as well.
> >>
> >> BTW, I might be a little tardy in replying until we get over a
> >> deadline middle of next week but after that I would like to push and
> >> get this working.
> >>
> >> Regards,
> >> Sachin
> >>
> >>
> >>
> >> On Tue, Sep 7, 2010 at 12:01 PM, Eric Perko <wisesage5001 at gmail.com>
> >> wrote:
> >> > 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
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
> >
> >
> > _______________________________________________
> > 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/bbc9b042/attachment-0003.html>