-
Notifications
You must be signed in to change notification settings - Fork 3
Current ompl interface in MoveIt
My notes from going through the code of the current ompl interface in MoveIt.
The correct state space is created using state space factories and additional methods to select the correct factory. The planning context manager has a map with state-space factories. Based on the planning request, each factory gets a priority. For a specific request, the factory with the highest priority is selected, unless enforce_joint_model_state_space is true.
The priority is calculated based on
- Is there an IK solver? (for all groups?? is this necessary?)
- Are there joint or visibility constraints?
- Are there path constraints?
The priority values and selection process is shown below:
The priorities lead to the following state-space selection process:
All of the above could be replaced by a simpler if-else statement. Do we really need the flexibility of this priority?
A call to this method goes through quite some layers.
-
PlannerManager::getPlanningContextcallsOMPLInterface::getPlanningContext. - Which calls
PlanningContextManager::getPlanningContext. - Which does some work and calls another version of
PlanningContextManager::getPlanningContext, after which some work is done on this context.
The long standing pose model issue is mentioned in planning_context_manager.cpp.
Start state and state validity checker set at line 117 of model_based_planning_context.cpp, but possibly changed later on because the context is cleared?
It should be possible to use the same simple setup pointer for constrained planning. But the state space is used a lot. The constrained state space cannot be saved in the same member of ModelBasedPlanningContextSpecification. The simple setup is created in planning_context_manager.cpp at line 347.
What is the state tag used for (related to the tag_snap_to_segment_).
Why not inherit from RealVectorStateSpace instead of StateSpace to avoid code duplication?