Hand-off Place 실험 기록

학습 분포(val)에서는 goal 이미지가 팔 궤적 오차를 23% 줄이고, 틀린 goal은 50% 늘린다 — 모델은 3번째 이미지 슬롯의 내용을 읽는다. 그런데 sim에서 물체를 든 채 넘겨받아 실제로 놓게 하면 place 데이터도, goal도, goal의 시점·프레임을 바꿔도 성공률은 21–24%에서 움직이지 않는다.

실패는 "놓지 못해서"가 아니다(97–100% 놓음). 참조 물체까지 마지막 15–40 cm를 못 맞춘다: 최종 표면거리 중앙값 0.17–0.24 m, 10 cm 이내는 25–32%뿐이다.

사용자의 2-stage 제어에서 pick과 navigation은 다른 모듈이 하고, pi0.5는 이미 물체를 든 상태에서 제어권을 받아 내려놓기만 한다. 그 hand-off 이후가 잘 안 된다. 두 질문:

• Q1 — place 구간만 잘라 만든 데이터(Keh0t0/molmo-augment)로 추가 학습하면 잘 놓는가?
• Q2 — 사전에 저장해 둔 "물체가 놓여 있던 장면" 이미지를 goal로 넣어 주면 큰 의미가 있는가?

처음에는 이를 val open-loop 오차와 기존 HardBench(Pick / PnP / NextTo, 깨끗한 초기 상태에서 pick부터)로 답했다. 사용자가 정정했다: 원하는 것은 "물체를 든 채 시작하고 Place 명령만 줬을 때"의 성공률이다. 기존 벤치는 pick부터 하고, val L1은 action 예측 오차일 뿐이다. 그래서 그 상황을 그대로 재현하는 closed-loop 벤치를 만들었다(§6).

학습 goal 카메라로 exo_camera_2를 썼다. 이 카메라가 정확히 무엇인지는 이번 기록을 쓰면서 다시 확인했다: h5에 저장된 관측 센서 4종(randomized_zed2_analogue_1/2, randomized_gopro_analogue_1, droid_shoulder_light_randomization) 중 어느 것과도 일치하지 않는 별도 카메라이고, 에피소드마다 위치가 달라 관측 exo 시점과도 다르다.

pi0.5(openpi PyTorch)의 입력은 이미지 슬롯 3개, 관절 상태, 언어 프롬프트다. 출력은 16 step × 32차원 action chunk이며 실제 의미 있는 차원은 8개(팔 관절 상대 위치 7 + 그리퍼 1). 평가에서는 이를 관절 속도 명령으로 실행한다.

dropout을 둔 이유는 두 가지다. 배포에서 goal을 못 만드는 상황에도 동작해야 하고, 한 번도 안 쓰던 슬롯을 켜면 attention 패턴이 바뀌어 기존 능력이 깎일 수 있어서다. 실제로 goal off 성능은 place10k와 3% 차이(0.0898 vs 0.0870)로 유지됐다.

배포 경로(pi.py)에서는 base가 이미 224×224로 들어오므로 goal에 같은 순서(squash → pad)를 재현하도록 obs_hw를 두었고, obs["goal_image"]를 넣으면 슬롯으로 가는 passthrough를 붙였다. 아래가 실제 학습 샘플 하나에서 모델이 받는 세 장이다.

place와 place_goal은 init·step·혼합비·지시문이 같고 goal 유무만 다르다(통제 A/B). place 클립은 전체 프레임의 0.7%지만 0.20 가중치로 약 28배 오버샘플링된다. 8×B200, 로그인 노드가 아닌 sbatch(own QOS). goal 학습은 세 번 죽고 네 번째에 돌았다(§8).

val 460궤적의 모든 프레임(39,040)에서 정규화 공간의 예측 chunk(16×8)와 GT의 L1. 모든 프레임이 "든 채 시작"한 분포이므로 hand-off 능력의 대리 지표로 썼다 — 나중에 이 가정이 틀렸음이 드러난다(§9). 네 가지 뷰: all, arm(7), gripper(1, 릴리즈 타이밍), step0(즉시 실행되는 첫 step). 조건은 --goal-camera(on), 없음(off), --goal-shuffle(다른 궤적의 goal, 460궤적 derangement), --goal-preproc crop(관측처럼 center-crop한 goal).

사용자 정의 측정을 그대로 재현한다. 물체를 "든 채 시작"하는 상태를 만들려면 누군가 집어야 한다. h5에는 물체 포즈가 저장돼 있지 않아 저장 상태 복원은 불가능했고(EnvStateSensor가 비어 있음), 물체를 그리퍼에 용접하는 코드도 없다. 대신 molmo_spaces에 들어 있는 데이터 생성용 scripted expert(PickAndPlaceNextToPlannerPolicy)를 그대로 써서 집게 하고, 학습 클립이 잘린 바로 그 지점에서 정책에 넘긴다.

정책이 매 step 받는 것은 아래와 같다. sim 관측 카메라는 droid_shoulder_light_randomization(352×624)로, 학습 관측 카메라와 다른 이름·랜덤화이지만 이 프로젝트의 모든 rollout 수치가 같은 설정이다.

