模倣学習 on Physical AI Hub

ロボット学習のアクション表現を選ぶ：関節・手先・速度指令の設計比較

Thu, 22 Oct 2026 13:27:39 +0900

同じ「アクション」でも、方策の出力と実機コントローラの入力は分けて設計できる点が気になります。

結論：機体と制御層に合わせて選ぶ

関節空間・エンドエフェクタ空間・速度指令のどれかが、すべてのタスクとロボットで優れるわけではありません。単一の既知ロボットで、デモデータと既存の低レベル制御器が関節軌道を中心に構成されているなら、関節空間が実装上の第一候補です。手先の幾何や複数ロボット間の共通化を重視するなら、エンドエフェクタ空間が有力になります。

速度指令は、状態を観測しながら短い時間幅で修正する閉ループ・サーボに向きます。ただし、積分、飽和、遅延、センサーノイズの影響を受けるため、方策の出力をそのままアクチュエータへ渡す設計は避けるべきです。実機では、方策と安全・制限処理を分離し、下位の制御層へ責務を分担させる構成が現実的です。

なぜアクション表現を分けるのか

模倣学習やVLAでいう「アクション」は、学習方策が予測する値と、実機の低レベルコントローラが受け取る指令の両方を指すことがあります。しかし、両者を同じ表現にする必要はありません。ROS 2 JazzyのJoint Trajectory Controllerは、関節の位置、速度、加速度、effortなどのインターフェースと、軌道の補間・実行を扱います。一方、方策は手先の姿勢や相対変位を出力し、別の制御層で関節指令へ変換することもできます。

したがって選定では、学習しやすさだけでなく、タスクの幾何、データの形式、機体固有性、更新周期、安全監視をどの層に置くかを確認します。

3つの表現の仕組み

関節空間

関節空間では、各関節の位置や速度などを出力します。関節インターフェースへ直接接続しやすく、方策から逆運動学を呼び出さずに済む点が利点です。固定ロボットで収集した関節状態・関節目標中心のデータを使う場合、学習データと実行系の対応も明確になります。ACTはALOHAのような固定された二腕機構で、関節状態・関節目標に近いアクション構成を用いています。

反面、関節数、ゼロ点、可動域、リンク構成への依存が強くなります。別の機構へ移す場合、同じ数値列をそのまま利用できるとは限りません。関節値の変化だけでは、対象物に対する手先の移動を表しにくいタスクもあります。

エンドエフェクタ空間

エンドエフェクタ空間では、手先の位置・姿勢、または相対的な変化を指令します。把持点や接触点など、タスクの幾何に近い表現です。Octoは複数のロボット・タスクへの適用を意識し、手先の位置・姿勢とグリッパを含む7次元のアクション表現を用いています。

手先の位置・姿勢を関節指令へ変換するには、通常、逆運動学を扱う制御層が必要です。手先の速度やtwistなら、ヤコビアンや微分逆運動学による変換が候補になります。特異点、関節限界、衝突などの制約も下流の制御層で処理しなければなりません。抽象度を上げられる一方、変換器や監視機能は複雑になり得ます。

速度指令

速度指令は、関節または手先の速度を指定する形式です。現在の状態を使い、短い時間幅で更新するため、反応的なサーボに適します。状態に応じて誤差を連続的に修正したい場合の候補です。

ただし、速度を積分して位置を更新する構成では、遅延やノイズの影響が蓄積する可能性があります。速度上限、飽和、通信断、異常値、停止時の積分状態も設計対象です。サーボ周波数や通信遅延が成功率へ与える定量的な影響は、資料内で条件を統一した比較がありません。採用時は対象機体で確認する必要があります。

