Re: Non Default OMPL Params

[Ioan Sucan]

Hello Matt,

It sounds like you want to use OMPL directly. There are ways to modify the parameters you suggest (there are getters and setters for them) and you can also add your own planner as well. A tutorial on that is here:
http://ompl.kavrakilab.org/newPlanner.html

Once you have the planner in OMPL, you will need to update the ompl_interface library in the moveit_planners_ompl package to include that planner; That will be just an association from a name that you can specify in ompl_planners.yaml and the new class you will define. Once you see the code there, I think it will be apparent how to do it. Please let me know if you run into problems.

PRM actually has a simple way of defining connection strategies (a base class for the connection strategy). You can look at how things work now with the PRM and PRM* connection strategies.

Ioan

On Mon, Jun 10, 2013 at 3:42 PM, Matt DiCicco <mdic...@rethinkrobotics.com> wrote:

Dear Ioan (and moveit users),

Are there any good examples or documentation on how to set specific parameters to be something other than the default in ompl_planning.yaml?

I'm interested in changing some of the parameters on the default planners (the step size and goal criteria on an RRT planner, for instance) and also adding a new planner with non default parameters (PRM with a new connection strategy).

Any pointers?  Is this even possible?

Thanks,

-Matt-

[Matt DiCicco]

Okay, I think I see what you mean.

I have moveit and ompl just as binaries from apt-get because I did the default install.  I guess that means I should remove those two packages and check them out directly in order to modify the source in the way you recommend.  

If I want to make my own RRT with different settings, I should just create a new RRT class, inheriting from the existing class and then use set methods to configure it how I want?  Once I've got that "new planner" I can add it to the list of planners in planning_context_manager.cpp and then put its name in my yaml file?

With PRM, I notice that there is already a PRMstar.h in ompl but not in the context manager.  If I modify the planning_context_manger.cpp, would that make it available for use?

Thanks,

-Matt-

[Ioan Sucan]

On Mon, Jun 10, 2013 at 9:25 PM, Matt DiCicco <mdic...@rethinkrobotics.com> wrote:

Okay, I think I see what you mean.

I have moveit and ompl just as binaries from apt-get because I did the default install.  I guess that means I should remove those two packages and check them out directly in order to modify the source in the way you recommend.  

If I want to make my own RRT with different settings, I should just create a new RRT class, inheriting from the existing class and then use set methods to configure it how I want?  Once I've got that "new planner" I can add it to the list of planners in planning_context_manager.cpp and then put its name in my yaml file?

Yes, but parameters that are already defined, like the range or goal bias for RRT -- exposed as a GenericParam in OMPL -- can be configured already in ompl_planning.yaml, so there is no need to define a new planner that is really the same planner but configured differently.

The new class would be needed when you want to change the behaviour of the algorithm, like what you described for PRM.

With PRM, I notice that there is already a PRMstar.h in ompl but not in the context manager.  If I modify the planning_context_manger.cpp, would that make it available for use?

Yes, that is correct.
 

[Matt DiCicco]

Okay, I think I see what you mean.

I have moveit and ompl just as binaries from apt-get because I did the default install.  I guess that means I should remove those two packages and check them out directly in order to modify the source in the way you recommend.  

If I want to make my own RRT with different settings, I should just create a new RRT class, inheriting from the existing class and then use set methods to configure it how I want?  Once I've got that "new planner" I can add it to the list of planners in planning_context_manager.cpp and then put its name in my yaml file?

Yes, but parameters that are already defined, like the range or goal bias for RRT -- exposed as a GenericParam in OMPL -- can be configured already in ompl_planning.yaml, so there is no need to define a new planner that is really the same planner but configured differently.

Does that mean that things set as GenericParam in OMPL can be set via a YAML file in MoveIt?  I took a look at the OMPL source and didn't actually find any GenericParams called out explicitly.  Looking at RRT specifically, I did see that there is a declareParam for "range" and "goalBias".   Can I add a "range" and "goalBias" param to ompl_planning.yaml? 

The new class would be needed when you want to change the behaviour of the algorithm, like what you described for PRM.

With PRM, I notice that there is already a PRMstar.h in ompl but not in the context manager.  If I modify the planning_context_manger.cpp, would that make it available for use?

Yes, that is correct.
 

 

Great.  I'd like to try this out, but...

Is there an easy way to point my checked-out-source version of  MoveIt to my locally installed version of OMPL?  Sorry if this is a basic question, but the ROS build system is a bit baffling to me.  Following the instructions here: http://moveit.ros.org/wiki/Installation didn't help much because the rosdep step for installing the moveit source pulled in the binary version of OMPL. 

[Ioan Sucan]

On Tue, Jun 11, 2013 at 7:21 PM, Matt DiCicco <mdic...@rethinkrobotics.com> wrote:

