🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

이 글은 Strands Robots가 LeRobot 데이터셋, 시뮬레이션, 정책 실행, 하드웨어 경로를 하나의 에이전트 루프로 묶어 Hugging Face Hub의 데모 데이터에서 실제 로봇 실행까지 이어지는 흐름을 설명한다.

📌 핵심 요약

• 기존 로봇 학습 워크플로는 데모 기록, 학습, 시뮬레이션 테스트, 하드웨어 배포, 다중 로봇 조정을 각각 별도 도구로 처리해야 해 서로 연결되지 않는 문제가 있었다.
• Strands Robots는 로봇 추상화, 시뮬레이션, LeRobot 스택을 AgentTool로 노출해 하나의 Strands 에이전트 안에서 조합할 수 있게 하며, LeRobot의 데이터 형식과 하드웨어 기록 도구를 그대로 활용한다.
• 기본 예제는 MuJoCo 기반 시뮬레이션에서 SO-100 로봇을 사용해 LeRobotDataset 형식의 데모를 기록하고, 필요하면 Hugging Face Hub에 푸시할 수 있다.
• Mock 정책은 구조적으로 완전한 데이터셋을 만들기 위한 기본 경로이며 실제 집기 동작을 학습시키는 데이터로는 유용하지 않다. 실제 동작에는 GR00T, MolmoAct2, LerobotLocal 같은 정책 경로를 사용할 수 있다.
• 같은 데이터셋 형식과 공통 정책 인터페이스 덕분에 시뮬레이션 기록, 하드웨어 기록, 정책 실행, 향후 실제 SO-101 배포와 로봇 플릿 조정까지 동일한 에이전트 코드 흐름 안에서 다룰 수 있다는 점이 핵심이다.

🧩 주요 포인트

1. 기존 로봇 학습 워크플로는 데모 기록, 학습, 시뮬레이션 테스트, 하드웨어 배포, 다중 로봇 조정을 각각 별도 도구로 처리해야 해 서로 연결되지 않는 문제가 있었다.
2. Strands Robots는 로봇 추상화, 시뮬레이션, LeRobot 스택을 AgentTool로 노출해 하나의 Strands 에이전트 안에서 조합할 수 있게 하며, LeRobot의 데이터 형식과 하드웨어 기록 도구를 그대로 활용한다.
3. 기본 예제는 MuJoCo 기반 시뮬레이션에서 SO-100 로봇을 사용해 LeRobotDataset 형식의 데모를 기록하고, 필요하면 Hugging Face Hub에 푸시할 수 있다.
4. Mock 정책은 구조적으로 완전한 데이터셋을 만들기 위한 기본 경로이며 실제 집기 동작을 학습시키는 데이터로는 유용하지 않다. 실제 동작에는 GR00T, MolmoAct2, LerobotLocal 같은 정책 경로를 사용할 수 있다.
5. 같은 데이터셋 형식과 공통 정책 인터페이스 덕분에 시뮬레이션 기록, 하드웨어 기록, 정책 실행, 향후 실제 SO-101 배포와 로봇 플릿 조정까지 동일한 에이전트 코드 흐름 안에서 다룰 수 있다는 점이 핵심이다.

🧠 상세 정리

1. 분리된 로봇 학습 도구를 하나의 에이전트 루프로 묶는 문제의식

글은 사용자가 로봇, Hugging Face Hub에 있는 데모 데이터 폴더, 새로 학습시키고 싶은 작업을 가지고 있다고 가정하며 시작한다. 현재 이런 작업은 새 데모를 기록하는 도구, 학습 도구, 시뮬레이션 테스트 도구, 하드웨어 배포용 커스텀 코드, 여러 로봇을 조정하는 또 다른 도구로 나뉘어 있다고 설명한다. 각각의 구성요소는 개별적으로는 작동하지만 서로 자연스럽게 대화하지 못한다는 것이 출발점이다. Strands Robots와 LeRobot 통합은 이 단절을 줄이고, 데이터 기록부터 정책 실행과 하드웨어 경로까지 하나의 에이전트 호출 안에서 이어지도록 만드는 데 초점을 둔다.

2. Strands Robots와 LeRobot 통합의 핵심 구조

