Copy English

Why

The load-bearing choice in a young tooling stack is rarely the tool. Robotics learning frameworks churn on a two-to-three-year cycle — the model architecture, the training harness, the sim backend all get replaced — but the data you collected does not. So the decision that keeps paying is not 'what do I train with' but 'what format do I collect in,' and LeRobot's actual contribution to the stack is exactly that: a standard dataset format that survives the frameworks built on top of it.

That reframes how to enter. The instinct is to pick the newest framework; the better move is to follow the data. A task with a rich public LeRobotDataset is an order of magnitude more tractable than an equally interesting task with none, because the expensive part of robotics is not the model, it is the demonstrations. So the entry sequence is data-first: check the dataset landscape, let it pick the task, generate more in sim if the hardware is not there, and only then care which framework wraps it. The card that maps the whole stack (robotics-entry-decision) answers 'which way in'; this one answers 'what actually persists once you are in.'

How it works

What churns vs. what persists

The data-first entry sequence

1. Count the data — public LeRobotDatasets for your task, and their episode-length spread.
2. Let data pick the task — a task with data is ~10x more tractable.
3. No hardware? Sim first (MuJoCo/MJX) to generate demonstrations.
4. Then choose the framework that wraps it — last, not first.

The trap

Tool-first entry spends the budget on tooling and trains nothing. LeRobot pays off after data exists; ordering it before data inverts the value.

Where it lands in Jayverse

• Number: pick the reading/indicator storage format before picking the analysis framework. Number's math and algorithm research should settle a stable schema for stored readings and indicators first, the same "format outlives the framework" lesson, since the analysis library will churn faster than the data.
• Devnet: the indexer's table schema is the asset, not any particular indexing tool. Whatever indexes Devnet's blocks and events, keep the schema stable and versioned deliberately, since it will outlive whichever indexing framework runs today.
• gitboard: store dashboard metrics in a durable, tool-agnostic format. If gitboard ever swaps its metrics pipeline, the stored history should survive that swap; define the schema now rather than after the first framework change.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

LeRobot — 데이터셋 포맷이 왜 프레임워크보다 오래 사는가

허깅페이스의 로보틱스 스택. 사전학습 정책·데이터셋·시뮬 환경을 표준 데이터셋 포맷(LeRobotDataset)을 중심으로 묶어, 텔레오퍼레이션 수집 → 학습 → 재생 루프를 한 저장소에서 돌립니다. 더 넓은 스택(ROS 2 / LeRobot / MuJoCo-MJX / openpi / Isaac Lab)에 놓으면, 실제 기여는 모델이 아니라 포맷입니다.

구현이 아니라 로보틱스 학습 진입의 순서 결정입니다. 프레임워크를 고르기 전에 데이터가 얼마나 있는지 세세요: 관심 태스크의 공개 LeRobotDataset 개수와 에피소드 길이 분포는? 데이터가 있는 태스크는 없는 것보다 약 열 배 쉬우므로, 그 개수가 태스크 선택을 이끌어야 합니다 — 반대가 아니라. 실기기가 없으면 시뮬(MuJoCo/MJX)로 데이터를 만드는 데서 시작하세요; LeRobot은 데이터가 생긴 다음에야 값어치가 납니다. 순서를 뒤집으면 — 도구 먼저, 데이터 나중 — 도구만 만지다 아무것도 학습 못 하고 끝납니다. 현행 LeRobot API·데이터셋 스펙은 허깅페이스 문서로 확인하세요.

왜

어린 도구 스택에서 하중을 견디는 선택은 좀처럼 도구가 아닙니다. 로보틱스 학습 프레임워크는 2~3년 주기로 갈립니다 — 모델 구조, 학습 하네스, 시뮬 백엔드 모두 교체됩니다 — 그러나 모은 데이터는 그렇지 않습니다. 그래서 계속 값을 주는 결정은 '무엇으로 학습하나'가 아니라 '어떤 포맷으로 모으나'이고, 스택에서 LeRobot의 실제 기여가 바로 그것입니다: 위에 지어진 프레임워크보다 오래 사는 표준 데이터셋 포맷.

이는 진입 방식을 다시 짭니다. 본능은 최신 프레임워크를 고르는 것이지만, 더 나은 수는 데이터를 따라가는 것입니다. 풍부한 공개 LeRobotDataset이 있는 태스크는 똑같이 흥미롭지만 데이터가 없는 태스크보다 한 자릿수 더 다루기 쉽습니다 — 로보틱스의 비싼 부분은 모델이 아니라 시연이기 때문입니다. 그래서 진입 순서는 데이터 우선입니다: 데이터셋 지형을 확인하고, 그것이 태스크를 고르게 하고, 실기기가 없으면 시뮬로 더 만들고, 그다음에야 어느 프레임워크가 감싸는지를 신경 쓰세요. 스택 전체를 지도화한 카드(robotics-entry-decision)는 '어느 길로 들어가나'에 답하고, 이 카드는 '들어간 뒤 실제로 남는 게 무엇인가'에 답합니다.

동작 방식

갈리는 것 vs 남는 것

데이터 우선 진입 순서

1. 데이터를 세라 — 태스크의 공개 LeRobotDataset과 에피소드 길이 분포.
2. 데이터가 태스크를 고르게 — 데이터 있는 태스크가 ~10배 다루기 쉬움.
3. 실기기 없으면 시뮬 먼저(MuJoCo/MJX)로 시연 생성.
4. 그다음 감싸는 프레임워크 선택 — 처음이 아니라 마지막.

함정

도구 우선 진입은 예산을 도구에 쓰고 아무것도 학습 못 합니다. LeRobot은 데이터가 생긴 다음 값을 주므로, 데이터보다 앞세우면 가치가 뒤집힙니다.

Jayverse에서의 위치

• Number: 분석 프레임워크보다 읽기/지표 저장 형식을 먼저 정한다. Number의 수학·알고리즘 리서치는 저장된 읽기와 지표에 대한 안정적 스키마를 먼저 정해야 한다. "형식이 프레임워크보다 오래 산다"는 교훈 그대로, 분석 라이브러리는 데이터보다 빨리 바뀐다.
• Devnet: 인덱서의 테이블 스키마가 자산이지 특정 인덱싱 도구가 아니다. Devnet의 블록과 이벤트를 무엇으로 인덱싱하든, 스키마를 의도적으로 안정되고 버전 관리되게 유지한다. 오늘 쓰는 인덱싱 프레임워크보다 스키마가 더 오래 살아남기 때문이다.
• gitboard: 대시보드 지표를 도구에 종속되지 않는 내구성 있는 형식으로 저장한다. gitboard가 지표 파이프라인을 언젠가 교체하더라도 저장된 이력은 그 교체에서 살아남아야 하므로, 프레임워크를 바꾸고 난 뒤가 아니라 지금 스키마를 정의한다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