Interpolator vs a local planner

[mkoval]

@cdellin raised a good point on Reviewable:

I feel like this interpolation idea, if removed from the StateSpace (which is a reasonable design decision), starts to look more like a local planner class which returns a trajectory (or path) between the two states. If we're already committing to an API for planners and for trajectories (i.e. plan between two states, get a trajectory, make queries on the trajectory such as different derivatives, etc) , it seems weird to duplicate that functionality here.

There may be an argument that planners will want to interpolate things very quickly, without for instance instantiating a path object at each step. But at least we should make the API identical, I'd think. And it would be cool if planners could be passed different types of local planners (here called interpolators) and concatenate the resulting path segments using the stock trajectory API.

[psigen]

I generally agree with this idea. It's especially cool because you could imagine doing things like using a VectorFieldPlanner to do large extend operations in an CBiRRT with much higher success rates.

Also, this means that SnapPlanner might take the role of the local planner in most cases, so that we don't have to handle VanDerCorput-sequenced collision checks in every planner and so forth.

[mklingen]

VectorFieldPlanner + CBiRRT is the mighty ATACE planner.