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

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