RoboTwin 2.0 SR 갭 진단 — 버그 3종 제거 후 τ₀ 실력 34.8% 확정

TL;DR

버그 3종 발견·수정: ① 브릿지가 절대 pose를 delta로 오적분(SR ~1%) ② 데이터로더 R/B 채널 반전(영향 작음) ③ B200(sm_100)에서 sapien 번들 OIDN 2.0.1이 실패 → 디노이즈 안 된 32-spp 노이즈 프레임이 정책 입력 (이 클러스터의 모든 이전 RoboTwin 평가 무효화)
하네스 무결 확인: X-WAM 공개 robotwin_sft를 동일 하네스로 평가 → pooled 115/140 = 82.1% (X-WAM 논문 90.7%, task별 재현 — lift_pot 100 vs 99, move_stapler_pad 70 vs 70)
τ₀ 54k는 학습 씬+seen 문장에서도 34.8% (40/115) — 일반화 실패가 아니라 실행 정밀도 문제로 확정
open-loop 정밀도 전 구간 1.4~2.3배 열세 (step1 0.39 vs 0.17cm → step32 3.04 vs 1.59cm), exec=8 A/B는 오히려 SR 37%→12%로 악화해 프로토콜 가설 기각

82.1%

X-WAM 하네스검증(96627)

34.8%

τ₀ 54k 학습씬(96628)

3종

발견·수정 버그

1.4~2.3×

open-loop 오차 열세

1 배경 / 목적

RoboTwin 2.0 τ₀-native 20ch posttrain(job 95687, 54k step, 최종 loss 0.113)이 완주된 뒤 첫 최종 평가(96393)에서 132 rollout 중 성공 1개(SR ~1%), R/B 채널 버그를 고친 재평가(96440/96561)도 task-mean 43~45%로 X-WAM 공개 수치(randomized 90.7%)에 크게 못 미쳤다. "학습을 잘못했나 / 하네스가 잘못됐나 / 모델 한계인가"를 가르는 것이 목적이다.

기존 한계: 사용자 지적 — "flex-π는 성공했으니 공개 성능대로 나오면 그냥 tau 모델 한계 아닌가"라는 가설을 검증 가능한 실험(공개 ckpt를 우리 하네스로, τ₀를 학습 씬에서)으로 쪼개기 전까지는 원인을 하나로 좁힐 수 없는 상태였다.

2 작업 내용

버그 3종 발견·수정

#	버그	증상	원인	수정
1	브릿지 절대 pose를 delta로 오적분	SR ~1%	X-WAM shim은 `[T,14]` delta 기대, 서버는 `[T,16]` 절대 pose 전송(shape 16≥14라 크래시 없이 통과)	`abs20_to_deltas14()` (`web_infer_utils/robotwin_zmq/server_zmq.py`), 왕복 오차 0
2	데이터로더 R/B 채널 반전	task-mean 43%, blocks_ranking_rgb 0%	RoboTwin HDF5는 `cv2.imencode`로 RGB 저장 → `imdecode`가 이미 RGB인데 `BGR2RGB` 중복 적용	`data/robotwin_tau.py` 변환 제거(재학습용) + 기존 ckpt 평가용 `--swap_rb` 플래그
3	렌더 디노이저 미작동 ★	평가 프레임이 32-spp 노이즈, 학습 분포와 불일치	sapien 번들 OIDN 2.0.1이 compute_90(Hopper)까지만 지원 → B200(sm_100) 실패, 클라이언트 로그당 `OIDN Error` 18만 건	`ROBOTWIN_RT_DENOISER` env 도입, worker에서 `optix` 사용 (`_base_task.py`)

버그 2는 결과적으로 영향이 작았다(두 모델 모두 채널 순서에 둔감: X-WAM open-loop 오차 1.31→1.35cm). 버그 3이 이 클러스터의 모든 RoboTwin 평가에 공통으로 걸려 있던 진짜 환경 결함이며, flex-π 세션이 먼저 규명한 것을 그대로 적용했다.

