Enable lightwheel kitchen mesh placement - #972
Conversation
Greptile SummaryEnables mesh-based Lightwheel kitchen placement while preventing placement resources from interfering with configuration validation and simulator startup.
Confidence Score: 5/5The PR appears safe to merge, with no concrete changed-code defect identified. Mesh resources cleared after construction are recreated by later solver and validator paths, while reset events consistently unwrap the shared pool handle and use the pool's own object set. Important Files Changed
Sequence DiagramsequenceDiagram
participant Builder as Environment Builder
participant Pool as PooledObjectPlacer
participant Solver as Relation Solver
participant Event as Reset Event
Builder->>Pool: Construct placement pool
Pool->>Solver: Solve initial mesh-aware layouts
Solver-->>Pool: Ranked layouts
Builder->>Pool: Release mesh collision resources
Builder->>Event: Store opaque PlacementPoolHandle
Event->>Pool: Sample layouts on reset
alt Pool needs refill
Pool->>Solver: Solve additional layouts
Solver->>Solver: Lazily rebuild mesh resources
Solver-->>Pool: Additional ranked layouts
end
Pool-->>Event: Per-environment placements
Reviews (1): Last reviewed commit: "Add placement pool handle." | Re-trigger Greptile |
🤖 Isaac Lab-Arena Review BotSummaryThis PR enables MESH collision on the Lightwheel Robocasa kitchen, drops warp mesh caches after the construction solve so CUDA BVHs are not pinned through Kit startup/reset, and wraps the live placement pool in an opaque Design, Boundaries & ScopeOne non-blocking question (also inline): Findings🟡 The Test CoverageGood. VerdictShip it — clean, well-tested fix; the one design question is a follow-up, not a blocker. |
949ab01 to
cc40fa2
Compare
cc40fa2 to
7d3c7dc
Compare
Store the live placement pool behind an opaque handle in EventTermCfg params instead of the pool object. Mesh-mode placement builds Warp BVHs on the pool's solver; configclass deepcopy then fails with "ctypes objects containing pointers cannot be pickled". The handle shares one pool across deep-copies and keeps validation from recursing into cyclic asset graphs. Leaving those Warp mesh caches on the pool through Fabric startup also hides the Droid stand_instanceable in Kit viz (physics and placement stay correct). Use --disable_fabric for viewport runs until that is resolved; a 4-env / 2000-step benchmark showed no rollout cost from the flag (87.0 vs 86.5 ms/step). Drop the redundant assets event kwarg; layouts come from placement_pool.objects. Signed-off-by: Qian Lin <qianl@nvidia.com>
7d3c7dc to
69ddc99
Compare
Summary
Set lightwheel kitchen placement to mesh and fix crashes from placement pool
Detailed description
Known issue: With Fabric enabled, live Warp caches on the pool can hide the Droid stand_instanceable in Kit viz while physics stays correct; use --disable_fabric --device cpu for viewport runs (4 env / 2000-step benchmark: 87.0 vs 86.5 ms/step rollout, no meaningful difference). Alternative to fix this problem requires releasing the warp cache before passing into EventTermCfg. This slows down the first refill solve significantly (x2).