Closed hersh closed 10 years ago
-1 Please do not merge this. This will lead to significantly increased computation time for planning. The attached object should not be ignored if it is attached to a link that is part of the group speficied.
So...
If I have a robot with a gripper which is in an end-effector group and I attach an object to some link in the end-effector, and that is attached to an arm whose links are grouped, and I want to plan... what group do I send to the planner? I don't want the planner to include the end-effector joints in the planning. I only want it to use the arm joints. So I send the arm group to the planner. But then it ignores the object I attached to the end-effector. So what do I do?
also, why would this significantly increase planning time?
OK, it does look like it is supposed to work correctly, based on this:
and
So it was already supposed to be considering not just links in the group, but all links and objects downstream from the group.
I wonder why the planner seems to be ignoring my attached object without this change. I've verified the object is attached in the RobotState that is passed in, and the scene has the other objects.
Ah, I see. I've run into the infamous problem of having my object attached to a link with no geometry. That's why this change makes it work for me. I guess I'll go create a tiny cube to add to my URDF. :(
That would do it :) Thanks Dave! Collision checking is >75% of time spent my moveit when motion planning, so doing collision checks for the entire robot would significantly increase that time.
For my industrial robot arm, there is only one link that doesn't move, the base. I wonder what type of robot you are working with. ;-)
Delete the branch? ...I can't stand dead branches :-)
This fixed a bug for me where ompl was ignoring attached object collisions with the scene during planning.