# Optimization Objective has no effect

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:

move_group_GR.setPoseReferenceFrame("world_zero");
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++){

move_group_GR.setNumPlanningAttempts(10);
move_group_GR.setPlanningTime(a);
move_group_GR.setPlannerId("RRTstar");
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
move_group_GR.setPoseTarget(t_pose);
// Start
move_group_GR.setStartStateToCurrentState();

// 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 close merge delete

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

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

Sort by » oldest newest most voted

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

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

( 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.

( 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?

( 2019-09-23 12:56:42 -0500 )edit

https://github.com/ompl/ompl/blob/374... not sure how to translate this into a number though ...

( 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.

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