검증 설계 — 하네스 vs 모델 분리

① job 96627: "하네스가 잘못됐을 가능성"을 배제하기 위해 X-WAM 공개 robotwin_sft(HF, 38.9GB)를 다운로드하고 scripts/eval_robotwin_tau.sh에 POLICY=xwam 스위치를 추가해 동일 하네스·동일 8 task·동일 시드로 평가. ② job 96628: τ₀를 SEED0=-1(데이터 수집 시드와 동일 장면) + INSTRUCTION=seen으로 재평가 — 일반화 실패와 실행 능력 부족을 분리하는 통제 실험. ③ open-loop 오차 곡선(tmp/error_profile.py): 학습 클립 140개(20 task×7)에 대해 chunk 내 step별 위치 오차를 두 모델 동일 입력으로 측정 — τ₀ 논문은 receding-horizon 실행을 명시하는데 우리는 X-WAM 프로토콜(32-step open-loop)로 평가 중이었기 때문에 replan 빈도의 영향을 정량화. ④ job 97149: 96628과 동일 조건 + EXEC_STEP=8로 receding-horizon 가설을 A/B. ⑤ posttrain 데이터셋 대조: X-WAM X-WAM-RoboTwin(HF) metadata/에피소드 JSON/mp4를 우리 데이터와 직접 비교.

3 결과 (수치)

하네스 검증 + τ₀ 학습-씬 재평가 (96627 / 96628, 동일 8 task·동일 시드, 둘 다 TIMEOUT으로 일부만 완주)

task	X-WAM (우리 하네스)	τ₀ 54k (학습 씬+seen)	X-WAM 논문
lift_pot	20/20 (100%)	13/20 (65%)	99
blocks_ranking_rgb	20/20 (100%)	1/8 (12%)	95
open_laptop	19/20 (95%)	4/16 (25%)	97
move_pillbottle_pad	18/20 (90%)	8/13 (61%)	98
place_a2b_left	14/18 (77%)	7/20 (35%)	87
move_stapler_pad	14/20 (70%)	1/10 (10%)	70
move_can_pot	1/2 (50%)	6/20 (30%)	84
hanging_mug	6/16 (37%)	0/8 (0%)	55
pooled	115/140 = 82.1%	40/115 = 34.8%	90.7 (50 task 평균)

핵심 발견: X-WAM은 완료된 task에서 논문 수치를 재현(lift_pot 100 vs 99, move_stapler_pad 70 vs 70, open_laptop 95 vs 97) → 브로커·shim·delta 변환·좌표계·디노이저·시드 처리 전부 정상. 낮은 SR은 하네스 탓이 아니다.

결정적 결과: τ₀는 학습에 쓴 장면·본 문장에서도 35% — 일반화 실패(augmentation 부재 등)로는 설명되지 않는다.

open-loop 정밀도 — 모든 horizon에서 1.4~2.3배 열세

chunk step별 위치 오차(cm), 학습 클립 n=140:

step	1	4	8	16	24	32
τ₀-WM 54k	0.39	1.06	1.87	2.23	2.84	3.04
X-WAM robotwin_sft	0.17	0.75	1.37	1.16	1.67	1.59

exec=K로 잘라 실행할 때 실행 액션의 평균 오차:

exec	1	4	8	16	32
τ₀	0.39	0.71	1.15	1.66	2.20
X-WAM	0.17	0.46	0.81	1.06	1.31
비율	2.26	1.56	1.41	1.56	1.69

exec=8 (receding horizon) A/B — 가설 기각, 오히려 악화 (job 97149, 44 에피소드에서 중단)

	pooled	lift_pot	move_can_pot	move_pillbottle_pad	open_laptop	place_a2b_left
