[ros-users] Navigation Stack on tight places

[Eitan Marder-Eppstein]

Brian,

I think I remember having that conversation at some point... but now its
ticketed here: https://code.ros.org/trac/ros-pkg/ticket/4599

<https://code.ros.org/trac/ros-pkg/ticket/4599>This happens to be really
easy to do, so I'll probably just put it in today. Unfortunately, I don't
think this is something that can be released into C-Turtle as its an
extension to the current API. So, it may have to wait for D-Turtle to go in.

Hope all is well,

Eitan

On Tue, Nov 30, 2010 at 8:58 AM, Brian Gerkey <gerkey at willowgarage.com>wrote:

> 2010/11/29 Gonçalo Cabrita <goncabrita at gmail.com>:
> > As far as the dwa_local_planner goes, I placed a bunch of ROS_INFO all
> over
> > the code to get an idea of what was going on while the robot was moving.
> > Turns out our xy goal tolerance was too small. Due to the Roomba's great
> > odometry (notice the sarcasm) when the robot was turning in place to
> reach
> > the goal heading it would sometimes become out of the xy goal, so it
> would
> > try to reposition itself. This would lead to the robot going for a little
> > trip in order to get back on the spot. Also, the EeePCs are so amazingly
> > fast (sarcasm once again!) that sometimes when the robot was rotating in
> > place to get to the goal heading we would have some glitches on the
> costmap
> > update, which in turn would make amcl jump the robot a bit on the map,
> thus
> > putting the robot out of xy goal.
>
> There's a feature to be added, which I think Eitan and I have
> discussed before: any time the xy goal tolerance is satisfied, latch
> that fact, and thereafter only execute the final heading adjustment,
> no matter what the apparent xy goal error is.  That would protect
> against both odometry drift and amcl jumps that can happen during the
> final heading adjustment.  This is how Player's 'wavefront' driver
> works.  The downside is that you no longer guarantee that the goal
> tolerances are satisfied after navigation says that it reached the
> goal.  But I suspect that it would be a beneficial tradeoff in most
> circumstances.  It should be easy to hack in, and could be made an
> option.
>
>        brian.
> _______________________________________________
> 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/20101130/1436ab3c/attachment-0003.html>