RoboDojo 시뮬 데이터 → Zero-WAM 학습 형식 변환 계획

TL;DR

변환 가능, 코드 변경 최소: HF에 LeRobot v2.1(63.4 GB) 공개, EE v3.0 16-D action/state가 RoboTwin과 같은 레이아웃(w-first quat, gripper 0..1, next-state action) → ZW Robotwin 액션 경로 무수정 사용
v2.1 ↔ EE v3.0 3,500 ep 길이·태스크 정렬 일치 → v2.1 mp4 그대로 쓰고 parquet action/state만 EE로 교체. 필요한 다운로드 약 64 GB
차이 3가지: 에피소드 길이(평균 530프레임 21 s, 최대 1,536) → 10.3 s 창 분할 / 25 Hz → stride 2 = 12.5 fps(latent 프레임당 action 8개) / human demo 없음 → 생성 필수
병목 = human demo: 태스크당 10개(350개) 약 700회 생성, Wan FLF 약 52 GPU·h, 사용 가능 비율 약 50%

64 GB

다운로드

55 GB

변환 산출물(권장)

8,906

세그먼트 수(10.3 s)

~52

GPU·h demo 350개

1 배경 / 목적

RoboDojo가 명세 추종 연구의 다음 무대 후보(261006-robodojo_cluster_pi05_smoke)이므로, 35태스크×100 궤적 시뮬 데이터를 ZW 학습 형식(LeRobot v2.1 + Wan2.2 VAE latent + UMT5 지시문 임베딩 + ICL 매니페스트/human latent)으로 바꿀 수 있는지 조사했다. 읽기 전용 조사이며 실제 변환은 하지 않았다.

2 작업 내용 — 데이터 구조 점검

폴더 (HF `RoboDojo-Benchmark/RoboDojo`)	형식	크기	비고
RoboDojo_lerobot_v21_video	LeRobot v2.1, joint	63.4 GB (14,004 파일)	35태스크 3,500 ep 병합 1개 — 사용
RoboDojo_ee_lerobot_v30_video	v3.0, EE	65.5 GB	meta+data 0.25 GB만 사용(영상 65.2 GB 불필요)
RoboDojo_lerobot_v30_video	v3.0, joint	119.8 GB	미사용
RoboDojo (HDF5)	HDF5 35폴더	1,851 GB	미사용

항목	값
fps / 총량	25, 1,856,102프레임(20.62 h)
카메라	cam_high / cam_left_wrist / cam_right_wrist, 480×640 AV1 — RoboTwin과 키·해상도·코덱 동일
joint (v2.1)	14-D(팔 6-DoF + joint_6=그리퍼), `action[t]==state[t+1]` 오차 0
EE (v3.0)	16-D `[l_xyz, l_quat(w first), l_g, r_...]`, quat norm 1, `action[t]≈state[t+1]` ≤1e-4
휴지 자세 비교	RoboTwin (-0.298,-0.314,0.942, 0.70,0,0,0.714, 1) vs RoboDojo (-0.299,-0.352,0.921, 0.707,0,0,0.707, 1)
지시문	태스크당 1개(35개), 100 ep 동일 문장 (RoboTwin은 ep마다 상이)
에피소드 길이	평균 530 / 중앙값 458 / 최소 104 / 최대 1,536프레임. 태스크 평균 178(insert_key) ~ 1,389(fasten_screws)
디코딩	pyav/dav1d 578프레임 640×480 ≈ 2.3 s (≈250 fps/프로세스)

태스크 매핑: task_index i = HDF5 태스크 폴더명 ASCII 정렬 i번째, ep 100i…100i+99가 태스크 i (ep 0 → arrange_largest_number, ep 3043 → stack_bowls 확인).

quat 주의: 두 데이터셋 모두 w 먼저 저장, ZW는 scipy from_quat(xyzw)로 읽어 축 해석은 틀리지만 학습·추론에서 같은 함수라 일관 — 순서를 바꾸지 말고 그대로 넣어야 RoboTwin 사후학습 가중치와 의미가 맞는다.

LingBot_VA `process_data.py` 재사용 여부

골격 약 70% 보유(v2.1 입력, action_config, Wan2.2 VAE 3캠 인코딩, empty_emb, 영상 symlink). ZW에 그대로는 불가한 5가지: ① 액션이 joint 14→30 zero-pad(ZW는 EE 16-D 기대) ② 256×256·10 fps(ZW는 224×288, 12.5 fps) ③ 텍스트 키 text_emb(umt_dense가 fallback하므로 동작) ④ 에피소드당 세그먼트 1개(최대 193 latent 프레임) ⑤ 태스크 분할 없는 병합 출력 → 복사해 script/convert_robodojo_to_zerowam.py로 수정. joint 대안(action_transform.yaml)은 RoboTwin ckpt와 액션 공간이 달라져 EE 권장.

3 결과 — 추정치

디스크 (latent 14×18×48 bf16 = 24.2 KB/프레임/카메라, 지시문 임베딩 4 MiB/세그먼트)

