Joint Dependent Mesh/BBox for Embodiment - #968

Greptile Summary

This PR introduces joint-dependent placement geometry and reusable collision-mesh artifacts.

• Poses embodiment bounding boxes and collision meshes from configured articulation joints.
• Adds persistent local and published mesh loading, validation, eviction, and export tooling.
• Adds per-embodiment robot-library folders, USD articulation kinematics, visualization helpers, and extensive simulation tests.

Confidence Score: 3/5

The PR should not merge until Franka and Droid placement geometry honors constructor-supplied initial joint poses; source-aware cache invalidation should also be strengthened.

Franka and Droid can reset into a constructor-selected arm pose while their newly introduced bounding box and collision mesh are computed from a different joint mapping, causing incorrect placement geometry on a supported path.

Files Needing Attention: isaaclab_arena/embodiments/embodiment_base.py, isaaclab_arena/embodiments/franka/franka.py, isaaclab_arena/embodiments/droid/droid.py, isaaclab_arena/utils/collision_mesh_store.py

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Config[Embodiment scene config] --> Source[PlacementGeometrySource]
  Source --> Pose[USD articulation posing]
  Pose --> BBox[Posed bounding box]
  Pose --> Extract[Mesh extraction]
  Source --> Store{Stored artifact valid?}
  Store -->|yes| Mesh[Scaled collision mesh]
  Store -->|no| Extract
  Extract --> Cache[Local/published mesh store]
  Cache --> Mesh
  BBox --> Placement[Relation placement]
  Mesh --> Placement

_{Reviews (1): Last reviewed commit: "add joint support for robots" | Re-trigger Greptile}

🤖 Isaac Lab-Arena Review Bot

Summary

This PR makes an embodiment's placement bounding box and collision mesh reflect the robot as actually spawned — posed at its configured init_state.joint_pos via offline USD forward kinematics — instead of the arbitrary joint configuration the asset was authored in. That is a real correctness improvement for relation-based placement, and it is backed by an unusually strong test suite (PhysX ground-truth link-pose comparison, closed-loop articulations, instanced geometry, prismatic/revolute cases, LRU eviction, and stale/foreign-artifact rejection). The FK and geometry code is careful and well-documented.

Design, Boundaries & Scope

My one real question is scope, raised inline on collision_mesh_store.py: the change ships a two-tier persistence layer — a 1 GiB on-disk LRU cache plus a Nucleus-published robot library with an export/upload pipeline. The in-process lru_cache on the posed-geometry helpers already covers the relation-solver hot path within a run, so the disk + Nucleus layer only saves the one-time 0.1–2.5 s extraction per fresh process. Against that it adds ongoing maintenance (re-export on every USD/joint change), a Nucleus dependency in the placement path, and a cache that grows in every user's ~/.cache on the default path. Worth confirming that cross-process cost actually bites before taking on the exported-library machinery; the in-process cache (plus perhaps a plain local disk cache) may deliver most of the value for far less surface.

Boundaries otherwise hold: the new FK/store code is generic USD/IO utility, no robot-specific logic leaks into core, and the embodiment geometry methods stay pure (no live env).

Findings

🟡 collision_mesh_store.py — question whether the published-library + disk-LRU persistence needs to ship now, or could be deferred behind the in-process cache (inline).

Test Coverage

Excellent. New tests follow the inner/outer run_simulation_app_function pattern with deferred sim imports and land in Phase 1 (in-process persistent app, no cameras/subprocess), matching the existing sibling test. Coverage spans unit FK, real-Droid geometry, PhysX agreement, and the full store lifecycle including negative cases. No gaps worth calling out.

Verdict

Minor fixes needed — essentially ship-ready; please just weigh in on the persistence-layer scope question before merge.