ロボット学習データの収集設計：実機デモの記録形式と品質検証

実機デモは動画として残すだけで十分なのか、という疑問から整理しました。

先に結論

ロボット学習用の実機デモは、動画だけでなく、episodeの中に時系列のstepを持つデータとして収集するのが基本です。各stepには、観測、行動、時刻、終了状態を紐づけ、episodeにはタスク、ロボット、センサー、キャリブレーションなどのメタデータを付与します。

品質検証は、保存後に一度だけ行うのでは不十分です。まずスキーマ、配列、欠損、時刻系列を自動検査し、次に行動値や関節状態の物理的妥当性、タスク成功ラベルを確認します。最後に、episode単位でデータを分割し、同じセッションや環境が学習・検証・テストにまたがるリークを防ぎます。

なぜ収集形式が重要なのか

模倣学習やVLAでは、画像だけでなく、ロボットの状態と操作指令の対応を学習します。映像、関節状態、エンドエフェクタの状態、操作コマンドの時刻関係が崩れると、モデルは誤った因果関係を学習する可能性があります。また、成功デモだけを残すと、停止、失敗、やり直しといった実環境で起きる状態を扱いにくくなります。

そのため、収集時点では失敗や中断も含めて保存し、後から終了理由やタスク結果を明示する設計が扱いやすくなります。ただし、成功・失敗ラベルの自動判定と人手判定のどちらが常に優れるかについて、全タスクに共通する基準はありません。タスクごとに判定方法を定義する必要があります。

基本用語とデータ単位

episodeは、タスクの開始から終了までの一つの試行です。stepは、episode内のある時刻における観測と行動の組です。RLDSはepisodeとstepの階層を採用し、stepにobservation、action、reward、discount、is_first、is_last、is_terminalなどを持たせます。

一方、robomimicはHDF5内のdemo単位に、actions、observations、rewards、donesなどを格納します。終了状態を表すフィールド名や意味は実装によって異なるため、単にdoneという名前を合わせるだけでは不十分です。時間制限による終了と、タスクの成功・失敗による終了を区別するかを仕様に記録してください。

推奨する収集スキーマ

最低限、次の情報をepisode・stepに分けて保持します。

• 観測：カメラ画像、深度、関節位置・速度、エンドエフェクタ状態などのraw値と前処理済み値
• 行動：指令値と実行値。関節位置・速度・トルク、エンドエフェクタ姿勢、デルタ動作などの表現を明記
• 時刻：センサーごとのtimestamp、フレーム番号、制御周期、episode開始・終了時刻
• 終了情報：報酬または評価値、discount、is_first、is_last、is_terminal、成功・失敗・中断の理由
• メタデータ：タスクID、ロボット構成、センサー構成、単位、座標系、カメラとロボットのキャリブレーション
• 再現性情報：収集ソフトウェア、データスキーマ、前処理、設定のバージョン

複数のロボットやデータセットを統合する場合は、共通の論理スキーマを使いながら、元の行動空間、単位、座標系、制御周期、観測モダリティをメタデータとして残します。同じactionというフィールドでも、関節指令なのかエンドエフェクタの相対動作なのかで意味は変わるためです。

flowchart TB
  D["Dataset"] --> E["Episode：1回の試行"]
  E --> EM["Episodeメタデータ：タスクID、ロボット構成、センサー構成、キャリブレーション、単位、座標系、バージョン"]
  E --> S["Step：episode内のある時刻の観測と行動"]
  S --> T["timestamp・フレーム番号・制御周期"]
  S --> O["observation：画像、深度、関節状態、エンドエフェクタ状態"]
  S --> A["action：指令値・実行値、行動表現"]
  S --> R["reward・評価値・discount"]
  S --> F["is_first・is_last・is_terminal"]
  E --> X["終了情報：成功・失敗・中断・時間制限などの理由"]

保存形式は学習基盤で選ぶ

