ロボット方策の機体間移植設計：形状・関節・センサー差を吸収する方法

Tue, 06 Oct 2026 15:07:23 +0900

ロボット方策の移植では、モデルの性能だけでなく、機体差をどの層で扱うかが成否を左右します。

結論

異なるロボットへ学習済み方策を移植する際は、単一の方策ネットワークに機体差をすべて覚えさせるより、共有方策層と機体固有層を分ける設計が有力な選択肢です。共有側では、関節角列よりもエンドエフェクターの姿勢・速度や対象物との相対関係など、機体の関節数に依存しにくいタスク空間を扱います。機体側には、運動学変換、可動域や衝突などの制約処理、グリッパー変換、センサー適応を置きます。

形状・関節構成の差はリターゲティングと制約層、カメラや力覚などの差は座標・単位・時間同期の正規化とモダリティ別アダプター、質量・摩擦・遅延などの差はシステム同定、動力学ランダム化、実行時適応から、差の大きさと検証結果に応じて選択・追加します。提示された研究範囲では、機体記述だけで任意の形状・関節・センサー構成へ完全にゼロショット移植できる一般的な保証は示されていません。

なぜ機体間移植が難しいのか

同じ「物体をつかむ」タスクでも、ロボットごとにリンク長、関節数、関節軸、可動域、エンドエフェクターの構造が異なります。ある機体で有効な関節指令を別機体へそのまま渡しても、同じ手先軌道にはなりません。可動域外の指令、セルフコリジョン、特異姿勢、冗長自由度の扱いも機体ごとに変わります。

センサーも単純な入力形状の問題ではありません。カメラの位置・向きや視野、深度・力覚の有無、固有受容感覚の定義が異なれば、同じテンソルにそろえても意味は一致しない可能性があります。さらに、質量分布、摩擦、バックラッシュ、アクチュエーター特性、通信遅延、接触特性は、形状や関節の写像だけでは解消できません。

前提となる用語

タスク空間表現は、関節角ではなく、手先の位置・姿勢、速度、対象物との相対関係、グリッパー状態などで動作を表す方法です。OpenVLAの標準的なロボット操作設定では、相対エンドエフェクター姿勢とグリッパー状態を含む7次元の操作表現が使われています。

リターゲティングは、操作主体や元のロボットから得た手先軌道を、移植先ロボットの運動学に合わせて変換する処理です。Universal Manipulation Interface（UMI）は、携帯型の操作インターフェースからエンドエフェクターの6自由度運動を取得し、ロボット側の運動学を使って実機アームへ移す方式を扱っています。

機体記述は、リンク配置、関節軸、可動域、速度・トルク上限、エンドエフェクターの意味などを機械可読な形で表す情報です。ROS REP-103は、SI単位、右手系、軸の向きなど、ロボット間で共有する座標・単位規約を定義しています。

内部の仕組み

入力側では、まず単位、座標系、時間同期、カメラの外部パラメータを共通化します。画像、深度、力覚、固有受容感覚を不足分のゼロ埋めだけで統合するのではなく、モダリティ別エンコーダーや変換層に分ける構成を検討します。Octoは画像、固有受容感覚、言語、目標画像などを入力する汎用ロボット方策として設計され、新しいタスクやロボット構成へのファインチューニングを想定しています。

出力は、可能な範囲でエンドエフェクター姿勢・速度、対象物相対座標、接触イベントなどの共通タスク空間に定義します。その後、機体固有層でIK、ヤコビアン制御、QP制約処理などを使い、関節指令へ変換します。機体記述から得た可動域、速度・トルク上限、セルフコリジョンなどを用いて、無効な動作をマスクまたは実行可能な指令へ投影する層は実装候補になります。ただし、機体記述からこれらを自動生成すれば全タスクで十分に機能するとは限らず、個別検証が必要です。

flowchart LR
  S["画像・深度・力覚・固有受容感覚"] --> N["単位・座標系・時間同期・外部パラメータの正規化"]
  N --> M["モダリティ別エンコーダー／変換層"]
  M --> P["共有エンコーダーと共有方策"]
  P --> A["共通タスク空間の行動\n手先姿勢・速度・対象物相対座標・グリッパー状態"]
  A --> R1["機体A用アダプター"]
  A --> R2["機体B用アダプター"]
  A --> R3["機体C用アダプター"]
  D1["機体記述\nリンク・関節軸・可動域・速度・トルク上限"] --> R1
  D1 --> R2
  D1 --> R3
  R1 --> K1["リターゲティング・IK／QP・制約処理・グリッパー変換"]
  R2 --> K2["リターゲティング・IK／QP・制約処理・グリッパー変換"]
  R3 --> K3["リターゲティング・IK／QP・制約処理・グリッパー変換"]
  K1 --> O1["機体Aの関節・エンドエフェクター指令"]
  K2 --> O2["機体Bの関節・エンドエフェクター指令"]
  K3 --> O3["機体Cの関節・エンドエフェクター指令"]

共有方策で機体に依存しにくいタスク空間の行動を生成し、機体別アダプターで運動学変換と制約処理を行う構成を示します。

機体差と設計層の対応

機体差	共通表現	機体記述	リターゲティング	センサーアダプター	動力学適応	主な検証項目
形状・リンク長	手先姿勢、対象物相対座標	リンク配置、関節軸	IK、ヤコビアン	カメラ外部パラメータ	必要に応じて同定	到達性、衝突
関節数・可動域	タスク空間行動	関節制限、速度・トルク上限	冗長性・不足自由度の処理	固有受容感覚の定義	差の大きさに応じて選択	特異姿勢、制約違反
アクチュエーター	速度・姿勢目標	出力上限、制御インターフェース	関節指令への変換	時間同期	同定、ランダム化、実行時適応	遅延、応答、保護機能
カメラ・深度	視覚特徴、対象物相対座標	センサー配置	視点変換	モダリティ別エンコーダー	必要に応じて適応	視野、欠損、外部パラメータ
力覚・固有受容感覚	接触・状態表現	センサー仕様	状態推定への変換	有無・単位・座標の統一	履歴に基づく適応	ノイズ、同期、欠損
通信遅延	時刻付き状態・行動	制御周期	実行周期への変換	タイムスタンプ統一	遅延を含む評価	安全停止、周期ずれ

タスク空間表現は関節数の差を扱いやすくしますが、狭い可動域、冗長自由度、特異姿勢、接触力を伴う操作では十分とは限りません。関節空間の補助出力や、機体固有の接触制御層を加えるかは、タスクと移植先の制約から判断します。

ロボット学習 on Physical AI Hub

ロボット方策の機体間移植設計：形状・関節・センサー差を吸収する方法

結論

なぜ機体間移植が難しいのか

前提となる用語

内部の仕組み

機体差と設計層の対応