generateCollisionTable does not detect "Always in collision" pairs with min_collision_faction 1.0 or if using CLI and ignoring "Default in collision"

[nbbrooks]

Description

I have a URDF where links with collision links are added to approximate where cable pinches could occur. Specifically, this is for a UR and a method for addressing UniversalRobots/Universal_Robots_ROS2_Driver#611, where the UR controller itself will halt your robot if it moves into a configuration where a common cable pinch could occur (regardless of if you have cables, but I digress).

I had a SRDF that was mostly right for this robot and had swapped out the end effector, so I thought I would save myself some time and use the collisions_updater CLI. I encountered 2 problems

Problem 1

The default behavior of the CLI is not obvious. I should have tested/looked if there was a --help command earlier, but I was surprised that, by default, "Default in collision" and "Always in collision" pairs are ignored. I can understand why Default collisions are ignored by default, and see why we would would to be extra safe with "Always in case they reduced the default min collision fraction (100%) and used a low number of trials. However, I suggest that in the summary output, where it prints the detected number in always/never/default/adjacent - we should instead tell the user those are being ignored due to settings (and maybe print what was detected).

Problem 2

Once I realized this was happening, I added the --always flag and still wasn't getting the output I expected. This is because:

• The min_collision_faction check is incorrect, it should be >=, not >. With min_collision_faction set to the default 1.0, we must see collisions happen in more trials than we ran, so it will never detect any. This is also going to be a problem if you run MSA with 1.0.
• disableDefaultCollisions is always run, even if you use the default behavior which does not add them to the SRDF. The problem with this is by running it, we tell the planning scene to ignore that collision pair going forward, so it then isn't picked up by the "Always in collision" check. We should not set the scene's ACM entry if we are not including it in the SRDF output (disableAlwaysInCollision needs to be corrected as well). I think this issue is unique to the CLI's method of optionally "ignoring" Default/Always pairs, but I would have to look at the widget code more closely to be sure.

Your environment

• ROS Distro: Humble
• OS Version: e.g. Ubuntu 22.04
• Source or Binary build? Source
• If source, which branch? main 865b006
• Which RMW (Fast DDS or Cyclone DDS)? Cyclone.

Steps to reproduce

1. Create a URDF with overlapping, but not adjacent links, and run
2. For Problem 1 run

ros2 run moveit_setup_assistant collisions_updater --urdf <PATH_TO_URDF> --srdf <PATH_TO_OLD_SRDF> --output out.srdf --trials 100000 --verbose

3. For Problem 2 run

ros2 run moveit_setup_assistant collisions_updater --urdf <PATH_TO_URDF> --srdf <PATH_TO_OLD_SRDF> --output out.srdf --trials 100000 --verbose --always

Actual behaviour

For Problem 1, the generated SRDF will not have any Default/Always in collision entries and no hint about why the reported ones in the CLI summary are not in the SRDF

For Problem 2, no Always in collision entries will be detected, when there should be.

[github-actions]

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.