Strands Robots는 Apache 2.0 라이선스의 오픈소스 SDK로 소개되며, 로봇 추상화, 시뮬레이션, LeRobot 스택을 Strands 에이전트가 조합할 수 있는 AgentTool로 노출한다. 통합은 의도적으로 얇게 설계되어 있으며, 하드웨어 기록과 보정은 LeRobot의 기존 스크립트가 담당하고 에이전트는 실제로 오케스트레이션이 필요한 부분에 개입한다. 시뮬레이션 도구는 LeRobot이 하드웨어에서 쓰는 것과 같은 형식의 LeRobotDataset을 기록한다. 또한 GR00T와 LerobotLocal은 공통 인터페이스 뒤에서 정책 추론을 제공하고, MolmoAct2 체크포인트는 LerobotLocal 경로로 실행된다고 설명한다.

3. 예제가 보여주는 다섯 단계의 전체 흐름

글은 하나의 에이전트 안에서 수행되는 다섯 단계의 흐름을 안내한다고 밝힌다. 먼저 LeRobot AgentTool 위에 에이전트를 구성하고, 시뮬레이션에서 LeRobotDataset 형식의 데모를 기록한 뒤, 같은 로봇에서 정책을 실행한다. 이어 같은 에이전트 코드를 물리적 SO-101 로봇에 배포할 수 있으며, 여러 로봇이 있을 때는 Zenoh mesh를 통해 플릿에 명령을 브로드캐스트할 수 있다고 소개한다. 제공된 기본 실행 경로는 노트북과 파이썬 스크립트 형태로 존재하며, 기본값은 시뮬레이션 전용과 Mock 정책이어서 하드웨어, GPU, Hugging Face 인증 정보 없이도 실행할 수 있다.

4. 시뮬레이션과 실제 로봇을 가르는 단순한 추상화

핵심 설계 선택 중 하나는 Robot("so100")이 기본적으로 MuJoCo 기반 시뮬레이션을 반환하고, mode="real"을 지정하면 LeRobot이 구동하는 하드웨어 로봇을 반환한다는 점이다. 이 설계 때문에 에이전트 코드는 시뮬레이션과 실제 로봇 모드에서 동일하게 유지될 수 있다. 또 다른 핵심은 DatasetRecorder가 시뮬레이션 경로와 LeRobot의 하드웨어 기록 경로에서 같은 LeRobotDataset 형식을 쓴다는 점이다. 결과적으로 MuJoCo에서 캡처한 데이터셋과 물리적 SO-101에서 캡처한 데이터셋은 동일한 온디스크 구조를 갖는다.

5. 기본 설치와 실행 조건

기본 시뮬레이션 경로의 최소 조건은 Python 3.12 이상, Linux 또는 macOS 환경, 에이전트 추론에 사용할 Strands 호환 모델 제공자, 그리고 sim-mujoco, lerobot, mesh extras를 포함한 Strands Robots 설치다. 글은 이 정도만 있으면 노트북에서 예제를 끝까지 실행할 수 있다고 설명한다. 고급 경로에서는 데이터셋을 Hub에 푸시하거나 정책 체크포인트를 가져오기 위해 쓰기 권한이 있는 Hugging Face 토큰이 필요하다. 실제 하드웨어 경로에는 SO-101 follower와 leader 쌍 또는 LeRobot이 지원하는 다른 로봇이 필요하며, 장치 보정 파일도 지정된 캐시 경로에 있어야 한다.

6. 시뮬레이션에서 데모를 기록하고 Hub 형식으로 저장하는 과정

Step 2는 하드웨어 없이 시뮬레이션 도구로 LeRobotDataset을 기록하는 과정을 다룬다. Simulation tool의 start_recording 액션은 같은 DatasetRecorder 클래스를 통해 데이터를 쓰며, 관절 상태와 액션을 담는 parquet 스키마, 카메라별 MP4 레이아웃도 LeRobot 하드웨어 기록과 동일하다고 설명한다. 예제 프롬프트는 빨간 큐브를 집어 상자에 넣는 데모를 30 FPS로 기록하고, 지정한 저장소에 데이터셋을 쓰며 완료 시 Hub에 푸시하라는 형태다. 기본 Mock 정책은 훈련된 체크포인트 없이도 전체 흐름을 실행하기 위해 의도적으로 사용된다.

