Re: [ompl-users] Distance metric and interpolation for RRTs

[Anand <ana...@gm...>]

Thanks Mark, sounds like it's not a very good idea.

Anand

On Wed, Jun 28, 2017 at 9:25 PM, Mark Moll <mm...@ri...> wrote:

> Hi Anand,
>
> You could derive a new class from DubinsStateSpace where you override
> distance. This might lead to some surprising results. The paths will
> probably have many twists and turns that path simplification cannot
> eliminate.
>
> As far as I know there really isn’t an efficient way to search nearest
> neighbors in non-metric spaces.
>
> Best,
>
> Mark
>
>
>
> On Jun 28, 2017, at 5:54 PM, Anand <ana...@gm...> wrote:
>
> In OMPL, the distance metric used (distance()) and the way in which states
> are connected (interpolate()) are encapsulated as part of the state space.
>
> For example, the DubinsStateSpace uses the path length of the Dubins curve
> to compute the distance() and interpolate().
>
> Does it make sense for an RRT to use a different distance metric for
> nearest neighbor computations, than what is used for interpolation?
>
> In my scenario (planning for a car-like robot), I wonder if it makes sense
> to speed up nearest neighbor searches by using a distance metric other than
> Dubins (say Euclidean distance) to find nearest neighbors, but still use
> Dubins to connect states? This will allow me to use nearest neighbor data
> structures like GNAT, which I can't otherwise do if I use the Dubins
> distance metric.
>
> If not, are there any alternative data structures I can use to speed up
> nearest neighbor searches for a Dubins-like non-metric space?
>
> Thanks,
> Anand
>
>
>