[ros-users] Nav Stack with nonholonomic robots

Tue Sep 7 07:26:13 UTC 2010

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