Procedural cube fallback vs. dex_cube asset-fidelity mismatch blocks GoalPose OOD generalization

[shaoxiang]

|---|---:|---:|---:|---:|---:|
| procedural_cube_ood | baseline_v3 | 1.0 | 0.0 | 0.0 | -2496.85 | 0.0 |
| procedural_cube_dex_size | baseline_v3 | 1.0 | 0.0 | 0.0 | -2496.85 | 0.0 |
| procedural_cube_large | baseline_v3 | 1.0 | 0.0 | 0.0 | -2496.85 | 0.0 |
| procedural_cube_ood | object_geometry_adapter_structural | 1.0 | 0.0 | 0.0 | -2496.85 | 0.0 |
| procedural_cube_dex_size | object_geometry_adapter_structural | 1.0 | 0.0 | 0.0 | -2496.85 | 0.0 |
| procedural_cube_large | object_geometry_adapter_structural | 1.0 | 0.0 | 0.0 | -2496.85 | 0.0 |

• lifted_rate = 0.0 and env_success_rate = 0.0 for every cell.
• object_height_delta ≈ -2496 m indicates the object sometimes falls through the floor.
• descend_exit_rate = 0.0 means the failure happens before the policy even enters GRASP.
• Adding structural hints (enable_regrasp, CONTACT_VERIFY, LIFT_VERIFY) does not help because those phases are downstream of DESCEND.

What we have already checked

1. Asset resolution detects the substitution: the requested procedural cube loads with scene key "object", triggering fallback_reason=loaded_object_instead_of_procedural_cube.
2. ObjectGeometryAdapter scales grasp tolerances / approach offsets / lift height to the loaded object geometry. It does not regress official dex_cube but also does not enable procedural lift.
3. Contact-proxy diagnosis is empty because DESCEND never exits, so there is no grasp phase to diagnose.
4. Size is not the root cause: dex_size (same 0.05 m as dex_cube), large, and ood variants all fail identically.

Questions for the Arena team

1. Is the procedural cube fallback intended to be physically equivalent to dex_cube? If not, what is the recommended way to register a deterministic OOD cube variant for controlled generalization experiments?
2. What are the official dex_cube size, mass, inertia, and friction parameters? We want to create a procedural variant that matches them exactly.
3. Why does the procedural cube spawn with scene key "object" instead of "procedural_cube"? Can the key be made deterministic?
4. Why does the object sometimes fall through the floor (object_height_delta ≈ -2496 m) after the policy run completes / resets?
5. Is the initial object pose / table height different between dex_cube and the procedural fallback? The policy descends to the same absolute z, so a small spawn-height mismatch would explain the DESCEND gate failure.
6. Is there an official working baseline for cube_goal_pose with a non-dex_cube object (e.g. a procedural variant)?
7. If we want to contribute a proper procedural-cube asset to IsaacLab-Arena, what is the preferred asset registration path?