[ros-users] Nav Stack with nonholonomic robots

Tue Sep 7 19:30:31 UTC 2010

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100907/38fc4f34/attachment-0003.html>