7. Mock 정책의 한계와 데이터셋 호환성 검증

Mock 정책은 placeholder joint action을 생성하기 때문에 로봇이 실제로 집기 동작을 완수하기보다는 무작위적인 움직임을 수행한다고 설명한다. 따라서 기록된 에피소드는 유효한 관절 상태, 유효한 카메라 프레임, 잘 구성된 LeRobotDataset 에피소드를 포함하지만, 그 자체로는 유용한 학습 데이터가 아니다. 실제 큐브 집기 동작을 보고 싶다면 LerobotLocal 정책과 MolmoAct2 체크포인트를 사용할 수 있으며, 이 경우에도 프롬프트와 데이터셋 형식, 에이전트 코드는 그대로 유지된다. 글은 LeRobotDataset 로더가 Strands 전용 경로 없이 시뮬레이션 기록 데이터를 읽는 예시를 보여주며, 동일한 column 이름과 parquet+MP4 구조가 유지된다는 점을 강조한다.

8. 하드웨어 기록과 정책 실행 경로

물리적 SO-101에서 데모를 기록할 때는 Strands 통합이 별도 AgentTool로 감싸지 않고 LeRobot의 기존 CLI를 직접 사용한다고 설명한다. 사용자는 follower와 leader를 각각 보정한 뒤 lerobot-record 명령으로 데이터셋 저장소, 작업 설명, 에피소드 수, Hub 푸시 여부를 지정해 기록한다. 이 명령으로 Hub에 올라가는 데이터셋도 시뮬레이션 기록과 같은 형식이므로, LeRobot의 표준 학습 CLI와 이어질 수 있다. 이후 정책 실행 단계에서는 GR00T inference 컨테이너를 시작하거나 LerobotLocalPolicy를 사용해 Hub의 체크포인트를 로드할 수 있으며, 공통 정책 인터페이스 덕분에 에이전트 코드의 구조는 유지된다.

🧾 핵심 주장 / 시사점

• 이 글의 핵심은 새로운 데이터 포맷을 만들기보다 LeRobot의 기존 기록·로딩·학습 생태계를 보존하고, Strands 에이전트를 그 위의 조정 계층으로 사용하는 데 있다.
• 시뮬레이션과 하드웨어가 같은 LeRobotDataset 형식을 공유한다는 점은 sim-to-real 실험에서 가장 큰 마찰 중 하나인 데이터 호환성 문제를 줄이는 설계로 볼 수 있다.
• Mock 정책은 기능 데모용으로는 유용하지만 실제 작업 성능을 보여주는 증거는 아니므로, 글의 실질적 가치는 Mock 실행 결과보다 GR00T, MolmoAct2, LerobotLocal 같은 정책을 같은 인터페이스로 교체할 수 있다는 구조에 있다.

✅ 액션 아이템

• 기존에 분리되어 있던 로봇 학습의 데모 기록, 학습, 시뮬레이션 테스트, 하드웨어 배포 단계를 Strands 에이전트 루프로 통합한다.
• LeRobotDataset 형식과 LeRobot 하드웨어 기록 도구를 같은 축으로 묶어 MuJoCo SO-100 데모 수집부터 Hub 푸시까지 동일 계약으로 유지한다.
• Mock 정책은 구조적으로 완전한 데이터셋 생성용으로만 사용하고, 실제 집기 동작 학습은 GR00T·MolmoAct2·LerobotLocal 경로로 분리해 실행한다.

❓ 열린 질문

• 공통 데이터셋 형식과 정책 인터페이스를 쓰는 에이전트가 시뮬레이션 기록에서 실제 SO-101 배포·로봇 플릿 조정으로 이어질 때 어떤 구간에서 붕괴 가능성이 큰가?
• MuJoCo SO-100 데모를 Hub에 푸시한 뒤 데이터셋·행동 로그 품질이 유지되는지 판단하려면 어떤 지표를 추가 수집해야 하는가?
• Mock 정책 기반 데이터셋이 학습 준비로는 충분하고 실제 조작 정책으로는 부적절한 기준은 무엇이며, GR00T·MolmoAct2·LerobotLocal 선택 기준은 어떻게 정하면 되는가?