NVIDIAがUnitree G1向けの一気通貫ワークフロー「GR00T reference workflow」を公開したので読み解いてみた
こんにちは。atsuです。
NVIDIAが、Unitree G1のマニピュレーション方策学習をテレオペによるデータ収集からJetson Thorでの実機デプロイまで一気通貫でカバーする「GR00T reference workflow」を公開しました。2026年6月のGTC Taipeiで発表されたIsaac GR00T開発プラットフォームの一環で、手順を追える学習コンテンツ（コース）として提供されています。
ちょうど同じ構成（Unitree G1 + GR00T のfine-tune）のパイプラインを自前で組んで検証していたところだったので、公開情報を整理しつつ、「自前で同じことをやってきた立場」から見た注目ポイントをまとめます。
本記事は2026-07-10時点の以下の公開情報をもとにしています。
GR00T reference workflowとは
一言でいうと、Unitree G1のマニピュレーション方策学習のための、検証済み・オープン・再現可能なリファレンスワークフローです。単発のデモでも汎用ヒューマノイドキットでもなく、NVIDIAのモデル・ライブラリ・フレームワーク群を1つの再現可能なワークフローに束ねたもの、と位置づけられています。
カバー範囲は次の通りです。
- テレオペレーション（シミュレーション or 実機）
- デモンストレーションデータの収集
- GR00T Vision-Language-Action（VLA）モデルのpost-training（収集したデモデータでの追加学習。以下fine-tuneと同義で使います）
- Isaac Lab-Arenaでの評価
- G1実機へのデプロイ
題材のタスクはテーブル上のリンゴをつかんで皿に置くpick-and-placeです。G1が立位でバランスを取りながら、知覚・把持・全身協調・方策実行までパイプライン全体を通す構成になっています。シンプルに見えますが「段階ごとにデバッグできる程度に簡単で、パイプライン全体を検証できる程度に複雑」という意図的な設計とのことです。
ワークフロー全体像
コース内容を私なりに図に整理するとこうなります。
図は実機デプロイまで含めた筆者の整理です（シミュレーションワークフローの場合、評価まででIsaac Lab-Arena内に完結します）。
特徴的なのは、シミュレーションと実機の2つのワークフローが完全に独立していることです。どちらか片方だけでも完結します。
| シミュレーションワークフロー | 実機ワークフロー | |
|---|---|---|
| データ収集 | Isaac Lab-Arena上でテレオペ | 実機G1でテレオペ |
| 記録形式 | HDF5 | MCAP（ROS 2 bag経由で記録） |
| 評価 | Isaac Lab-Arenaで成功率測定 | 実機で成功率測定 |
| デプロイ | （シミュ内で完結） | LEAPPでエクスポートしJetson Thorで推論 |
| 所要時間の目安 | 3〜6時間 | 3〜6時間 |
所要時間はいずれも「前提条件とハードウェアが揃っている場合」の公称値です。
構成コンポーネント
ワークフローを構成する主要コンポーネントは次の通りです。
| コンポーネント | 役割 |
|---|---|
| Isaac Lab-Arena | Isaac Lab上に構築されたタスク作成・大規模評価フレームワーク。並列rollout（方策を環境で実際に走らせる試行）・タスクランダム化・成功率ベンチマーク |
| Isaac Teleop | テレオペ基盤。XRヘッドセットの標準デバイスインターフェース、リターゲティング、MCAP記録スキーマを提供。シミュではCloudXRで一人称視点ストリーミング |
| AGILE | GR00T Whole-Body Control（WBC）の推奨デフォルトコントローラ。立位・バランスのみを受け持ち、上半身はテレオペ操作者や学習済み方策に委ねる分離設計 |
| LeRobot形式 | Hugging Faceの学習向けデータセットスキーマ。HDF5（シミュ）/ MCAP（実機）から変換して学習に使う |
| GR00T 1.7 | fine-tune対象のVLA基盤モデル（Hugging Face上のモデル名はGR00T-N1.7-3B）。カメラ画像+言語指示+ロボット状態を入力に、action chunk（短い未来の行動列）を出力 |
| LEAPP | 学習チェックポイントを実機推論用にパッケージングするエクスポート機構（前処理→推論→後処理のパイプライン記述を生成） |
| Jetson Thor | 実機側のエッジ推論を担う（Jetson AGX Thor Developer Kit） |
必要なハードウェア
やってみる前に確認しておきたい要件です（詳細は公式のprerequisitesを参照）。
共通（シミュ・実機とも）
- テレオペデバイス: Isaac Teleop対応のXRヘッドセット（Meta Quest 3、PICO 4 Ultraなど）。Apple Vision Proは対象外と明記されています
- 学習GPU: VRAM 48 GB以上のNVIDIA GPU（最低1枚。実機ワークフローを大規模に回すなら8枚推奨）
シミュレーションワークフロー
- Isaac Sim 6.0のx86_64ワークステーション要件に準拠（最低でもRTX 4080 / VRAM 16 GB / RAM 32 GB）
- 注意点として、Isaac SimはRT Coreを持たないGPU（A100やH100など）では動かないと要件に明記されています。クラウドGPUで試す場合はL40SなどRT Core搭載GPUを選ぶ必要があります
実機ワークフロー
- Unitree G1（Dex3-1ハンド構成）+ Jetson AGX Thor Developer Kit を有線接続
- 頭部RealSenseカメラをThorへつなぐUSB3延長ケーブル
- ワークスペース条件も指定されています: 黒いテーブルクロスのテーブル、白い壁背景、赤いリンゴ・白い皿の配置、影やグレアを避けた一定の照明
ワークスペース条件が要件として明文化されているのが面白いところで、「わずかな物理的変化がデータ分布を変えるため、収集と評価をまたいで再現可能に保つ必要がある」という理由が添えられています。
自前で同じ構成を組んだ経験から見た注目ポイント
私はこのワークフローの公開前から、G1 + GR00T 1.7で「実機テレオペ収集 → fine-tune → 実機デプロイ」のパイプラインを自前で組んで検証してきました。その経験から、このリファレンスワークフローで注目ポイントを挙げます。
1. 収集と推論の条件一致がスキーマで担保される
自前構成で最初に直面したのが、学習データとデプロイ時の観測条件（カメラ視点・姿勢）のズレでした。公開データセットで学習したモデルは、カメラ構成が違うだけでタスクが成立しなくなります。
このワークフローでは、Isaac Teleopがシミュ・実機で共通のデバイスインターフェース・リターゲティング・記録スキーマを持ち、収集した観測がそのまま学習スキーマ（LeRobotのobservation / state / action）に対応します。「収集時と推論時で入力分布を揃える」作業が、個人の注意力ではなくツールチェーンの構造で担保されるのは大きいと感じます。
2. 評価が「成功率」ベース
もう1つ経験から共感したのが評価設計です。オフラインの模倣誤差（open-loop評価: 記録済みデータの観測を入力し、モデルの予測行動とお手本の誤差を測る評価）が良くても、実機でタスクが成功するとは限らない — これは自前検証でも身をもって確認した点です。
このワークフローの評価はIsaac Lab-Arenaでのrollout成功率（方策を実際に走らせてタスクが成功した割合）が基準で、「シミュで成功率が低い方策はハードウェアテストに進めない」という検証ゲートとして機能します。失敗が安いシミュで失敗モードを特定してから実機に進む流れは、実機時間が貴重なヒューマノイド開発では合理的な設計だと思います。
3. AGILEによる「バランスと操作の分離」
ヒューマノイドのテレオペは、腕・手・胴体・脚・バランスを同時に操作する必要があるのが難所です。AGILEが立位バランスを引き受け、操作者は上半身の操作に集中する分離設計は、テレオペの習熟コストとデータ品質の両方に効きます。学習時と実行時で同じコントローラが土台になるので、姿勢条件の一致という意味でもポイントです。
4. LEAPPによるデプロイの分離
学習チェックポイントは学習の柔軟性のための形式であって、リアルタイム実行用ではない — として、前処理・推論・後処理をエクスポートして記述するLEAPPという仕組みが実機パスに挟まっています。自前構成ではGPUサーバ上のpolicy serverとロボット側クライアントをZMQでつなぐ形にしていましたが、エッジ（Thor）で低レイテンシに回す前提のパッケージングが最初から用意されているのは実運用寄りの設計です。
気をつけたい点
一方で、手元の環境にそのまま持ち込む前に確認しておきたい点もあります。
- ハンドはDex3-1前提です。私の手元のG1はInspireハンド構成なので、実機パスをそのまま流用はできず、ハンド周りの読み替えが必要になりそうです
- 実機パスはJetson Thor前提です。手元のエッジ計算機がOrin世代の場合は構成が変わります
- 学習にVRAM 48 GB以上が必要なので、ローカルGPUで足りない場合はクラウドGPUの利用が現実的です（その場合もIsaac Sim併用ならRT Core搭載GPUを選ぶ点に注意）
- Isaac Lab-Arenaは2026-07時点でv0.2系の早期リリースで、公式リポジトリに「APIは不安定で変更される」「本番利用はしないこと」と明記されています。ワークフローを学ぶ・試す用途は問題ありませんが、自プロジェクトへの組み込みは前提を理解した上で
このあたりは実際に手を動かして確認し、別記事にする予定です。
まとめ
- NVIDIAがUnitree G1向けに、テレオペ収集→LeRobot変換→GR00T 1.7 post-training→評価→実機デプロイの一気通貫リファレンスワークフローを公開しました
- シミュレーションと実機の2パスが独立していて、どちらか片方だけでも完結します（公称3〜6時間）
- 自前で同様のパイプラインを組んだ経験からは、「観測条件の一致をスキーマで担保」「成功率ベースの評価ゲート」「バランスと操作の分離」あたりが、実際に苦労する箇所を的確に押さえに来ている印象です
- 手元のG1はハンド構成（Inspire）とエッジ計算機が要件と異なるので、どこまで流用できるかは今後実際に試して確認します
自前でヒューマノイドの模倣学習パイプラインを組んだ経験では、各段のつなぎ目（データスキーマ・条件一致・評価基準）に一番時間を取られました。そこが製品化されたワークフローとして公開された意味は大きいと思います。実際に動かしてみた結果は続報を書きます。
