| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
Hi, I'm having an issue with moveit::planning_interface::MoveGroup::plan() It returns MoveitErrorCode. But unfortunately it doesn't specify the exact error that occured while planning, but only returns either -2 or -1 if failed. What I want to know is the exact failure reason such as GOAL_IN_COLLISION=-12. Please help me with this one. If possible provide with helpful links on this topic.
If you look at the MoveIt code for when it uses -1 (PLANNING_FAILED) or -2 (INVALID_MOTION_PLAN), you can see that these values are returned when the motion planner simply didn't find a solution; motion planning is a difficult problem and sometimes the planner won't find a valid solution. Knowing the "exact failure reason" might not be possible in these cases. Generally, MoveIt! will return a more specific error code if one occurs, so if you don't receive a more specific code, I think it's safe to say that those cases aren't true (i.e., that your start and goal are not in collision, etc).
The thing is that I've tried to give it a Pose that obviously is not valid (50, 50, 50 for ex.). Still it returns -1 instead of "GOAL_VIOLATES_PATH_CONSTRAINTS=-13". What I'm trying to achieve here is ti simply test path planning with my environment to see how it performs.
PLANNING FAILED is just not enough information. Can I somehow get those errors through moveit for at least GOAL_IN_COLLISION=-12? To me it seems like there is no reason in moveit to not check goal pose for collisions.
Ah, I see. When you give MoveIt! a goal pose, as opposed to a single goal position, it tries to use IK to sample valid positions of the robot that satisfy that goal pose (eventually the code gets here).
So it just tries to continually sample a goal pose and if it can't reach it, then the motion planning is consider to not be solved. MoveIt! doesn't seem to try to calculate if a pose is outside the reachable workspace of the robot. I agree, it's definitely a deficiency, but PRs would be welcome!
Yep, I found lines where it actually promts mistakes but returns false in any case. Thanks a lot! You really helped!
If you find a situation where a more specific error code should be returned, please consider creating an issue in the github project and/or providing patches to improve the response!
I believe that in situations where there is no valid IK, it is indeed not very helpful to return "planning failed".
At least we could check whether there is IK solutions without collision checks to identify GOAL_IN_COLLISION. Unreachable goals(GOAL_CONSTRAINTS_VIOLATED) are harder to identify because the ik solver might not have found the solution.
Still it might make sense to return the code then.
Asked: 2018-06-15 05:34:01 -0600
Seen: 235 times
Last updated: Jun 15 '18
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
