Apple Vision Pro 텔레오퍼레이션으로 실물 로봇 시연 데이터를 모으고, VLA(Vision-Language-Action) 모델을 학습해
"언어가 로봇의 행동을 실제로 바꾸는가"를 실기로 검증하는 연구
Weights & Data · 실물 평가 · 데이터 수집 · Docs · Robot Trial Logs · Mirror
로봇 ROBOTIS AI Worker FFW-BG2 · 모델 π0.5 (openpi) · GR00T N1.7 · RDT-1B · 수행 김건희 (전남대학교 / ETRI)
Note
main 은 프로젝트 입구다 — 이 문서와 시연 GIF(assets/)만 있고 코드는 없다.
코드는 목적별 브랜치에 있다 — 수집은 VisionPro, 실물 평가는 LAB, 학습은 Train.
가중치·데이터는 HuggingFace. 어느 브랜치를 받아야 하는지는 저장소 구조 표를 보면 된다.
전체 구조 한 장 — 사람의 시범(수집)이 가중치(학습)가 되고, 가중치가 같은 로봇에서 시험(평가)되고, 그 판정이 다음 설계를 정한다:
장비로 보면 — 실제 기계는 네 대다. 사람이 쓰는 Vision Pro, 로봇 옆에서 지휘하는 우분투 제어 컴퓨터, 몸을 움직이는 AI Worker,
그리고 인터넷 너머의 학습 GPU 서버. 수집과 평가는 같은 두 대(제어 컴퓨터 ↔ 로봇) 를 쓰고 포트 8013 의 내용물만 바뀐다:
- Highlights
- 시연 미리보기
- 연구 질문 — L1·L2 만으로 L3 를 시험한다
- 과제와 객체 — 전부 YCB
- 1부 — 데이터 수집: 왜 지금의 방식인가
- 2부 — 학습: v3 → v9, 각 전환의 이유
- 3부 — LIBERO 와의 관계
- 4부 — 현행 실험과 실기 결과
- v9 — 깊이 보조 지각 ★실물에서는 배제
- 재현
- 저장소 구조
- 문서 찾기
- Citation
- 자체 WebXR 텔레옵 스택. 기성
vuer경로는 Vision Pro Safari 가immersive-vr세션에서 WebSocket 을 끊는 문제로 폐기했다 — 최소 HTML 3종 격리 테스트(WS 단독 ✅ / WebXR+WS ❌ / WebXR+fetch✅)로 원인을 전송 계층으로 특정하고 FastAPI + Three.js WebXR 로 전면 전환. - 실물 3구간 분리 아키텍처. Vision Pro → FastAPI
:8014→ 팔 브릿지:8013(게이트·캘리브·IK) → 로봇 컨테이너 joint 릴레이(신선도·클램프·워치독) → ros2_control 100Hz. 각 층이 실패 유형 하나씩을 담당해 사고 시 원인 층이 즉시 갈린다. - 8축 표준형 스키마. 물체 좌표(FK 역산 = 정답 누출)와 상수축(오른팔·머리·리프트)을 걷어내 state 8 in / action 8 out 으로 고정 — openpi 표준 예시와 같은 "자기 관절값만" 구조. 로봇 특화 판정은 학습·추론 어디에도 넣지 않아 가중치가 이식 가능하다.
- 통제된 학습 행렬. 태스크당 정확히 100 에피소드, 전 런 epoch 2.39
2.41 정렬, 지시문 문자열 단일 출처. P0P3 조합 15종 전부 — v8 30종(π0.5 15·GR00T 15) + v9 15종(π0.5 + 깊이 보조) 완결 — v9 는 실물 성능이 안 나와 배제. - 실기 66회차로 얻은 첫 증거. 병합 학습 모델이 학습에 없던 다물체 장면에서 지시문만으로 목표를 갈랐다(목표 혼동 3/10 → 1/20). 반대로 방해물 하나가 단일 학습 모델의 성공률을 80% → 30% 로 반토막 — 병목이 언어가 아니라 지각임을 수치로 확인.
- 다물체 장면이 다음 병목. 4과제 병합 v8 모델을 물체 5개 장면에 올리자 15/40 — 실패의 2/3 가 물체 선택이었다(학습 장면엔 물체가 2개뿐). 복합 문장 첫 L3 시도(Fixed Budget)는 2차 과제 성공 P0→P3 2/10 · P3→P0 6/10.
- YCB 객체만 사용. 수프 캔·Cheez-It 박스·Spam 캔·접시·그릇 전부 YCB 세트라 물리 모델이 있어 MuJoCo 등 가상환경에서 같은 실험을 재현할 수 있다.
조작자와 로봇을 한 화면에 — Vision Pro 를 쓴 조작자(오른쪽)의 양손 움직임을 FFW-BG2 가 그대로 따라간다 (외부 카메라, 2배속, 39초 전체).
같은 방식으로 수집한 양손 과제 — 오른손이 캔, 왼손이 Cheez-It 박스를 집어 옮겨 적재한다 (양손 적재 시험 수집분, 2배속).
| 양손 실물 조작 — 근접 | 양손 실물 조작 — 전경 |
|---|---|
 |
 |
| 파지·적재 디테일 (핵심 84초 구간) | 전체 작업 흐름: 캔 집기 → 박스 파지 → 이송 → 적재 (핵심 80초 구간) |
조작자 시점 → 시뮬 — 헤드셋 안에서 무엇을 보며 조작하는가.
| Vision Pro 착용자 시점 | MuJoCo 시뮬 |
|---|---|
 |
 |
| 로봇 카메라 피드(헤드·손목 시점 패널)를 보며 양손 트래킹으로 조작. 핀치 홀드 버튼과 입체/단안(STEREO·FLAT) 전환 UI | 그 조작이 만드는 시뮬 장면: 캔→박스 파지 |
실물 P3 수집 — 조작자 화면과 로봇 카메라를 나란히 (Pick up the Spam can and place it in the red bowl.)
| 조작자: Vision Pro 화면 | 로봇: 헤드캠 | 로봇: 왼손목캠 |
|---|---|---|
 |
 |
 |
