N8에서 zed2(학습분포)를 온라인 실행 기준 카메라로 확정했지만, 실제 벤치마크 데이터셋(~/sample/val_136__0)은 base-mounted L/R 토인 쌍 고정 카메라를 쓴다 — zed2와 다른 시점이다. 사용자 승인 질문: "벤치마크 데이터셋 카메라로 VLA 실행했을 때 잘 되는지 확인." 목표는 승패 판정이 아니라 하락 폭 측정 — 벤치 카메라 규약으로 실행형(Tier B/C) 평가를 돌리려면 벤치 카메라 데이터로 별도 FT한 VLA가 필요한지에 대한 정량 근거 확보.
bench_exo_L/bench_exo_R(RobotMountedCameraConfig, reference body robot_0/fr3_link0)를 컨트롤러 검증 파라미터로 정의해 FrankaOmniPurposeCameraSystem에 합성(교체 아닌 append — 기존 5개 카메라 유지). 서버측은 MolmoBot-Pi0 레포 무수정 원칙을 지키며 hydra.searchpath로 우리 레포의 카메라 yaml을 추가 검색 경로로 얹었다.
scripts/warmup_molmobot.py의 dummy-obs dict가 N8 시절 하드코딩이라 bench_exo_L 키가 없었고, 서버가 KeyError를 문자열로 회신했는데 워밍업 스크립트엔 molmobot_policy.py에 이미 있던 isinstance(response, str) 분기가 없어 msgpack_numpy.unpackb(str)이 즉시 TypeError로 죽으며 원인 문자열이 유실됐다. 두 가지 다 고쳐(obs 키 추가 + str 분기) bench 잡만 재제출.METADATA_OK {'cameras': {'bench_exo_L': 'observation/exterior_image_1_left', ...}} → WARMUP_OK 왕복 확인 — 모델이 실제로 bench_exo_L을 읽는다.좌: 우리 렌더(house 136 신규 샘플) / 우: 벤치마크 데이터셋 실제 프레임(val_136__0/exo_camera_1.mp4 frame 0). 씬 내용은 다르지만(신규 샘플 vs 저장된 episode) 검증 대상인 카메라 외부파라미터(뒤-위→전방-아래 구도, 문/창틀 위치)는 시각적으로 일치한다.
| house | skill | zed2 | steps | qpos_len | gt | bench | steps | qpos_len | gt |
|---|---|---|---|---|---|---|---|---|---|
| 136 | pick | OK | 568 | 20.53 | 36 | OK | 89 | 3.22 | 4 |
| 136 | pnp | FAIL | 600 | 16.87 | 14 | FAIL | 600 | 17.12 | 36 |
| 290 | pick | OK | 44 | 1.01 | 1 | FAIL | 600 | 8.15 | 12 |
| 290 | pnp | FAIL | 600 | 2.17 | 0 | FAIL | 600 | 6.12 | 2 |
| 375 | pick | OK | 126 | 3.62 | 9 | OK | 199 | 8.73 | 4 |
| 375 | pnp | OK | 307 | 8.98 | 10 | FAIL | 600 | 23.65 | 32 |
| 446 | pick | FAIL | 600 | 13.09 | 18 | FAIL | 600 | 1.03 | 0 |
| 446 | pnp | OK | 330 | 9.37 | 16 | FAIL | 600 | 4.44 | 0 |
| 640 | pick | FAIL | 600 | 1.66 | 0 | FAIL | 600 | 18.15 | 28 |
| 640 | pnp | OK | 164 | 5.61 | 2 | FAIL | 600 | 14.95 | 10 |
| 합계 | 6/10 | avg 8.29 | FAIL avg 8.0 | 2/10 | avg 10.56 | FAIL avg 15.0 | |||
qpos_len = qpos_path_len, gt = gripper_transitions. FAIL avg는 실패 행만 평균.
"Pick up the tomato and place it in or on the bowl" — steps=600(타임아웃), qpos_path_len=17.12, gripper_transitions=36, secs=391.3.
"Pick up the candle" — steps=600, qpos_path_len=1.03, gripper_transitions=0, secs=268.0. 같은 house의 pnp 행도 동일 candle 오브젝트로 gt=0 — 같은 씬에서 두 번 다 무반응.
"Pick up the cup" — steps=600, qpos_path_len=18.15, gripper_transitions=28, secs=280.1. 같은 house 640에서 zed2는 다른 오브젝트(mug)로 pick 실패했지만 그쪽은 gt=0(무반응)이었다 — 오브젝트가 달라 직접 통제 비교는 아니지만 bench 조건의 "적극적 실패" 경향을 보여준다.
part1-20k(zed2류 카메라로 FT)는 벤치마크 카메라 그대로는 신뢰할 만한 실행 평가 기반이 아니다. 이 -40pp(pnp -60pp) 하락 폭이 "벤치마크 카메라 규약으로 실행형(Tier B/C) 평가를 돌리려면 벤치 카메라 데이터로 FT한 VLA가 필요하다"는 가설의 정량적 근거다. 다만 정책이 완전히 죽는 게 아니라(모션 활력·그리퍼 관여는 오히려 zed2 실패군보다 높음) OOD 시점에서 조작 정밀도가 무너지는 형태 — "인식은 되는데 학습 안 된 기하에서 grasp을 못 맞춘다"는 서사가 지배적이다(예외 1건, h446 candle 무반응).
워밍업 스크립트의 하드코딩 dummy-obs 키 목록이 새 exo 카메라 추가 시마다 수동 갱신이 필요 — 서버 metadata의 cameras 키를 동적으로 읽어 구성하도록 리팩터링하면 이 실수 클래스가 원천 차단되지만 이번 범위 밖. h446 무반응(gt=0) 원인은 조명/오브젝트 크기 가설 수준, 추가 근거 없음.
벤치 카메라 FT VLA 필요성이 정량 확인됐으므로, 벤치 카메라 데이터로의 FT 계획 수립(팀 결정 필요) 또는 wrist 카메라까지 벤치 규약으로 맞춘 2차 라운드.