Fail when start point is inside an obstacle

[justbuchanan]

This is useful for robot planning if we start out in a virtual obstacle where we're not supposed to be. The current implementation will fail to find us a path out of the obstacle.

[jgkamat]

Now that we have the escape path planner, this isn't needed (and it dosen't make sense for the RRT to solve this problem, since the solution isn't immediately clear, and can break other usages of the RRT), so we should fail immediately instead of waiting until we hit the RRT MaxIterations.

[justbuchanan]

This is mainly handled by the StateSpace class's transitionValid() and stateValid() methods. Our subclass of StateSpace in robocup-software overrides these methods to allow starting inside an obstacle. EscapeObstaclesPlanner is actually used on the endpoint - this way if our gameplay code requests an invalid goal point, we find a nearby non-blocked point and go there instead.

StateSpace is meant to be subclassed for specific use-cases, so obstacles aren't really something this library has to handle. We do use obstacles in the RRT Viewer, but this is just for a simple demo. I wouldn't worry about starting inside obstacles in the demo.

[jgkamat]

Oh, that makes a lot more sense (than what I was thinking before).

transitionValid might be hard, but do you think it would be a good idea to fail if the goal isn't stateValid()? (I haven't looked too much at the rrt, so I might be still misunderstanding the statespace class). I'm mainly trying to avoid running until maxIterations if we know we cannot find a path with the current layout (and I think that's a good feature to have for anyone who's using our RRT, since it gives the same result without wasting cycles). For example, if someone /wanted/ the rrt to fail when the goal/start state was in an obstacle for some reason, they would have to wait until MaxIterations to see that failure. That could easily be fixed on their side, but I think it would make our library a little nicer to use if we had a small check.

[justbuchanan]

That might be a good idea. You could check the goal state with stateValid() at the beginning of Tree.run() and return early.