Index
2026-08-18 — Experiment (Task N10)

벤치마크 카메라(bench_exo_L) vs zed2 — 실행형 VLA A/B

scene_bench | part1-20k, houses {136,290,375,446,640} × {pick, pick_and_place}

TL;DR

2/10
bench SR
6/10
zed2 SR
-40pp
전체 하락
0/5
bench pnp (전멸)
75%
적극적 실패 비율

1 배경 / 목적

N8에서 zed2(학습분포)를 온라인 실행 기준 카메라로 확정했지만, 실제 벤치마크 데이터셋(~/sample/val_136__0)은 base-mounted L/R 토인 쌍 고정 카메라를 쓴다 — zed2와 다른 시점이다. 사용자 승인 질문: "벤치마크 데이터셋 카메라로 VLA 실행했을 때 잘 되는지 확인." 목표는 승패 판정이 아니라 하락 폭 측정 — 벤치 카메라 규약으로 실행형(Tier B/C) 평가를 돌리려면 벤치 카메라 데이터로 별도 FT한 VLA가 필요한지에 대한 정량 근거 확보.

가설: OOD 카메라 시점이라 SR이 하락할 것이다. 측정 목적: 하락 폭이 "FT 필요"를 정당화할 만큼 큰지.

2 작업 내용

bench_exo_L/bench_exo_R(RobotMountedCameraConfig, reference body robot_0/fr3_link0)를 컨트롤러 검증 파라미터로 정의해 FrankaOmniPurposeCameraSystem에 합성(교체 아닌 append — 기존 5개 카메라 유지). 서버측은 MolmoBot-Pi0 레포 무수정 원칙을 지키며 hydra.searchpath로 우리 레포의 카메라 yaml을 추가 검색 경로로 얹었다.