exec=32	37% (40/109)	13/20	6/20	8/13	4/14	7/20
exec=8	12% (5/42)	2/8	0/7	0/6	2/6	0/8

원인: 성공 에피소드가 2배 느려짐(lift_pot 성공 길이 32→63 프레임) — 같은 과제를 끝내는 데 2배의 waypoint를 쓰다가 timeout. under-shoot 가설은 기각(chunk 시작점 기준 예측/GT 변위 비율이 step1~32에서 0.93~1.14로 균일). 영상 확인 결과 잦은 재계획마다 궤적 앞부분을 다시 밟는 진동으로 순 진행이 상쇄되는 양상 — chunk-relative 20ch 표현이 잦은 재계획과 궁합이 나쁜 것으로 보인다.

posttrain 데이터셋 — 같은 벤치마크, 다른 구성

항목	X-WAM	우리 run1
에피소드/task	550 = clean 50 + randomized 500	randomized 500
씬 seed	자체 재생성(첫 프레임 픽셀 diff 17~42, 매칭 없음)	공식 RoboTwin2.0 zip
학습 해상도	256×320	192×256 (픽셀 1.8배 적음)
augmentation	crop 0.95 + color jitter	없음
depth	보조 예측 loss 사용	없음
action 표현	per-step delta 14ch, q01/q99	chunk-relative eef6d 20ch, meanstd
학습량	40k×32 = 1.28M, lr 1e-5	54k×96 = 5.2M, lr 5e-5

task 목록은 50개 완전 일치(누락 없음), 프레임 길이 분포도 task별로 일치 → 같은 생성기·같은 난이도.

4 Takeaway

의미

1) 하네스·환경 결함은 모두 제거됐고, 남은 갭은 모델/레시피의 것이다. 사용자 가설대로 X-WAM 공개 ckpt가 우리 하네스에서 논문 수치를 재현한다.
2) τ₀의 약점은 일반화가 아니라 액션 예측 정밀도다. 학습 씬에서도 35%이고, 단일 스텝 예측조차 X-WAM보다 2.3배 부정확하다(0.39 vs 0.17cm). augmentation·해상도 같은 일반화 장치로는 이 결과가 설명되지 않는다.
3) 평가 프로토콜은 τ₀에 불리하지 않았다 — exec=8이면 실행 오차가 −48% 줄어 유리해 보였으나 실제 A/B에서는 SR이 37%→12%로 악화했다. exec=32(X-WAM 프로토콜)가 τ₀에게도 최선이므로 기존 수치를 그대로 쓴다.
4) RoboCasa 63.0% 결과는 채널·디노이저 문제와 무관(decord 경로, 렌더 사전 생성)하므로 유효하다.

5 Next Steps

미해결 한계

96627(X-WAM 하네스 8 task)·96628(τ₀ 학습 씬) 둘 다 TIMEOUT으로 일부 task만 완주 — pooled 수치는 6~8/8 task 표본. open-loop 오차 누적(3.04cm)은 실패의 주된 메커니즘이 아닌 것으로 보이며, 재계획 안정성 + 액션 예측 정밀도 자체가 근본 원인이라는 가설은 아직 정량적으로 완전히 분리되지 않았다.

다음 작업

레시피 재학습 후보로 좁혀짐: 해상도/augmentation보다 action 표현(chunk-relative 20ch → per-step delta)이 exec=8 실패 양상(진동)을 볼 때 더 유망한 변경점. 학습 하이퍼파라미터(lr/schedule/batch) 자체를 X-WAM/τ₀ 논문과 대조해 run2를 설계·제출한 내용은 별도 카드(260827-robotwin_run2_recipe.html) 참조. run1 최종 50-task×100 전체 평가는 job 97360(optix+swap_rb)으로 재제출되어 현재 실행 중. 무효 처리된 결과 디렉토리: eval_results/robotwin_tau_step54000_INVALID_{abs_vs_delta,rb_swapped_train,noisy_render_*}.