Ask Your Question
4

Details of MoveIt! to OMPL Pipeline

asked 2018-08-14 15:47:00 -0500

scchow gravatar image

updated 2018-08-14 15:51:15 -0500

I have recently been trying to wrap my head around the pipeline between MoveIt! and OMPL.

Currently, my main issue is that I want to be able to take a state generated by OMPL and map it back to what it means in the context of the planning problem. This help me answer important questions such as "what configurations is the planner sampling?" and "why does one planner perform better/worse than the other?".

As stated in the documentation, "planners in OMPL are abstract; i.e. OMPL has no concept of a robot. Instead, MoveIt! configures OMPL and provides the back-end for OMPL to work with problems in Robotics."

From reading through the OMPL documentation, I understand that OMPL requires at least a StateSpace, StateValidityChecker, and a ControlSpace used in conjunction with the SimpleSetup object to plan.

On the other hand, it seems that MoveIt! generates a motion plan by sending a MotionPlanRequest through a pipeline that converts the problem into a form understandable to the planner. This pipeline is what I am interested in.

My questions are:

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

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

  3. 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?

Some approaches I have taken are:

  1. Look through the documentation and the tutorial on MoveIt! and OMPL. But it seems to be more focused on the high level implementation rather than how the interface works/

  2. Look at the source code for the OMPL interface in Moveit!. The code is relatively complex and difficult to navigate, specifically, it is difficult to tell how the adapter plugins and the classes interact. Some guidance in understanding the code structure would also be greatly appreciated.

Thanks for your help!

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
6

answered 2018-08-15 16:23:53 -0500

updated 2018-08-24 10:42:22 -0500

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:

  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.

edit flag offensive delete link more

Comments

This answer mentions a PR that will make planning plugins easier but I'd like to note that this PR has been closed for now. It could be taken up at a later date but I'd check the discussion on the link in the answer above for more details if you're interested.

jgkawell gravatar imagejgkawell ( 2019-06-04 15:26:40 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2018-08-14 15:47:00 -0500

Seen: 217 times

Last updated: Aug 24 '18