isaac-sim
Adds option to search for RigidBodyAPI on all matching prim paths
Description
When defining RigidObject instances with regex that encapsulates heterogeneous objects, the objects may not always have the RigidBodyAPI schema attached to the same prim path in the object hierarchy. Currently, we make this assumption such that we only search for the location of the RigidBodyAPI schema on the first matching prim path of the regex. However, when the assumption doesn't hold on objects that have different topologies, the RigidObject instance is not able to find all objects in the scene that match the regex.
This change introduces a new option in the RigidObjectCfg that allows for parsing of all matching prim paths instead of just the first matching path. This will incur performance costs when parsing large stages, so it is recommended to only use this option when necessary, when it is desired to have a RigidObject that encapsulates a collection of varying objects where the RigidBodyAPI schema is attached to different locations.
Type of change
- New feature (non-breaking change which adds functionality)
Checklist
- [x] I have run the
pre-commitchecks with./isaaclab.sh --format - [x] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective or that my feature works
- [x] I have updated the changelog and the corresponding version in the extension's
config/extension.tomlfile - [ ] I have added my name to the
CONTRIBUTORS.mdor my name already exists there
Doesn't this affect the shape of the tensors? We always expect one rigid body per environment so all the tensors have shape (num_envs, ...). Now if you are allowing multiple prims to be captured, wouldn't the shape become (num_envs * num_rigid_body_per_env, ...)? This seems rather not the right way in that case.
Doesn't this affect the shape of the tensors? We always expect one rigid body per environment so all the tensors have shape (num_envs, ...). Now if you are allowing multiple prims to be captured, wouldn't the shape become (num_envs * num_rigid_body_per_env, ...)? This seems rather not the right way in that case.
hmm ya this could happen if the regex encapsulates multiple objects in an environment. If we want to keep it to a single body per env, I guess we can use the same logic to get the first template path and traverse each tree from there to find the RigidBodyAPI.