세그먼트	수	latent 프레임/카메라	latent	cam_high 임베딩	합계
에피소드 전체(LingBot 방식)	3,500	233,547	16.9 GB	14.7 GB	32 GB
10.3 s 창, 겹침 없음(권장)	8,906	237,588	17.2 GB	37.4 GB	55 GB
10.3 s 창, hop 5.2 s	12,757	389,771	28.3 GB	53.5 GB	82 GB
5.2 s 창, hop 5.2 s	16,034	244,497	17.7 GB	67.3 GB	85 GB

NAS 총 사용 ≈ 원본 64 GB + 변환 55~85 GB = 120~150 GB. 고유 문장이 35개뿐이므로 로더 약 10줄 패치(태스크 공유 .pt 캐시)로 37~67 GB → 0.15 GB 절감 가능(선택).

연산

디코딩 3캠 × 1,856,102 = 5.57M 프레임 ≈ 6.2 프로세스·h → 16 워커 약 25분
VAE 인코딩 2.77M 프레임(224×288), 겹침 창이면 최대 1.6배. B200 처리량 미측정(로그인 GPU 타이밍 측정 금지) → 추정 1~4 GPU·h, 첫 sbatch에서 20 ep 실측 후 결정
텍스트 인코딩 35+1개 — 무시 가능

human demo 생성량

안	개수	생성 횟수	비용
최소	태스크당 1 = 35개	70회	약 5 GPU·h
권장	태스크당 10 = 350개	약 700회	Wan FLF 약 52 GPU·h + Nano Banana 편집 1.4k~4.2k회 + VLM 2~3k회 + 사람 검수 700건

선례 ICL_config_robotwin.json: 50태스크×50 샘플 = 2,499 짝(고유 human 영상 994개). 자체 파이프라인(Gemini 3.1 Pro VLM + Nano Banana 2 + Wan2.1-I2V-14B FLF, exp-a2b_goal_spec 실측): 영상 1개(40 step, 544×720) 약 4.5분/B200, 사용 가능 비율 약 50%(20개 중 10개), 사람 판정 9/10 "어색함"(제3의 팔, 순간이동).

RoboDojo 고유 문제: 태스크가 길고 다단계(fasten_screws 55 s, imitate_sorting_sequence 48 s)이며 기억형 태스크(cover_blocks, imitate_sorting_sequence, match_and_pick_from_conveyor, make_kong, play_tic_tac_toe)가 있다. FLF 5초 영상은 첫·끝 프레임만 고정해 다단계를 담지 못함 → (a) 하위 단계 클립 이어 붙이기 (b) 세그먼트 단위 짝 + 하위 태스크 경계 주석.

실행 단계 요약

Step 0 snapshot_download(allow_patterns: v21 전체 + ee_v30 meta/data) ≈ 64 GB (CPU/네트워크) Step 1 convert_robodojo_to_zerowam.py --stage meta : 태스크 분할(ep 0..99 재번호, mp4 symlink), EE 16-D parquet 주입, action_config = 258프레임 창(마지막 창 <9샘플이면 병합), meta/action_stats.json 자체 계산(RoboTwin q99 x 0.35 m보다 변위 클 수 있어 기존 stats는 ±2 clip) Step 2 --stage latents : 224x288, stride 2(12.5 fps), 4k+1 프레임, GPU sbatch 4 job (tasks 0-8/9-17/18-26/27-34, -c 16 --mem 200GB --time 4:00:00) Step 3 va_robodojo_train_cfg(복사 ~30줄), VA_CONFIGS['robodojo_train'], DATASETS=robotwin:1.0,robodojo:1.0 혼합 가능; 추론 cfg action_per_frame=8 Step 4 human demo(tmp/demo_gen) → encode_demo_latents.py(320x448, 12 fps) → ICL_config_robodojo.json (3,500 ep 전부 덮음) Step 5 build_dataset_index(CPU) → 로그인 dset[0] shape 검사(latents [48,F,14,54], actions [30,F,8,1]) → 짧은 train sbatch

4 Takeaway

RoboDojo EE 데이터는 사실상 RoboTwin과 같은 액션 공간 → RoboTwin 사후학습 ZW를 RoboDojo로 바로 미세조정하거나 혼합학습 가능. 엔지니어링 부담은 작다(다운로드 64 GB, 변환 스크립트 1개, config 30줄, GPU 수 시간).

병목은 human demo — 긴 다단계·기억 태스크에서 의미 있는 demo를 만드는 비용(~52 GPU·h)과 품질 위험(사용률 ~50%).

5 Next Steps

Step 0 다운로드 → Step 1 메타 변환 → 20 ep로 Step 2 실측해 VAE 처리량으로 GPU 수 결정
세그먼트 길이: 10.3 s 창(권장, attn_window 64 이하) vs 에피소드 전체(최대 192 latent 프레임) — 메모리 실측 후 선택
지시문 임베딩 공유 패치 여부(디스크 37 GB 이상 절감)
human demo: 최소 35개로 파이프라인 검증 후 태스크당 10개로 확대, 다단계 demo 형식 결정
연구 목적(명세 추종)이라면 태스크당 지시문 1개 구조가 RoboTwin과 같은 "장면=태스크" 누설을 만드는지 선검토