| 수집 당시 헤드셋 안 화면 — 로봇 카메라 패널 3개를 보며 손 트래킹(관절 마커)으로 조작 | 그 조작이 만든 학습 데이터 (파지→이송→bowl 안착 전체) | 모델이 입력받는 손목 시점 (같은 에피소드) |
L3 실험용 원격 실험·모니터링 웹 — 로봇 PC(우분투)에서 서버를 띄우고 같은 내부망의 어느 기기에서든 브라우저로 접속해 L3 4방법 실험을 그대로 수행·기록하는 페이지. 아래는 Single(M0) 조건 한 회차(8배속): 가중치 선택 → 회차 시작 → 로봇 카메라 확인 → 정지 → 판정 기록.
| 화면 구성 (원본 해상도 스크린샷) |
|---|
왼쪽 위 외부 카메라 실시간 (사람 모니터링·기록 전용, 판정에 안 씀) · 왼쪽 가운데 로봇 카메라 토글 — 헤드캠·왼손목캠 = 모델이 실제로 보는 입력 · 왼쪽 아래 실행 패널: 방법(M0 Single / M1 Fixed Budget / M2 TTD vision gate / M3 Human Oracle), 1차·2차 지시문과 예산(P0 66초 · P3 52초), 가중치 선택([openpi] pi05_v8_p0123 · step 17899 · 6.34GB — HF에서 받은 것을 반입함→보관소로 등록, 목록 새로고침), 장면 물체 목록, 브릿지 로그 콘솔 |
오른쪽 회차 상태(정지/녹화 중 · 녹화 시간 · 기록 프레임 · 관절 age(E-Stop 감지) · 외부캠 1280×720@30 · 전환 신호(vision/timeout) · 게이트 카메라(TTD 회차에만) · 직전 저장분 · 중지 사유) · 판정 패널(1차/2차 성공·실패, 실패 유형 — 설계 §9 목록, 관찰 메모 → partial credit 0/0.5/1.0 자동 산출 → trial_meta.json·CSV 기록) |
회차마다 모델 입력 프레임·외부캠 영상·switch.log(전환 시각+2차 지시문)·trial_meta.json(조건+판정)이 자동 저장되고 HF result 브랜치 v8/L3_* 로 올라간다. 첫 결과(Fixed Budget, P0↔P3 각 10회)는 그 브랜치 README 에 요약돼 있다. 화면 녹화 원본은 HF result/media/l3_web_monitor/.
미리보기는 전부 2배속 GIF 다 (L3 웹만 8배속). 출처 — 외부 카메라 3컷: HF all_data 브랜치 joint_pred_collect/ (..._103213_003, ..._110654_008, ..._145632_006 의 cam_ext.mp4) · Vision Pro 시점 원본(1080p·88초): HF result 브랜치 media/visionpro_mujoco/ (Logic_Experiment 브랜치에서 옮김) · 실물 P3 세 컷: raw_v7_p3/..._20260818_162346_018 (45초·4캠) 그대로 · 시뮬 샘플: 여기. 실물 검증 회차 영상 전체는 HF result 브랜치.
이것은 개발이 아니라 실험이다. 목표를 사다리로 정의한다:
| 단계 | 내용 | 역할 |
|---|---|---|
| L1 | 단일 과제·깨끗한 장면 (P0~P3 각각, 1 파지 사이클) | 학습 |
| L2 | 병합 학습 + 다물체 장면에서 단일 지시문 평가 — 물건을 여러 개 놓아도 지시문에 맞는 것만 맞는 곳에 | 학습 + 평가 |
| L3 | LIBERO-Long 식 복합 프롬프트 ("A 하고 B 도 해라") 로 한 에피소드에 2 사이클 연쇄 | 평가 전용 — zero-shot |
연구 질문: L1·L2 데이터만 학습한 VLA 가, 한 번도 본 적 없는 복합 프롬프트(L3)를 수행할 수 있는가.
Important
복합(2사이클) 시연은 수집하지도, 학습하지도 않는다. 그걸 학습시키면 "되게 만든 것"이지 창발이 아니며 실험의 존재 이유가 사라진다. 실패해도 어느 지점에서 끊기는지(1사이클 후 정지, 프롬프트 절반만 실행, 다물체 장면 붕괴)가 그 자체로 발표할 성과다.
지키는 원칙 두 가지:
- 이식 가능한 가중치 — 로봇 특화 판정(그리퍼 엔코더 임계 등)을 학습·추론 어디에도 넣지 않는다. 모델 계약은 state 8축 in / action 8축 out 뿐이다.
- 재현 가능한 실험 — 태스크당 에피소드 수·epoch·지시문 체계 통일. 스텝은 변환본의 실측 프레임에서 자동 산출한다 (raw 20Hz 스냅샷 개수로 세면 epoch 이 2배로 튄다 — 한 번 겪고 규칙으로 박았다).
지시문 문자열은 이대로 수집·학습·평가에 쓰인다 (대문자·마침표·전치사까지 단일 출처. plate 는 on, bowl 은 in):
P0 Pick up the tomato soup can and place it on the red plate.
P1 Pick up the tomato soup can and place it in the red bowl.
P2 Pick up the Cheez-It box and place it on the red plate.
P3 Pick up the Spam can and place it in the red bowl.
물체 3종 × 목적지 2종 중 4칸을 쓴다. soup 만 목적지가 둘이라 언어로만 갈리는 쌍은 P0/P1 이고, P2·P3 은 물체가 다르다. 모든 태스크는 필요한 물체 2개만 놓은 깨끗한 장면(L1) 으로 수집하고, 다물체 배치는 평가(L2·L3)에서만 쓴다.
사용하는 객체는 전부 YCB Object and Model Set 의 표준 품목이다:
| 우리 이름 | YCB 객체 | 역할 |
|---|---|---|
| tomato soup can | 005_tomato_soup_can |
P0·P1 대상 (원통 파지) |
| Cheez-It box | 003_cracker_box |
P2 대상 (직육면체·폭 넓음 — 수집 전 그리퍼 개구 폭 확인) |
| Spam can | 010_potted_meat_can |
P3 대상 (soup 캔과 같은 "캔"이라 색·크기가 구분 단서) |
| red plate | 029_plate |
목적지 "on" |
| red bowl | 024_bowl |
목적지 "in" (둘 다 red — 형태가 구분 단서) |
YCB 를 고른 이유는 가상환경 이식성이다. YCB 객체는 메시·질량·관성 등 물리 모델이 공개돼 있어 MuJoCo 같은 물리 엔진에 그대로 올릴 수 있고, 우리 MuJoCo 씬도 이미 freejoint 물체와 캔→접시 거리로 성공을 자동 판정하는 π0.5 평가 씬을 갖고 있다. 실물에서 수집·학습한 과제를 같은 객체로 시뮬에서 재현·확장할 수 있게 처음부터 객체 선택을 맞춘 것이다.
Vision Pro 를 vuer 기반 서버에 연결하는 표준 경로로 시작했다. 인증서("Not Secure" — visionOS 는 프로필 설치와 Full Trust 토글을 별개로 취급), pass-through 권한 무시 등 여러 벽이 있었지만 결정타는 WebSocket 이 immersive-vr 세션에 들어가는 순간 끊기는 것이었다. 인증서를 바꿔도 재현됐다.
원인을 추정으로 두지 않고 xr_capability_tests/ 에 최소 HTML 3개를 만들어 격리했다:
| 테스트 | 결과 |
|---|---|
| WebSocket 단독 | ✅ |
| WebXR + WebSocket | ❌ 세션 진입 직후 소켓 끊김 (반복 재현) |
WebXR + fetch() POST |
✅ 35초+ 연속 안정 |
결론: WebXR 자체는 문제가 없고 WebSocket 이라는 전송 계층만 immersive-vr 과 충돌한다. 공식 ROBOTIS VR 스택(robotis_vuer, Meta Quest 3 전용)은 Vision Pro 에서 구조적으로 쓸 수 없었다. 제어할 수 없는 스택 위에서는 디버깅이 불가능하다 — 통신 계층을 전부 우리 손에 쥐는 방향으로 전환했다.
- Vision Pro 는 Safari 로 접속해 손목 4×4 행렬 + 핀치를
POST /pose로 전송 (10Hz → 30Hz) - 로봇 1인칭 카메라 4대는 1920×480 아틀라스 한 장으로 합성해 MJPEG 스트림 하나로 보내고, VR 공간의 가상 디스플레이에 스테레오(왼눈/오른눈 레이어)로 표시 — 스트림을 여러 개 만들지 않아 GPU 업로드가 프레임당 1회
- PAPRLE 의
TeleopLeader인터페이스에fastapi_leader를 구현해 물리 엔진과 분리 (IK 는 pinocchio) - WSL2 에서 카메라 3대 렌더가 스텝의 94%(177ms)를 먹어 5.3Hz 였던 루프를 RTX 4090 네이티브 우분투로 옮겨 1.8ms/step · 49.6Hz 로 회복
이 구조로 MuJoCo 시뮬레이션 조작·수집이 안정화됐다 (2026-07 초).
실물 FFW-BG2 는 층을 하나씩 추가해 연결했다:
Vision Pro (WebXR 손 트래킹, POST /pose)
→ FastAPI :8014 pose 보관 · 카메라 4채널 아틀라스 스트림 · 20Hz 레코더
→ 팔 브릿지 :8013 MuJoCo-자세 게이트(±0.15rad) → 캘리브(3s 정착+40샘플)
→ 델타 EEF → PAPRLE pinocchio IK → target_qpos
→ joint 릴레이 로봇 PC 컨테이너: 신선도 검사 · 스텝 클램프(0.1rad)
· following-error 워치독(0.15rad) → JointTrajectory
→ ros2_control 100Hz → 다이나믹셀(RS-485) → 실물 FFW-BG2
각 층이 하나의 실패 유형을 담당한다 — 게이트는 이상 자세 진입을, 클램프는 IK 튐을, 워치독은 추종 실패를 막는다. 컨테이너에는 아무 패키지도 설치하지 않고 릴레이를 stdin 으로 실행하며, 공식 bringup 이 컨트롤러 토픽을 remap 해 직접 발행을 막기 때문에 base 를 뺀 arm-only 커스텀 bringup(19관절) 을 따로 둔다.
카메라는 ZED Mini 스테레오(헤드 좌/우) + RealSense D405(양 손목). 학습 해상도와 라이브 해상도가 달라 시연이 실패한 적이 있어(launch 기본 424×240 vs 학습 640×480) 카메라 프로파일을 명시하는 것이 런북의 첫 줄이다.
수집 방침은 사고에서 배웠다: 에피소드 "삭제"는 rm 이 아니라 _rejected/ 이동, 재파지·회복 시연은 드롭하지 않고 유지(가치 있는 시연), 레코더는 서버 기동과 별개로 POST /record/start 를 명시 호출(안 하면 조용히 아무것도 남지 않는다).
| 세대 | 스키마 | 무엇을 했나 | 왜 넘어갔나 |
|---|---|---|---|
| v3 | state 25 / action 17 | 물체 좌표(캔·접시 3D)를 FK 역산으로 넣고 리프트를 액션에 추가. loss 0.032·상관 0.95 | 시연은 파지 직전 이탈 반복 — 액션 예측 정확도와 파지 성공률은 별개. 좌표가 "앞으로 잡을 지점"이라 정답 누출 |
| v4 | state 25 (내용만 4변형) | 몸통 고정(lift −0.22) + 왼손. 카메라·좌표계 4모델 통제 비교 | MSE 순위가 카메라 수 순서와 정확히 일치 → 효과 분리 불가. 결정적으로 state 가 모델에 도달하지 않는 결함(discrete_state_input 미설정, 캔 좌표를 바꿔도 예측 Δ 0.000) — 4모델 비교는 사실상 카메라 개수 비교였다 |
| (정규화) | — | 상수축 q99−q01=0 이 quantile 정규화에서 엔코더 노이즈를 ±1,900 으로 증폭. clip_gradient_norm 이 전체 벡터에 걸리는 스칼라라 왼팔 gradient 까지 1/50 로 잘림 |
fix_norm_stats.py 도입: grad_norm>1 스텝 36/95 → 0/95, 스파이크 23개 → 0개. v4 전량 재학습 |
| v5→v6 | state 8 / action 8 | 왼팔7+왼그리퍼1 표준형. 물체 좌표·상수축(오른팔·머리·리프트) 전부 제거 | 3프레임워크 실물 검증: π0.5 MSE 0.01744 로 1위(GR00T 0.01889, RDT 0.02563) — 그것도 4.4배 적은 학습량으로. 단 지시문이 하나(put the can on the plate)라 언어가 죽어 있는 상태 |
| v7 | 8 / 8 (무변경) | 언어 조건화 1차: P1 100ep, P0+P1 병합 187ep. 두 서버 분업(21h → 9h) | 학습·실기는 성공했으나 데이터 규모 불균일(P0 87 · P2 81ep)과 epoch 흩어짐(3.2~4.8)으로 논문용 비교로는 부적합 |
| v8 | 8 / 8 | 태스크당 100ep · epoch 2.4 · 지시문 통일. P0~P3 조합 15종 × π0.5·GR00T = 30종 완결 | 통제된 기준선 완성. 실기 결과는 4부 |
| v9 ★실물 배제 | 8 / 8 (+깊이 라벨) | v8 과 동일 레시피 + Depth-Anything-V2 깊이 보조 손실. π0.5 15종 완결 | 실기가 드러낸 지각 병목을 겨냥. 실기 비교 진행 중 |
학습 인프라는 임대 GPU 서버(RTX 6000 Ada ×3, 공유)의 빈 GPU 자동 투입 큐로 돌아간다 — 카드가 비면 잡고, 완료되면 HuggingFace 로 자동 업로드한다. P3 확장기(08-13~26)에는 H100 을 빌려 π0.5 의 긴 런을 분담했고(스텝 3.2배 빠름), 그 환경 구성·사고 기록은 Train 브랜치 H100_분업학습_환경구성_기록/ 에 남겼다(종료).
옛 통합 브랜치 이름 LIBERO_training 의 유래. v6 까지는 단일 물체·단일 지시문·단일 파지였고, 다음 단계를 설계하며 LIBERO 벤치마크(특히 LIBERO-10, 통칭 LIBERO-Long) 를 BDDL 원문까지 대조했다. 단순 태스크와 Long 의 차이는 목표가 술어의 결합이라는 것뿐이다:
;; libero_object (단순) — 우리 v6 와 같은 구조
(:goal (And (In alphabet_soup_1 basket_1_contain_region)))
;; libero_10 (Long) — 하위 과제 2개의 결합
(:goal (And (In alphabet_soup_1 basket_1_contain_region)
(In cream_cheese_1 basket_1_contain_region)))가져온 결정적 관찰 두 가지:
- 같은 장면, 다른 지시문. LIBERO 의 한 장면(
LIVING_ROOM_SCENE2)에는 태스크가 두 개 있다 — 물체 배치가 같고 지시문이 목표를 결정하며, 장면에는 목표가 아닌 방해물도 있다. 이것이 언어 조건화가 실제로 학습되는 조건이다. - 단일 지시문에서는 언어가 죽는다. 지시문이 하나뿐이면 텍스트를 무시하는 것이 최적해가 된다 — 우리 v6 가중치가 정확히 그 상태였다.
이 관찰이 v7/v8 태스크 행렬의 설계 원리가 됐다: 물체·목적지를 조합해 언어만이 분기 단서인 쌍을 만들고, 단독 학습(언어 죽음)을 대조군으로 둔다. LIBERO 데이터나 시뮬레이터를 쓰는 것이 아니라 그 과제 설계 문법을 실물 수집에 이식한 것이다. 덤으로 우리 셋업은 에피소드 안의 하위 과제 경계가 그리퍼 개폐 신호로 자동 검출된다 — LIBERO 에는 없는 라벨이다.
가중치 행렬 — 조합이 각각 다른 질문을 던진다:
| 조합 | 물체 | 목적지 | 언어가 골라야 하는 것 |
|---|---|---|---|
| P0+P1 | 같음 | 다름 | 목적지 |
| P0+P2 · P1+P3 | 다름 | 같음 | 물체 |
| P0+P3 · P1+P2 · P2+P3 | 다름 | 다름 | 아무거나 (가장 쉬움) |
| 3종 조합 4개 · P0+P1+P2+P3 | — | — | 상호 간섭 여부 · 전체 병합 (L3 피험체) |
| P0 / P1 / P2 / P3 단독 | — | — | 대조군 (언어 죽음이 정상) |
총 15조합. v8 은 π0.5·GR00T 둘 다, v9 는 π0.5 로 학습했다 (HF pi05·groot 브랜치).
실기는 v8 만 쓴다 — v9 배제 사유는 4부.
이 행렬은 L2(언어 선택) 측정이자 L3 zero-shot 시험의 피험체다. 복합 프롬프트 연쇄가 성립하는 쌍은 물체가 다른 쌍(P0+P2, P0+P3, P1+P2, P2+P3) 이다 — 물체가 둘이어야 1절이 끝난 장면 자체가 진행 상태를 담는다. L3 평가는 지시문 전환 방식이 다른 4방법으로 한다 — M0 Single(복합 문장 한 문장, 전환 없음) · M1 Fixed Budget(1차 지시문을 예산 시간 뒤 2차로 교체) · M2 TTD(비전 게이트가 1차 완료를 감지하면 교체) · M3 Human Oracle(사람이 전환). 프로토콜은 LAB/docs/30_회차_실행/L3_실험.
판정은 세 갈래다: 지시문대로 정답 / 엉뚱한 쪽으로 감(언어 무시의 직접 증거) / 과제 실패. 로봇에 올리기 전 오프라인 프로브(eval_prompt_swap.py — 같은 관측에 지시문 2종을 넣어 예측 발산 측정)로 선별한다.
| 조건 | 가중치 | 학습 범위 | 장면 | 지시 | 성공률 |
|---|---|---|---|---|---|
| P0 기준선 | v6_std/2999 | 접시만 | 캔+접시 | 접시 | 8/10 |
| P1 기준선 | p1/4999 | 그릇만 | 캔+그릇 | 그릇 | 6/10 |
| P0 + 방해물 | v6_std/2999 | 접시만 | 캔+접시+그릇 | 접시 | 3/10 |
| P1 + 방해물 | p1/4999 | 그릇만 | 캔+그릇+접시 | 그릇 | 4/10 |
| p0p1 → 접시 | p0p1/7999 | 양쪽 | 캔+접시+그릇 | 접시 | 6/10 |
| p0p1 → 그릇 | p0p1/7999 | 양쪽 | 캔+접시+그릇 | 그릇 | 5/10 |
| p0p1 연쇄 문장 | p0p1/7999 | 양쪽 | 캔+접시+그릇 | 두 작업 한 문장 | 0/6 |
- 병합 학습이 언어 분기를 만들었다. p0p1 의 평가 장면(접시+그릇 동시)은 학습에 없던 조합인데 지시문만 바꿔 접시 60% / 그릇 50% 를 수행했고, 목표 혼동이 단독 P1 의 3/10 에서 1/20 로 줄었다. 장면이 답을 결정하지 못하는 배치에서 지시를 따랐으므로 scene shortcut 이 아니다 — 조합 일반화 부분 창발의 첫 실기 증거.
- 병목은 지각이다. 방해물 하나로 80→30%, 60→40%. P1 은 접시·그릇을 붙여 놓으면 0승 3패(떼어 놓으면 3승 1패)로 목표를 못 고르고, P0 은 실패 6건 중 5건이 파지 실패다. 이 두 실패 모드(헤드캠 경계 분리 / 손목캠 거리 추정)가 v9 의 설계 근거가 됐다.
- 같은 캔 연쇄(P0+P1)는 구조적으로 불가. 6회 전패. 캔을 원위치로 되돌리자 또 접시로 갔다 — 정책 입력은 현재 3캠+관절+고정 문장뿐이라 장면이 같으면 같은 행동을 한다. LIBERO-Long 이 "물체 2개"로 설계된 이유의 실증 반례.
- 플랫폼 실패와 정책 실패는 분리해 센다. 팔꿈치 과부하(ID:34)로 팔이 죽은 회차, 과제를 완수한 뒤 멈추지 못해 접시를 쳐서 떨어뜨린 회차가 섞여 있다. 보정하면 P0 기준선의 정책 순수 실패는 0~1건.
| 날짜 | 가중치 | 장면 | 결과 |
|---|---|---|---|
| 08-24 | v8 단독 4종 (v8_p0/3449 · p1/4999 · v8_p2/5499 · v8_p3/4049) |
과제별 깨끗한 장면(물체 2개), 각 10회 | P0 8/10 · P1 6/10 · P2 3/10 · P3 3/10 = 20/40 |
| 08-25 | v8_p0123/17899 (4과제 병합) |
물체 5개 전부 놓은 장면, 과제별 10회 | P0 5/10 · P1 3/10 · P2 5/10 · P3 2/10 = 15/40 |
| 08-26 | v8_p0123/17899 — L3 Fixed Budget (M1) |
복합 연쇄 P0→P3 / P3→P0, 각 10회, 예산 66초·52초 | 1차 9/10 → 2차 2/10 / 1차 1/10 → 2차 6/10 |
- 납작한 물체가 단독에서도 약하다. Cheez-It 박스·Spam 캔은 30% — 위에서 누르며 접근하다 파지에 실패하는 유형이 다수. v9(깊이 보조)의 표적.
- 병합 모델의 실패 2/3 는 물체 선택이다. 5물체 장면에서 캔 대신 박스를 옮기거나 옆 물체에 걸린다. 학습 장면엔 목표 물체와 목적지 2개뿐이라 다물체 배치 자체가 분포 밖 — 데이터가 다음 병목이다.
- 연쇄는 순서에 민감하다. P0 를 먼저 하면 1차는 되지만 예산 뒤 P3 로 넘어가 2/10, 반대 순서는 1차부터 무너진다. 회차 기록(모델 입력 프레임·
switch.log·판정)은 HFresult브랜치v8/.
같은 가중치·같은 장면·같은 예산(B0 66초 · 타임아웃 118초)에서 언제 2차 지시문으로 바꾸는가만 달리했다. 부분점수는 1차만 성공 0.5 · 둘 다 1.0.
| 조건 | 방법 | 회차 | 1차 | 2차 | 최종 | 부분점수 |
|---|---|---|---|---|---|---|
L3_single_P0P3 |
M0 Single (한 문장, 전환 없음) | 10 | 6 | 3 | 3 | 0.45 |
L3_fb_P0P3 |
M1 Fixed Budget (66초에 전환) | 10 | 9 | 2 | 2 | 0.55 |
L3_fb_P3P0 |
M1 (역순) | 10 | 1 | 6 | 1 | 0.35 |
L3_ttd_P0P3 |
M2 TTD (legacy 게이트) | 10 | 7 | 2 | 1 | 0.45 |
L3_ttd_P3P0 |
M2 (역순) | 8 | 0 | 3 | 0 | 0.19 |
L3_ttdspec_P0P3-1 |
M2 TTD (규격 §6 게이트) | 10 | 3 | 2 | 1 | 0.25 |
L3_ttdspec_P0P3-2 |
〃 (같은 조건, 이어서) | 10 | 7 | 4 | 4 | 0.55 |
- 순서가 방법보다 크다.
P0→P3는 어느 방법에서든 1차 69/10 인데1/10 이다. Spam 캔(P3)을 먼저 집는 것 자체가 안 된다 — 납작한 물체 파지 실패라는 같은 병목이다.P3→P0는 1차 0 - 시계(M1)가 카메라(M2)보다 나쁘지 않다. 전환 시점을 사람이 안 정하는 두 방법의 부분점수가 0.55 / 0.25~0.55 로 겹친다. 게이트가 아직 이득을 못 만든다.
-1과-2는 기록상 조건이 완전히 같다 (방법·과제·예산·체크포인트·설정·전환키). 코드 차이는gate.jsonl기록 추가뿐이고 게이트 판정 로직·임계값은 그대로다. 그런데 1차가 3/10 → 7/10 으로 갈렸다 — 장면 배치·조작 쪽 요인이고 아직 규명되지 않았다. 둘을 한 조건으로 합쳐서 보면 안 된다.
L3 의 M2(TTD)는 "1차가 끝났는지"를 카메라로 판정한다. 가상환경에서 성립한 규격이 실물에서 그대로 깨졌고, 무엇이 달랐는지를 실측으로 좁혔다.
| 규격의 전제 | 실물에서 | 실측 |
|---|---|---|
| 장면에서 대상 물체만 변한다 | 로봇 자기 팔이 작업영역의 15.8~17.9% 를 덮고 있다가 비켜난다 | 그 자리가 영영 changed AND NOT moving |
| 조명이 일정하다 | 팔이 나가면 책상이 배율 1.12배로 밝아진다 | ref·cur 상관 0.66~0.80 (내용이 아니라 밝기 변화) |
| 안 변한 화소는 값이 같다 | 합쳐서 static_changed 가 작업영역의 40~52% |
규격 기준 0.05% 의 800~1000배 |
- 카메라 흔들림은 원인이 아니다. 675프레임 위상상관 이동 0.10
0.31px, 특징점 정합(ORB+RANSAC 270440점) 배율 0.9982~1.0001 — 고정이다. diff_tol×motion_tol25개 조합 전부 수용조건을 못 넘겼다.- 주기도 다르다. 규격은 20Hz 전제인데 실측 18.3Hz —
persist 25프레임이 1.25초가 아니라 1.37초에 해당한다. - 지금은 임계값을 규격 원값 그대로 두고
gate.jsonl(20Hz held 시계열)을 모으는 중이다. 재산정 절차와 도구:LAB브랜치docs/30_회차_실행/L3_실험/게이트_임계값_재산정_2026-08-28.md,pipeline/30_trial/gate_calibrate.py.
납작한 물체의 파지 실패(위 08-24 결과의 P2·P3 30%)를 깊이로 보완하려던 세대다. 학습·등록·실행 경로는 전부 살아 있지만 실물에서 쓰지 않는다.
- 실기 1회차
openpi_pi05_v9_p0123_17899 / L3_ttd_P0P3— 부분점수 0.0, 관찰 "그냥 못하고 있어" - v8 대비 파라미터 차이는
depth_head두 개(bias·kernel)뿐이고 그 헤드는loss안에서만 쓰인다. 추론 경로(FFWSG2InputsStdDepth→FFWSG2InputsStd)는 v8 과 동일하다 — 즉 추론 시 깊이가 안 들어간다. - 우리가 원한 방식으로 π0.5 를 고친 것이 실제 구동 방식과 맞지 않았다는 것이 현재 판단이다.
가중치·설정은
weights_manifest.json에 남겨 두었으므로 되살리려면 그대로 쓸 수 있다.
Important
v9 는 실기에서 쓰지 않는다. 실물 1회차 부분점수 0.0, 관찰 "그냥 못하고 있어".
아래는 무엇을 만들었고 왜 안 됐는지의 기록이다 — 결과는 4부 참고.
핵심은 추론 경로에 깊이가 안 들어간다는 점이다: depth_head 는 loss 안에서만 쓰이고,
FFWSG2InputsStdDepth 는 추론 시 FFWSG2InputsStd 를 그대로 부른다.
즉 v9 는 "깊이를 보고 판단하는 모델"이 아니라 학습 때 깊이로 표현을 규제한 v8 이다.
v8 과 데이터·스텝·배치·학습률·epoch 이 완전히 동일하고, Depth-Anything-V2(ViT-L) 로 오프라인 사전계산한 상대 깊이 라벨에 대한 보조 손실(λ=0.05) 만 더했다. SigLIP 이미지 토큰(16×16 그리드)마다 14×14 깊이 패치를 선형 예측해 MSE 로 채점하며, 헤드캠의 기하 증강(crop·회전)은 라벨에도 동일 적용해 픽셀 정렬을 지킨다. diffusion(flow matching) 액션 경로는 무변경이고, 추론 시 깊이 입력이 없으면 헤드는 쓰이지 않아 실행 인터페이스가 v8 과 같다.
Warning
v9 체크포인트에는 depth_head 파라미터가 들어 있어 v8 코드로는 로드되지 않는다. Train 브랜치 pipeline/overlay/openpi_port/ 를 적용하고(00_setup/03_apply_overlay.sh openpi) config 이름 pi05_v9_<combo>_lora 로 로드할 것 (v8 config 로 열면 depth_head 가 버려지고 로드된다 — 추론엔 깊이 입력이 없어 동작은 같다).
상세(라벨 파이프라인·파일별 코드 변경·손실식·엣지 학습 방식)는 HF pi05 브랜치 README 또는 LAB 브랜치 docs/20_가중치/03_v9_가중치.md.
학습은 Train 브랜치 하나로 새 GPU 서버에서 재현된다 (클린룸 2회 검증, 상세는 그 브랜치 README·docs/10_환경_구성/01_새_GPU서버.md). 프레임워크 수정분은 업스트림(openpi 15a9616a, GR00T)에 기준 커밋 고정 + 해시 검증으로 덧씌운다:
git clone -b Train --single-branch https://github.com/logan0741/ETRI_VR_Robotics_data_research train && cd train
. pipeline/env.sh # VLA_ROOT 등 경로 변수
bash pipeline/00_setup/02_bootstrap_server.sh env # uv → openpi/groot/rdt clone + overlay → venv 3종 → 베이스 가중치
bash pipeline/00_setup/02_bootstrap_server.sh data # HF 원본 → LeRobot 데이터셋 (P0~P3)
# v8: 실측 프레임으로 스텝 산출 → 빈 GPU 자동 투입 큐 (완료 시 HF 업로드)
python pipeline/30_train/01_gen_runs_v8.py --stage 1
RUNS=pipeline/30_train/runs/runs_v8_stage1_pi05.json GPUS=auto bash pipeline/30_train/03_run_queue.sh
# v9: 깊이 라벨 사전계산(DA-V2) → 조합 데이터셋 라벨 링크 → 큐
python pipeline/20_dataset/06_precompute_depth.py can_left_v8_p0 can_left_v8_p1 can_left_v8_p2 can_left_v8_p3
python pipeline/20_dataset/07_build_depth_links.py
RUNS=pipeline/30_train/runs/runs_v9_rtx.json GPUS=auto bash pipeline/30_train/03_run_queue.sh정규화 통계는 compute_norm_stats.py 직후 fix_norm_stats.py 를 반드시 적용한다 (건너뛰면 크래시가 아니라 조용한 학습 품질 저하 — 04_train_pi05.sh 가 자동으로 한다). 체크포인트만 받을 때는 GIT_LFS_SKIP_SMUDGE=1 git clone -b <branch> --single-branch 후 git lfs pull --include=... 로 필요한 것만.
두 실행 브랜치는 문서 폴더 번호 = 파이프라인 폴더 번호 로 맞춰져 있다 (
docs/30_회차_실행↔pipeline/30_trial). 각 폴더의README.md가 그 단계의 순서를 갖는다.
목적별로 나뉘어 있다. 하나만 받으면 그 일은 끝까지 된다 (2026-08-27 재구성).
| 브랜치 | 무엇을 하나 | 시작점 |
|---|---|---|
VisionPro |
데이터 수집 — Vision Pro 로 조종해 에피소드를 모으고 LeRobot 형식으로 변환 | README.md 하나로 실행 |
LAB |
실물 평가 — 가중치를 로봇에서 돌리고 회차 기록·판정을 남긴다 | README.md 하나로 실행 |
Train |
학습 — 새 GPU 서버에서 π0.5·GR00T·RDT 를 학습하는 파이프라인(단계별 코드·overlay·정규화 통계) + 왜 이렇게 학습하는지(연구 방향)·환경 구성·확장 가이드 | README.md → docs/00~08 |
docs-archive |
세션 기록·인수인계·지난 버전(v3·v4·v6) 결과 보존 (실행용 아님) | 옛 경위를 찾을 때 |
main |
프로젝트 입구 (이 문서). 코드 작업 없음 | — |
# 읽기만 하면 되면 (HTTPS) — 올릴 권한이 있으면 git@github.com:logan0741/… 로 바꾼다
R=https://github.com/logan0741/ETRI_VR_Robotics_data_research.git
git clone -b VisionPro $R etri-visionpro # 수집
git clone -b LAB $R etri-lab # 평가
git clone -b Train $R etri-train # 학습 (GPU 서버)
# ★폴더 이름은 아무거나 좋다 — env.sh 가 파일 위치에서 저장소 뿌리를 찾는다.
# 그래서 세 브랜치를 한 컴퓨터에 나란히 둘 수 있다.
# 받은 뒤 이 셋이면 하루가 돈다 (LAB 예)
bash pipeline/00_setup/00_install_deps.sh --check # 외부 의존·자격증명·저장 자리 점검
bash pipeline/30_trial/00_session.sh start # 아침에 연다
bash pipeline/30_trial/00_session.sh stop # 저녁에 닫는다 (다음날 start 로 이어진다)처음이라면 각 브랜치의 [docs/00_환경_준비/00_처음_시작.md] 부터 본다 — 깃허브 SSH 키 만들기,
로봇 SSH 연동(ssh-copy-id), 자격증명·토큰을 어디서 받아 어디에 넣는지가
단계마다 "이렇게 나오면 성공" 과 함께 적혀 있다. 받은 뒤 한 줄이면 지금 상황을 알려 준다:
bash pipeline/00_setup/00_install_deps.sh --check
# ▶ 처음이다 / ▶ 설치는 끝났고 아직 안 돌렸다 / ▶ 이어하기
# + 로봇 접속 네 줄 (ping · 전에 접속했나 · 키 · 컨테이너)clone 하나로 끝까지 돈다. 데이터·회차 기록·실험 상태·로그가 전부 clone 안에
쌓이고(training_datasets/ · pipeline/_state · pipeline/_logs), 저장소 밖에 두는 것은
자격증명과 TLS 인증서뿐이다. 절차는 각 브랜치 README.md 에 상황별로 정리돼 있다
(0 상황 판별 · A 처음 세우기 · B 하루 시작/종료/이어하기 · C 운용 · D 업무 전환 ·
E status 읽는 법 · F 막혔을 때). docs/ 는 고장났을 때 원인을 찾는 용도다.
같은 로봇·같은 카메라·같은 FastAPI 포트(:8014)를 쓰고, relay 는 둘 다
로봇 컨테이너 안에서 돈다(파일은 브랜치마다 다르다).
★두 스택은 포트가 겹쳐 동시에 못 띄운다. 수집에서 평가로 넘어갈 때는 브리지·FastAPI 를 내리고 로봇 컨테이너 안의 relay 유령까지 죽인 뒤 다시 올린다.
| 포트 | VisionPro |
LAB |
|---|---|---|
| 8013 | 텔레옵 브리지 (VR 손 → 관절) | 추론 브리지 (가중치 → 관절) |
| 8014 | FastAPI (카메라·레코더·VR 화면) | FastAPI (카메라 중계) |
| 8017 | 관절예측 브리지 (곁가지) | 회차 녹화 웹 UI |
★bringup 도 다르다. 수집은 공식 bringup, 평가는 arm-only bringup 이다 —
공식 bringup 이 /arm_l_controller/joint_trajectory 를 /leader/... 로 리맵해서
직접 발행해도 로봇이 안 움직이기 때문이다. arm-only 자산은
LAB/pipeline/10_robot/robot_container/ 에 있다
(로봇 컨테이너의 /tmp 에만 있던 것을 2026-08-31 에 회수했다 — /tmp 는 컨테이너를
다시 만들면 사라진다).
VisionPro |
LAB |
|
|---|---|---|
| VR 헤드셋 | 필요 | 불필요 |
| 저장 | real_collect_v7/<과제>/ — 20Hz 전체 관측 |
trial_records_v7/<가중치>/<조건>-<묶음>/ — 추론당 1장 |
| 오른팔을 정하는 곳 | VR 브리지의 상수 | 브리지의 right_latched (RESUME 순간 실측) |
| 리프트를 막는 층 | 런처 1층 | 런처 + 브리지 클램프 + lift_direction=0 = 3층 |
한쪽 내용이 필요하면 그 브랜치의 문서를 본다. 코드를 가져다 섞지 않는다 — 브랜치마다
경로 전제가 다르다. VisionPro/docs/20_로봇_기동/02_오른팔_리프트_해제.md · LAB/docs/10_로봇_기동/01_오른팔_리프트_해제.md 에
동결을 푸는 법이, 두 브랜치의 docs/00_환경_준비/05_저장_위치_바꾸기.md 에 저장 위치를 옮기는 법이 코드 근거와 함께 적혀 있다.
인수인계로 넘길 때는 두 브랜치의 README.md 만 주면 된다 —
처음 세우기부터 업무 전환까지 상황별로 있다. 검증 기록(도커 경계 포함)은
docs-archive/70_실험기록 에 있다.
경로를 코드에 박지 않는다. 각 브랜치의 pipeline/env.sh·env.py 가 파일 위치에서
저장소 뿌리를 찾아내고, 등록표의 $REPO 토큰도 실행할 때 치환된다.
깃허브에 못 올리는 것은 가중치 실물(하나에 6~25GB, 파일 100MB 제한) · 수집 원본 ·
자격 증명 셋뿐이고, 목록(weights_manifest.json)에 HF 어디서 받는지 적혀 있다.
실물이 없으면 미보유 로 알려주고 회차는 시작되지 않는다.
재구성 전의 브랜치 12개는 삭제했고, 각 마지막 커밋을 archive/<브랜치> 태그로 남겼다 (git checkout archive/v4 처럼 언제든 꺼낼 수 있다).
내용은 전부 VisionPro·LAB·Train·docs-archive 에 더 새 버전으로 있다.
| 태그 | 무엇이었나 |
|---|---|
archive/in_mac archive/wsl2-local archive/for_imac_GPU_com archive/7.10_ai_limit |
초기 환경 이식(vuer 시대) · MuJoCo UI · 자체 FastAPI 전환기 (2026-07 초) |
archive/ai_worker_direct archive/Logic_Experiment archive/wip_local-changes-on-logic-experiment |
실물 FFW 연결 1차 · 다이나믹셀 read-cycle 대응 (Vision Pro 시점 영상은 HF result/media/visionpro_mujoco/) |
archive/experiment_vision-teleop-assist-control archive/gpu-ubuntu-real-verify archive/docs_claude-code-cli-ubuntu |
시야 기반 보조 제어 · π0.5/GR00T 첫 GPU 실행 확인 · CLI 환경 문서 |
archive/verify_assist-phase2 archive/v4 |
분리모델(헤드→리프트/손목→팔) 실물 시연 · v4~v6 세대 스냅샷 (2026-08 초) |
branch-docs 는 2026-08-28 에 docs-archive 로 합쳐졌다.
LIBERO_training(재구성 이전 통합 브랜치)은 2026-08-31 에 전수 대조를 마쳐 삭제해도 된다.
파일 386개 중 328개는 다른 브랜치에 내용까지 같은 사본이 있고, 나머지 58개(재편 이전
이름의 스크립트·문서)는 docs-archive/10_옛브랜치_문서/LIBERO_training/_재편이전_스냅샷/ 에
바이트 동일하게 보관했다. 어디에도 없는 파일은 0개다.
정본 ETRI7203/ETRI_VR_Robotics_data_research · 미러 logan098/...
브랜치는 목적별로 나뉘어 있고, 각 브랜치의 README 만 읽으면 실행까지 가능하다 (2026-08-26 재구성):
| HF 브랜치 | 내용 | 이런 목적이면 |
|---|---|---|
main |
브랜치 안내 · 연구 방법 + 원본 시연 데이터 data/raw/P0~P3 (태스크당 100ep, 에피소드별 tar) |
원본으로 직접 가공·학습 |
pi05 |
π0.5 가중치 v8·v9 각 15종 + 가공 LeRobot 데이터셋(data/v8) + 깊이 라벨(data/v9) + 레시피·실기 결과 문서 |
π0.5 실행·재학습·비교 |
groot |
GR00T N1.7 가중치 v8 15종 + GR00T 형식 데이터셋(data/v8/*_groot) + 문서 |
GR00T 실행·재학습 |
rdt |
RDT-1B 가중치(v6) + 데이터셋 + 정규화 통계·언어 임베딩 부속 | RDT 실행·재학습 |
result |
실물 로봇 회차 기록 — 모델이 실제로 본 프레임 + 판정·switch.log·bridge.log (v8/standalone_20260824 · v8/p0123_standalone_20260825 · v8/L3_fixed_budget_20260826) + 시연 영상 media/. v6·v7 회차는 all_data/result_pre_v8/ |
실기 결과 검증·재분석 |
all_data |
학습 서버 작업 디렉토리 tar + H100_분업학습_환경구성_기록/ + 사양·성능 문서 + v8 이전 가중치(models_pre_v8/)·실기 기록(result_pre_v8/)·초기 데이터 |
환경 통째 복원, 중간 산출물 |
HF 의 LIBERO_training 은 재구성 이전의 통합 브랜치로, 내용이 위 브랜치로 전부 옮겨졌고 삭제 예정 (v4 는 2026-08-27 삭제).
GitHub 쪽도 같다 — 코드·문서는 VisionPro · LAB · Train 으로 옮기고 옛 브랜치는 archive/* 태그로만 남겼다.
VisionPro·LAB·Train 브랜치의 docs/ 는 목적별 번호 폴더다 (VisionPro/docs · LAB/docs · Train/docs). 정의서·초기 실행보고서 등 이력성 문서는 docs-archive 브랜치로 분리돼 있다.
| 브랜치 · 폴더 | 무엇을 찾을 때 | 대표 문서 |
|---|---|---|
VisionPro/docs/10_시뮬레이션/ |
Vision Pro → MuJoCo 텔레옵·수집 · 보조제어 이론 | 01_무조코_컨트롤러와_저장.md · 02_가상환경_데이터_수집.md · 03_비전프로_맥_설정.md · 이론_보조제어/(시야 기반 거리·높이·속도 제어 6종) |
VisionPro/docs/30_텔레옵_수집/ |
실물 수집 절차 | 02_E2E_수집_학습_시연_가이드.md · 01_왜_공식스택이_아닌가.md · 04_v4_왼손수집_런북.md (웹UI·오른팔은 docs/20_로봇_기동/) |
LAB/docs/30_회차_실행/ · docs/20_가중치/ |
실험 설계·가중치·실행 | L3_실험/ (4방법·게이트 규격·임계값 재산정) · 01_가중치_실행_런북.md · 02_실물평가_운영서.md · 02_v8_가중치.md · 03_v9_가중치.md |
두 브랜치 docs/00_환경_준비/ |
실물 연결 구조·운영·안전 | 00_아키텍처_및_네트워크.md · 01_직접연결_구성요소.md · 03_운영_가이드.md · 04_안전_체크리스트.md · 05_저장_위치_바꾸기.md · 07_트러블슈팅_카메라.md |
두 브랜치 README.md |
실행은 이것 하나로 — 상황 판별·처음 세우기·하루 운영·업무 전환 | |
두 브랜치 docs/00_환경_준비/00_처음_시작.md |
아무것도 없는 컴퓨터에서 (SSH 키·로봇 접속·토큰) | |
VisionPro/docs/20_로봇_기동/ |
실물 기동 준비 | 01_자세초기화_메모.md · 02_오른팔_리프트_해제.md · 03_로봇_웹UI_사용법.md |
VisionPro/docs/40_녹화_복구 · 50_데이터셋 · 60_관절예측 |
영상 복구 · LeRobot 변환 · 관절예측 수집(:8016) | 각 폴더 README.md · 01_관절예측_수집_런북.md |
LAB/docs/10_로봇_기동/ · 40_분석/ |
로봇 기동 · 판정과 정리 문서 | 01_오른팔_리프트_해제.md · 각 폴더 README.md |
Train/docs/ |
학습 — 연구 방향·환경 구성·데이터·모델별 학습·확장·운영 | 00_전체흐름_단계별.md · 00_연구방향/ ~ 50_확장_참고/ 폴더 · 흐름도/ |
학습 서버 이관·H100 분업(종료): Train 브랜치 H100_분업학습_환경구성_기록/ (원문 docs-archive/70_실험기록/LAB/H100_이관_및_분업학습_2026-08-13.md · GPU서버_학습_이관_가이드.md). 수집 방식 전환 기록(WebSocket → FastAPI)·v6 3프레임워크 검증 결과는 docs-archive 브랜치 docs/archive/, docs/real/.
@misc{kim2026etrivrvla,
title = {ETRI VR Robotics Data Research: Vision Pro Teleoperation Data Collection and
Language-Conditioned VLA Training on the ROBOTIS AI Worker FFW-BG2},
author = {Kim, Gunhee},
year = {2026},
howpublished = {\url{https://github.com/logan0741/ETRI_VR_Robotics_data_research}},
note = {Weights and data: \url{https://huggingface.co/datasets/ETRI7203/ETRI_VR_Robotics_data_research}}
}