HiFi-UMI-2K 데이터셋 비교: 원본 / 변환본 / X-WAM 기존

TL;DR

같은 "action"이라는 이름이 세 데이터셋에서 전혀 다른 것을 뜻한다. HiFi-UMI는 절대 next-state target(미터), RoboCasa는 [-1,1]로 정규화된 7-dim delta 명령. LeRobot 포맷은 이를 규정하지 않는다.
변환은 무손실이다. 위치 왕복 오차 0.50 µm, action[t]==proprio[t+1] 오차 정확히 0. 비디오는 재인코딩하지 않고 start 오프셋으로 원본 concat mp4를 그대로 참조한다.
회전 표현이 셋 다 다르다 — rot6d(6) / rotvec(3) / 3×3 rotm(9). 전부 같은 SO(3)이지만 저장 형태만 다르다.
RoboCasa는 단일팔이라 right_* 키가 아예 없고 action 14-dim 중 7개가 0 마스킹된다. HiFi-UMI는 양팔을 다 채운다.

453

변환 ep0 frames

0.50µm

위치 왕복오차

action 시프트 오차

GOP (frames)

256×

task 불균형 max

1 세 데이터셋 한눈에

항목	HiFi-UMI 원본	변환본 (X-WAM)	RoboCasa_linlog_pm (기존)
포맷	LeRobot v3.0	X-WAM sft_dataset	X-WAM sft_dataset
팔	양팔	양팔	단일팔 (left만)
episode 수	1,125 / shard	28,506 (24 shard)	1,320
총 길이	2,000 h (전체 릴리스)	129.4 h (보유분)	~7 h
비디오	640×512 25fps concat 5.3 h/파일	원본 참조 + `start`	256×256 20fps episode당 1개
view	6 (head×2, hand×4)	3 (head + 양손 up)	3 (agentview×2, eye_in_hand)
depth / pointmap	없음	없음	있음
디스크	904 GiB	3.4 GB (JSON만)	143 MB + 심볼릭 비디오

변환본이 3.4 GB로 끝나는 이유: 비디오를 복사하지 않는다. episode JSON이 원본 concat mp4의 경로와 프레임 오프셋만 들고 있고, X-WAM 로더의 abs_frame_ids = frame_ids + obs_start가 나머지를 처리한다.

2 실제 값 — 같은 프레임, 세 가지 표현

2.1 HiFi-UMI 원본 `observation.state[0]` (20-dim 단일 벡터)

[-0.05110, +0.35142, +0.37270, -0.34670, -0.84375, -0.40973, -0.93761, +0.29955, +0.17653, +0.02662, -0.11543, +0.32543, +0.36787, +0.54835, -0.83618, -0.01058, -0.82831, -0.54484, +0.13054, +0.02761]

이 20개 숫자가 meta/modality.json의 슬라이스 정의에 따라 다음과 같이 쪼개진다:

슬라이스	의미	값
`[0:3]`	right xyz (m)	[-0.05110, +0.35142, +0.37270]
`[3:6]`	right rot6d row0	[-0.34670, -0.84375, -0.40973]
`[6:9]`	right rot6d row1	[-0.93761, +0.29955, +0.17653]
`[9:10]`	right gripper (rad)	[+0.02662]
`[10:13]`	left xyz (m)	[-0.11543, +0.32543, +0.36787]
`[13:16]`	left rot6d row0	[+0.54835, -0.83618, -0.01058]
`[16:19]`	left rot6d row1	[-0.82831, -0.54484, +0.13054]
`[19:20]`	left gripper (rad)	[+0.02761]

2.2 변환본 — named key로 분리 + rot6d → rotvec

proprios.right_ee_pos[0] = [-0.051099, +0.351415, +0.372697] ← 원본 [0:3] 그대로 (m) proprios.right_ee_rotm[0] = [+1.632410, -2.328724, -0.569890] ← rot6d 6개 → rotvec 3개 proprios.right_gripper_pos[0]= [+0.026625] ← 원본 [9:10] 그대로 (rad) actions.right_ee_pos[0] = [-0.051058, +0.348121, +0.372754] proprios.right_ee_pos[1] = [-0.051058, +0.348121, +0.372754] ← 정확히 동일

