UBTECH GHRC 2026 베이스라인은 Walker S2 시뮬레이터를 실행하고, 키보드 원격조작으로 네 개 카메라와 관절 데이터를 모아 LeRobotDataset v3로 저장한 뒤, ACT 또는 π0 정책을 학습·평가하는 공식 참조 파이프라인이다. 참가자는 먼저 Isaac Sim 5.1.0 기반 컨테이너와 GPU 드라이버를 맞추고, 제공 데이터로 한 번 끝까지 재현한 다음 자신의 데이터를 추가하는 순서가 안전하다. 처음부터 대규모 학습을 시작하면 환경 오류와 데이터 오류를 구분하기 어렵다.
베이스라인이 제공하는 범위부터 정확히 잡는다
GHRC 2026 공식 기술 문서는 물리 시뮬레이션, 데이터 수집, 모델 학습, 정책 배포까지의 통합 흐름을 제공한다. Walker S2 환경의 상태공간은 팔 관절 14개, 그리퍼 관절 4개, 그리퍼 제어 명령 2개를 합친 20차원으로 설명된다. 카메라는 머리 좌·우와 손목 좌·우의 RGB 영상 네 개다.
공식 자산과 학습 데이터는 Hugging Face에 별도로 올라가며, 코드 저장소에서 하위 모듈과 데이터셋을 내려받아야 한다. 베이스라인은 참가자가 같은 출발점에서 결과를 비교하도록 만든 구현이지, 실제 Walker S2의 모든 센서·안전 제어·동역학을 완벽히 복제한 디지털 쌍둥이라는 보장은 아니다. 시뮬레이터에서 높은 점수를 얻어도 실제 기체 배포에는 별도의 Sim-to-Real 검증이 남는다.
| 구성요소 | 공식 베이스라인의 역할 | 처음 확인할 것 |
|---|---|---|
| Isaac Sim | Walker S2 물리 환경과 센서 렌더링 | 컨테이너 버전, GPU 인식, 실시간 계수 |
| 키보드 원격조작 | 과업 시범과 에피소드 생성 | 입력 장치 경로, 제어 지연, 중단 키 |
| LeRobotDataset v3 | 영상·상태·행동·메타데이터 저장 | 카메라 순서, fps, 에피소드 성공 라벨 |
| ACT | 행동 묶음을 예측하는 모방학습 기준선 | 청크 길이, 관측 창, 메모리 사용량 |
| π0 | 영상·언어·행동을 함께 다루는 정책 기준선 | 체크포인트, 전처리, 작업 문장 일관성 |
설치는 코드보다 드라이버와 컨테이너 조합에서 자주 막힌다
공식 문서의 최소 구성은 CPU 4코어, RAM 32GB, SSD 50GB, GeForce RTX 4080과 VRAM 16GB다. 권장 구성은 8코어, RAM 64GB, SSD 500GB, RTX 5080이며, 이상적 구성은 16코어, RAM 64GB, 1TB NVMe와 RTX PRO 6000 Blackwell 48GB로 적혀 있다. 모델 학습을 병행하면 저장공간과 VRAM 여유가 더 필요하다.
운영체제는 Ubuntu 22.04/24.04 또는 Windows 10/11이 표에 포함되지만, 제공 Docker 명령과 키보드 장치 예시는 Linux 흐름에 가깝다. 기본 이미지는 `nvcr.io/nvidia/isaac-sim:5.1.0`, CUDA는 12.8로 안내된다. 문서는 드라이버 580 계열을 권장하며 595를 설치한 경우 Docker 안의 Isaac Sim이 나중에 충돌할 수 있다고 경고한다. 새 드라이버가 항상 더 적합한 것은 아니다.
환경을 만들기 전에 `nvidia-smi`, Docker의 GPU 접근, NVIDIA Container Toolkit, 저장공간을 따로 검사한다. 그다음 공식 이미지 그대로 빈 장면을 띄우고, 마지막에 GHRC 자산을 불러온다. 한 번에 모든 의존성을 설치하면 검은 화면, 렌더러 충돌, 자산 누락 중 무엇이 원인인지 좁히기 어렵다. NVIDIA Isaac Sim 공식 문서의 버전별 알려진 문제도 GHRC 고정 버전과 대조해야 한다.
첫 실행에서는 네 카메라와 20차원 상태가 같은 시간을 가리켜야 한다
화면에 Walker S2가 나타나고 키가 먹는다고 데이터 파이프라인이 정상인 것은 아니다. 머리 좌·우, 손목 좌·우 영상이 올바른 이름과 순서로 저장되는지 확인한다. 관절 상태와 명령이 같은 타임스탬프 축을 쓰는지, 프레임이 드롭될 때 메타데이터가 남는지도 본다. 좌우 카메라를 뒤바꾸면 학습은 돌아가도 손-물체 관계가 틀린 모델이 만들어질 수 있다.
원격조작 입력은 Linux의 `/dev/input/event*`에서 키보드 장치를 찾는다. Docker 안에 해당 장치를 마운트하지 않으면 키 입력이 호스트에는 보이지만 시뮬레이터에는 전달되지 않는다. 자동 스캔 결과가 여러 장치를 가리킬 때는 `/dev/input/by-id/`의 안정적인 링크를 사용하는 편이 낫다. 컨테이너를 다시 실행했을 때 event 번호가 바뀌는 문제도 줄일 수 있다.
.jpg){kind=link}
LeRobotDataset v3는 폴더 형식보다 에피소드 정의가 중요하다
LeRobotDataset v3는 여러 로봇의 영상·상태·행동 데이터를 공통 방식으로 저장하고 불러오기 위한 형식이다. Hugging Face LeRobot 공식 문서는 데이터셋 도구, 로봇 인터페이스, 학습 정책을 한 생태계로 제공한다. GHRC 기준선은 이 구조를 사용하므로 공개 데이터와 자신이 모은 에피소드를 같은 도구로 다룰 수 있다.
그러나 파일이 열리는 것만으로 좋은 데이터는 아니다. 에피소드 시작 상태, 작업 문장, 성공·실패 기준, 조종자 개입, 카메라 fps와 관절 주기를 고정해야 한다. `Part_Sorting`, `Conveyor_Sorting`, `Foam_Inlaying`, `Packing_Box`처럼 과업 이름이 다르면 물체와 종료 조건도 분리해야 한다. 실패한 시도를 조용히 삭제하면 정책이 복구 장면을 배우지 못하고 평가 분모도 왜곡된다.
| 데이터 QA 항목 | 통과 기준의 예 | 문제가 생겼을 때 보이는 현상 |
|---|---|---|
| 카메라 매핑 | head_left/right, wrist_left/right가 샘플과 일치 | 좌우 손이 엉뚱한 영상에 대응함 |
| 시간 동기화 | 접촉 순간의 영상·상태·행동 오차가 허용범위 안 | 물체를 잡기 전부터 힘 명령이 기록됨 |
| 시작 상태 | 물체·로봇 위치 분포와 리셋 규칙이 기록됨 | 정책이 특정 배치에서만 성공함 |
| 작업 문장 | 같은 과업은 같은 의미와 이름을 사용 | π0가 문장 차이를 다른 작업으로 해석함 |
| 분할 | 장면·물체 단위로 학습과 평가를 분리 | 검증 점수는 높지만 새 배치에서 실패함 |
| 실패 보존 | 중단 사유와 마지막 유효 프레임을 남김 | 실패율과 복구 능력을 계산할 수 없음 |
ACT는 재현하기 쉬운 출발선, π0는 더 넓은 입력을 요구한다
ACT는 짧은 행동 묶음(action chunk)을 예측해 긴 조작을 안정적으로 이어 가는 모방학습 계열이다. 입력과 출력 구조가 비교적 명확해 데이터 파이프라인이 제대로 동작하는지 확인하기 좋은 기준선이다. 처음에는 공식 체크포인트와 데이터로 학습·추론을 재현하고, 작은 데이터 일부를 의도적으로 빼거나 카메라를 가려 민감도를 확인한다.
π0 계열은 영상과 자연어 작업 지시, 로봇 상태를 함께 다루는 범용 정책 방향이다. 더 다양한 작업으로 확장할 여지가 있지만, 문장 전처리와 체크포인트 호환, 메모리 요구량, 로봇 행동 표현이 맞아야 한다. ACT보다 이름이 새롭다는 이유만으로 우수하다고 정할 수 없다. 같은 평가 에피소드와 동일한 성공 판정으로 비교해야 한다. 관련 개념은 로봇 파운데이션 모델에서 이어서 볼 수 있다.
두 모델을 비교할 때 학습 손실과 평균 성공률만 보지 않는다. 물체 종류별 실패, 긴 과업에서의 누적 오차, 카메라 가림, 시작 위치 변화, 잘못된 작업 문장에 대한 행동을 따로 본다. 시드와 데이터 분할을 세 개 이상 바꿔 결과 편차를 기록하면 우연히 잘 나온 체크포인트를 고르는 위험이 줄어든다.
학습보다 먼저 추론 결과를 다시 데이터셋으로 기록한다
공식 정책 추론 예시는 `lerobot_record.py`에 `walker_s2_sim`과 체크포인트 경로를 주고, 실행 결과를 평가용 데이터셋으로 저장한다. 기본적으로 영상 기록을 켜고, 공식 문서 표에서는 30fps와 에피소드 60초, 평가 에피소드 50개가 기본값으로 안내된다. 평가 저장소 이름을 `eval_` 형식으로 구분하라는 지침도 있다.
이 구조를 살리는 것이 중요하다. 정책이 실패한 장면을 영상, 상태, 행동과 함께 다시 열 수 있어야 원인이 인지인지 제어인지 판단할 수 있다. 평가 영상만 보고 수동으로 성공을 세면 체크포인트와 환경 버전이 분리되기 쉽다. 결과 데이터셋에 Git 커밋, 자산 버전, 정책 해시, 랜덤 시드와 드라이버 정보를 추가하면 다른 팀이 같은 실패를 재현하기 쉬워진다.
시뮬레이션 성공 뒤에는 현실의 지연·마찰·안전 제어가 남는다
Isaac Sim 안의 마찰계수와 관절 응답, 카메라 노이즈는 실제 Walker S2와 완전히 같지 않다. 시뮬레이터에서 손이 상자에 정확히 닿아도 현실에서는 캘리브레이션 오차와 통신 지연, 모터 백래시, 조명 반사 때문에 접촉점이 달라질 수 있다. Sim-to-Real 핵심 개념에서 다루는 도메인 랜덤화와 실제 소량 보정이 필요한 지점이다.
실기 배포 전에는 속도·힘·작업영역 제한을 학습 정책 밖의 안전 계층에 둔다. 빈 공간과 가벼운 물체부터 시작하고, 사람 접근 시 즉시 멈추는지 확인한다. 시뮬레이션 성적은 정책 후보를 고르는 근거이지 사람 곁에서 사용할 안전 인증이 아니다. 피지컬 AI 전체 맥락은 피지컬 AI 뜻과 범위와 연결된다.
첫날 목표는 높은 점수가 아니라 완전한 재현 기록이다
처음 하루에는 공식 환경을 빌드하고 제공 체크포인트로 두 개 에피소드를 실행해 영상과 상태·행동이 저장되는지 확인하면 충분하다. 둘째 날에는 공식 데이터의 작은 부분으로 ACT를 학습해 손실과 추론을 재현한다. 그다음에 π0를 같은 평가 세트로 돌리고, 마지막에 자신의 원격조작 데이터를 소량 추가한다.
중간 결과를 건너뛰지 않으면 문제가 생긴 위치를 찾을 수 있다. 컨테이너가 깨졌는지, 자산이 바뀌었는지, 데이터가 틀렸는지, 모델 설정이 맞지 않는지 단계별로 확인된다. GHRC 베이스라인의 가치는 최신 모델 이름을 한 번 실행하는 데보다, 참가자들이 비교 가능한 환경과 데이터·평가 흐름을 공유하는 데 있다.
공식 성적표에 없는 진단도 따로 남긴다. 에피소드 성공률이 같아도 한 정책은 초반에 안전하게 중단하고 다른 정책은 마지막에 물체를 떨어뜨릴 수 있다. 작업 완료시간의 중앙값과 최악값, 실패 직전 행동, 안전 제한 발동 횟수를 함께 보면 점수 하나가 가리는 차이가 드러난다. 평가용 장면을 새 물체·새 조명·새 시작 자세로 나누고 각 묶음의 결과를 공개하면, 공식 데이터에 과적합된 체크포인트와 실제로 일반화하는 정책을 구분하기 쉬워진다.
자주 묻는 질문
ACT와 π0 중 하나만 선택해야 하나요?
아니다. 공식 베이스라인은 둘을 비교 가능한 기준선으로 제공한다. 먼저 ACT로 데이터 흐름을 검증하고, 같은 평가 조건에서 π0의 추가 이득과 비용을 확인하는 순서가 실용적이다.
LeRobotDataset v3이면 모든 데이터 품질이 자동으로 맞나요?
아니다. 저장 형식은 통일하지만 카메라 매핑, 시간 동기화, 시작 상태, 성공 라벨과 학습·평가 분리는 사용자가 검증해야 한다.
시뮬레이터에서 성공하면 실제 Walker S2에서도 바로 작동하나요?
아니다. 물리·센서·지연 차이가 남고, 실제 기체의 안전 제한과 교정이 필요하다. 시뮬레이션 결과는 실기 시험 후보를 줄이는 근거다.
확인한 공식 자료
최종 확인: 2026년 8월 23일