flowchart LR
  A["観測センサー"] --> B["学習方策"]
  B --> C1["関節目標"]
  B --> C2["手先 pose / twist"]
  B --> C3["速度指令"]
  C1 --> D1["スケーリング・レート制限"]
  C2 --> D2["逆運動学・ヤコビアン"]
  C3 --> D3["積分・速度制限・平滑化"]
  D1 --> E["関節・速度・加速度などの制限"]
  D2 --> E
  D3 --> E
  E --> F["安全監視・異常値確認・停止処理"]
  F --> G["サーボ層 / 関節軌道制御"]
  G --> H["アクチュエータ・実機"]
  H --> A

方策の出力と実機インターフェースを分離し、表現ごとの変換・制限・安全処理を下位の制御層に配置する構成を示します。

図1：方策の出力表現と実機制御層の分担。表現の優劣ではなく、変換・制限・安全監視の配置を示す概念図です。

ロボット学習のアクティブラーニング：実機データ収集を不確実性とカバレッジで最適化する

Tue, 13 Oct 2026 15:39:47 +0900

実機データを増やすほど学習が良くなるとは限らない点が、このテーマで特に気になるところです。

先に結論

ロボット学習で次に収集する実機データは、単に失敗回数が多いものや、モデルの不確実性が高いものから選ぶべきではありません。タスク、状態、作業フェーズ、環境条件ごとに、不確実性、条件付き失敗リスク、既存データのカバレッジ不足、多様性、安全性、収集コストを組み合わせて判断します。

実装の出発点としては、候補となる状態や時間窓ごとに、次のような獲得スコアを計算します。

S(x)=w_uU(x)+w_fF(x)+w_cC(x)+w_dD(x)-w_kK(x)

ここで、Uは不確実性、Fは条件付き失敗リスク、Cはカバレッジ不足、Dは多様性・新規性、Kは収集コストまたは安全リスクです。スコア上位をそのまま大量収集するのではなく、似た候補が集中しないよう多様性制約を加え、収集後は固定した層別ホールドアウトで効果を検証します。

なぜ収集対象の選択が必要か

実機データには、ロボットの稼働時間、操作者の作業時間、設備の占有、安全監視などのコストがあります。データ量を増やしても、すでに十分観測された状態ばかりが追加されれば、未経験の初期条件や失敗直前の状態は埋まりません。

ロボットの模倣学習では、デモンストレーションの総量だけでなく、品質、タスクや状態の多様性、初期条件のばらつきが性能に関係します。したがって、全体の平均的な成功率だけでなく、どの条件が不足しているかを把握する必要があります。

判断に使う用語

不確実性は、モデルが入力に対してどれほど確信を持てないかを表します。たとえばMC dropoutでは、dropoutを有効にした確率的推論を複数回行い、予測の分散からモデル由来の不確実性を近似します。ただし、これは成功確率や失敗確率そのものではありません。センサー雑音、接触の偶然性、物体の滑りやすさのようなデータ固有の不確実性とは一致しない場合があります。

条件付き失敗リスクは、全体の失敗件数ではなく、特定の条件における失敗確率です。対象には、タスク、物体、初期姿勢、作業フェーズ、環境、操作者、ロボット構成などが含まれます。頻出する失敗でも、すでに十分な例が集まっていれば、追加収集の情報価値は低い可能性があります。

カバレッジ不足は、既存データで十分に観測されていない領域です。タスク・フェーズ別のヒストグラム、表現空間の近傍密度、クラスタ占有率、環境・物体・操作者の組み合わせなどで確認できます。全体平均ではなく、どの条件の組み合わせが空いているかを見ることがポイントです。

アクティブラーニングの仕組み

候補を作る単位は、エピソード全体に限りません。失敗直前の時間窓、接触イベント、タスクの初期状態、リカバリ操作などを候補にできます。各候補について、モデルの予測、過去ログ、状態分布を参照して指標を正規化します。

不確実性の選択には、MC dropout、アンサンブル分散、モデル間の行動不一致、予測エントロピー、価値関数の分散などが考えられます。失敗については、生の件数よりも条件付き失敗確率、失敗の重大度を加味した期待損失、回復可能性を考慮した優先度が適しています。

