Adds a rigid body collection class

[Dhoeller19]

Description

Adds a rigid body collection class, which allows to spawn multiple objects in each environment and access/modify the quantities with a unified (env_ids, object_ids) API.

Type of change

• New feature (non-breaking change which adds functionality)

Checklist

• I have run the pre-commit checks with ./isaaclab.sh --format
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• I have updated the changelog and the corresponding version in the extension's config/extension.toml file
• I have added my name to the CONTRIBUTORS.md or my name already exists there

[jtigue-bdai]

Do we want to use the same convention as RigidObjects for these properties i.e. body_? Or do we want to change RigidObjects to reflect this convention? What are your thoughts?

[Dhoeller19]

This is a question I have been thinking a lot about when designing this.

The core difference between rigid objects, and object collections is that object collections can have rigid bodies that contain the same prim structure (for example when two rigid bodies come from the same USD). That is why something like body_names would not work in general as there would be duplicates in that case. To mark that subtle but important difference, I have introduced the concept of object_names which refer to the keys of the dict you create the config with (see code). This allows you to uniquely identify each rigid object in the collection and do proper indexing later on.

I thought to be consistent with that, I would rename all the occurrences of body with object.

But I am open for debate :)

[jtigue-bdai]

Ah OK I see what you mean. I think that is reasonable.

[Dhoeller19]

Let's see what @Mayankm96 / @kellyguo11 say

[kellyguo11]

I think the distinction makes sense, maybe we just need to make the use cases of these classes clear in the docs so users understand the differences between the classes.

[PerFrivik]

Awesome, literally what we needed. Will test it, thank you!

[pascal-roth]

this code will break if we don't have the exact same number of rigid objects as the defined num_envs of our interactive scene. Would recommend that we remove them

[Dhoeller19]

Where should we put them though?

[pascal-roth]

I am not sure if we can. As env_ids assumes that we have num_envs instances but that may not be the case, we might have to leave that reset to the user?

[Dhoeller19]

This argument also holds for Articulations and RigidObjects thought

[pascal-roth]

true that, but wasn't the idea that with the collection, we allow exactly an option that does not have to be repeated num_envs times?

[pascal-roth]

Is there a reason why there is a change in the naming convention? For the regular RigidObject and Articulation, we use root as an indicator (e.g., root_pos_w), and now all of this has been renamed to object (e.g., object_pos_w).

[Dhoeller19]

Is there a reason why there is a change in the naming convention? For the regular RigidObject and Articulation, we use root as an indicator (e.g., root_pos_w), and now all of this has been renamed to object (e.g., object_pos_w).

This is explained in the comment above

[jtigue-bdai]

This goes for both class and data files. Do we plan on implementing this before or after the root_link_state/root_com_state change? At some point it would be good to implement the velocity transformation here as well.