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

Unable to allow collisions between a link and a collision object if their name share the same prefix #646

Closed
DaniGarciaLopez opened this issue Jan 27, 2025 · 2 comments

Comments

@DaniGarciaLopez
Copy link
Contributor

I have a link with a collision geometry defined in the URDF named holder and a collision object named tool, which spawns inside the collision geometry at the start of the task (allowing their collision using a ModifyPlanningScene stage). Then, I pick up the tool object, disallow the collision between tool and holder, and later place it back, allowing their collision again in the ComputeIK stage (passing a monitored stage with the ACM modified, as explained here). This works as expected, and I can correctly place the tool inside the collision geometry.

However, if I rename the link to tool_holder, the task fails in the ComputeIK stage. On the other hand, if the word "tool" appears at the end of the name (e.g., holder_tool), it works correctly. It seems there is an issue when allowing or disallowing collisions between a pair of objects that share the same prefix in their names (tool and tool_holder).

I’m not sure if this is a moveit or MTC issue, I couldn't find the root cause of it. I'm using ROS2 Jazzy with the latest commits from the moveit2 main branch and moveit_task_constructor ros2 branch.

Does anyone have an idea why this could be happening? Otherwise, I’ll try to prepare a small example in the next few days to reproduce the issue.

Thanks!

@rhaschke
Copy link
Contributor

I'm not aware that name matching uses a prefix only. Please provide a minimal example. Thanks.

@DaniGarciaLopez
Copy link
Contributor Author

Looking deeper into the problem, we realized that it was actually on our end. No issue here. Thanks anyway!

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

No branches or pull requests

2 participants