Currently, OMPL's RRTstar planner is implemented in a way which is invalid for state spaces with asymmetric distance/cost functions, e.g. DubinsStateSpace. To be helpful, I've attached my own OMPL implementation of RRTstar which correctly handles asymmetric distance and cost functions.
The current implementation of RRTstar makes the following assumptions which do not hold in a space like DubinsStateSpace: 1) checkMotion(s1, s2) is the same as checkMotion(s2,s1); 2) distance(s1,s2) is the same as distance(s2,s1); 3) cost(s1,s2) is the same as cost(s2,s1); 4) the nearby neighbors for the connection step are the same as the nearby neighbors for the rewiring step.
Therefore, an RRTstar implementation which works for DubinsStateSpace would do TWO nearest neighborhood searches (one FROM the new motion, and one TO the new motion), and it would perform distinct sets of distance(), cost() and checkMotion() calls for each of the two different neighborhoods. This is of course more computationally intensive, which further motivates having a way of knowing at run-time whether the StateSpace has symmetric distance/cost functions (this way we can save computation if we know the StateSpace's distance/cost functions are symmetric).
Another tangential issue in the current implementation of RRTstar is the assumption of a PathLengthOptimizationObjective. This is unnecessarily strict, since the cost metric only requires certain boundedness, monotonicity, and smoothness properties. In my implementation, I've used the getIncrementalCost() and combineObjectiveCosts() methods of OptimizationObjective in order to generalize the objective optimized by the planner. I've chosen to enforce the use of a BoundedAdditiveOptimizationObjective for semantic reasons, because RRT* assumes that path cost is "accumulated" from one configuration to another (although I think ideally we should enforce the use of a class called something like BoundedAccumulativeOptimizationObjective).