[ros-users] Nav Stack with nonholonomic robots

Eitan Marder-Eppstein eitan at willowgarage.com
Tue Sep 7 18:18:06 UTC 2010


I'll reply in-line below:

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).

I'd expect to see some poor choices for in-place rotation from time to time
due to the way that trajectories are simulated and scored. Specifically,
since a fixed time is used for rolling out trajectories, there are cases
that a velocity that goes the long way around will score better than one
that goes the short way around if they are both applied for something like 1
second. This hasn't been a huge problem for us, though we do see it happen,
but I can put some thought into possible solutions. The only one that's
coming to me off the top of my head is to have a different time threshold
for forward simulating in-place rotations, but there's probably a better

> 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.

The PR2 has similar, if not more restrictive, clearance requirements. I
believe we get 5cm on each side going through certain doorways. A 5cm map is
definitely not high enough resolution to operate in these environments, so
we use a 2.5cm map. In practice, that seems to work well. We do have the
advantage that our base can strafe when moving through these tight spaces,
so its possible that we just don't encounter the same kind of sticky
situations that your robot gets into.

As far as costs go, I haven't had to change parameters when moving between
resolutions, but you do have a point about the costs for path_distance and
goal_distance being in map cells. The costmap actually moved away from
representing costs based on cell distance and instead uses Euclidean
distance for propagation, but the base_local_planner never made the switch.
I think this was an oversight, and I've created a ticket to explore moving
to meters from cells for the base_local_planner:

> 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.

That's great. The more planning approaches out there, the better as far as
I'm concerned. Its unlikely that one kind of local planner will work for
everything, and it would be nice for people to have some options out there.
We've also played around with different approaches internally, especially
when doing things like pushing a cart around the office. One local planner
that might be of interest to you is the pose_follower. It lives in the
navigation_experimental stack and is designed to follow a global path as
closely as possible and to stop when the path is blocked by an obstacle.
Obviously, its experimental code, and we've only tested it on a holonomic
robot, but it might work out if you do get a different global planner up and

> 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 :)

One thing that isn't always so clear about navfn, though it is documented on
the wiki page for the planner, is that navfn assumes a circular robot. This
means that as your robot gets more and more non-circular, navfn's plans will
be progressively worse. This causes all sorts of problems and we'd like to
move to something that considers the full footprint in the future. To this
end, and as Sachin mentioned, you may want to check out the
sbpl_lattice_planner package and see if that works out for you.

> 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.

Thanks for the feedback, its always appreciated and will help to improve the
navigation stack in the long term. Do let me know when you have some
simulation stuff set up, as that will be really useful for testing.

Hope all is well,


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

More information about the ros-users mailing list