Pick 링 A/B

TL;DR

빈손으로 작은 물체에 다가갈 때 가까운 링부터 자리를 찾게 함: (0, 0.45) → (0.45, 0.55) → (0.55, 0.7) m. 스위치 RRBENCH_PICK_RINGS(현재 기본 0).
같은 셀 115개(Finding 59, Restore 56)를 두 방식으로 실행: 첫 pick 성공 35 → 46 (0.30 → 0.40). 짝 비교에서 링만 성공 22, 현재만 성공 11 (p≈0.08).
개선은 전부 가까이 서는 비율 덕분. 0.45 m 안쪽 성공률은 두 방식 모두 0.47로 같고, 이것이 MolmoBot 정책의 상한.

0.30→0.40

첫 pick 성공

0.61→0.44 m

도착 거리 중앙값

77→13

0.55 m 이상 도착 /115

API 비용

1배경/목적

10-14 실행 스모크 분석에서 첫 pick 성공이 도착 거리에 크게 좌우됨(<0.45 m 6/10, 0.65~0.8 m 2/18). 현재 navigate는 MolmoBot 학습 범위 (0, 0.7) m 안에서 빈 자리를 찾다 보니 0.55~0.7 m에 서는 경우가 102회 중 77회. GT execute 전체(약 $670) 전에 고칠지 판단하려고 비용 0으로 비교.

2작업 내용

src/rrbench/agent/nav0.py: PICK_APPROACH_RINGS + pick_rings(). 비운반·비가구 대상에만 적용(물건 들고 가구로 갈 때는 기존 RECEPTACLE_APPROACH_RINGS).
harness_v2.CONDITION_ENV에 pick_rings 추가 — 모든 행에 기록, 조건이 섞이면 aggregator가 거부.
테스트 1개 추가, 940 passed.
probe tmp/nav_analysis/pick_probe.py: 실제 실행 하네스(GT preset, drive, MolmoBot, lift 판정)를 그대로 쓰되 VLM 클라이언트는 호출하면 에러를 내는 stub, 플래너는 "GT 물체로 navigate → pick 1회 → done".
Finding·Restore GT 셀에서 각 60개 무작위(plan 59/56). arm0 = 현재, arm1 = 링. job 200007–200010, GPU 1장씩 약 1.4시간.

3결과

	arm0 (현재)	arm1 (링)
Finding pick 성공	15/59 (0.25)	21/59 (0.36)
Restore pick 성공	20/56 (0.36)	25/56 (0.45)
합계	35/115 (0.30)	46/115 (0.40)
도착 거리 중앙값	0.61 m	0.44 m
0.55 m 이상 도착	77	13
navigate 성공	115	115

도착 거리별 pick 성공 (두 arm 합침)

거리	n	성공	비율
< 0.45 m	93	44	0.47
0.45~0.55 m	47	12	0.26
0.55~0.65 m	48	14	0.29
0.65~0.8 m	42	11	0.26

짝 비교: Finding 링만 11 / 현재만 5 / 둘 다 10, Restore 링만 11 / 현재만 6 / 둘 다 14. 합계 22 대 11, 부호 검정 p≈0.08.

4Takeaway

링은 navigate 실패를 늘리지 않고 첫 pick 성공을 상대 +31% 올림. GT execute 성공률이 pick 성공에 거의 비례하므로, 정책 실패로 생기는 측정 노이즈가 줄어듦.

0.45 m 안에 서도 성공은 0.47. 나머지 실패는 MolmoBot 자체 한계라 navigate로 더 올릴 여지는 작음. 스모크에서 보였던 0.45~0.55 m의 이점은 이번엔 재현되지 않음(0.26) — 유효 경계는 0.45 근처.

5Next

링을 v2 기본으로 할지 결정(docs/EXECUTION.md 스위치 표, paper_config preset 갱신).
GT execute 파일럿 → 전체 실행(약 $670) — 승인 필요.