そのうえで、期待値の高い候補をバッチで選びます。不確実性上位だけを選ぶと、外れ値や互いに似たサンプルばかりになることがあります。代表性や多様性を組み込み、異なるクラスタ、作業フェーズ、環境条件が同じバッチに含まれるようにします。

flowchart LR
  A["既存データ・実機ログ"] --> B["タスク・状態・フェーズ・環境ごとに分割"]
  B --> C["候補状態・時間窓・接触イベントを作成"]
  C --> D["モデル推論"]
  C --> E["既存データ分布の分析"]
  C --> F["安全性・収集コストの確認"]
  D --> G["不確実性を推定"]
  D --> H["条件付き失敗リスクを推定"]
  E --> I["カバレッジ不足・新規性を計算"]
  G --> J["獲得スコアを統合"]
  H --> J
  I --> J
  F --> J
  J["S(x)=w_uU+w_fF+w_cC+w_dD-w_kK"] --> K["多様性制約付きバッチ選択"]
  K --> L{"安全確認を通過したか"}
  L -->|"はい"| M["人間デモ・自律試行・リカバリ試行を割り当て"]
  L -->|"いいえ"| N["候補を除外または条件を再設計"]
  M --> O["実機データを収集"]
  O --> P["モデルを再学習"]
  P --> Q["固定した層別ホールドアウトで評価"]
  Q --> R["未観測条件・成功率・回復率・安全性を確認"]
  R --> C
  N --> C

不確実性や条件付き失敗リスクだけでなく、カバレッジ不足、多様性、安全性、収集コストを統合して実機データを選択する反復ループです。

指標と選択方法の比較

観点	代表的な方法	優先しやすいケース	誤選択のリスク
不確実性	MC dropout、アンサンブル分散、行動不一致	モデルが判断に迷う状態	外れ値やノイズを選びやすい。不確実性は失敗確率を直接示さない
失敗	条件付き失敗確率、期待損失、回復可能性	特定条件で失敗が集中する状態	生の件数だけでは露出回数や既存データ量を反映しない
カバレッジ	フェーズ別分布、近傍密度、クラスタ占有率	未観測の初期条件や環境	密度を広げてもデモ品質や接触ダイナミクスが不足する場合がある
多様性	クラスタ別層化、代表性制約	バッチ内の重複を避けたい場合	代表性を優先しすぎると高リスク条件を取り逃す可能性がある
コスト・安全	監視コスト、損傷リスク、収集時間	実機試行に制約がある場合	低コストだけを選ぶと重要な危険状態を学べない

実装の流れ

まず、ログにタスク名だけでなく、物体、初期姿勢、作業フェーズ、環境、照明、操作者、ロボット構成、成功・失敗、失敗の重大度、リカバリ結果を記録します。次に、既存データを条件別に分割し、状態ごとの露出回数と失敗確率を推定します。

ロボット行動方策の実行粒度：アクションチャンクと再計画周期の設計

Thu, 24 Sep 2026 13:31:55 +0900

アクションチャンクの「長さ」と再計画の「間隔」は、同じ数字で語られがちな点が気になります。

先に結論

ロボットの行動方策では、1回の推論で予測する長さ H と、次の推論まで実際に実行する長さ K を分けて設計するべきです。Hはタスクの時間的なまとまりや先読みを表し、Kは環境変化に対する反応性と推論負荷を左右します。

基本方針は、通常 H >= K とし、予測した全アクションを固定的に実行しないことです。接触、物体移動、外乱、視覚変化が多い局面ではKを小さくし、安定した自由空間動作や推論コストが高い構成ではKを大きくする候補があります。ただし、最適な数値はロボット、制御周期、アクション表現、推論遅延、タスクによって変わるため、実機でHとKを組み合わせたアブレーションを行って決めます。

