[ros-users] Nav Stack with nonholonomic robots

Tue Sep 7 19:13:03 UTC 2010

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