src/sbench_online/exp_matrix.py:38-63 — BENCH_EXO_L_PARAMS/BENCH_EXO_R_PARAMS camera_offset=[-0.40, 0.24, 0.965], camera_quaternion=[0.5375,0.2858,-0.3725,-0.7005] (L) reference_body_names=["robot_0/fr3_link0"], fov=70.0, 노이즈 없음(고정 포즈) make_bench_camera_system(): FrankaOmniPurposeCameraSystem().add_camera(bench_exo_L/R) scripts/serve_molmobot.sh: hydra.searchpath=[file://.../config/molmobot_cameras] 로 MolmoBot-Pi0 무수정 cameras=bench 주입
발견한 크래시: 1차 제출(85102)이 워밍업 단계에서 6:33 만에 사망. 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 잡만 재제출.
서버 obs 키 검증(N8 함정 재확인): METADATA_OK {'cameras': {'bench_exo_L': 'observation/exterior_image_1_left', ...}} → WARMUP_OK 왕복 확인 — 모델이 실제로 bench_exo_L을 읽는다.

3 결과 — bench_exo_L 실물 프레임 검증

좌: 우리 렌더(house 136 신규 샘플) / 우: 벤치마크 데이터셋 실제 프레임(val_136__0/exo_camera_1.mp4 frame 0). 씬 내용은 다르지만(신규 샘플 vs 저장된 episode) 검증 대상인 카메라 외부파라미터(뒤-위→전방-아래 구도, 문/창틀 위치)는 시각적으로 일치한다.

bench_exo_L 렌더 vs 벤치마크 데이터셋 프레임 비교
Figure 1: bench_exo_L 렌더(좌) vs 벤치마크 데이터셋 실제 프레임(우) — 카메라 배선 정확성 확인

4 SR / qpos 표 (house × skill × 카메라)

houseskillzed2stepsqpos_lengtbenchstepsqpos_lengt
136pickOK56820.5336OK893.224
136pnpFAIL60016.8714FAIL60017.1236
290pickOK441.011FAIL6008.1512
290pnpFAIL6002.170FAIL6006.122
375pickOK1263.629OK1998.734
375pnpOK3078.9810FAIL60023.6532
446pickFAIL60013.0918FAIL6001.030
446pnpOK3309.3716FAIL6004.440
640pickFAIL6001.660FAIL60018.1528
640pnpOK1645.612FAIL60014.9510
합계6/10avg 8.29FAIL avg 8.02/10avg 10.56FAIL avg 15.0

qpos_len = qpos_path_len, gt = gripper_transitions. FAIL avg는 실패 행만 평균.

하락 폭: 전체 6/10→2/10 (-4행, -40pp). pick 3/5→2/5(-20pp), pnp 3/5→0/5(-60pp, 전멸) — 단독 pick은 어느 정도 버티지만 place까지 포함된 복합 조작은 완전히 무너진다.
"얼어붙음" 가설 기각: bench 실패군의 gripper_transitions 평균(15.0)이 zed2 실패군(8.0)보다 오히려 높고, qpos_path_len 평균도 bench(10.56)가 zed2(8.29)보다 약간 높다 — 정책은 계속 시도하지만 조작 정밀도가 무너지는 형태다.

5 실패 사례 (bench pnp 0/5에서 대표 선정)

F1 — h136 pnp: tomato → bowl (gripper_transitions=36, 전체 최고)

"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.

h136 pnp 키프레임
Figure 2: frame 0/99/199/299 — 팔이 토마토(붉은 물체)로 계속 접근하며 그리퍼가 반복 개폐, 600스텝 내내 파지 시도가 이어지지만 완료되지 않음
bench h136 pnp FAIL (tomato→bowl, gt=36) — 20런 중 최고 활동량 실패 사례
대조: bench h136 pick OK (candle, gt=4, 89스텝) — 같은 house, pick 단독은 성공

F2 — h446 pick: candle (gripper_transitions=0, 무반응 실패)

"Pick up the candle" — steps=600, qpos_path_len=1.03, gripper_transitions=0, secs=268.0. 같은 house의 pnp 행도 동일 candle 오브젝트로 gt=0 — 같은 씬에서 두 번 다 무반응.

h446 pick 키프레임
Figure 3: frame 0/99/199/299 — 팔이 사실상 정지 상태(4프레임 거의 동일). 씬 조명이 유난히 어둡고 캔들이 어두운 구석에 겨우 식별될 정도로만 보임
bench h446 pick FAIL (candle, gt=0) — bench 8실패 중 유일한 "무반응" 사례, 저조도 가설

F3 — h640 pick: cup → bowl (gripper_transitions=28)

"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 조건의 "적극적 실패" 경향을 보여준다.

bench h640 pick FAIL (cup, gt=28) — 반복 접근·파지 시도 후 실패
대조: zed2 h640 pnp OK (remote→bowl, gt=2, 164스텝) — 같은 house, zed2는 pnp 성공

6 Takeaway

의미

part1-20k(zed2류 카메라로 FT)는 벤치마크 카메라 그대로는 신뢰할 만한 실행 평가 기반이 아니다. 이 -40pp(pnp -60pp) 하락 폭이 "벤치마크 카메라 규약으로 실행형(Tier B/C) 평가를 돌리려면 벤치 카메라 데이터로 FT한 VLA가 필요하다"는 가설의 정량적 근거다. 다만 정책이 완전히 죽는 게 아니라(모션 활력·그리퍼 관여는 오히려 zed2 실패군보다 높음) OOD 시점에서 조작 정밀도가 무너지는 형태 — "인식은 되는데 학습 안 된 기하에서 grasp을 못 맞춘다"는 서사가 지배적이다(예외 1건, h446 candle 무반응).

n=1/셀 잠정: house당 1샘플, 카메라 조건별 독립 재샘플이라 같은 house도 다른 오브젝트가 뽑힌다(h640 사례). 합계 비교(6/10 vs 2/10)와 pnp 전멸은 표본 노이즈로 설명하기엔 크지만 표본 확대 전까지 잠정치.

7 Next Steps

미해결 한계

워밍업 스크립트의 하드코딩 dummy-obs 키 목록이 새 exo 카메라 추가 시마다 수동 갱신이 필요 — 서버 metadata의 cameras 키를 동적으로 읽어 구성하도록 리팩터링하면 이 실수 클래스가 원천 차단되지만 이번 범위 밖. h446 무반응(gt=0) 원인은 조명/오브젝트 크기 가설 수준, 추가 근거 없음.

다음 실험

벤치 카메라 FT VLA 필요성이 정량 확인됐으므로, 벤치 카메라 데이터로의 FT 계획 수립(팀 결정 필요) 또는 wrist 카메라까지 벤치 규약으로 맞춘 2차 라운드.