Future work for improving MoveIt's collision detection

[j-petit]

As part of wrapping up my GSoC (see #1427), I identified several aspects of the collision detection process which could be topics for future work. This is open to discussion.

The ACM as part of the collision environment

The Allowed Collision Matrix (ACM) (which specifies which objects are allowed to collide) is currently given as an input to each collision check. Instead, I propose directly integrating it into the collision environment. This possibly gives performance improvements as collision pairs are persistently disabled even before broadphase checking and no string comparisons have to be done during collision checking. Furthermore, it keeps the collision environment consistent as this is the place to modify any collision checking behavior. I think in most use cases the ACM stays the same between two checks and therefore it makes sense to keep this information persistent in the collision manager. The ACM should only be modified through the collision environment so the internal collision manager is able to update its broadphase structure with disabled/enabled collisions and can keep those changes persistent.

Refactoring existing collision environment

While unifying the collision environment in #1584, I simply combined the existing collision detectors in new classes (collision_env_fcl, collision_env_hybrid, collision_env_signed_distance, collision_env_all_valid). Therefore, I didn't implement any possible improvements to the code in terms of clarity as well as performance in certain scenarios which might be possible.

The FCL collision environment is the most promising candidate I think as it is the default collision detector in MoveIt.

Adding continuous self-collision checks

Currently with Bullet, CCD is only possible for robot-world collision checks. However, continuous self-collision checks are useful too and can be built upon the already available CCD Bullet code.

Removing the distinction between distance request and collision requests

In MoveIt, there exists a distinction between a distance request and collision request although they use the same underlying code and share many similarities. This leads to a lot of duplicate code.

I think it makes sense to have only a single request and see a distance vs a collision as the same thing except that one has a negative distance. This would greatly simplify some code as well as the collision environment interface.

Extending Bullet collision capabilities

There are many Bullet capabilities which are not utilized yet in. To name a few:

• use GPU for collision detection
• use bullets margin instead of padding
• convex-to-convex speedups through tag in URDF (see this discussion)
• turn off distance computing when only binary yes/no collision is required (I didn't find this option in Bullet yet)
• multi-threading with Bullet

Extensive benchmarking of Bullet

For further speed improvements, it is important to identify the bottlenecks when using Bullet as a collision detector. I have written a benchmark script which could be extended with more scenarios to get a more profound understanding of the runtime behavior.

See the project board for some more ideas.

[felixvd]

Thanks for the write-up! Great work.

I think it makes sense to have only a single request and see a distance vs a collision as the same thing except that one has a negative distance. This would greatly simplify some code as well as the collision environment interface.

Is it possible to write collisionRequest as a wrapper that just checks if distanceRequest returns a negative distance?

I propose directly integrating [the ACM] into the collision environment.

That makes a lot of sense. I wasn't aware that it's not done this way already, but with a split robot and world I can see why it was not.

convex-to-convex speedups through tag in URDF

Just noting the link to the previous discussion about this.

[j-petit]

Is it possible to write collisionRequest as a wrapper that just checks if distanceRequest returns a negative distance?

In general yes, however this would degrade the performance of FCL as it can do collision checking without computing any distances. For Bullet, I haven't yet found a way to turn the distance computation off.

[v4hn]

For future reference:

The bullet plugin currently does not implement distance requests through the existing API.

[AndyZe]

I've come around to believing we should remove DistanceRequest from the MoveIt API, as @j-petit suggested. You can get the distance information from a CollisionRequest so DistanceRequest seems redundant.

Plus now there's the added confusion that DistanceRequest doesn't make any sense for Bullet.