Revision history [back]

This is a very good, but very involved question. As you mentioned, most of the answers to your questions are in the code to MoveIt, but that code is pretty complex; hopefully this answer should help guide you to the parts you're interested in.

1. How does MoveIt convert a Motion Plan Request to a StateSpace, StateValidityChecker, and Control Space that OMPL needs?

MoveIt creates a StateSpace per robot and a StateValidityChecker for the planning scene the robot is in. MoveIt extends OMPL StateSpace class with it's Model Based State Space, which can either be a Joint Based State Space or a Pose Based State Space (see the other directories in that folder).

As can be seen in this line, MoveIt sets the StateValidityChecker to be MoveIt's StateValidityChecker, which is actually just a thin wrapper around MoveIt's Planning Scene.

The actual motion plan request really just gives the start and goal of the problem, since MoveIt should already have the StateSpace and the StateValidityChecker.

1. Given that OMPL has no sense of what a robot is, how does MoveIt! abstract the problem down to a form solvable by OMPL?

This problem is a very difficult one to answer in a single answer. Very briefly, OMPL works with Configuration Spaces, and searches for a path of a point through this space. MoveIt turns each configuration of the robot into a single point in this configuration space through the StateSpace, and lets OMPL know which states are valid and invalid through the StateValiditiyChecker.

This could be an entire class to answer this question, so here's some more resources that explain this concept in more detail if you are interested: * The original paper explaining the idea of the C-Space (http://lis.csail.mit.edu/pubs/tlp/spatial-planning.pdf) * A book that covers Motion Planning broadly (http://planning.cs.uiuc.edu/book.html)

1. Is there a way to gain some physical intuition on what the states explored by the planner are? Or are the intermediate plans stuck in a black box with only the solution reported by the planning plugin?

At the moment, unfortunately yes. While OMPL itself allows you to see the space explored by the planner (see this method), the MoveIt plugin doesn't easily allow you to do this. However, MoveIt is open source for a reason! The easiest way to do what you are describing is to add a line of simple_setup_->getPlannerData(...) right before returning the final solution, and to store that data somewhere for you to analyze later.

For a disclaimer, much of this specific code is planned on being refactored soon (see this PR for the planned changes), specifically to enable you to write your own motion planning plugins using OMPL, which would make your task easier. In addition, with the major refactor of the OMPL Plugin, this is a good chance for detailed documentation to be written about using the Plugin, so keep an eye out for that.

This is a very good, but very involved question. As you mentioned, most of the answers to your questions are in the code to MoveIt, but that code is pretty complex; hopefully this answer should help guide you to the parts you're interested in.

1. How does MoveIt convert a Motion Plan Request to a StateSpace, StateValidityChecker, and Control Space that OMPL needs?

MoveIt creates a StateSpace per robot and a StateValidityChecker for the planning scene the robot is in. MoveIt extends OMPL StateSpace class with it's Model Based State Space, which can either be a Joint Based State Space or a Pose Based State Space (see the other directories in that folder).

As can be seen in this line, MoveIt sets the StateValidityChecker to be MoveIt's StateValidityChecker, which is actually just a thin wrapper around MoveIt's Planning Scene.

The actual motion plan request really just gives the start and goal of the problem, since MoveIt should already have the StateSpace and the StateValidityChecker.

1. Given that OMPL has no sense of what a robot is, how does MoveIt! abstract the problem down to a form solvable by OMPL?

This problem is a very difficult one to answer in a single answer. Very briefly, OMPL works with Configuration Spaces, and searches for a path of a point through this space. MoveIt turns each configuration of the robot into a single point in this configuration space through the StateSpace, and lets OMPL know which states are valid and invalid through the StateValiditiyChecker.

This could be an entire class to answer this question, so here's some more resources that explain this concept in more detail if you are interested: * interested:

• The original paper explaining the idea of the C-Space (http://lis.csail.mit.edu/pubs/tlp/spatial-planning.pdf) * (http://lis.csail.mit.edu/pubs/tlp/spatial-planning.pdf)
• A book that covers Motion Planning broadly (http://planning.cs.uiuc.edu/book.html)

1. Is there a way to gain some physical intuition on what the states explored by the planner are? Or are the intermediate plans stuck in a black box with only the solution reported by the planning plugin?

At the moment, unfortunately yes. While OMPL itself allows you to see the space explored by the planner (see this method), the MoveIt plugin doesn't easily allow you to do this. However, MoveIt is open source for a reason! The easiest way to do what you are describing is to add a line of simple_setup_->getPlannerData(...) right before returning the final solution, and to store that data somewhere for you to analyze later.

For a disclaimer, much of this specific code is planned on being refactored soon (see this PR for the planned changes), specifically to enable you to write your own motion planning plugins using OMPL, which would make your task easier. In addition, with the major refactor of the OMPL Plugin, this is a good chance for detailed documentation to be written about using the Plugin, so keep an eye out for that.