Define an interface for Sample-able regions about aikido

[mkoval]

Here's a quick overview of the OMPL API:

• Goal
  • void isSatisfied (const State *st) const: Decide whether a given state is part of the goal region.
  • void isStartGoalPairValid (const State *, const State *) const
• GoalRegion:
  • distanceGoal (const State *st) const: Compute the distance to the goal (heuristic).
• GoalSampleableRegion:
  • void sampleGoal (State *st) const: Sample a state in the goal region.
  • void maxSampleCount () const: Return the maximum number of samples that can be asked for before repeating.
  • void canSample () const: Return true if maxSampleCount() > 0, since in this case samples can certainly be produced.

This raises some interesting considerations that I had not previously thought about:

• isSatisfied is useful for uni-directional planners.
• It's important to avoid sampling the same goal twice from a finite set of goals.
• Do we care about isStartGoalPairValid? Where would this fit in the API?

@cdellin Thoughts?

[cdellin]

I don't have a strong opinion about these -- I think it's probably a good idea to define a common planning problem specification for us to use that's OMPL-agnostic, but we don't need to cover all the possible use-cases.

It seems to me that we might start by just implementing prpy-like planning methods by wrapping the OMPL API directly for OMPL planners, and then introduce an intermediate base class if we end up duplicating too much code (either between wrappers of different OMPL planners, or when we start wrapping CHOMP / trajopt / etc).

FWIW, one thing that always bothered me a bit about the OMPL API is how asymmetric it is between starts and goals -- you can't have a sampleable start region, etc.

[psigen]

Linking this issue to the excellent PR that @lgw903 has been putting together: #13

[mkoval]

Implemented by #13.