핵심: HiFi-UMI의 action은 state를 한 칸 민 복사본이다 (11,616,549 프레임 전체 max 오차 0.000e+00). X-WAM의 delta 경로가 요구하는 "absolute next target"과 정확히 일치하므로, RoboCasa처럼 delta를 미리 계산해 넣을 필요가 없다.

2.3 RoboCasa — 완전히 다른 규약

proprios.left_ee_pos[0] = [+0.24744, -0.00362, +0.59642] (m, 절대) proprios.left_ee_rotm[0] = 9개 (3×3 평탄화) proprios.{right_*} = 키 자체가 없음 → 로더가 zeros + mask 0 으로 채움 actions.raw_actions[0] = [-0.00000, +0.00714, -0.00000, -0.00286, -0.00000, -0.00000, -1.00000] └─ dx dy dz drx dry drz gripper ↑ xyz는 [-1,1] 정규화된 delta 명령, 미터가 아님 gripper -1 = 열림

같은 이름, 다른 의미: HiFi-UMI action은 미터 단위 절대 위치, RoboCasa raw_actions는 무차원 delta 명령이다. quantile.yaml이 이를 뒷받침한다 — action_left_ee_xyz의 q01/q99가 정확히 -1.0 / 1.0로 클리핑되어 있다.

2.4 규약 대조

항목	HiFi-UMI 원본	변환본	RoboCasa
회전 표현	rot6d (6) R의 첫 두 행	rotvec (3)	3×3 rotm (9)
위치 단위	m, 절대	m, 절대	m, 절대
좌표계	egocentric world +Z=중력, 원점=recording 시작 head	동일	로봇 base
action 의미	absolute next target	동일	정규화 delta 명령
gripper	개방각 rad, 0~0.6 클수록 열림, 손가락당 최대 35°	동일	명령값, -1 = 열림
arm 순서	`[right, left]`	키 이름으로 지정	left만
delta 계산 주체	—	로더가 계산	빌드 시 사전계산

이식 시 함정 두 가지. ① X-WAM의 _ACTION_COMPONENTS는 left→right 순인데 HiFi-UMI state는 right→left다 — 키 이름으로 매핑하면 안전하지만 위치로 매핑하면 좌우가 조용히 뒤바뀐다. ② gripper 부호 규약이 RoboCasa(-1=열림)와 반대다. delta 경로의 inverse_gripper 플래그로 맞춰야 하며, RoboTwin config가 쓰는 inverse_gripper: false 쪽이 HiFi-UMI와 같은 방향이다.

3 observations — 비디오 참조 방식

변환본 (concat mp4 + 프레임 오프셋)

view	type	start → end	fps	crop	HFoV
`head_main`	dynamic	0 → 453	25	1.0000	144° → 144°
`left_hand_up`	dynamic	0 → 453	25	0.7673	200° → 144°
`right_hand_up`	dynamic	0 → 453	25	0.7673	200° → 144°

rgb_path는 원본 shard의 concat mp4를 가리킨다:

../HiFi-UMI-2K/chunk-0000/part-0000/videos/observation.images.head_main/chunk-000/file-000.mp4

crop 0.7673의 근거: 손 카메라는 200° HFoV, head는 144°(저자 확인). equisolid 모델에서 200°를 144°로 줄이는 중앙 crop 비율이 0.7673이고, 640px로 되돌리면 실효 f = 208.9 × 1.303 = 272.2 px/rad가 되어 head의 272.2와 정확히 일치한다. 즉 세 view가 같은 화각·같은 각해상도가 된다.

RoboCasa (episode당 mp4, 오프셋 0)

view	type	start → end	fps	crop	HFoV
`robot0_agentview_left`	static	0 → 217	20	—	—
`robot0_agentview_right`	static	0 → 217	20	—	—
`robot0_eye_in_hand`	dynamic	0 → 217	20	—	—

4 영상 비교

HiFi-UMI는 chunk-0000 / episode 0 (Take the disposable food container out of the microwave.)의 앞 5초, RoboCasa는 episode 0 전체(217 frames)다.

4.1 HiFi-UMI — head (144°)

head_main — 144° HFoV, 학습에 crop 없이 그대로 사용

head 카메라

착용형 스테레오 rig의 좌안. 원 논문에서는 offline SLAM 전용이고 policy 입력에서 제외되지만, world model 입장에서는 가장 넓은 장면 맥락을 담은 egocentric 뷰다.

HFoV 144°이므로 이것도 광각이다 — rectilinear가 아니다.

4.2 HiFi-UMI — wrist 원본(200°) vs crop(144°)

left_hand_up 원본 — 200° fisheye

left_hand_up crop 0.7673 — 144°, 실제 학습 입력

right_hand_up 원본 — 200° fisheye

right_hand_up crop 0.7673 — 144°, 실제 학습 입력

왜 펴지 않고 자르는가. 카메라 intrinsics가 공개되지 않았고 (저자: "intrinsic parameters vary across devices"), rectilinear로 펴면 tan 발산 때문에 640px 출력 기준 144°에서 중심 해상도가 0.57×로 떨어진다. crop은 입체각 59%를 보존하면서 각해상도가 오히려 올라가고, 무엇보다 렌즈 모델 가정이 결과에 영향을 주지 않는다.

4.3 RoboCasa (X-WAM 기존)

robot0_agentview_left — static 카메라, 256×256

robot0_eye_in_hand — dynamic, 256×256

카메라 성격이 다르다. RoboCasa/DROID에는 type: static 뷰가 있지만 HiFi-UMI는 6 view 전부 착용형이라 모두 dynamic이다. X-WAM의 camera_type_mask가 전부 1이 되는데, static 뷰를 섞어 본 사전학습 체크포인트라면 입력 분포가 달라진다.

5 변환 검증 & 통계 (24 shard 전체)

검증 항목	결과	판정
`action[t] == state[t+1]` (11,616,549 프레임)	max 오차 0.000e+00	통과
rot6d 직교성 `\|RR^T−I\|`	max 1.72e-07	통과
위치 왕복 오차 (원본 → JSON → 복원)	max 0.50 µm	통과
회전 왕복 오차	max 75.3 arcsec = 12cm 링크에서 45 µm	데이터 정확도 3mm의 1/66
마지막 episode `end` vs 비디오 총 프레임	478,810 = 478,810	일치
`valid.frame` 비율	min 0.999970	무시 가능
task 불균형 (최다/최소 프레임 비)	median 60.2×, max 256.6×	샘플링 가중치 필수

Δpos / frame (40ms)

p50 4.200 mm

Δrot / frame

p50 0.450°

episode 시작 3D std

0.181 m

heading 균일성 χ²

85,930

episode JSON

127 KB

JSON 파싱

3.32 ms

egocentric frame 확인

episode 시작 위치의 3D 표준편차가 0.181 m로 좁게 모이고, 시작 heading 히스토그램의 균일성 χ² = 85,930 (df=11, 임계 19.7)로 강하게 편향돼 있다. world frame 원점이 recording마다 임의가 아니라 착용자 기준으로 고정된다는 뜻이고, 따라서 절대 xyz가 recording 간에도 의미를 가진다. X-WAM의 단순 world-frame 뺄셈 delta가 그대로 유효한 근거다.

6 남은 작업

X-WAM 패치 3건

data/robot_dataset.py (depth optional · VideoReader LRU 캐싱 · per-view crop), data/augmentation.py (data["depths"] 가드) — 두 파일 모두 git clean.

runners/xwam_runner.py의 validation_step depth 가드 2곳은 진행 중인 REPA/World Forcing 작업(+236줄)과 같은 파일이라 보류 중.

결정 필요

task 불균형 가중치를 shard 내 task별로 줄지 전체 코퍼스 기준으로 줄지. shard마다 task 구성이 17~59개로 달라 두 방식의 결과가 크게 다르다.