Fixed spurious CloneException errors in planning stack. #298
Conversation
Due to OpenRAVE weirdness, we are forced to throw a CloneException if a robot is cloned from a self-colliding configuration. We also clone at the beginning of our planning operations. This means that calling a planning method while a robot is in self collision would create a CloneException, which is generally not expected or handled in code that is calling a planning method. It is also not clear to calling code that this is actually a failure within a planner, and it breaks MetaPlanner logic. In this PR, ClonedPlanningMethods will catch CloneExceptions and wrap them as ClonedPlanningErrors instead, which inherit from PlanningError and are thus handled correctly throughout the planning stack as a form of planning failure.
|
I am concerned that letting meta-planners catch I'd rather fail fast by letting the |
|
The motivation for this is that no one actually handles If I put the robot into collision, and tell it to plan to another place, I don't expect to have to catch a Note that the only reason we can get a |
|
I see your point. I was missing the obvious (in hindsight) fact that a |
|
@mkoval bump. |
|
Travis is happy. Merging. |
Due to OpenRAVE weirdness, we are forced to throw a
CloneExceptionif a robot is cloned from a self-colliding configuration. We also clone at the beginning of some of our planning operations.This means that calling a planning method while a robot is in self-collision can create a
CloneException, which is generally not expected or handled in code that is calling a planning method. It is also not clear to calling code that this is actually a failure within a planner, and it breaksMetaPlannerlogic.In this PR,
ClonedPlanningMethods will catchCloneExceptions and wrap them asClonedPlanningErrors instead, which inherit fromPlanningErrorand are thus handled correctly throughout the planning stack as a form of planning failure.