保存形式は一つに固定されません。重要なのは、論理的なepisode・step構造と、原仕様を失わないメタデータです。

実務では、変更しないrawログ層、学習向けに正規化した層、品質検証結果とprovenanceを管理するmanifest層の三層構成が扱いやすい設計です。rawを上書きせず、変換元と変換処理のバージョンを追跡できるようにします。

品質検証の段階

1. 構造と欠損を自動検査する

最初に、必須フィールドの有無、配列の長さとshape、dtype、episode境界、重複step、欠損値を検査します。動画と状態系列のフレーム数やstep数が対応しているかも確認します。timestampが単調増加しているか、開始・終了フラグがepisode構造と一致するかは、取り込み時に自動判定できる項目です。

2. 同期を検証する

複数カメラ、ロボット状態、操作入力を扱う場合、各センサーの時刻基準を確認します。フレーム欠落、重複、timestampのずれ、長時間収集でのドリフトを測定し、フレーム番号と時刻の対応も保存します。許容するずれに一律の標準値はありません。センサー周期とタスクの反応速度を基準に、ロボットやタスクごとに定義します。

3. 物理的妥当性を確認する

行動値の範囲、関節限界、速度・加速度・jerk、停止や飽和の発生、通信異常を確認します。指令値と実行値を別々に保存すれば、制御系が指令を追従できなかったstepを識別できます。ここでも最大欠損率や許容範囲に、全ロボットへ適用できる統一値はありません。異常を検出する閾値は、機体と制御周期に合わせて設定します。

4. タスク結果と分割を検証する

成功条件を自動判定できるタスクではルール化し、難しい場合は人手レビューを組み合わせます。成功ラベルだけでなく、失敗、途中停止、時間制限による終了などの理由も記録します。

学習・検証・テストの分割はフレーム単位ではなくepisode単位で行います。同一セッション、環境、物体、操作者、初期状態が分割をまたぐと、評価データを事前に見たようなリークが起こり得ます。複数ロボット・環境・タスクを統合する場合は、これらのグループ単位も分割条件に含めます。

使いどころと判断基準

単一ロボットで短い操作を扱う場合でも、episode・step構造と時刻、行動、終了状態は省略しない方がよいでしょう。後から別の学習基盤へ移行したり、失敗データだけを分析したりする際に必要になるためです。

複数ロボットを統合する場合は、共通スキーマよりも意味の保存を優先します。行動空間、座標系、単位、制御周期が異なるなら、正規化後の値だけでなく原仕様も残します。映像を圧縮する場合は容量とI/O効率を検討できますが、codec、解像度、フレームレートの最適条件はタスク、モデル、ハードウェアで変わります。学習性能への影響を一般化せず、再生可能な元データや検証用の情報を確保してください。

まとめ

実機デモの標準的な設計単位は、観測と行動を時系列で結んだepisode・stepです。rawセンサー値、前処理値、指令値、実行値、時刻、終了状態、座標系、単位、キャリブレーション、タスク結果、バージョン情報を一体で管理します。

品質検証は、構造、欠損、同期、物理妥当性、タスクラベル、データ分割の順に段階化すると運用しやすくなります。ただし、同期ずれや欠損率などの閾値に万能な標準値はありません。ロボット、センサー、タスクの反応速度を基準に、検査規則と判定基準をデータセットの仕様として明文化することが、再利用可能な学習データにつながります。

参考情報

• RLDS data format
• What Matters in Learning from Offline Human Demonstrations for Robot Manipulation
• Open X-Embodiment: Robotic Learning Datasets and RT-X Models
• LeRobotDataset v3.0 — Dataset format
• DROID: A Large-Scale In-the-Wild Robot Manipulation Dataset
• BridgeData V2: A Dataset for Robot Learning at Scale

収集時に残した時刻と意味の情報が、後工程の検証可能性を大きく左右します。

AI利用に関する注記

本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。