reward == 1.0 → robocasa 0.2.0은 task 완료 시에도 reward=0. _check_success() 써야 함.EnvUtils.reset_to(model+states+ep_meta) 필요.Pi0.5 B0 ckpt-010500 24-task simulator eval에서 SR=0/4가 나왔다. B1 (synthetic P2)도 동일하게 0/4. 문제가 (a) policy가 undertrained이기 때문인지 (b) eval pipeline bug인지 (c) sim-data 호환성 문제인지를 분리 진단해야 했다.
pi05의 eval pipeline은 DexMG wrapper (resfit/dexmg/environments/dexmg.py)가 robocasa 0.2.0을 감싸는 구조. 학습 데이터는 v0.1 HDF5 (minhopark 수집, pre-public robocasa).
dexmg.py:477에서 success = reward == 1.0을 사용. 그런데 robocasa 0.2.0의 env.reward()는 task 완료 시에도 sparse reward 분기에서 0을 반환함 → success가 영영 fire 안 됨.
pi05 env가 robot-data-gen/libs/robocasa (subtree, robocasa 0.2.0 master)를 사용하는데, subtree의 models/assets/ 안에 objects/, textures/ 디렉토리 자체가 없고 fixtures/도 XML만 있음(571KB vs 원본 1GB). → sample_kitchen_object 호출 시 빈 distribution → Probabilities contain NaN.
kitchen_doors.py:67의 _check_success: 모든 door joint <= 0.05. 그런데 GT actions으로 replay해도 left_door가 0.105까지밖에 안 닫힘 (right=-0.000). 영상에서는 닫혀 보이나 strict criterion 통과 불가.
DexMG random reset은 doors 0.94 (fully open)으로 초기화. heldout 분포와 매칭은 되나, set_state(states[0])를 단순히 박는 방식은 broken: HDF5 state 154-dim vs current env state 153-dim → 부분 적용으로 doors=0 (이미 닫힘) 같은 false positive 발생.
올바른 방법은 dataset_states_to_obs_v1.py가 사용하는 EnvUtils.create_env_for_data_processing wrapper의 reset_to:
robocasa_legacy (robosuite 1.4.5 + robocasa 1.4.1 public release be5d99c, 2024-05-29)로 reset_to 시도 → 1/10 성공, 9 demos에서 joint cab_1_left_group_rightdoorhinge not found. HDF5 XML의 cab_1_* vs public release env의 cab_main_* 이름 불일치. pre-public 코드가 어디에도 없어 v0.1 native eval은 영구 불가능.
| Demo | init_max (door) | final_max | Strict (0.05) | Relaxed (0.15) |
|---|---|---|---|---|
| demo_0 | 0.938 | -0.000 | ✓ | ✓ |
| demo_1 | 0.978 | -0.000 | ✓ | ✓ |
| demo_2 | 0.962 | 0.082 | ✗ | ✓ |
| demo_3 | 0.930 | 0.053 | ✗ | ✓ |
| demo_4 | 0.988 | -0.000 | ✓ | ✓ |
| demo_5 | 0.931 | -0.000 | ✓ | ✓ |
| demo_6 | 0.955 | -0.000 | ✓ | ✓ |
| demo_7 | 0.990 | 0.122 | ✗ | ✓ |
| demo_8 | 0.949 | -0.000 | ✓ | ✓ |
| demo_9 | 0.995 | 0.007 | ✓ | ✓ |
| Total | 7/10 (70%) | 10/10 (100%) |
| Demo | GT replay final | EEF drift | 원인 |
|---|---|---|---|
| demo_0 | −0.012 ✓ | 0.008m | perfect |
| demo_2 | 0.082 ✗ | 0.056m | v0.1 demo 자체가 threshold 근처 |
| demo_7 | 0.122 ✗ | 0.477m (47cm!) | controller drift chaotic 누적 |
| 조건 | SR (4-ep) |
|---|---|
| Fix 전 (DexMG wrapper, pi05 B0 ckpt-010500) | 0/4 |
| Bug 1 fix (reward → _check_success) + Bug 2 fix (assets symlink), random init | 0/4 |
| + Bug 3 fix (threshold relax 0.15), random init | 0/4 |
| GT actions + Bug 4 fix (EnvUtils reset_to) + relaxed | 10/10 ⭐ (이론 상한) |
0% SR의 원인이 policy 부족이 아니라 eval pipeline의 4중 bug임이 확인됐다. 진행 중인 B0/B1/B2 학습은 그대로 두고 eval pipeline 수정으로 진짜 학습 quality 측정 가능.
v0.1 native eval은 pre-public robocasa commit이 유실되어 영구 불가능. EnvUtils.reset_to (v02-preprocessing 방식) + 0.15 threshold가 현재 가질 수 있는 최선. 영상으로 닫혀 보이는 borderline case는 인정하는 것이 합리적.
controller drift (30% strict fail)와 threshold calibration 문제의 근본 해결은 DAVIAN-Robotics/robocasa-MG_30 또는 fresh demo 생성(0.2.0으로)으로 학습+eval 통일. 현재 pipeline은 v0.1↔0.2.0 mismatch를 workaround하는 구조.
EnvUtils.create_env_for_data_processing 기반 새 eval 스크립트 완성. HDF5 demo 선택 + reset_to + policy + relaxed success 조합. B0 ckpt-010500으로 8 ep 돌려 진짜 SR 측정 (이론 상한 70~100% 사이 어디인지). 작동하면 eval_lora_finetuning_bc_pi05_hydra_ga.py + dexmg.py에 통합.
CloseDoubleDoor(0.15)만 검증됨. OpenDoubleDoor, CloseSingleDoor, Drawer, Microwave, Sink 등 나머지 task도 GT replay 후 final_max 분포 측정 → 95th percentile 기반 데이터 driven threshold 설정.
controller drift 0%, threshold issue 0%의 native eval 환경. DAVIAN-Robotics/robocasa-MG_30 사용 또는 0.2.0으로 fresh demo 생성 후 pi05 재학습. 현재 v0.1 기반 heldout 720 ep의 근본 한계 해소.