변형 3종: 늦은 프레임(HANDOFF_GOAL_DELAY=30, 팔이 물체에서 떨어진 뒤), 틀린 goal(HANDOFF_GOAL_BANK, 다른 에피소드의 goal PNG), 다른 시점(HANDOFF_GOAL_CAMERA=randomized_zed2_analogue_2, 진행 중). goal 없이 학습한 ckpt는 이 키를 버리므로 같은 러너에서 goal-off와 동일하게 동작한다.

mix20k vs place10k는 142편에서 17:17로 완전 동률이다. goal 조건은 on > off > wrong의 방향은 있지만 어느 쌍도 유의하지 않다(n=117, 성공률 ~22%면 표준오차 ≈ 3.8%p).

에피소드별 일치도(공통 117편, 6조건): 어느 조건에서도 성공 못 한 편 55, 1조건만 19, 2조건 18, 3조건 8, 4조건 9, 5조건 5, 6조건 모두 3. 절반은 어떤 모델도 못 풀고, 나머지는 실행마다 성패가 갈린다 — 모델 차이보다 에피소드 난이도와 샘플링 분산이 크다.

각 영상은 행 = 조건(goal ON / goal OFF / 틀린 goal / place10k / mix20k), 열 = goal 이미지 | exo 카메라 | wrist 카메라. t=0이 hand-off 순간이다: scripted expert가 집어 올린 뒤(그 구간은 영상에서 뺐다) 물체를 든 상태에서 VLA가 제어를 넘겨받는 시점부터 303 step(20 s)을 15 fps 실시간으로 보여 준다. 첫 0.5 s의 노란 테두리가 hand-off 표시다. 라벨의 판정은 종료 시점 상태(성공 / 근접 실패 ≤15 cm / 15–40 cm / far / 다른 면)이고, 본문 집계의 성공은 0.5 s 지속 판정이라 드물게 다를 수 있다(house_117).

학습 3회 실패, 벤치 스모크 11회. 각각 원인과 수정(모두 claude/context.md 함정 17–27로 기록).

• hand-off 상태는 학습 클립과 같은 phase에서 생성되고, 시드 고정으로 세 ckpt가 정확히 같은 142편을 평가했다(expert 불가 집합 동일).
• goal-on 변형의 상태 복원은 qpos drift 2e-16, 복원 후 재계획도 같은 지점(119 step)에서 hand-off.
• goal 주입 경로는 학습 경로 출력이 기존과 바이트 동일, 추론 경로(base 224×224)가 학습 goal의 224 pad와 정확히 일치.
• goal_shuffle(틀린 goal) 대조군은 460궤적 derangement, 같은 house로 떨어진 6편 제외 전부 다른 장면.

open-loop vs closed-loop. val L1은 시연 상태 분포 위에서 "다음 16 step을 시연처럼 예측하는가"를 잰다. place 데이터와 goal은 이 예측을 확실히 좋게 했다. 그러나 closed-loop에서 정책은 자기 행동으로 만든 상태를 보게 되고, 그 상태에서의 마지막 15–40 cm 정밀 접근은 두 개입 모두 바꾸지 못했다. val open-loop L1은 이 질문의 대리 지표로 부족하다 — 이번에 −22%가 성공률 0%p였다.

goal 도메인. 기하(squash vs crop)는 crop 프로브로 대부분 기각됐다(이득의 73% 유지). 프레임 시점(팔이 위에 있느냐)도 무관했다. 남은 것은 시점이다: 학습 goal은 관측과 다른 제3 시점의 완료 장면인데 sim goal은 관측 카메라와 같은 시점이었다. 다른 랜덤 exo 카메라로 goal을 만드는 진단(107886)이 이를 가른다.

벤치 자체의 한계. (i) expert 불가 29%가 빠져 분모가 142/117편이고, 그 집합은 "expert가 풀 수 있는 쪽"으로 치우친다. (ii) 성공 판정 5 cm는 엄격하다 — 근접 실패(≤15 cm)까지 합치면 36–40%다. (iii) sim 관측 카메라(droid_shoulder)가 학습 관측 카메라와 다르다는 점은 모든 rollout 수치가 공유하는 조건이다. (iv) n=117에서 ±4%p 이하 효과는 검출되지 않는다.

사용자 파이프라인에 대해. 현재 ckpt 세 개(mix20k·place10k·place_goal10k) 중 어느 것을 hand-off에 써도 sim 기준 성공률은 같다. goal을 줄 거라면 저장된 사전 관측을 관측과 같은 전처리로 넣으면 되지만(pi.py passthrough), 이번 결과로는 그것이 성공률을 올린다는 근거가 없다.

1. 시점 진단(107886) 결과 확인. 효과가 있으면 goal을 "관측과 다른 고정 카메라"로 정의하고 그 조건으로 배포·재평가.
2. 효과가 없으면 goal 재학습보다 정밀 배치 자체를 다룬다: 배치 직전 구간 오버샘플링, wrist 카메라 비중, place 지점을 명시하는 저수준 목표(좌표·마커) 조건화, NextTo 판정 거리별 커리큘럼.
3. 벤치 보강: grasp 후보 다양화로 expert 불가 29%를 줄이고, 근접 실패(≤15 cm)를 보조 지표로 같이 보고.
4. 지표: 이후 모든 hand-off 관련 판단은 이 벤치의 성공률 + 최종 표면거리 분포로 한다. val L1은 학습 진단용으로만.