what does enabled_self_collisions do?

[kbkartik]

newbie to the sim2real world. In cartpole config, enabled_self_collisions is set to False whereas shadow hand config has set it to True. how does this parameter affects a robot's dynamic behavior?

[StrainFlow]

If this parameter is off, all collisions of all pieces of the articulation are ignored.

If this parameter is on, parts that are connected at a joint ignore collisions but parts that are more separated will collide.

So, the cartpole only has the two parts connected by a single joint so this parameter won't effect anything either way.

The shadow hand is a little more involved, I've read that it is based off of the MuJoCo shadow hand asset which has specific collision pairs. I'll take a look at how that's set up and add more detail, but I hope this answer is a good start.

have you gone through the Isaac Lab tutorials?

[StrainFlow]

I'm sorry I wasn't clear, it's all a bit confusing!

enabled_self_collisions ignores adjacent link collisions. This is the current, expected behavior but is going to be changed in a future release.

To find the inconsistent behavior I loaded the shadow hand and ran a quick, simulation. In that simulation collisions were not working correctly between non-adjacent links. I've helped the engineering team reproduce these issues and we are looking into those as a bug.

So, in summary, if enabled_self_collisions is true, non-adjacent links should collide and adjacent links should not collide.

The way to filter collisions in Isaac Sim is with collision groups. I'll do a few tests to see if these work with Articulations and in Isaac Lab.

[StrainFlow]

Here's a quick video that hopefully clarifies how some of this works:

2024-11-21.09-08-50.mp4

here's the link to that sample articulation in onshape: https://cad.onshape.com/documents/fe1b791d94752587aaa1333a/w/a69fd08b3e95651376141135/e/78dfb913c41e3e9d74ca8a40?renderMode=0&uiState=673f5cf45180b26366e6368a

[StrainFlow]

And here's a quick video demonstrating the expected vs unexpected behavior on the shadow hand:

2024-11-21.09-19-41.mp4

[kbkartik]

enabled_self_collision_analysis.mp4

Many Thanks for your prompt reply! Sorry I am late in mine.

And here's a quick video demonstrating the expected vs unexpected behavior on the shadow hand:
2024-11-21.09-19-41.mp4

I will first address the issue regarding the unexpected behavior of the Shadow Hand. My simulation results yield the opposite outcome of what was shown in your video. To demonstrate this, I have followed these steps:

1. I used the existing run_articulation.py script from IsaacLab.

2. I imported the Shadow Hand's configuration file and made the following changes:

   • Set rot=(0.0, 0.0, 0.0, 0.0) for easier visualization.
   • Toggled enabled_self_collisions between True and False to observe the collision behavior under both conditions.

3. I set the target joint positions for all joints in the middle finger and thumb to a very large value (e.g., 150 degrees). Isaac Sim should, by default, restrict the steady-state joint angles to stay within joint limits.

   Additionally, if collisions are being respected, the steady-state joint angles should remain within the joint limits.

4. I ran the simulation, and you can find the script I used here: run_articulation_shadow_hand.py.

Upon simulating and examining the results closely (see the video above), I observed that collisions between non-adjacent links occur regardless of the enabled_self_collisions flag's value. This raises the question: What exactly does enabled_self_collisions do? The simulation rendering is a bit fast, and I'm unsure how to slow it down. If you know how to adjust the speed in a Python script, please let me know.

In essence, I believe the issue with non-adjacent links penetrating each other is related to the Isaac Sim UI. Additionally, the behavior of the enabled_self_collisions flag in IsaacLab seems unusual, and I'm uncertain how to interpret it. I’d appreciate your thoughts on this.

On a related note, the Shadow Hand's config file comments out CollisionPropertiesCfg. Are these properties related to collisions with external rigid bodies, like a ball or a cube? Or are they primarily for self-collisions within an articulation?

Here's a quick video that hopefully clarifies how some of this works:
2024-11-21.09-08-50.mp4

here's the link to that sample articulation in onshape: https://cad.onshape.com/documents/fe1b791d94752587aaa1333a/w/a69fd08b3e95651376141135/e/78dfb913c41e3e9d74ca8a40?renderMode=0&uiState=673f5cf45180b26366e6368a

Given the discrepancies with enabled_self_collisions, I’m unsure how to interpret the first demo you showed. In that video, when enabled_self_collisions was set to True, the top link collides with the base and penetrates the middle link. This suggests that enabled_self_collisions is functioning as expected. However, in the Shadow Hand example, enabled_self_collisions did not behave as anticipated.

I'm sorry I wasn't clear, it's all a bit confusing!

enabled_self_collisions ignores adjacent link collisions. This is the current, expected behavior but is going to be changed in a future release.

To find the inconsistent behavior I loaded the shadow hand and ran a quick, simulation. In that simulation collisions were not working correctly between non-adjacent links. I've helped the engineering team reproduce these issues and we are looking into those as a bug.

So, in summary, if enabled_self_collisions is true, non-adjacent links should collide and adjacent links should not collide.

The way to filter collisions in Isaac Sim is with collision groups. I'll do a few tests to see if these work with Articulations and in Isaac Lab.

Regarding terminology related to collisions (e.g., including or excluding collision groups), I believe we should simplify the approach by using just two variables: enabled_self_collisions and collision_filter_map. If enabled_self_collisions is set to True, all links should collide. The collision_filter_map can be used to disable specific collisions. If enabled_self_collisions is set to False, no collisions should occur, and the collision_filter_map can enable specific collisions.

For defining collision_filter_map between links, the strategy should be to set the map in a way that respects the mechanics of the real-world robotic hand. For example, consider a modified Shadow Hand where three thumb links are coupled together. In this case, when simulating the hand, we would disable collisions specifically between these links to ensure they behave according to the real-world mechanics of the hand. We can define this functionality similar to how we setup contact sensor:

The reporting of the filtered contact forces is only possible as one-to-many. This means that only one sensor body in an environment can be filtered against multiple bodies in that environment. If you need to filter multiple sensor bodies against multiple bodies, you need to create separate sensors for each sensor body.

As an example, suppose you want to report the contact forces for all the feet of a robot against an object exclusively. In that case, setting the ContactSensorCfg.prim_path and ContactSensorCfg.filter_prim_paths_expr with {ENV_REGEX_NS}/Robot/.*_FOOT and {ENV_REGEX_NS}/Object respectively will not work. Instead, you need to create a separate sensor for each foot and filter it against the object.

I hope this example makes sense, but the TL;DR is that an user can simulate the real-world behavior of the robotic hand using a simple variable like collision_filter_map.

Lastly, could you clarify the role of the articulation_enabled parameter?

Let me know your thoughts!

[kbkartik]

@StrainFlow rechecking with you if my analysis is correct/incorrect.

[StrainFlow]

It seems like that enabled_self_collisions parameter might behave differently in the Isaac Sim environment and the Isaac Lab environment. I like your dictionary idea for something with a small number of colliders like we see in robotics, but it's important to keep in mind that the same scene authoring tools are used in entirely different disciplines like media and entertainment that might work with very large numbers of colliders. Regardless, I agree with your conclusion that the collider filtering UI could be more clear and easy to set up.

One possibility is that somehow the enabled_self_collisions flag you are setting is being overidden at some other point in your environment setup. It might be a good idea to print that flag in your logs to debug it at runtime and see if it has the value you expect.

As far as the articulation_enabled goes, that should toggle the physics model betweeen a low-fidelity joint solver and a high-fidelity joint solver where an articulation is the high-fidelity solver.