なぜHとKを分けるのか

アクションチャンクとは、方策が1回の推論で単一のアクションではなく、複数ステップの連続アクション列を予測する設計です。ACT（Action Chunking with Transformers）は固定長のアクション列を予測し、時間的に重なる予測をtemporal ensembleで融合する構成を採用しています。一方、Diffusion Policyはアクション列を生成し、その一部を実行して観測を更新し、再計画するreceding-horizon controlを用います。

ここで「チャンク長」という言葉を、予測する列の長さと、再計画まで実行する長さの両方に使うと、実装上の議論が曖昧になります。本稿では、予測長をH、実行してから次に推論する間隔をKと定義します。Hを長くしても、Kを短く保つことは可能です。逆にHとKを同じ値にして、予測列全体をオープンループで実行することもできますが、その場合は途中の観測を使った修正機会が減ります。

ステップ数ではなく時間で考える

HとKはステップ数だけでなく、低レベル制御周期 Δt_ctrl と組み合わせて評価します。予測時間はHΔt_ctrl、再計画時間はKΔt_ctrlです。同じKでも、制御周期が異なれば、ロボットが観測なしで動く物理的な時間は変わります。

さらに、観測、通信、方策推論を含むエンドツーエンド遅延を T_inf とします。同期推論では、少なくともT_infがKΔt_ctrlを超えないかを確認する必要があります。超える場合、推論完了までに現在のアクション列を使い切る可能性があります。そのときは、アクションバッファ、非同期推論、低レベルサーボ、安全な停止・ホールド機構などを設け、推論の遅さを単純なオープンループ時間の増加として放置しないことが重要です。

flowchart LR
  A["時刻 t0：観測"] --> B["方策推論"]
  B --> C["長さHのアクション列を予測"]
  C --> D["最初のKステップだけ実行"]
  D --> E["時刻 t0+K：新しい観測"]
  E --> F["次のアクション列を再計画"]
  F --> G["新しい列の一部を実行"]
  G --> H["次の観測と再計画"]
  C -. "HΔt_ctrl：予測時間" .-> D
  D -. "KΔt_ctrl：実行・再計画間隔" .-> E
  F -. "予測が重なる場合" .-> I["temporal ensembleや加重平均で融合"]
  I -. "滑らかさと反応遅れを評価" .-> G
  C -. "基本方針 H≥K" .-> F

予測長Hは先読みの長さ、再計画間隔Kは実際に実行してから次の推論を行うまでの長さを表す。基本方針はHをK以上とし、観測更新によって実行列を分割することです。

HとKの時間軸

時刻t0で方策が長さHのアクション列を予測し、そのうち最初のKステップを実行します。t0+Kで新しい観測を取得し、次の列を予測します。新しい予測と過去の予測が同じ時刻に対応する場合は、temporal ensembleや加重平均によって融合できます。これにより、チャンク境界での入力の不連続や急変を抑えられる可能性があります。

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

Sun, 08 Mar 2026 08:24:51 +0900

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

先に結論

ロボット学習用の実機デモは、動画だけでなく、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の階層で管理し、各stepに観測・行動・時刻・終了状態を、episodeにタスクやセンサーなどのメタデータを付与します。

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

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

形式	構造・特徴	向いている場面	注意点
RLDS	episodeとstepを中心に、観測、行動、終了状態などを表現	step中心の学習基盤、複数データセットの統合	`is_last`や`is_terminal`の意味を実装間で確認する
robomimic HDF5	demo単位にactions、observations、rewards、donesなどを格納	robomimicを利用するロボット操作学習	HDF5内のキーとデータ型、終了状態の意味をそろえる
Parquet・MP4系	低次元データやメタデータを表形式、映像を動画チャンクとして分離	映像と状態データを分けた運用、I/Oや管理単位を重視する場合	圧縮方式やフレーム欠落の影響をタスクごとに確認する

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