[ros-users] Oddness in global plan from navfn / costmap_2d

[Eitan Marder-Eppstein]

Armin,

Right now, navfn requires that the start and the goal map to the center of a
grid cell for planning. Propagation of the potential function will always be
done assuming cells of some resolution, however, I suppose we could start
walking the gradient from a non-centered cell coordinate which could make a
fair amount of difference if you're talking about a large cell size in your
gird. I filed a ticket to do this here:
https://code.ros.org/trac/ros-pkg/ticket/4001.

I've got some other stuff going on right now, but I'll try to get to this
when I can... hopefully in the next week or so.

Thanks again for pointing these things out, its been quite helpful.

Hope all is well,

Eitan

On Fri, Apr 16, 2010 at 3:13 AM, Armin Hornung <
HornungA at informatik.uni-freiburg.de> wrote:

> Hi Eitan!
>
>  Thanks so much for finding this, I've fixed the bug in both trunk (rev
>> 28749) and the 1.0 branch (rev 28750) of navigation and the fixes will go
>> out with the next patch release of both the 1.0 and the 1.1 series. I'll
>> try
>> to push out patch releases either later today or tomorrow and I believe it
>> should fix the problem you're seeing.
>>
>>
>
> I had a look at the fixed navfn now, and the paths indeed look a lot nicer
> and smoother now. Thanks!
>
> Now only the strange behavior at the start and the end of a path remain, as
> seen in the attached screenshot. It seems like the computed path starts and
> ends at the top right grid cell center of the actual start and goal
> position, with an added (unsmooth) path segment from the computed goal to
> the requested one. The effect is of course more pronounced in larger grid
> resolutions (and also happend in my empty test case map). Is that something
> fixable in the navfn code?
>
> If it's only possible to plan on grid cell centers, a workaround could be
> to start and end the computed path on the grid cell that is between the
> actual (requested) goal and start and then adding a first and last segment
> which extends the computed path in a similar direction. That should cause a
> less discontinuous curve.
>
>
> Cheers,
> Armin
>
> --
> Armin Hornung                              Albert-Ludwigs-Universität
> www.informatik.uni-freiburg.de/~hornunga<http://www.informatik.uni-freiburg.de/%7Ehornunga>  Dept. of Computer Science
> HornungA at informatik.uni-freiburg.de        Humanoid Robots Lab
> Tel.: +49 (0)761-203-8010                  Georges-Köhler-Allee 79
> Fax : +49 (0)761-203-8007                  D-79110 Freiburg, Germany
>
>
>
> _______________________________________________
> 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/20100416/5113a21b/attachment-0003.html>