Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only check end effector collisions for target pose in ComputeIK #117

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

henningkayser
Copy link
Member

@henningkayser henningkayser commented Jan 5, 2020

Fixes false positive collisions of links/objects unrelated to the (rigidly extended) end effector. This includes collisions between objects or secondary groups and root links caused by the added padding. Common examples for this are collision objects positioned on a table link or another planning group having a self collision.

@codecov-io
Copy link

codecov-io commented Jan 5, 2020

Codecov Report

Merging #117 into master will decrease coverage by 0.02%.
The diff coverage is 0.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #117      +/-   ##
==========================================
- Coverage   26.87%   26.84%   -0.03%     
==========================================
  Files          90       90              
  Lines        5752     5758       +6     
==========================================
  Hits         1546     1546              
- Misses       4206     4212       +6     
Impacted Files Coverage Δ
core/src/stages/compute_ik.cpp 20.00% <0.00%> (-0.62%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4fa7066...66b4381. Read the comment docs.

Copy link
Contributor

@rhaschke rhaschke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please elaborate which issue you want to tackle with this PR?
At first sight, it doesn't make sense to me to restrict collision checking to the end-effector.
If there are collisions with the arm, the IK solution is not feasible, is it?

Also, there is a much better approach to restrict collision planning to a subset of links:
https://github.com/ros-planning/moveit/blob/844a0212865d66541a3d6dc6ac6abef23b0da526/moveit_core/collision_detection/include/moveit/collision_detection/collision_common.h#L275-L276

@henningkayser
Copy link
Member Author

henningkayser commented Jan 6, 2020

Could you please elaborate which issue you want to tackle with this PR?
At first sight, it doesn't make sense to me to restrict collision checking to the end-effector.
If there are collisions with the arm, the IK solution is not feasible, is it?

Also, there is a much better approach to restrict collision planning to a subset of links:
https://github.com/ros-planning/moveit/blob/844a0212865d66541a3d6dc6ac6abef23b0da526/moveit_core/collision_detection/include/moveit/collision_detection/collision_common.h#L275-L276

This is just the pre-check for seeing if the target pose itself is in collision (not the IK solution). The actual collision check inside the IK validation callback is not affected and would still detect collisions in the arm, therefore all IK solutions are feasible. The solved issue is simply that ComputeIK detects collisions in static links and secondary groups (i.e. other groups than the ones it should run IK for) only because of added padding. IMO ComputeIK should only "care" for collisions in the groups it was initiated with.

The method you linked is a distance request. I wasn't aware that you could run this without computing the distances.

@rhaschke
Copy link
Contributor

rhaschke commented Jan 6, 2020

This is just the pre-check for seeing if the target pose itself is in collision (not the IK solution).

I missed this fact. Sorry.

The solved issue is simply that ComputeIK detects collisions in static links and secondary groups (i.e. other groups than the ones it should run IK for) only because of added padding.

Are those unrelated links considered without padding in all remaining checks?
In this case, you are right.

But, your implementation is still sub optimal: Instead of first checking all possible collision pairs and subsequently filtering out unrelated ones, you should restrict collision checking to the relevant pairs in first place.
Maybe active_components_only cannot be specified (yet) for collision checking (as an old TODO comment above the function suggests). In this case you should (further) modify the ACM to exclude unrelated link pairs.

@mamoll
Copy link
Contributor

mamoll commented Jun 8, 2020

@henningkayser, @rhaschke's suggestion of setting up the ACM correctly before the collision check seems reasonable to me. Can you make this change?

@henningkayser henningkayser force-pushed the pr-compute_ik_target_col_check branch from 35a7aa3 to 366b7fa Compare June 16, 2020 11:30
@henningkayser
Copy link
Member Author

henningkayser commented Jun 16, 2020

@rhaschke @mamoll I updated this PR to only modify the ACM instead of checking the colliding links afterwards. Collisions between rigidly connected root links and scene objects are now allowed since these don't affect the IK solution as already discussed above. Also, the modifications are applied to a copied ACM so that IK is run using only the original entries.
Correct me if I'm wrong, but didn't the collision check in setFromIK() (original implementation) still allow the disabled collisions for all group links since it's using the same sandbox_scene with the modified ACM? I didn't run a test to validate this, but looking at the code this seems to be the case and this PR would fix this.

Copy link
Contributor

@mamoll mamoll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me.

@henningkayser henningkayser force-pushed the pr-compute_ik_target_col_check branch from 366b7fa to 8123dd0 Compare June 17, 2020 17:49
@henningkayser
Copy link
Member Author

I just saw that this still doesn't cover all cases. If the colliding links are outside of the kinematic chain then the pre-check will still collide with other collision objects. My suggestion now is to really only check for collisions in the eef links in the pre-check and disable all others.

@henningkayser henningkayser force-pushed the pr-compute_ik_target_col_check branch from 8123dd0 to 66b4381 Compare June 17, 2020 20:59
@henningkayser
Copy link
Member Author

@mamoll @rhaschke please re-review.
I don't think there is really a better way to fix this here but this fully covers all edge cases, including disabling collisions between static links outside of kinematic chain and scene objects while still checking for self-collisions.

Copy link
Contributor

@mamoll mamoll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@henningkayser
Copy link
Member Author

@rhaschke ping

Copy link
Contributor

@rhaschke rhaschke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for noticing the wrong reuse of the sandbox scene!

@@ -96,15 +96,16 @@ bool isTargetPoseColliding(const planning_scene::PlanningScenePtr& scene, Eigen:

// consider all rigidly connected parent links as well
const robot_model::LinkModel* parent = robot_model::RobotModel::getRigidlyConnectedParentLinkModel(link);
const auto& target_links = parent->getParentJointModel()->getDescendantLinkModels();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe move this line down to the code block that actually uses this variable?

Comment on lines +123 to +131
// disable collision checking between collision objects and links not part of the rigid target group
const auto& world_object_ids = scene->getWorld()->getObjectIds();
for (const auto& robot_link : scene->getRobotModel()->getLinkModelsWithCollisionGeometry()) {
if (std::find(target_links.begin(), target_links.end(), robot_link) == target_links.end()) {
for (const auto& object_id : world_object_ids) {
acm.setEntry(object_id, robot_link->getName(), true);
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand, this PR wants to consider collisions of end-effector links with collision objects only, for the pre-check in isTargetPoseColliding(). I agree that unrelated group links (e.g. another arm) should be ignored because they will be ignored later as well.
However, collisions of links rigidly connected to the root link of the current group should be still considered, shouldn't they? That's what the code in lines 107-121 was doing. With your PR this code actually would become superfluous.

@gautz
Copy link

gautz commented Oct 22, 2021

@rhaschke @henningkayser My end-effector is randomly colliding with some remote environment link. This is not happening with a MoveTo stage. I am guessing the error comes from the issue explained here. Any plan to merge this? Or was it solve already elsewhere?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants