ETRI7203/ETRI_VR_Robotics_data_research

ETRI VR Robotics — FFW-SG2 텔레오퍼레이션 데이터 및 체크포인트

ROBOTIS AI Worker (FFW-SG2) 를 Vision Pro VR로 텔레오퍼레이션해 수집한 모방학습 데이터셋과, 이를 π0.5(openpi)로 파인튜닝한 체크포인트 저장소입니다.

과제: 캔을 집어 접시에 놓기 (put the can on the plate)

이 문서는 데이터 추출 머신이 참조할 규약서를 겸합니다. 새 데이터를 만들어 이 저장소에 올리실 때 아래 "데이터 제출 규약"을 따라주세요.

---

저장소 구조

datasets/       LeRobot 형식 데이터셋 (학습 입력)
checkpoints/    π0.5 LoRA 학습 결과 (.gitattributes 의 checkpoints/** 규칙으로 전부 LFS)
info.json       LeRobot 스키마 참조용 템플릿

데이터셋 목록

이름	에피소드	프레임	fps	state	action	비고
can1	6	6,903	10	19	16	초기 수집 (오른손)
can2	1	2,433	10	19	16	초기 수집
can_left	19	17,346	10	19	16	왼손 수집 (28ep → 선별 19ep)
can_left_v2	29	23,096	10	19	16	v2 스키마
can_left_v3	29	19,944	10	25	17	v3 스키마
can_left_v4	9	5,463	10	25	17	0731 추가 수집 (v3와 동일 스키마)
raw_left_20260728	—	—	—	—	—	원본 에피소드 (LeRobot 변환 전)
raw_left_20260731	—	—	—	—	—	원본 에피소드 (tar, 9개)

카메라 4대 공통: cam_head_l, cam_head_r, cam_wrist_l, cam_wrist_r (640×480)

can_left_v3 와 can_left_v4 는 스키마가 같아 합쳐 쓸 수 있습니다 (38ep / 25,407프레임). 합칠 때는 episode_index 와 전역 index 를 이어붙이도록 재번호해야 합니다 — parquet 안에 두 컬럼이 들어 있어 파일만 복사하면 인덱스가 충돌합니다.

v3 스키마 (현행)

convert_pkl_to_lerobot_v3.py 로 생성. v2 대비 세 가지가 달라졌습니다.

state 25 = 기존 로봇 상태 19 + can(x,y,z) 3 + plate(x,y,z) 3

객체 좌표 주석은 비전이 아니라 실측 FK 입니다. 캔은 파지점 기준(파지 전 고정 → 파지 중 손에 부착 → 이후 고정), 접시는 놓는점 고정. 따라서 카메라 오차가 0입니다.

action 17 = 기존 16 + lift (몸 높이)

리프트를 액션에 넣은 이유: 조작자가 "캔이 안 보이거나 책상에 가까우면 몸을 올리고, 리치가 부족하면 몸을 낮추는" 전략을 쓰는데, v2까지는 이 전략이 데모에는 있으나 정책이 출력할 수단이 없었습니다. 다음 프레임 측정값을 라벨로 하는 델타 액션입니다.

종료 트리밍 — 마지막 그리퍼 열림 + 2초까지만 사용합니다. VR 종료 버튼을 누르려고 손을 드는 동작이 29ep 중 11ep를 오염시켜 3,152프레임(14%)을 제거했습니다.

openpi 연결: FFWSG2InputsV3 (오른손목 카메라는 마스크 + 제로 이미지 — 왼손 전용 학습) / LeRobotFFWSG2V3DataConfig / config pi05_can_left_v3_lora

---

데이터 제출 규약

새 데이터를 만들어 올리실 때 지켜주실 사항입니다.

1. 형식

LeRobot 형식(data/, meta/, videos/)으로 datasets/<이름>/ 아래 두세요. meta/info.json 의 total_episodes, total_frames 가 실제 값과 일치해야 합니다.

2. 학습/검증 분할 — 에피소드 단위 80/20

datasets/
  <이름>_train/     학습용 80%
  <이름>_val/       검증용 20%

반드시 에피소드를 통째로 나눠주세요. 프레임 단위로 섞어서 나누면 안 됩니다. 10fps라 인접 프레임이 거의 동일한 이미지여서, 같은 에피소드가 양쪽에 걸치면 검증 loss가 비현실적으로 낮게 나오고 아무 의미가 없어집니다.

검증용 에피소드는 조명·캔 위치·촬영 시간대가 골고루 섞이게 골라주세요. 연속된 구간을 그냥 잘라내면 특정 조건에 몰릴 수 있습니다.

3. 큐레이션

성공한 시연만 넣는 것이 기본 원칙이고 지금까지 그렇게 해왔습니다(28ep → 19ep 선별 등).

다만 실패-복구 데모는 포함하시길 권합니다. 완전 실패가 아니라 살짝 벗어났다가 되돌아오는 궤적입니다. 성공 궤적만 학습하면 정책은 성공 경로 위에서만 행동을 알고, 한 번 벗어나면 그 상태가 학습 데이터에 없어 발산합니다(분포 이동). 실제로 v3 시연에서 "접근 목표는 정확하나 파지 직전 데모에 없는 상태로 이탈"하는 실패가 반복됐습니다.

4. 규모

현재 38ep(v3 29 + v4 9)이 병목입니다. 100ep 이상을 목표로 하고 있습니다.

5. 여러 데이터셋을 합칠 때

parquet 안에 episode_index 와 전역 index 컬럼이 들어 있어, 파일을 복사만 하면 인덱스가 충돌합니다. 이어붙일 때는 두 컬럼을 재번호해야 합니다.

v3 마지막  ep=28  index=19943
v4 첫      ep=29  index=19944      ← 오프셋 = 앞 데이터셋의 total_frames

meta/episodes.jsonl, meta/episodes_stats.jsonl 의 episode_index 도 같이 옮기고, meta/info.json 의 total_episodes / total_frames / total_videos / splits 를 갱신해야 합니다. 영상은 재인코딩 없이 파일명만 새 번호로 바꾸면 됩니다.

---

체크포인트

경로	학습 데이터	입력 카메라	출력 액션
checkpoints/pi05_can1_lora/2999	can1 (6ep)	head_l + wrist_l	16 (state 19)
checkpoints/pi05_can_left_v3_lora/2999	can_left_v3 (29ep)	head_l + wrist_l	17 (state 25)
checkpoints/pi05_lift_head_lora/2999	v3+v4 (38ep)	head_l + head_r	1 — 리프트
checkpoints/pi05_arm_wrist_lora/2999	v3+v4 (38ep)	wrist_l	16 — 팔+그리퍼

각 약 8.9GB (params + train_state + assets). orbax OCDBT 형식이라 파일명에 확장자가 없으며, .gitattributes 의 checkpoints/** filter=lfs 규칙으로 전부 LFS 추적됩니다.

카메라×액션 분리 (2026-07-31)

뒤의 두 체크포인트는 한 쌍으로 함께 쓰는 모델입니다. 각 카메라가 자기와 물리적으로 함께 움직이는 축을 담당합니다.

헤드 스테레오(리프트에 장착)  →  리프트 1차원        action[16:17]
왼손목      (팔 끝에 장착)    →  팔+그리퍼 16차원    action[0:16]

동기: 머리 카메라는 리프트에 붙어 있어 몸 높이가 바뀌면 픽셀→좌표 대응이 무효가 되고, 손목 카메라는 팔과 함께 움직인다. 두 시점이 인지하는 거리가 서로 달라지는 구조라 축을 나눠 학습했다.

두 모델은 데이터·스텝·학습률·배치가 전부 동일하다 (38ep/25,407f, 3,000 step, batch 16, peak_lr 5e-5). 입력 카메라와 담당 액션만 다르므로 결과 차이를 그 두 가지로 귀속할 수 있다.

추론 시에는 두 모델을 각각 돌려 17차원으로 조립한다 — pi05_inference_bridge.py --split-models (SplitPolicy). 조립 결과가 단일 17차원 모델과 같은 규약이라 하류(청크 실행·FK·relay·안전 계층)는 수정이 필요 없다.

	리프트(헤드)	팔(손목)
최종 loss 중앙값	0.00030	0.03740
MAE (학습셋 150프레임)	0.02181	0.05547
"항상 0" 기준선 대비	+86.6%	+87.8%
예측/실제 표준편차 비	1.13	0.89~1.02
예측·실제 상관계수	0.950	0.875~0.991

두 모델의 loss 를 서로 비교하지 말 것 — 1차원이 16차원보다 쉬워서 낮게 나온다. 자명한 기준선("항상 0", "항상 평균") 대비 얼마나 이겼는지로 보는 것이 맞다. 위 표는 두 모델 모두 상수를 출력하는 것이 아니라 실제 변화를 따라간다는 것을 보여준다.

단, 이 수치는 학습에 쓴 프레임으로 잰 것이라 일반화를 보장하지 않는다. 그리고 액션 예측 정확도와 파지 성공률은 별개다 (아래 "알려진 제약" 참조).

학습 기준선 (pi05_can_left_v3_lora/2999)

모델      π0.5 LoRA (paligemma gemma_2b_lora + action expert gemma_300m_lora), EMA off
데이터    can_left_v3 — 29ep / 19,944 frames  (batch 16 기준 2.41 epoch)
스텝      3,000  (batch 16, action_horizon 10)
학습률    cosine — warmup 100 → peak 5e-5 → decay 3,000 → 5e-6, AdamW clip 1.0
하드웨어  RTX 6000 Ada 48GB × 1 (공유 환경, 실효 가용 약 39GB)
소요      2시간 34분  (3.0~3.1 s/step)

loss 중앙값 추이 (300스텝 구간):

구간	0~299	600~899	1200~1499	1800~2099	2400~2699	2700~2999
loss	0.0912	0.0609	0.0479	0.0398	0.0319	0.0314

역전 없이 단조 감소했고 종료 시점에도 하락 추세가 남아 있었습니다(스케줄 종료로 중단). 발산 지표: loss>0.3 10건/3,000, grad_norm>1.0(클리핑) 19건/3,000.

loss가 낮은 것과 캔을 집는 것은 별개입니다. 이 값은 액션 예측 정확도이지 작업 성공률이 아닙니다. 성공률은 실물 롤아웃으로만 측정되며, 100회 이상 시행해야 유의미한 수치가 나옵니다. 이 체크포인트는 기준선으로 쓰기 위한 것입니다.

---

사용법

git clone https://huggingface.co/datasets/ETRI7203/ETRI_VR_Robotics_data_research hf_data
# git-lfs 필수. 없으면 17GB가 포인터 텍스트로만 내려옵니다.

mkdir -p ~/.cache/huggingface/lerobot/etri
ln -s $(pwd)/hf_data/datasets/can_left_v3 ~/.cache/huggingface/lerobot/etri/can_left_v3

openpi 학습 코드와 설정은 별도 저장소(ETRI_VR_Robotics_data_research, 브랜치 verify/assist-phase2)의 pipeline/vla/ffw_sg2/openpi_port/ 에 있습니다.

알려진 제약

• 그리퍼 실구동 경로 미구현 — 현재 Cyclo 경로에 그리퍼 컨트롤러가 없어, 정책이 파지 동작을 출력해도 물리적으로 쥐지 못합니다. 파지 성공률 측정의 선결 조건입니다.
• 성공률 미달성 — 접근까지는 정확하나 파지 직전 이탈이 반복됩니다. 병목은 데이터 규모로 판정됐습니다(시스템 결함 아님).
• raw_left_20260728 은 LeRobot 변환 전 원본이라 그대로 학습에 쓸 수 없습니다.