ロボットデータ フライウィール 構築: 最初のデモから継続的な改善
ロボット技術チームのリーダーがデータフライホイールを構築する方法 データを収集し,訓練し,展開し,故障を特定し,さらに多くのものを収集する. 連続的なロボット学習のための実践的なガイド.
[←ガイド]
ロボット学習で勝利するチームは,データ数が多いチームではなく,展開失敗と標的データ収集間のフィードバックループが速いチームです.このガイドは,そのループをどのように構築するかを示します.
ロボット データ フライウィールとは
データフライホイールは,ロボットを部署することで,改善に必要なデータを生成し,ロボットがより能力を持ち,より多くの部署機会を生み出し,より多くのデータを生成する自強ループです.ループの各回転は,人間の限界的な努力が減少するにつれて,政策パフォーマンスを向上させます.
ソフトウェア企業から借りた概念です. 検索は,より多くのユーザーがより多くのクエリを生成し,ランキングアルゴリズムを向上させ,より多くのユーザーを惹きつけます.ロボット工学では,フライホイールは別の通貨で動作します. 失敗エピソード.あなたの導入されたポリシーが失敗するたびに,その失敗は,ポリシーのトレーニング配分が強化されるべき場所を正確に教えてくれます.
2026年に最も能力のあるロボットを製造する企業 (テスラ (オプティマス),図 (図02),物理知能 (pi0) によりデータフライホイールが運用される.テスラは,工場で数百台のオプティマスユニットを運行し,あらゆる操作試みを記録する.特定のタスク変数でユニットが失敗すると,その失敗が標識され,人間が修正を証明し,データは次のトレーニングサイクルに供給される. 物理知能の pi0モデルはパートナー部署からの遠隔操作データを継続的に摂取することで改善されます.このアーキテクチャは,任意のスケールで適用されます.
なぜ 飛行車 の 実験 室 が ほとんど 失敗 する の です か
ロボット工学の研究室の多くは,一瞬でデータを収集し,政策を訓練し,評価し,その後,成功を宣言するか,別の不分別なデモを収集する.これはフライホイールではありません. 重要な違いはターゲット化です: 飛行車輪は,導入によって明らかになった故障モードを特定して,既に政策がうまく処理している条件に関するデータを収集するのではなく,
フライホイール ループ
ロボットデータフライホールは連続サイクルを形成する6つの段階で構成されています.
1 集める
2 列車
3 部署
4 監視
5 障害を検出する
6 追加収集
↑ ステージ2へ戻る 列車
ステージ1
段階1:種子データセット (50200 試行)
種子データセットは,ベースラインポリシーを確立します.目標は生産準備ができているポリシーではありません. 導入ベースの失敗マイニングが生産性になるように十分な頻度で (40
"初 の 訓練 に 十分 な"もの の 見方
- タスク範囲: 目標タスクの最もシンプルな意味のあるバージョンから始めましょう.最終目標は"混ざったアイテムをビニに分類する"なら",既知のオブジェクトを1ビニに選んで置く"から始めましょう. 変異性を削除します:固定位置,制御照明,単一のオブジェクトタイプ.
- アルゴリズムによるデモカウント: ACT:50
200デモ.拡散ポリシー:100 300.VLA細かな調 (OpenVLA/Octo):50 100前訓練ベース.検証成功率の高原まで収集する,丸い数字をヒットするまでは. - オペレーター一貫性: 複数のクラウドソーシング・オペレーターではなく1
3の訓練を受けたオペレーターを使用する.多様性は後には役立ちます.シードフェーズでは,同じ戦略の一貫した示範は,同じデモカウントで多様な戦略を上回ります. - 品質ゲート: 訓練に追加する前に,各エピソードをレビューする.操作者の躊躇>2秒,再接近によって回復された失敗の把握 (特に復旧データを収集しない限り),操作点のカメラの遮断,または不完全な作業実行を含むエピソードを拒絶する.完全なQAプロトコルについては,当社の [データ収集ガイド]
T2 ]を参照してください.
種子データセット タイムライン
経験豊富なオペレーターと検証された [テレオペレーション設定] (T3
第2段階:最初の展開と監視
種子データセットの訓練後,テスト環境でポリシーを展開します. これは生産部署ではありません. ** 装置部署**は次のフライホイール回転を動かす故障データを生成するように設計されています.
遠隔操作の影モード
完全に自動展開前に,シードモードでポリシーを実行します.ポリシーはアクションを予測しますが,オペレーターは遠隔操作のオーバーリードを維持します.ポリシーが失敗すると,オペレーターは任務を担い,完了します.ポリシーの予測されたアクションとオペレーターの修正アクションの両方を記録します.これは高価値 DAgger スタイルのデータです.
シェードモードは2つの目的を果たします: 政策の実際の状態分布 (ポリシーがトラブルに巻き込まれた州) からトレーニングデータを生成し,人間の安全網を削除する前に政策の行動の安全な評価を提供します.
性能モニタリング
部署中に,各エピソードで以下の記録を:
- ** 完全エピソード記録:** 訓練データに一致する形式の関節位置,カメラ画像,アクション,タイムスタンプ
- 結果ラベル: 成功,失敗,または操作者が介入した.可能な限り自動的にラベル (例えば,成功 = 対象エリアで空端カメラによって検出されたオブジェクト).曖昧なケースの手動ラベル.
- ** 失敗カテゴリー:** 事件が失敗した場合,失敗を分類する.カテゴリー:把握障害,配置エラー,衝突,タイムアウト,復旧障害,配送終了状態.これらのカテゴリーはフェーズ3を駆動します.
- ポリシーバージョン: 各エピソードを生成したモデルチェックポイントでタグ付けします. フライホイールの回転の改善を追跡するために不可欠です.
失敗 記録インフラストラクチャ
最低実行可能な失敗記録システムとは,エピソード_id,タイムスタンプ,ポリシー_バージョン,結果,失敗_カテゴリー,メモを含むCSVファイルである. [RCSVデータプラットフォーム]
3 段階: 鉱山失敗
失敗マイニングはフライホイルの機能の核心革新です 詳細なデモを集める代わりに 性能を制限する特定の失敗モードを特定し,直接それらのモードに対応するデータを収集します
優先順位 を 設定 する こと が 失敗 し て いる こと を 特定 する
50
- 頻度: 最も頻繁に発生する故障モードはどれか? 40% の故障が把握障害であり, 10% は配置エラーである場合は,最初に把握を修正してください.
- 固定性: いくつかの障害はデータで対処可能 (ポリシーでは決してその状態が表示されていない).他のものはハードウェア変更を必要とする (ロボットが物理的に目標に到達することはできません).より多くのデモで修正できる障害にデータ収集を集中します.
- **インパクト:**特定のオブジェクト変数に対する試みの100%をブロックする故障モードは,すべての変数で間接的な故障を引き起こすものよりも優先度が高い.
記号戦略
- タイムスタンプ注釈: 各失敗エピソードにおいて,失敗が始まった時間スタンプをマークします. これにより,政策訓練士に軌道のどの部分が強化する必要があるかを正確に伝えます.
- 状態注釈: 障害点での状態を記述する. "オブジェクトは45度回転され,グリッパーが間違った角度から近づいた". これは修正デモのデータ収集戦略を指針します.
- クラスター解析: クラスター障害のエピソードは,故障点での視覚的類似性によってグループ化されます. 20 つの故障がすべてロボットに同じ方法でオブジェクトが欠けていることを示している場合,そのクラスターはトレーニング分布における単一のアドレス可能なギャップを表します.
第4段階: 対象データ収集
飛行車輪が効果を及ぼすのはここです. 汎用的なデモを200回増やす代わりに (減少する収益を上げます) 3期で確認されたトップ故障モードを対象とした30
特定の故障モードの収集
- Grasp 失敗: 設定設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定 設定
- 位置誤り: 物体がすでに把握されている状態からデモを開始する (把握段階をスキップする). 目標に正確な調整をすることで位置軌道を集中する.
- 回復デモ: ポリシーを実行して,ほぼ失敗状態に達するまで (例えば,物体がわずかに誤った操作) を操作して回復を示します.これらの"回復デモ"は,エピソードごとに最も高い値値のデータです.
- エッジケースカバー: 障害が特定のオブジェクト位置または方向に集まった場合,それらの位置を特定的にカバーするデモを収集します.障害領域の一貫したカバーを確保するために物理的なテンプレートまたはグリッドを使用します.
対象集計対一般改善
失敗を標的にする代わりに"すべてに多くを集める"という一般的な間違いです.数学は明確です.既に政策が処理している条件を1つに合わせて100の示例を均一に追加すると,過小な改善が得られます.政策が失敗する特定の地域で30の示例を追加すると,その失敗モードの成功率は15~25%増加します. フライホイールはこの標的にされた規律に依存します.
インフラストラクチャの要件
機能するフライホイールは基本的なデータ収集以上のインフラを必要とします. 各段階では以下のようにする必要があります.
データパイプライン
- エピソードストレージ: 部署エピソード (トレーニングデータだけでなく) は全て,完全な録音とメタデータとともに保存されなければならない.
- エピソードタグ付け: タイプ別でエピソードタグ付け: "種子",""標的型復元","展開成功","展開失敗","自動収集". 訓練スクリプトはタグ別でフィルタリングをサポートする必要があります.
- 自動摂取: 自動ファイルコピーなしで新しいエピソードが収集機や部署機からトレーニングデータセットに流れる. rsync,共有NFSマウント,またはクラウドシンクロ (S3/GCS) を使用する.
モデルバージョン
- 訓練されたポリシーチェックポイントを:データセットバージョン,ハイパーパラメータ,トレーニング日期,検証メトリックでタグ付けします.
- 実行中の各エピソードをどのポリシーバージョンが生成したかを記録する.このチェーンは,パフォーマンス逆戻り (ポリシー v3 は v2 よりも悪い.何が変わったか?) をデバッグするために不可欠です.
- ロールバックのために少なくとも最後の5つのポリシーチェックポイントを利用してください. ストレージコストは最小 (100
500 MB/チェックポイント) です.
自動化 訓練
- 新しいエピソードを監視するスクリプトを設定し,新しいNエピソードのバッチ (通常25
50) が利用可能になったときにトレーニングを実行します. - 転職訓練を夜間実行するために 作業スケジュラルを (cron, Ray, Modal) 活用して 次の朝の部署セッションに新しい方針が準備されています
- 訓練の各回後に 標準化評価を自動で実行し (シミュレーションや再演で20回の展開) チェックポイントの横に結果を記録する.
監視ダッシュボード
少なくとも,この指標を時間とともに追跡してください.
- 政策バージョンによる成功率 (フライホイールが実際に改善しているか?)
- 政策バージョンによる失敗モード分布 (ターゲット修正が有効か?)
- 飛行車回転ごとに収集されたエピソード (収集の努力が減少しているのでしょうか?)
- 失敗の確認から再訓練された政策までの時間 (あなたのサイクル時間)
追跡する指標
| Metric | What It Measures | Target | Red Flag |
|---|---|---|---|
| Success rate | % of deployment episodes that succeed | Increasing each rotation | Flat or decreasing after new data |
| 汎化 score | Success rate on unseen conditions vs. seen conditions | >0.7 ratio | <0.5 (severe overfitting) |
| Data efficiency curve | Success rate improvement per N new episodes | Diminishing returns curve visible | No improvement despite more data |
| Cost per successful episode | Total collection cost / number of new successes | Decreasing each rotation | Increasing (flywheel is stalling) |
| Cycle time | Days from failure detection to retrained policy | <1 week | >2 weeks (pipeline bottleneck) |
| Failure mode coverage | % of identified failure modes with targeted data | >80% by rotation 3 | Same failure mode persists after 2 targeted collections |
常見なフライホイール 罠
1. 配分シフトの蓄積
何が起こるか: 各フライホイール回転は特定の故障モードのターゲットデータを追加します.時間の経過とともに,トレーニング分布はエッジケースと回復シナリオに大きく偏っています. 政策はうまく処理するために使用した"簡単"ケースで失敗し始めます.
固定: 訓練セットの6070%のベースラインデモと3040%のターゲットデータとの比率を維持する.ターゲットデータを追加する際,ベースラインデータを削除しないでください.トレーニングセットが大きすぎると,ベースラインデータを完全に落とすのではなく,均質に下回ししてください. ローテーションを介して固定された"ベースライン評価セット"でパフォーマンスを監視します.
2 記号不一致性
何が起こるのか: チームメンバーは失敗を異なる方法で分類する. ある人は"成功"と 接近の失敗を標籤にします. 別の人は"失敗を標籤にします". 失敗統計は信頼性が低下し,標的の収集は誤り方向に導かれる.
修正: 各失敗カテゴリーに例の画像を含む明示的な注釈ガイドラインを書いてください. バイナリー成功/失敗を主要なラベルとして使用します (同意しないのは難しい),失敗サブカテゴリーを次元のラベルとして使用します. 記者間の合意のチェックを毎月実行します. 成功/失敗ラベルについて90%以上合意を要求します.
3 ハードウェア・ドリフト
何が起こるか: 動作数週間の間にロボット関節が反発反応を起こし,グリッパーゴムが劣化し,カメラマントが軽く緩やかされる.ロボットの物理的行動はトレーニングデータ分布から逸脱し,データ問題のように見える徐々に性能低下を引き起こします.
修正: 各部署週の初めに校正チェックを実行します:ロボットに5つの既知の構成を指示し,0.5度以内で関節位置が一致することを確認します. 握手力計で握手力力を確認します. ArUcoボードでカメラの外側を確認します. 記録の校正結果とエピソードデータとともに. ハードウェアのメンテナンスが行われる場合,修理されたハードウェアで20
4\ 解決した課題のためのより多くのデータを収集する
何が起こるか: 最も一般的なフライホイールエラー.チームは,すでに90%以上の成功率で政策が処理している条件のためのさらに200のデモを収集します.その間,現実の世界でのパフォーマンスを制限する3つの失敗モードは,まだ解決されていません.
修正: 各収集セッションの前に",私がターゲットにしている特定の失敗モードはどれか"に答える.そのうちの1つを挙げられない場合は,まず10のポリシー展開を実行して最も一般的な失敗を特定してください.この規律
ケーススタディ: 0 から 10,000 回の操作開始
この仮説案例では,スタートアップがゴミ収集システムを構築する際に リアルなフライホイール進行を示しています.
月1: 種子データセット
チームでは,リーダーフォロワー遠隔操作を搭載したViperX-300S2を使用しています.経験豊富なオペレーターは,ビニーの1つの既知のオブジェクトを拾い,コンベイヤーに配置する200のクリーンデモを収集します.タスク:制御された照明,単体オブジェクトタイプ,固定されたビニ位置.彼らはACTポリシーを訓練します. 結果:55%の成功率が制御されたセットアップで.
2ヶ月: 最初の鉱山転転機
失敗分布: 45% 把握障害 (対象の方向性が対象のトレーニングデータよりも大きく異なります), 30% 配置誤り (輸送ベルト位置容量が狭すぎます), 25% タイムアウト (ポリシーが接近に固まります). 対象となるデモは60個,対象対象の対象の30個,対象の位置を正確に設定する20個,アプローチの回復のための10個,再訓練.結果: 72%の成功率.
3月: 一般化拡大
初期成功率は新しいオブジェクトで35%に低下する. 6つのオブジェクト全体で位置/方向変異による150のデモを収集する. 多オブジェクト分布を処理するためにACTから拡散ポリシーに切り替える. 結果: 68%すべてのオブジェクトで成功率.
4 ヶ月: 活発な学習
セキュリティー・セキュリティー・システム (SMS) は,セキュリティー・セキュリティー・システム (SMS) を導入し,セキュリティー・システム (SMS) を導入する.
56月:スケーリングと自動収集
自動収集は,自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で自動で 結果: 既知の物体で91%の成功率,新しい物体では78%の成功率
7月12日:生産 フライホイール
機械の駅は,無休中に連続的に収集を行います.その週の失敗からデータに合わせて週ごとに再訓練を行います.月12日までに,1万以上のエピソードで,既知の物体で95%の成功,同じカテゴリ内の新しい物体で85%の成功.フライホイールは,週に約5時間の人間の監視で自立しています.
RCSV と 内部ビルド の 対処
| Scenario | RCSV | In-House |
|---|---|---|
| Seed dataset (first 200 demos) | Faster — our operators are trained, hardware is calibrated | Good if your team needs to learn the data collection process |
| Targeted failure-mode data | Strong — we specialize in collecting edge-case data efficiently | Requires operator training for each failure mode |
| Scaling to 1,000+ episodes | Cost-effective — we provide shifts, QA, and infrastructure | Good if you have dedicated operators and hardware |
| Hardware you don't own yet | Lease from RCSV — try before buying | Requires capital outlay upfront |
| Bimanual or dexterous data | Specialized — we operate ALOHA and glove systems | Significant hardware and operator investment |
| Continuous flywheel operation | Hybrid: RCSV handles collection, you handle training/deployment | Best if you have a dedicated data ops team |
タイムライン:ブートストラップ から 自律 維持 可能な フライホイール
| Month | Phase | Activity | Expected Outcome |
|---|---|---|---|
| Month 1 | Seed | 200 clean demos, 3 training runs | 40–60% success on controlled setup |
| Month 2 | Failure mining | 100 deployment episodes, 60 targeted demos | 65–80% success, failure modes identified |
| Month 3 | 汎化 | 150 demos with object/position variation | 70–80% success across 3x variation range |
| Month 4 | Active learning | 80 uncertainty-guided demos | >80% success, equivalent to 300 random demos |
| Month 5 | Auto-collection pilot | Autonomous collection, 20% human review | Validated auto-labeling; 200 episodes/day |
| Month 6+ | Self-sustaining | Continuous auto-collection + weekly retraining | 90%+ success; continuous improvement |
RCSVでデータフライホイールを加速する
RCSVは,データフライホイールプログラムを実行しているチームにターゲット化されたデータ収集,故障回復デモ,エピソードQA,パイプライン配信を提供しています.私たちは,すでに持っているデモではなく,必要なデモを収集します.







