RRTstar planner assumes symmetric distance/cost functions

[ompl]

RRTstar planner assumes symmetric distance/cost functions

[mamoll]

Original comment by Luis G. Torres (Bitbucket: [Luis Torres](https://bitbucket.org/Luis Torres), ).

---

updated readability

[mamoll]

Original comment by Ioan Sucan (Bitbucket: isucan, GitHub: isucan).

---

This looks good. We can add a virtual method to StateSpace to tell whether motions are symmetric. We can use that instead of some of the sanity checks flags too.

[mamoll]

Original comment by Luis G. Torres (Bitbucket: [Luis Torres](https://bitbucket.org/Luis Torres), ).

---

Removed references to "asymmetric metric" since an asymmetric distance function cannot technically define a metric

[mamoll]

Original comment by Luis G. Torres (Bitbucket: [Luis Torres](https://bitbucket.org/Luis Torres), ).

---

In my fork of OMPL, I've added a virtual method hasSymmetricDistance() to StateSpace.

However, it seems that there's more than one notion of symmetry in a given space; there's also the question of whether the state interpolation is symmetric; i.e. whether

interpolate(from, to, t, s) == interpolate(to, from, (1-t), s)

Ideally symmetry would imply that both the distance function and the state interpolation are symmetric, but this may not necessarily be the case. For instance, one may think that the current (asymmetric) DubinsStateSpace::distance() function is too expensive, and therefore opt to use the (symmetric) SE2StateSpace::distance() function instead as a heuristic, but still prefer to use the current (asymmetric) DubinsStateSpace::interpolate() function. In such a case, we'd have a symmetric distance function and an asymmetric interpolation.

Maintaining this distinction in symmetry of interpolation is again important for RRTstar: if interpolation is symmetric, we can assume that if checkMotion(s1, s2) is true, then checkMotion(s2, s1) is true and save some computation time.

Does adding yet another virtual method, StateSpace::hasSymmetricInterpolation(), make sense?

[mamoll]

Original comment by Mark Moll (Bitbucket: mamoll, GitHub: mamoll).

---

Is the member function StateSpace::isMetricSpace() sufficient for your needs, or do you still need StateSpace::hasSymmetricInterpolation()? Given that you are working on this in your own fork, we should just wait for your pull request and close this ticket after you code has been pulled (provided it all looks look to the OMPL developers)? BTW, I think your generalization of RRT* is a great idea.

[mamoll]

Original comment by Mark Moll (Bitbucket: mamoll, GitHub: mamoll).

---

fixed since Luis' branch has been merged

[mamoll]

Original comment by Florian Hauer (Bitbucket: hauerflorian, GitHub: hauerflorian).

---

I'm trying to use RRTStar with asymmetric cost and interpolation. It looks like this is handled in the code, but there is that test:

#!c++

if (!si_->getStateSpace()->hasSymmetricDistance() || !si_->getStateSpace()->hasSymmetricInterpolate())
    {
        OMPL_WARN("%s requires a state space with symmetric distance and symmetric interpolation.", getName().c_str());
    }

in the setup method (line 109 of RRTStar.cpp).
Is that test remaining from before asymmetric cases were handled?
Or are asymmetric cases still not properly handled by the algorithm?