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

ompl_planning returns invalid plans

asked 2011-05-02 04:46:52 -0500

jbarry gravatar image


I've been using the OMPL planner for the PR2 arm in fairly constrained situations (trying to pick items out of a cabinet) and it keeps returning invalid plans. Specifically, it returns a plan that hits an obstacle in the environment. Usually when this is the case it prints out a message that the "plan appears to have become invalidated already". When I check the validity of the plan using the planning_environment trajectory validity checker, it is indeed invalid. If I actually run the plan, the arm will collide with an obstacle. The environment is not dynamic; the obstacles the arm collides with were present and in the collision map during planning.

At the moment, I am simply re-planning when and invalid plan is returned and usually it will eventually find a valid plan, but I have had over 50 invalid plans returned. Each plan takes some computation time and then more time for the validity check, making for an unacceptably long planning time even when a valid plan is eventually found. The return from the planner is always 0 (whether the plan is valid or not). I tried using the pick and place pickup action for the same goal and observed the same behavior; the plans returned are usually invalid and the pickup action usually fails.

I give the planner 45 seconds, which it never uses all of and often some ordered collisions, but never the ones that invalidate the plan. I've reproduced the full call below.

Has anyone else seen this? Is there something simple I am overlooking?

Thanks, Jenny

motion_planning_msgs::GetMotionPlan mprsrv;

mprsrv.request.motion_plan_request.group_name =
mprsrv.request.motion_plan_request.num_planning_attempts = 1;
mprsrv.request.motion_plan_request.allowed_planning_time = 

//I set mprsrv.request.motion_plan_request.goal_constraints, which is long and
//dependent on the arguments to the function so I've omitted it
mprsrv.request.motion_plan_request.ordered_collision_operations = 
    collisionOperationsForGrasp(req.pickup_goal, req.names);

//I set the starting state equal to the robot's current state using get_robot_state

    workspace_region_pose.header.stamp = ros::Time::now();

ros::ServiceClient planner = 

ROS_INFO("Waiting for planning service"); planner.waitForExistence(); ROS_INFO("Planning"); bool goodcall =; ROS_INFO("Finished planning");

edit retag flag offensive close merge delete


Could you please mention which version of ompl you are using - cturtle or diamondback? There has been a whole new release of ompl in diamondback which fixes a lot of these issues.
Sachin Chitta gravatar image Sachin Chitta  ( 2011-05-02 05:55:34 -0500 )edit
I have seen the same thing happen in Cturtle, with my Katana arm. I thought I was using ompl wrongly, but maybe that's just not the case. Thanks for the up, Sachin, I think it's time to upgrade to Diamondback.
Martin Günther gravatar image Martin Günther  ( 2011-05-02 21:33:20 -0500 )edit
I am using the cturtle version of ompl, as our PR2 is still running cturtle. If the diamondback version of OMPL is likely to work better, I could try to upgrade the planning (we're not ready to upgrade the whole robot yet). Thanks!
jbarry gravatar image jbarry  ( 2011-05-04 06:47:25 -0500 )edit

1 Answer

Sort by » oldest newest most voted

answered 2011-10-06 16:52:26 -0500

tfoote gravatar image

If you can find a way to specifically reproduce this it would be great for a ticket. It looks like this has more or less been answered in the comments that it's been seen by a few. Answering this so I can close it.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2011-05-02 04:46:52 -0500

Seen: 316 times

Last updated: Oct 06 '11