ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Optimization Objective has no effect

asked 2019-09-18 01:18:16 -0500

cpetersmeier gravatar image

updated 2019-09-18 02:49:08 -0500

I am planning with RRTstar for a 6 DOF articulated robot. I move from a joint start to a pose goal. I plot mean of path length vs planning time and do 10 runs for each 0.1s intervall in [0.1; 9.9]

Although I see high variability, the mean of the path length does not decrease when planning time increases. I am quite surprised by this since I have set the optimization objective to PathLengthOptimizationObjective. I see the same behaviour when I play with num_planning_attempts or range.

Is there something I am missing like enabling the planner params set by setPlannerParams()? Or is this expected behaviour since I am not planning around an obstacle, but rather "besides" it.

Here is my code:

bool success = false;
int num_runs = 10;
double max_planning_time = 10.0;
double min_planning_time = 0.1; 
double planning_time_step = 0.1;

for(float a = min_planning_time; a <= max_planning_time; a = a + planning_time_step ){
    for(int i = 0; i < num_runs; i++){

    std::map<std::string, std::string> m;
    m.insert(std::pair<std::string, std::string>("range", "0.0"));
    m.insert(std::pair<std::string, std::string>("goal_bias", "0.05"));
    m.insert(std::pair<std::string, std::string>("delay_collision_checking", "1"));
    m.insert(std::pair<std::string, std::string>("optimization_objective", "PathLengthOptimizationObjective"));
    move_group_GR.setPlannerParams("RRTstar", "Gripper", m);

    // Target
    // Start

    // Generate Plan
    moveit::planning_interface::MoveGroupInterface::Plan measurePlan;
    success = false;
    success = (move_group_GR.plan(measurePlan) == moveit::planning_interface::MoveItErrorCode::SUCCESS);

    // Executing and logging ...

    // Move back to start ...
edit retag flag offensive close merge delete


Setting the range with setPlannerParams() seems to have no effect on the configuration variables on the parameter server.

cpetersmeier gravatar image cpetersmeier  ( 2019-09-19 03:58:59 -0500 )edit

1 Answer

Sort by » oldest newest most voted

answered 2019-09-23 03:25:28 -0500

Simon Schmeisser gravatar image

I'm not sure all of these parameters get passed on correctly. Your best bet would be to have a look at the code directly.

I also don't think setting the parameters this is way is supposed to change anything on the parameter server, this is rather intended as a override for the parameter server.

Mark Moll and I fixed some issues with localization in this area, you could try running your test with the classic locale if you have any other set (one that uses comma , as decimal separator). This should all be fixed in packages by now however.

Setting range to zero will not give very good results for anything complicated. We usually use something like 0.2. The smaller you set it the longer it will take to find a solution but they will also be superior. It basically is the maximum length of a new branch of the tree and a smaller value will give you a more compact tree

edit flag offensive delete link more


If the range set to 0.0, should there be a tree at all? To change parameters I modified ompl_planning.yaml and restarted the simulation - this seems to work, but does not really alter the trajectory length.

For my main experiments I left the range at 0.0, giving me good results even in workspaces with obstacles. I found it very surprising that the optimizaton Algorithms like RRTstar did not improve with greater range (I tried 0.0, 20.0 and 40.0) over different planning times (0.1 to 10.0 seconds).

Maybe my environment was just too straight forward and there is not really much play to improve the path; or my expectations where too high

cpetersmeier gravatar image cpetersmeier  ( 2019-09-23 07:40:16 -0500 )edit

0.0 means that it uses some heuristics, I think it's either the workspace diameter or something similar.

20 and 40 sound way off, what is the scale of your system? Typically its meters and radians so it should be something smaller than 1 (meter) if using cartesian distance and in case it uses a joint space distance metric 1.0 would still be a sensible upper limit (57°)

RRT samples random states and then checks if any of the existing branches of the tree are < range away. It will then do collision checking for those candidates. As your time budget for collision checking is constant, you should try to have good candidates.

Simon Schmeisser gravatar image Simon Schmeisser  ( 2019-09-23 08:34:00 -0500 )edit

That helps a lot, I wasn't sure about the unit of the range parameter. On the official OMPL Benchmarking Page they set higher range values - even going up to 200. seeing the graphic at the bottom of the page, I thought 20 and 40 should be a good first guess.

Is there any documentation on what range 0.0 means, or is the only way to find out looking at the OMPL code?

cpetersmeier gravatar image cpetersmeier  ( 2019-09-23 12:56:42 -0500 )edit not sure how to translate this into a number though ...

Simon Schmeisser gravatar image Simon Schmeisser  ( 2019-09-25 00:56:56 -0500 )edit

Ill try and dig myself through, thanks very much for the pointer!

In the RRT Implementation I found allowed range boundaries of 0.1 and 10000.

cpetersmeier gravatar image cpetersmeier  ( 2019-09-25 02:47:06 -0500 )edit

Question Tools



Asked: 2019-09-18 01:18:16 -0500

Seen: 407 times

Last updated: Sep 23 '19