Determining Geom A vs Geom B when using RigidEntity.get_contacts()

[EZ-Blue]

Hello, I have a quick question about how the order of the contact pairs in determined in .get_contacts( ). Specifically, what determines which entity / geometry is geom_a and which is geom_b?

For example, in my case I want to be able to determine in simulation when an object exerts a force downward on a robot arm. So I tested using .get_contacts() on both the object entity and the robot entity, but the return result always has the object as geom_a and the robot as geom_b.

Even when I changed the order of the entities when adding them to the scene (robot first vs object first), the object is still always designated as geom_a in .get_contacts().

I assumed geom_a vs geom_b would be determined by the order of the geometry ids in the global entity and geom buffers, but now I am no longer sure. Does anyone have some insight into this?

[jgillick]

I don't know if there's a hard rule about which appears as A or B. It might be the directionality of the force. Generally, though, I think it's best to explicitly match the forces to the link IDs returned. The other thing to realize is that often there will be multiple contact forces reported for each A/B link pair.

A framework I created, Genesis Forge, has a contact sensor that lets you filter the Genesis contact forces to entities/links:
https://genesis-forge.readthedocs.io/en/latest/guide/managers/contact.html

You can see how it does it, here:
https://github.com/jgillick/genesis-forge/blob/main/genesis_forge/managers/contact/contact_manager.py

In your case, you'd want to know about any collision between anything and the robot arm. In Genesis Forge, it might look like this

self.contact_manager = ContactManager(
    self,
    entity_attr="robot",
    sensor_links=["arm"],
)

Without Genesis Forge, you would grab the contact forces and link IDs and then loop over the values (or create complex tensor masks) to filter out matching forces. This can be very slow to do manually in a vectorized environment, but you can create a gstaichi function to do it much faster. You can see the gstaichi function used for Genesis Forge, here.

[duburcqa]

I don’t think using a kernel should be necessary anymore now that zero-copy has been implemented. It may even be slower now if torch-based implementation is fully vectorized without any GPU sync, and accelerated via torch.jit.script.

[jgillick]

@duburcqa good point. I've been away from this for a month or so, and need to brush up on the updates. Now that zero-copy has been implemented, I can probably update the contact manager in my library with this.