0
$\begingroup$

Rosanswers logo

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!


Originally posted by scchow on ROS Answers with karma: 55 on 2018-08-14

Post score: 4

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

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.


Originally posted by BryceWilley with karma: 711 on 2018-08-15

This answer was ACCEPTED on the original site

Post score: 7


Original comments

Comment by jgkawell on 2019-06-04:
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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.