Okay, I think I see what you mean.

I have moveit and ompl just as binaries from apt-get because I did the default install.  I guess that means I should remove those two packages and check them out directly in order to modify the source in the way you recommend.  

If I want to make my own RRT with different settings, I should just create a new RRT class, inheriting from the existing class and then use set methods to configure it how I want?  Once I've got that "new planner" I can add it to the list of planners in planning_context_manager.cpp and then put its name in my yaml file?

Yes, but parameters that are already defined, like the range or goal bias for RRT -- exposed as a GenericParam in OMPL -- can be configured already in ompl_planning.yaml, so there is no need to define a new planner that is really the same planner but configured differently.

Does that mean that things set as GenericParam in OMPL can be set via a YAML file in MoveIt?  I took a look at the OMPL source and didn't actually find any GenericParams called out explicitly.  Looking at RRT specifically, I did see that there is a declareParam for "range" and "goalBias".   Can I add a "range" and "goalBias" param to ompl_planning.yaml? 

Yes, that is correct. Under type:, you can specify things like "range:" -- any name of a defined param, actually. If you switch ROS_CONSOLE debug mode on, you should also see messages about which params are updated.

The new class would be needed when you want to change the behaviour of the algorithm, like what you described for PRM.

With PRM, I notice that there is already a PRMstar.h in ompl but not in the context manager.  If I modify the planning_context_manger.cpp, would that make it available for use?

Yes, that is correct.
 

 

Great.  I'd like to try this out, but...

Is there an easy way to point my checked-out-source version of  MoveIt to my locally installed version of OMPL?  Sorry if this is a basic question, but the ROS build system is a bit baffling to me.  Following the instructions here: http://moveit.ros.org/wiki/Installation didn't help much because the rosdep step for installing the moveit source pulled in the binary version of OMPL. 

Easy... this is a bit tough  :)

Try this:

From the ompl repo, copy doc/dox/FindOMPL.cmake to moveit_planners/ompl/

Then in the command line, before calling catkin_make again on moveit, do this:

export OMPL_LIB_PATH=/path/to/your/compiled/ompl/lib/folder

export OMPL_INCLUDE_PATH=/path/to/your/ompl/src/folder

catkin_make

Ioan

[Matt DiCicco]

The new class would be needed when you want to change the behaviour of the algorithm, like what you described for PRM.

With PRM, I notice that there is already a PRMstar.h in ompl but not in the context manager.  If I modify the planning_context_manger.cpp, would that make it available for use?

Yes, that is correct.
 

 

Great.  I'd like to try this out, but...

Is there an easy way to point my checked-out-source version of  MoveIt to my locally installed version of OMPL?  Sorry if this is a basic question, but the ROS build system is a bit baffling to me.  Following the instructions here: http://moveit.ros.org/wiki/Installation didn't help much because the rosdep step for installing the moveit source pulled in the binary version of OMPL. 

Easy... this is a bit tough  :)

Try this:

From the ompl repo, copy doc/dox/FindOMPL.cmake to moveit_planners/ompl/

Then in the command line, before calling catkin_make again on moveit, do this:

export OMPL_LIB_PATH=/path/to/your/compiled/ompl/lib/folder

export OMPL_INCLUDE_PATH=/path/to/your/ompl/src/folder

catkin_make

Ioan

Thanks Ioan, 

I was able to get PRMstar to pull into moveit by simply editting the context manager!  PRMstar.h is there, available in ompl already. Is there any reason this wasn't included in the default list of available planners?

Also, I have a bit of a more conceptual question about the moveit pipeline:  It seems like PRM and PRMstar throw away the roadmap after each plan invocation.  Is that true?  If so, it seems somewhat strange and loses a lot of the power of the roadmap planner (having the map persist between calls).  It it possible to have it persist via changes to the OMPL implementation of the planner or will something on the moveit side prevent me from doing that?

Thanks,

-Matt-

[Ioan Sucan]

Hello Matt,

PRMstar was recently released as a separate header in OMPL, so it is simply an omission that it is not included in the default list of planners.

The clearing of the roadmap is actually intentional. Typically the situation is that the environment changes. And the planner does not assume the environment remained constant between calls. Hence the call to clear(), which resets the roadmap.

We could add an option to disable the call to clear() if that is a strong need. Do you have a usecase for this?

Ioan

[Matt DiCicco]

I can think of some simple use case where the environment is not changing (i.e., stationary robot, small number of obstacles which are also stationary and not expected to move).  Multiple motion plans in the same area would benefit from a persistent roadmap where each planner call adds more nodes according to whichever connection strategy is chosen.  Constantly adding and refining the roadmap over time seems like a good idea in this case.

I can scan the code and look for the 'clear()' call and try to remove it on my own for my test purposes, but it seems like a good feature to add, at least for PRM's.