Embodied AI on Physical AI Hub

ロボット視覚の語彙設計：オープンボキャブラリー認識とタスク限定認識の使い分け

Thu, 05 Nov 2026 15:22:58 +0900

語彙を広げるほどロボットが賢くなるのか、それとも判断を狭く保つことが安全につながるのかが、このテーマの出発点です。

結論

認識対象が頻繁に変わり、未知物体の発見や自然言語による対象指定が必要なら、オープンボキャブラリー認識を第一候補にする。一方、棚卸しSKUやピッキング対象が固定され、誤検出のコストと再現性が重い場合は、タスク限定認識を基本にするのが妥当だ。

安全性が必要なロボットでは、どちらか一方に任せるより、オープンボキャブラリー方式で候補を発見し、後段のタスク限定モデル、未知拒否、行動ゲートで検証する構成が現実的である。

なぜ語彙設計が重要か

ロボットの視覚認識では、画像中の物体を見つけるだけでは動作を決められない。検出結果が示すのは、主に対象の位置と、指定された語彙との一致である。把持可能性、向き、材質、危険性、作業手順への適合性まで自動的に確定するわけではない。

そのため、認識器の選択は既知クラスの精度だけで決められない。未知物体を誤って受け入れる割合、低信頼度入力を拒否したときのカバレッジ、信頼度の校正、推論遅延、メモリ使用量、カテゴリ追加コスト、最終的な行動成功率を分けて考える必要がある。

用語と仕組み

オープンボキャブラリー認識は、学習時に固定したクラスIDだけでなく、推論時にテキストクエリなどで指定した語彙の対象を認識・検出する方式である。画像と自然言語の対応を学習したモデルでは、テキストラベルを指定したゼロショット分類が可能になる。OWL-ViT、Grounding DINO、ViLDは、この考え方を物体検出へ適用する代表例である。

一方、タスク限定認識は、業務で扱う対象とラベル定義をあらかじめ限定し、その範囲で分類・検出する構成を指す。対象が固定されているなら、必要なクラス、属性、拒否条件を明確に設計しやすい。反復的なピッキングや固定SKUの棚卸しでは、語彙を広げることよりも、定義した対象を安定して扱うことが優先される。

なお、オープンボキャブラリー認識とオープンセット認識は同義ではない。前者は推論時に語彙を拡張・指定する能力であり、後者は既知クラス以外の未知入力を検出し、拒否または未知として扱う能力である。テキストで対象を指定できても、未知物体を必ず安全に拒否できるとは限らない。

オープンボキャブラリー方式の価値と限界

カテゴリ追加のたびに完全な教師データを用意しなくても、長い尾のカテゴリや自然言語で指定した対象を候補化できることが大きな利点である。事前に全カテゴリを列挙しにくい環境理解や、探索段階の棚卸しでは、対象語彙を後から変更できる柔軟性が役立つ。

ただし、ゼロショット性能は、プロンプトの表現、画像ドメイン、照明、視点、遮蔽、対象カテゴリの粒度に左右される。研究論文で示されたベンチマーク結果から、特定の現場でタスク限定モデルを上回ることや、未知物体を適切に拒否することを保証することはできない。同義語、階層カテゴリ、ブランド名、属性語の影響もモデルとデータセットに依存する。

タスク限定方式の価値と限界

対象の種類とラベル定義が安定し、同じ対象を反復して扱うなら、タスク限定認識は評価範囲を明確にしやすい。誤検出が停止、衝突、誤ピッキングにつながる場合には、対象外を受け入れない条件やクラス別しきい値を設けやすい点も有利である。

ただし、限定したモデルでも信頼度をそのまま成功確率として扱ってはいけない。ニューラルネットワークの予測信頼度は、実際の正解率と一致しないことがある。温度スケーリングなどの校正、クラス別しきい値、拒否領域の検証が必要になる。限定方式だから必ず高精度、とは言えない。

flowchart LR
  A["画像入力"] --> B["オープンボキャブラリー候補生成\nテキストクエリで対象を指定"]
  B --> C{"候補の信頼度と対象条件を確認"}
  C -->|"未知・低信頼度、または条件不一致"| D["拒否・再観測・人手確認"]
  C -->|"検証対象として受理"| E["タスク限定分類"]
  E --> F["属性・姿勢・把持可能性を検証"]
  F --> G{"信頼度と安全規則を確認"}
  G -->|"条件を満たす"| H["ロボット動作"]
  G -->|"条件を満たさない"| D

オープンボキャブラリー認識を候補発見に使い、タスク限定の検証と信頼度・安全規則による行動ゲートを後段に置く構成。

選択肢の比較

観点	オープンボキャブラリー認識	タスク限定認識	ハイブリッド構成
語彙	推論時にテキストなどで変更・追加	事前に対象を定義	発見は広く、検証は限定
向く場面	未知物体の探索、環境理解、変動するカテゴリ	固定SKU、反復ピッキング、固定部品	安全性と柔軟性を両立したい場面
未知物体	候補化できるが、未知拒否は別機能	対象外として定義しやすいが、未知発見は弱い	候補生成後に拒否・検証できる
データ追加	カテゴリ追加時の教師データ負担を抑えやすい	アノテーションや再学習が必要になりやすい	追加対象だけを段階的に検証できる
主な注意点	プロンプト、視点、照明、遮蔽への依存	校正不良、対象外の誤受理、語彙外への対応	段数増加による遅延と設計複雑化
評価	未知誤受理率、候補再現、拒否性能	既知精度、校正、拒否性能	最終行動成功率と各段の失敗率

実装での使い分け

探索フェーズでは、画像入力に対してテキストクエリを変えながら候補を生成し、未知または低信頼度の候補をそのまま行動へ渡さない構成が考えられる。運用フェーズでは、候補に対してタスク限定の分類、属性確認、姿勢推定、把持可能性判定を行い、最後に信頼度と安全規則による行動ゲートを置く。

移動マニピュレーターの全身動作計画：台車とアームを同時に最適化する方法

Tue, 03 Nov 2026 15:28:56 +0900

台車とアームを別々に安全と判断しても、全身では別の問題が現れる点が気になります。

先に結論

移動マニピュレーターの全身動作計画では、台車とアームを別々に計画するのではなく、台車姿勢とアーム関節を結合した一つの構成空間として扱うのが基本です。平面移動なら台車状態をSE(2)、高さや姿勢も変化するならSE(3)として表し、全身状態を q=[q_base,q_arm] とします。

この状態と軌道に対して、エンドエフェクタの可到達性、台車・アーム・把持物を含む衝突、支持多角形に基づく安定性を同じ検証ループで評価します。衝突と安定性はハード制約、可操作性、経路長、台車移動量、クリアランスなどは目的関数またはソフト制約として分けると、設計意図を明確にできます。

MoveItのPlanning Sceneはロボット状態、環境中の衝突物、付着物を管理し、衝突判定に利用できます。一方、Nav2のフットプリントは主に台車外形を2Dコストマップ上で扱う仕組みです。これらだけでアームの掃引体積やペイロード依存の安定性まで自動的に統合されるわけではないため、共有状態モデルと追加の妥当性判定が必要です。

なぜ統合が必要なのか

台車だけを見れば障害物を避けていても、アームのリンクや把持物が接触することがあります。反対に、アームの逆運動学が解けても、その姿勢で重心が支持領域の外側へ移動すれば、転倒余裕が小さくなる可能性があります。台車姿勢が変われば、同じ関節値でもエンドエフェクタの位置、障害物との距離、可到達性が変化するためです。

Nav2では円形または多角形のフットプリントを設定し、台車の衝突・通行可能性をコストマップで評価します。しかし、アームのリンク形状、把持物、アームの動作による掃引体積までは自動的に表しません。MoveItのPlanning Sceneはロボットリンクと環境形状を含む3D衝突モデルに向いていますが、Nav2のフットプリントや安定性評価との同期は別途設計する必要があります。

用語と内部の仕組み

可到達性はアーム単体の性質ではありません。台車姿勢と、エンドエフェクタに許される位置・姿勢の組み合わせとして評価します。Task Space Regionは許容されるエンドエフェクタの位置・姿勢領域を表し、その範囲でのIK可解性を計画へ組み込むために利用できます。

候補状態 q について、まず台車姿勢とアーム関節から全リンクの姿勢を計算します。次に、エンドエフェクタが目標領域に入るか、IKが解けるかを確認します。そのうえで、台車、アーム、把持物と環境の衝突を判定し、支持多角形と重心投影、または設定した転倒余裕を評価します。アーム姿勢、ペイロード、把持物の位置が変わると重心も変わるため、安定性はアーム計画から切り離せません。

サンプリング型計画では、ウェイポイントだけでなく状態間のモーションも検証します。ウェイポイントが安全でも、補間区間でアームや把持物が障害物を横切る可能性があるためです。状態妥当性チェッカーとモーション妥当性チェッカーを分ける構成では、全身軌道の区間にも衝突・安定性検証を適用します。補間分解能、形状近似、連続衝突検出の有無によって検証精度が変わる点には注意が必要です。

計画問題は次のように分けると扱いやすくなります。

ハード制約：関節限界、全身衝突、支持条件、設定した安定余裕
ソフト目的：経路長、台車移動量、可操作性、クリアランス、速度・加速度
目標条件：エンドエフェクタの位置・姿勢、または許容姿勢領域

flowchart LR
  S["環境センサ・ロボット状態"] --> W["共有ワールドモデル\n台車・アーム・把持物・環境・予約済み空間"]
  W --> B["台車候補姿勢・粗い経路の生成"]
  W --> Q["全身状態 q=[q_base,q_arm] の生成"]
  B --> Q
  Q --> IK["全身IK・可到達性評価\nTask Space Region を確認"]
  IK -->|"可解"| C["全身衝突判定\n台車・アーム・把持物・環境"]
  IK -->|"不可解"| R["候補を除外"]
  C -->|"衝突なし"| ST["安定性評価\n支持多角形・重心投影・設定した安定余裕"]
  C -->|"衝突あり"| R
  ST -->|"条件を満たす"| O["軌道最適化\n経路長・台車移動量・可操作性・クリアランス"]
  ST -->|"条件を満たさない"| R
  O --> V["補間軌道全体の検証\n状態と軌道区間の衝突・安定性"]
  V -->|"妥当"| E["軌道実行"]
  V -->|"不妥当"| R
  E --> X["環境またはロボット状態の変化"]
  X --> S

台車、アーム、把持物、環境を共有状態モデルで扱い、可到達性・全身衝突・安定性を状態と軌道区間の両方で検証する計画ループ。

計画方式の比較

方式	特徴	向いている場面	主な制約
別計画	台車経路とアーム動作を独立に生成	単純な環境、動作範囲が明確な場合	全身衝突や安定性の不整合を見落としやすい
階層方式	台車候補や粗い経路を先に作り、全身IK・衝突・安定性で絞り込む	計算量を抑えたい場合	先に除外した台車姿勢を後段で使えない
全身同時最適化	台車とアームの変数を同時に探索・最適化	狭い環境、把持姿勢と台車位置の依存が強い場合	状態空間が大きく、計算量とモデル設計が難しい
ハイブリッド方式	候補生成、全身IK、最適化、軌道検証を組み合わせる	実装と性能のバランスを取りたい場合	各層の状態・環境同期が必要

実装構成と使いどころ

現実的な出発点は階層型です。まず台車候補姿勢、または粗いベース経路を生成します。次に各候補について全身IKと可到達性を評価し、目標を実現できる候補だけを残します。その後、Planning Sceneなどで台車・アーム・把持物・環境の衝突を判定し、安定性評価を加えた全身計画または軌道最適化を行います。最後に補間された軌道全体を検証し、環境やロボット状態が変化した場合は再計画します。

ロボットの遠隔操作と自律制御を安全に切り替える：人間への引き継ぎ設計

Fri, 30 Oct 2026 14:33:57 +0900

自律制御と遠隔操作の境界では、切り替えの速さよりも権限の重なりをどう防ぐかが設計上の焦点になります。

先に結論

ロボットの自律制御と遠隔操作の切り替えは、単一の信頼度スコアや「人間を常に優先する」という規則だけで決めるべきではない。安全包絡への接近、認識・自己位置推定の不確実性、タスク例外、通信状態、人間からの介入要求を組み合わせたリスクベースの状態遷移として設計する。

運動指令を発行できる主体は、常に一つに限定する。自律系と遠隔操作者の指令経路から分離した安全監視層を設け、必要な場合には双方の指令を拒否・遮断できるようにする。通信断、端末の無応答、許容遅延の超過、制御権の期限切れでは、遠隔操作を継続せず、検証済みの安全停止または最小リスク状態へ移行させる。

なぜ引き継ぎ設計が難しいのか

引き継ぎは、単にモード名を書き換える処理ではない。自律系が指令を出し続けたまま遠隔操作者の指令を受け付ければ、切り替え境界で指令が競合する。逆に自律系を先に停止すると、操作者が状況を把握する前にロボットが別の状態へ移る可能性がある。

そのため、設計対象はトリガーだけではない。旧制御主体がいつ指令権を失ったか、新しい主体がいつ取得したか、操作者がどの状態を見ているか、引き継ぎに失敗した場合にどこへ遷移するかまでを、制御契約として定義する必要がある。ISO 12100:2010も、意図する使用と合理的に予見可能な誤使用を含むリスクアセスメントとリスク低減を示しており、モード切替もその対象として扱うのが妥当である。ISO 12100:2010

前提となる用語

自律制御は、ロボット側の方策やプランナーが運動指令を生成する状態である。遠隔操作は、通信経路を通じて操作者が指令を入力する状態を指す。共有自律は、人間の方策とロボットの方策を組み合わせる設計で、意図検出、制御権の裁定、状態や意図の伝達が主要な論点になる。

共有自律には、人間とロボットの指令を連続的に混合するpolicy blendingと、明示的な裁定によって一方へ制御権を渡す方式がある。すべての用途で優れた単一方式が定まっているわけではないため、責任主体と安全制約を明確にできるかで選ぶべきである。

引き継ぎ条件の設計

引き継ぎトリガーは、次の観測項目を個別に評価し、論理条件として組み合わせる。

予測軌道が安全包絡に接近、または違反する
認識や自己位置推定の不確実性が許容範囲を超える
予定外の物体、作業対象、経路、タスク状態が現れる
遠隔操作者が介入を要求する
通信の期限、ハートビート、遅延などに異常がある

数値閾値は一般化できない。安全包絡、信頼度、通信遅延、タイムアウトの値は、ロボットの速度や質量、環境、作業対象、運用地域、適用規格によって変わるため、対象機のリスク分析と検証で定める。NIST AI Risk Management Frameworkは役割・責任、リスク測定、継続的監視、リスク対応を扱うが、具体的なロボットの切替閾値は規定していない。NIST AI RMF

状態機械と操作権限

実装では、少なくとも「自律制御」「引き継ぎ要求」「引き継ぎ待ち」「遠隔操作」「安全停止」「復旧」を明示した状態機械にする。引き継ぎ要求が発生しても、直ちに操作者へ運動指令を許可するのではなく、ロボット状態、通信品質、操作者の準備状態、停止が必要かどうかを確認する。

旧制御主体のアクチュエーション権限が失われたことを確認してから、新しい主体へ権限を渡す。制御権をリースまたはトークンとして扱い、期限切れ、二重取得、明示的な解放を検出できるようにすると、境界上の異常を追跡しやすい。

flowchart LR
  A["自律制御\n運動指令の主体: 自律系"] -->|"安全包絡への接近・認識不確実性・タスク例外・人間要求"| B["引き継ぎ要求"]
  B --> C["引き継ぎ待ち\n状態・通信・認証・準備状態を確認"]
  C -->|"旧主体の権限喪失を確認\n制御権リースを解放"| D["遠隔操作\n運動指令の主体: 操作者"]
  C -->|"確認失敗・承認失敗・危険状態"| E["安全停止または\n最小リスク状態"]
  D -->|"ハートビート途切れ・端末無応答\n許容遅延超過・リース期限切れ"| E
  D -->|"自律系への復帰条件を確認\n制御権を明示的に解放"| F["復旧"]
  E -->|"原因除去・安全確認・復旧承認"| F
  F -->|"新しい制御権を単一主体へ付与"| A
  S["独立した安全監視層\n速度・位置・侵入・停止条件を監視"] -.->|"必要時に指令を拒否・遮断"| A
  S -.->|"必要時に指令を拒否・遮断"| D
  S -.->|"通常の権限裁定とは分離"| E

引き継ぎ条件の評価、旧制御主体の権限喪失確認、新しい主体への制御権付与、通信異常時の安全遷移を状態機械として示す。

方式	指令の扱い	使いどころ	主な制約
自律制御	自律系が運動指令を発行	通常運転の自動化	想定外状態での引き継ぎ条件が必要
遠隔操作	操作者が運動指令を発行	例外状態への人間の介入	通信遅延、端末障害、状況認識が制約になる
共有自律	指令を混合または裁定	人間と自律系の協調	責任主体と指令競合の明確化が必要
安全監視・停止	指令を監視し拒否・遮断	危険状態の抑制	通常の操作権限とは分離して検証する

基本形として採用しやすいのは、単一オーナー方式である。自律系、遠隔操作者、保守・設定系のうち、運動指令を発行できる主体を常に一つにする。アクセス強制と最小権限の考え方は、主体ごとの権限分離に利用できるが、NIST SP 800-53自体はロボット安全規格ではない。NIST SP 800-53 Rev. 5

ロボットの長期記憶アーキテクチャ：エピソード・意味・手続き記憶をどう設計するか

Mon, 26 Oct 2026 13:28:05 +0900

長時間タスクでは、記憶を増やすことより、記憶をどう疑いながら使うかが設計上の焦点になります。

先に結論

ロボットの長時間タスクでは、エピソード記憶・意味記憶・手続き記憶を、異なる役割を持つ層として分離する設計が妥当です。エピソード記憶は時系列の経験証拠、意味記憶は検証・抽象化された環境知識、手続き記憶は条件付きで再利用できるスキルを担当させます。

オンライン実行では、現在のタスクとセンサー情報から過去の記憶を検索し、現在の状態と照合してから手続きを選択します。実行結果は新しいエピソードとして保存し、反復的に確認された事実や、検証済みで再利用価値のある行動だけを上位の記憶へ昇格させます。過去の記憶を、現在の環境の代わりに無条件で使わないことが設計の基本です。

なぜ記憶を分けるのか

長時間タスクでは、過去の観測や成功した操作を再利用できると、毎回ゼロから推論する必要を減らせます。一方、全履歴をVLMやVLAのコンテキストに入れ続ける方法は、履歴の増加と検索負荷を招きます。MemGPTは、モデルの主要コンテキストと外部アーカイブ記憶を分離し、必要な情報を関数呼び出しで移動・検索する構成を示しました。ロボットでも、実行モデルと長期記憶を分ける際の参考になります。

ただし、3分類はロボット研究で統一された標準仕様ではありません。メモリーストリームと反省を中心に扱う構成や、コンテキストとアーカイブの階層を扱う構成もあります。ここでの3分類は、保存対象、検索条件、更新条件、実行系との接続を整理するための設計上の枠組みです。

3種類の記憶の役割

エピソード記憶：経験の証拠

エピソード記憶には、時刻、場所、対象、観測、行動、成否、環境からのフィードバックを、一つの経験ログとして保存します。現在と似た状況を探す用途に向きますが、検索結果をそのまま事実や命令として扱ってはいけません。現在の知覚と照合するための状況証拠として利用します。

検索キーは意味的な類似度だけでなく、場所、対象、タスク、時刻、成功履歴などを組み合わせます。Inner Monologueが示すように、物体検出やシーン状態、行動の成功・失敗を推論へ戻せば、実行中の計画を更新できます。

意味記憶：抽象化された知識

意味記憶には、複数の経験から抽象化された安定的な事実を保存します。物体と場所の関係、ユーザーや施設の好み、環境の制約などが対象です。個別の観測をそのまま蓄積するのではなく、再利用しやすい知識として扱います。

各項目には、出典、信頼度、有効期限を付与します。単一の観測だけで固定せず、反復確認や他の観測との整合性を経て更新する方針が適しています。必要な反復回数や信頼度のしきい値に、一般的な数値基準は確立していません。

手続き記憶：実行可能なスキル

手続き記憶には、再利用可能なスキル、プログラム、ポリシー、行動スキーマを保存します。前提条件、引数、期待効果、実行後の検証方法も併せて管理します。

Voyagerは、環境からのフィードバックを用いて、実行可能なコード形式のスキルを蓄積・再利用する構成を示しました。これは手続き記憶の実装例として解釈できます。ただし、未知の物体、照明、配置、摩擦条件へ安全に一般化できる範囲は、スキル表現とロボットに依存します。

読み出しと書き込みの流れ

flowchart LR
  A["現在のタスクとセンサー入力"] --> B["メモリールータ"]
  B --> C["エピソード記憶\n経験証拠"]
  B --> D["意味記憶\n制約・環境知識"]
  C --> E["現在の状態との照合"]
  D --> E
  E --> F["手続き記憶\n前提条件付きスキル"]
  F --> G["実行可能性の再検証"]
  G --> H["実行器"]
  H --> I["行動結果・新しい観測"]
  I --> C

現在の知覚を起点に過去の記憶を検索し、手続きを再検証して実行した結果をエピソード記憶へ保存する流れ。

読み出しでは、現在のタスクと知覚情報をメモリールータへ渡します。エピソード記憶から類似する経験を、意味記憶から関連する制約や環境知識を検索し、それらを条件として手続き記憶から候補スキルを選びます。

SayCanは、言語モデルによる行動選択と、ロボットが各スキルを実行できる可能性を表すアフォーダンスを組み合わせます。この考え方は、手続きの検索と実行可能性の検証を分ける設計に対応します。実行後は、成功・失敗や環境からのフィードバックを取得し、継続または再計画します。

書き込みでは、まず全試行をエピソードとして保存します。反復・整合性・信頼度を確認し、安定した事実を意味記憶へ、再利用価値と安全性を検証できた行動系列を手続き記憶へ昇格させます。

記憶層の比較

記憶	保存対象	検索キー	更新	実行系との接続
エピソード	観測・行動・結果・時刻・場所	類似状況、場所、対象、タスク	試行ごとに保存	状況証拠として提供
意味	事実、関係、制約、好み	対象、場所、関係、制約	反復確認後に更新	手続き選択の条件
手続き	スキル、プログラム、ポリシー	タスク、前提条件、実行可能性	検証済みのものを登録	実行器へ渡すが再検証する

環境再訪での判断基準

再訪時は、場所・対象・タスクで候補を検索し、時刻、位置、信頼度、有効期限で絞り込みます。その後、現在のセンサー情報や状態推定と照合します。整合すれば手続きを候補にできますが、過去の成功履歴だけで実行を確定してはいけません。不一致なら、再観測や再計画へ分岐させます。

キャリブレーション誤差を計画へ伝える：ロボットの位置不確実性を扱う方法

Fri, 23 Oct 2026 13:32:17 +0900

校正値を高精度な固定値として扱うだけで、計画時の安全性まで十分に表せるのかが本稿の出発点です。

先に結論

キャリブレーション誤差は、単一の安全マージンやXYZ各軸の独立した誤差として扱うのではなく、校正パラメータ、関節状態、認識結果などの誤差源を分けた確率分布として保持し、最終的な手先・対象物・障害物の座標へ伝播させるべきです。姿勢にはSE(3)上の局所摂動と6次元共分散を使い、局所的な非線形性であればヤコビアンによる共分散伝播を適用します。非線形性や分布の歪みが強い場合は、シグマ点法やモンテカルロ法へ切り替えます。

経路計画では、衝突確率を制約する方法、または不確実性に応じてリンクや掃引体積を保守的に膨張させる方法を使います。把持計画では、エンドエフェクタと対象物の姿勢を同じ基準座標系へ変換し、相対姿勢の分布から接触成立、衝突回避、力閉包、把持成功のロバスト性を評価します。

なぜ校正誤差を計画へ伝えるのか

校正後の変換値を固定パラメータとして扱うと、計画器は「推定された平均姿勢が正しい」という前提で動作します。しかし実際には、校正データの測定誤差、関節角度の誤差、対象物認識の誤差などが残ります。校正パラメータの推定時に測定値の不確実性を重み付けし、パラメータ間の相関を含む推定共分散を保存できれば、その不確実性を後段の計画に入力できます。

ここで重要なのは、校正残差の共分散だけで実機の誤差全体を説明できるとは限らないことです。温度、荷重によるたわみ、バックラッシュ、摩擦、未モデル化の機構誤差などは、校正時と運用時で変化する可能性があります。したがって、検証用の姿勢、荷重、温度条件で残差を確認し、必要なら計画側の不確実性モデルへ反映します。

前提となる姿勢表現

位置と回転を別々のスカラー誤差として扱うのではなく、ロボットの姿勢をSE(3)上の状態として表します。基準姿勢の近傍にある小さな変動を6次元の局所摂動で表し、その平均と6×6共分散を保持する形が基本です。共分散には、位置と回転の相関や、回転軸間の相関も含められます。

ただし、共分散行列だけを保存しても意味は完全には決まりません。左摂動か右摂動か、摂動をbody frameで定義するかworld frameで定義するか、回転摂動をどのように定義するかによって、同じ6×6行列の解釈が変わります。実装では、共分散とともに摂動の定義、基準座標系、姿勢の変換規約を記録します。

共分散を座標変換へ伝播する仕組み

関節状態、校正パラメータ、対象物姿勢などを入力x、変換後の手先姿勢や相対姿勢を出力yとし、y=f(x)と表します。平均状態の近傍で線形化できるなら、ヤコビアンJを用いて次のように出力共分散を近似します。

Σ_y ≈ JΣ_xJᵀ

校正パラメータと関節状態など複数の誤差源を同時に扱う場合、それぞれの共分散を足すだけでは不十分です。誤差源の間に相関があるなら、交差共分散も含めて計算します。たとえば、校正パラメータの不確実性を順運動学へ入力し、手先姿勢の分布を得た後、対象物姿勢の分布と同じ座標系へ変換して相対姿勢を構成します。

一次のヤコビアン近似は、摂動が小さく、変換が局所的に線形とみなせる場合に適しています。大きな回転誤差、接触境界付近の判定、強い非線形性、多峰性のある分布では、平均と共分散だけでは形状を十分に表現できません。その場合はシグマ点法、モンテカルロ法、粒子表現を検討します。

flowchart LR
  A["校正データ"] --> B["校正パラメータ推定"]
  A --> C["測定誤差のモデル化"]
  B --> D["パラメータ平均と共分散"]
  E["関節状態"] --> F["誤差源の統合"]
  G["対象物認識結果"] --> F
  D --> F
  C --> F
  F --> H["摂動規約と基準座標系を統一"]
  H --> I["SE(3)姿勢変換"]
  I --> J["ヤコビアンによる共分散伝播"]
  J --> K["手先・対象物・障害物の姿勢分布"]
  K --> L{ "非線形性や分布の歪みが強いか" }
  L -- "いいえ" --> M["共分散を計画へ入力"]
  L -- "はい" --> N["シグマ点法またはモンテカルロ法"]
  N --> M
  M --> O["確率制約または保守的形状膨張"]
  M --> P["相対姿勢分布による把持評価"]

校正パラメータ、関節状態、認識結果の不確実性を姿勢分布へ伝播し、経路計画と把持計画へ入力する処理の全体像。

伝播手法の比較

手法	非線形性への対応	計算量の目安	相関の扱い	向いている場面	注意点
ヤコビアンによる共分散伝播	局所近似	小	共分散に含めて扱う	連続的な姿勢変換、計画の反復	大きな摂動や多峰性に弱い
シグマ点法	一次近似より広い非線形性に対応	中	入力分布から反映	姿勢変換や状態推定	分布の多峰性を完全には表せない
モンテカルロ法	強い非線形性に対応	大	サンプル間の関係として扱う	接触・衝突・把持成功の評価	サンプル数と計算時間が必要
保守的な形状膨張	分布形状を単純化	小	相関を別途考慮	衝突判定のベースライン	安全性と保守性の調整が必要

経路計画と衝突判定

経路計画では、各時刻のロボット状態と障害物との衝突確率に上限を設ける確率制約付き計画を構成できます。実装しやすいベースラインは、障害物境界へ向かう距離方向に位置分散を投影し、信頼区間や分位点を計算してリンク形状や掃引体積を膨張させる方法です。平均姿勢だけで衝突なしと判定するより、不確実性が大きい方向へ余裕を持たせられます。

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

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

実装の流れ

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

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

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

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

ロボット視覚の分布外検知：未知物体を見つけて安全に行動を保留する設計

Sun, 04 Oct 2026 14:37:40 +0900

未知物体を見つけることと、ロボットを安全に止めることは、同じ判定ではありません。この違いが設計の分かれ目です。

結論

ロボットの視覚認識で未知物体や分布外（OOD）入力を扱うには、最大ソフトマックス確率だけで行動可否を決めてはいけません。分類信頼度、OODスコア、物体の位置推定品質、モデル間の不一致、センサ健全性、フレーム間の一貫性を組み合わせた受理ゲートを設け、条件を満たさない入力は行動系へ渡さず、明示的なsafe-hold状態へ送る設計が現実的です。

safe-holdでは、状況に応じて停止または減速し、再観測、再計画、人間確認などへ切り替えます。閾値は一般的な固定値ではなく、危険な誤受理を重く扱うリスク・カバレッジ評価と、照明、遮蔽、反射、モーションブラー、センサ欠損を含む実機シナリオで決める必要があります。

なぜ未知入力への備えが必要か

OOD検知は、学習時のデータ分布から外れた入力を検出する問題です。一方、オープンセット認識は、テスト時に学習時には存在しなかった未知クラスを扱う問題として整理できます。既知クラスの精度が高くても、実環境で未知物体を既知クラスの一つとして誤認すれば、把持や進入などの行動に誤った前提を渡す可能性があります。

ただし、未知物体であること自体が物理的危険を意味するわけではありません。反対に、既知クラスでも遮蔽、異常姿勢、反射、ブラー、センサ故障によって危険な認識が生じる場合があります。そのため、OOD検知は安全性全体の判定器ではなく、視覚認識パイプラインの一つの警告信号として扱います。

信頼度とOODスコアの前提

最大ソフトマックス確率は、誤分類例やOOD例を検出する低コストなベースラインです。しかし、その値を正しさや安全性の確率として直接解釈することはできません。深層モデルでは、予測確率と実際の正解率が一致しない校正不良が起こり得るためです。必要に応じて校正を検討しても、分布シフト下で安全な確信度が保証されるわけではありません。

候補となる方法には、特徴空間での距離、クラス条件付き分布からのMahalanobis距離、複数モデルの予測分散を利用する深層アンサンブルがあります。手法ごとに検出しやすい分布外入力が異なり、画像分類、物体検出、敵対的入力、実環境のセンサ劣化を横断して論文上の数値を直接比較することはできません。

ロボットでは画像全体のOOD判定だけで不十分な場合があります。未知物体が画面の一部にあるなら、その領域を局所化し、既知物体と未知物体を区別するオープンワールド物体検出が必要です。物体検出の信頼度が低い、位置が不安定、未知領域が行動経路に重なる、といった情報を行動判断へ渡せる形にします。

flowchart LR
  A["カメラなどのセンサ入力"] --> B["物体検出・分類"]
  B --> C["物体クラス・位置・物体性・検出信頼度"]
  C --> D["OOD・不確実性の評価"]
  D --> D1["最大確率・校正済み信頼度"]
  D --> D2["特徴距離"]
  D --> D3["モデル間の予測ばらつき"]
  C --> E["未知物体の領域・局所化"]
  A --> F["センサ健全性の確認"]
  B --> G["フレーム間の位置・クラスの一貫性"]
  D1 --> H["多段の受理ゲート"]
  D2 --> H
  D3 --> H
  E --> H
  F --> H
  G --> H
  H -->|"条件を満たす"| I["行動計画へ渡す"]
  H -->|"条件を満たさない"| J["safe-hold"]
  J --> J1["停止または減速"]
  J --> J2["再観測・再計画"]
  J --> J3["人間確認"]

視覚認識の出力を直接アクチュエータへ接続せず、複数の信号を受理ゲートで確認してから行動またはsafe-holdへ分岐させる。

受理ゲートの構成

実装では、認識器の出力をそのままアクチュエータへ接続せず、次のような多段ゲートを置きます。

ロボットの地図を長期運用する：環境変化の検出と再マッピング設計

Fri, 02 Oct 2026 14:21:39 +0900

長期運用では、地図を更新する仕組みよりも、更新してよい変化を見分ける仕組みの設計が難しくなります。

結論

長期運用するロボットの地図は、1枚のデータを観測のたびに書き換えるのではなく、少なくとも次の三つに分けて管理するのが安全です。

承認済みの基準地図
センサから得た一時的な障害物・占有情報
恒久的な変更かどうかを検証中の更新候補地図

走行時は一時的な情報で即座に経路を調整し、恒久地図の更新は別の制御ループで扱います。単発観測による誤更新を避けるため、時間的な持続性、複数回・複数視点からの再観測、動的物体ではないことの確認、検証走行を経て初めて新しい地図版へ昇格させます。旧版は削除せず、不変スナップショットとして保存し、失敗時にロールバックできるようにします。

なぜ地図更新を分けて考えるのか

屋内環境では、家具や棚の移動、通路の変更、物体の一時的な放置などが起こります。これらをすべて同じ「地図の変化」として扱うと、短時間だけ置かれた荷物や通過中の人まで恒久的な障害物として記録するおそれがあります。一方、変化をまったく反映しなければ、古い通路や棚の情報によって走行可能性の判断を誤ります。

したがって、変化検出の目的は観測差分を見つけることだけではありません。恒久的な構造変化、周期的または一時的な障害物、センサノイズや自己遮蔽を区別し、それぞれに異なる反応を割り当てることが目的です。

前提となる地図と座標系

Nav2のCostmap 2Dは、静的地図、センサ由来の障害物情報、障害物の膨張処理などをレイヤーとして組み合わせます。センサ観測による障害物のマーキングとクリアも設定できます。この構造は、走行中の即時反応と、基準地図の恒久更新を分離する土台になります。

一方、Nav2のMap Serverは地図を提供するライフサイクルノードで、地図の読み込みや保存を扱います。地図画像とYAMLメタデータには、解像度、原点、フレームなどの情報が含まれます。これらは地図版を管理する際にも重要な属性です。

座標系については、ROSのREP-105で、mapはグローバルな基準、odomは連続的だが長期的にはドリフトし得る座標系、base_linkはロボット本体の座標系として整理されています。基準地図を差し替えると、同じmapという名前でも幾何学的な内容が変わる可能性があります。そのため、切り替え時刻、座標変換、ロボットごとの適用状態を管理し、ローカライゼーションの初期状態や経路計画が不連続にならないことを検証する必要があります。

推奨する更新データフロー

センサ入力は、まず動的物体の検出・追跡と、基準地図との差分検出に使います。短期的な障害物はライブのコストマップへ反映し、走行の安全性や経路計画に利用します。同時に、差分の位置、観測時刻、視点、再観測結果を履歴として蓄積します。

一定の条件を満たした差分は更新候補または差分パッチになります。候補は再マッピングや観測ログの再生によって検証し、問題がなければ新しい地図版として原子的に昇格させます。旧版はバージョンストアに残します。

flowchart LR
  S["センサ入力"] --> F["動的物体の検出・追跡"]
  S --> D["基準地図との差分検出"]
  F --> C["ライブコストマップ"]
  C --> N["走行安全性・経路計画"]
  D --> H["観測履歴\n時刻・位置・視点・再観測"]
  H --> P["持続性・複数視点・動的物体でないことの判定"]
  P --> Q["更新候補／差分パッチ"]
  Q --> R["再マッピング・観測ログ再生"]
  R --> V["検証走行・指標確認"]
  V --> A["承認"]
  A --> U["新しい地図版へ原子的に昇格"]
  U --> B["承認済みの基準地図"]
  B --> D
  U --> W["旧版を不変スナップショットとして保存"]

走行時はライブコストマップで即時対応し、恒久的な地図変更は候補化、再マッピング、検証、承認を経て別の地図版として昇格させる。

この設計では、ライブコストマップは「今、通れるか」を判断するための層、基準地図は「環境の標準状態」を表す層、候補地図は「標準状態を変更してよいか」を審査する層です。SLAM Toolboxは通常のSLAMに加え、長期的なマッピング、既存地図を用いたローカライゼーション、地図・ポーズグラフの保存と再利用を扱うソフトウェアとして提供されています。ただし、どの変化を恒久地図へ昇格させるかは、利用側のポリシーとして定義する必要があります。

ロボットのタスク実行アーキテクチャ：行動木・状態機械・プランナーの選択基準

Tue, 29 Sep 2026 14:33:23 +0900

ロボットのタスク実行では、分岐を増やすほど設計方式の選択が難しくなる点が気になった。

結論

再利用性と検証性を両立しやすいのは、三つの方式から一つを選ぶ構成ではなく、責務を分ける階層型のハイブリッド構成である。タスクの分解と手順の再生成をプランナー、実行・リトライ・回復を行動木、安全モードとノードのライフサイクルを状態機械に担当させる。

ただし、常にプランナーを導入する必要はない。固定された状態と安全制約が中心なら状態機械、共通スキルの組み合わせと失敗復帰が中心なら行動木、目標・資源・物体状態に応じて手順を動的に変えるならプランナーを優先する。選定では、再利用単位と検証対象を先に定義し、各層の契約を明示することが判断の軸になる。

なぜ方式の分担が必要か

サービスロボットのタスクには、環境に応じた分岐、並行実行、タイムアウト、キャンセル、リトライ、回復、安全モードへの移行が同時に現れる。これらを一つの巨大な状態機械に詰め込むと、タスク種類や例外、再試行条件の増加に伴って状態と遷移の組み合わせが増え、保守と網羅検証の負担が大きくなり得る。

一方、行動木だけで高位のタスク選択まで表現すると、資源や環境の変化に応じた手順の再生成を、多数の分岐として作り込むことになる。プランナーも万能ではない。記号モデルと実世界の状態推定が一致しなければ、生成された計画の妥当性を保てないからである。三方式は競合する実装形式というより、異なる抽象化として比較する方が適切だ。

三つの方式の基本

状態機械は、状態と遷移を明示的に列挙するモデルである。許可された遷移、到達可能性、モードごとの不変条件を検証計画に落とし込みやすい。ドアの開閉、充電、緊急停止、手動介入、ナビゲーションの有効・無効など、相互排他的で有限個の運用モードに向く。Statechartsのように階層、直交並行性、履歴を備えた拡張もある。

行動木は、複合ノードを階層的に組み合わせて実行フローを表す。Sequenceは順番に処理し、Fallbackは代替経路を扱い、Decoratorは条件や実行規則を付加する。ノードはSuccess、Failure、Runningなどの結果を返す。サブツリーやノードプラグインを単位に、ナビゲーション、認識、把持、回復処理などの実行パターンを分割し、再利用できる。

タスクプランナーは、目標に至る手順をモデルから生成する。PDDL系では、ドメインと問題を分離し、アクションの前提条件と効果を記述する。PDDL 2.1では、時間制約、持続アクション、数値フルエントも扱える。目標、利用可能な資源、物体状態、作業順序が変わるタスクで、手順を再生成しやすい。

内部の仕組みと責務分担

ハイブリッド構成では、まずプランナーが「何を、どの順序で達成するか」を決める。次に、計画の各ステップを行動木のアクションやスキルへ対応付ける。行動木は実行中の失敗を検知し、Fallback、リトライ、タイムアウト、キャンセルなどを扱う。必要なら実行結果をもとに、プランナーへ再計画を要求する。

状態機械は、細かな作業手順ではなく、システム全体の運用モードを管理する。安全停止や手動介入中は行動木の実行を許可せず、条件が整った場合だけ再開させる、といった境界を明示できる。ROS 2のmanaged nodeも、Unconfigured、Inactive、Activeなどのライフサイクル状態と遷移を定義し、ノードの設定、起動、停止、クリーンアップを状態機械として管理する。

flowchart TD
  G["目標・物体状態・利用可能な資源"] --> P["タスクプランナー\nドメイン・問題・アクションから手順を生成"]
  P --> T["計画されたタスク手順"]
  T --> B["行動木\n実行・リトライ・Fallback・タイムアウト・キャンセル"]
  B --> N["再利用可能なスキル\nナビゲーション・認識・把持"]
  N --> R["実機上の実行"]
  R --> M["実行結果・状態推定"]
  M --> B
  M -. "計画が不成立または状態が変化" .-> P

  S["安全・運用モードの状態機械\n安全停止・手動介入・充電など"] -->|"実行可否を制御"| B
  S -->|"モード遷移と不変条件"| R
  L["ノードのライフサイクル状態\n設定・起動・停止・クリーンアップ"] --> S

  classDef planner fill:#dbeafe,stroke:#2563eb,color:#111827;
  classDef bt fill:#dcfce7,stroke:#16a34a,color:#111827;
  classDef state fill:#ffedd5,stroke:#ea580c,color:#111827;
  class P,T planner;
  class B,N,R,M bt;
  class S,L state;

タスクプランナーは手順生成、行動木は実行と回復、状態機械は安全・運用モードと実行可否を担当する。実行結果や状態変化は監視され、必要に応じて再計画される。

選択肢の比較

方式	主な抽象化	得意な変化	再利用単位	検証の中心	失敗・回復
状態機械	状態と遷移	固定モード、安全条件	状態、遷移、階層状態	到達可能性、遷移、不変条件	遷移先として明示
行動木	ノードと階層フロー	分岐、順序、回復	サブツリー、ノードプラグイン	ノード契約、フロー、結果	Fallback、リトライ、タイムアウト
プランナー	ドメイン、問題、アクション	目標、資源、環境、手順	ドメイン、アクション、スキル	前提条件、効果、計画妥当性	実行監視と再計画
ハイブリッド	三方式の責務分担	動的性と安全要求の両立	各層の契約単位	層ごとの限定モデル	行動木の回復と再計画

ROS 2での利用場面

ROS 2では、Nav2のBT NavigatorがBehavior Treeでナビゲーションタスクを実行し、XMLで記述されたツリーとBTノードのプラグインを利用する構成を提供している。行動木を実行オーケストレーション層に置く実例として捉えられる。

自然言語からロボット行動へ：3Dグラウンディングと実行制約の設計

Mon, 28 Sep 2026 14:09:11 +0900

自然言語の「右側」や「隣」が、ロボットにとってどの座標と距離を意味するのかが気になるテーマです。

先に結論

ロボットに自然言語を直接モータ指令として渡すのは適切ではありません。「赤い箱を棚の右側へ置く」のような指示は、対象物、参照表現、空間関係、3D目標、座標系、許容誤差、動作前提、禁止条件、完了条件へ分解し、構造化された中間表現に変換するべきです。

VLMやLLMは、指示の意味解釈や操作候補の生成に使います。一方、実行前には物体の再同定、座標変換、到達可能性、衝突、視認性、把持可能性などを別の検証段階で確認します。意味の確信度が高くても、3D測位や軌道計画が成立するとは限りません。不確実性が大きければ、実行せずに確認質問、追加観測、再計画へ切り替える構成が基本になります。

なぜ3Dグラウンディングが必要か

自然言語には、ロボットがそのまま利用できる座標が含まれていません。「右側」は何を基準にした右側か、「隣」はどの距離までか、「それ」はどの物体を指すのかを決める必要があります。さらに、対象を認識できても、把持姿勢やアームの可動範囲、周囲の障害物を考慮しなければ行動には変換できません。

3D-LLMやSpatialVLM系の研究は、3Dシーン理解、視覚グラウンディング、物体間の距離や方向、相対位置の推論を扱います。ただし、3D上の参照対象を得られることは、安全な軌道や実行可能な把持姿勢を得たことと同じではありません。空間推論の評価結果を、そのまま実機操作の成功や安全性として扱うこともできません。

中間表現に含める情報

実装上は、言語理解の結果を一つの曖昧な文字列として保持せず、次の情報を分けて管理します。

対象物の同一性、検出された物体の候補、参照表現
「右側」「隣」などの空間関係と、その基準となる物体・座標系
目標となる3D位置、3D領域、または物体姿勢
許容誤差、把持や配置に必要な動作前提、禁止条件
言語解釈の確信度、対象同定の確信度、3D測位の不確実性
完了条件と、条件を満たさなかった場合の再計画方針

これは業界標準として確立した形式ではありません。実際にはロボット、センサ、タスクに合わせて設計する必要があります。重要なのは、意味解釈、幾何情報、実行可否を分離し、どの段階で不確実性が生じたかを追跡できることです。

変換の仕組み

処理は、おおむね次の段階に分けられます。まずVLMやLLMが、指示から対象物、操作、空間関係、候補となるスキル列を生成します。SayCanは、LLMによる言語的なタスク分解に、現在のロボット状態で各スキルを実行できるかを示すアフォーダンス値を組み合わせる方式です。言語的にもっとも自然な手順ではなく、環境で実行可能な候補を選ぶ点に意味があります。

次に、画像、点群、深度、ロボット状態などから作られた3Dシーンへ、対象と関係を接地します。VoxPoserは、物体や空間関係を3Dボクセル上の価値マップとして表現し、複数の価値マップを合成して操作や経路計画へ利用する枠組みを示しています。3D目標を一点だけでなく領域や価値として持てるため、配置や経路の条件を計画器へ渡しやすくなります。

その後、カメラ座標系などで得た情報をロボット基準の座標系へ変換し、目標位置・姿勢と動作条件を検証します。到達できるか、衝突しないか、対象を視認し続けられるか、把持できるか、速度や力の制約を満たすかを確認してから、モーションプランナーへ渡します。実行中も観測を更新し、状態が想定から外れれば停止、再観測、再計画へ分岐させます。

flowchart LR
  A["自然言語指示"] --> B["対象物・操作・空間関係・スキル候補の生成"]
  B --> C["候補集合の作成と参照表現の解決"]
  C --> D{"対象が一意か"}
  D -- "いいえ" --> Q["確認質問または追加観測"]
  Q --> C
  D -- "はい" --> E["3Dシーンへグラウンディング"]
  E --> F["構造化中間表現の生成"]
  F --> F1["対象・基準物体・座標系・3D目標・許容誤差・禁止条件"]
  F1 --> G["座標変換と状態統合"]
  G --> H["到達可能性・衝突・視認性・把持・速度・力の検証"]
  H --> I{"実行条件を満たすか"}
  I -- "いいえ" --> R["停止・再観測・再計画"]
  R --> E
  I -- "はい" --> J["モーション計画"]
  J --> K["ロボット実行"]
  K --> L["実行中の観測更新"]
  L --> M{"完了条件を満たすか"}
  M -- "はい" --> N["完了"]
  M -- "いいえ" --> R

言語モデルの出力を直接モータ指令に接続せず、3D目標と実行制約を検証してからロボットへ渡す処理の流れ。

参照表現は候補集合として扱う

「赤い箱の隣」「それを持ち上げて」のような表現を、最初から単一の物体へ決め打ちするのは危険です。検出された物体、過去の行動履歴、3Dシーン内の空間関係を使って候補集合を作り、候補が一意になるかを確認します。

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

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や加重平均によって融合できます。これにより、チャンク境界での入力の不連続や急変を抑えられる可能性があります。

ロボットの失敗からの復旧設計：リトライ・再計画・人への引き継ぎを使い分ける

Wed, 23 Sep 2026 13:35:31 +0900

ロボットの失敗時に、単純な再試行が安全とは限らない点に着目しました。

先に結論

ロボットのタスク実行失敗は、すべて同じ動作を繰り返して解決するものではありません。失敗した原因、現在の状態を信頼できるか、再実行で副作用が生じるか、危険度がどの程度かを評価し、対応を分岐させます。

一時的な通信断やタイムアウトで、安全条件と状態が維持されているなら、回数や時間の上限を設けたリトライが候補です。障害物、物体姿勢、把持状態、マップ、位置推定などの前提が変化した、または不確実になった場合は、再観測と状態推定の更新を含む再計画を優先します。衝突、挟まれ、落下、過大な力、センサーやアクチュエータの異常、状態不明、反復失敗では、安全状態へ移行して人に引き継ぎます。

なぜ実行中の復旧設計が必要か

自律ロボットは、計画を一度生成して最後まで実行するだけでは運用できません。実行中には、観測された世界と計画が仮定した状態に差異が生じます。その差異や失敗を監視し、回復または再計画につなげる実行管理が必要です。計画、実行、監視、再計画を循環させる構成は、自律ロボットのdeliberationでも整理されています。

ここで扱うのは、ノードの起動や停止だけではなく、把持や搬送などのタスクが途中で失敗したとき、次に何をするかを決める上位の復旧ポリシーです。

前提となる用語

リトライは、同じタスクまたは局所動作を再実行することです。リカバリ動作は、再試行の前に待機、後退、再配置などの処置を行うことを指します。Nav2の行動木には、主タスクの失敗後にリカバリを実行し、主タスクへ戻るRecoveryNodeや、複数のリカバリ動作を順番に試す構成があります。

再計画は、最新の観測や状態推定を使って、目標までの手順や制約を組み直すことです。人への引き継ぎは、単に通知して停止することではありません。安全状態への移行、診断情報の提示、人の介入確認、再検証、明示的な再開承認までを含む状態遷移として設計します。

内部の仕組み

実装では、タスク実行器と安全監視を分離します。実行器は成功、失敗、フィードバック、観測結果をタスクオーケストレータへ返します。オーケストレータは失敗分類と状態信頼性を評価し、リトライ、再計画、停止を選択します。状態推定器は対象物や環境の最新状態を更新し、計画器はその結果を制約として使います。安全監視は、タスク側の再試行判断とは別に、危険時の停止要求を担います。

ROS 2のActionは、長時間実行される目標について、目標、フィードバック、結果、キャンセルを扱う通信方式です。実行監視や停止要求の受け渡しに利用できます。一方、ROS 2 Managed Nodeのライフサイクルは、未構成、非アクティブ、アクティブ、終了済みなどの状態と、設定、起動、停止、クリーンアップ、エラー処理の遷移を明示します。これらは、停止後の再初期化や再アクティベーションを、暗黙の再開と区別する基盤になります。

行動木では、BehaviorTree.CPPのRetryやRetryUntilSuccessfulのようなデコレータで、子ノードの失敗時の再実行や回数制御を表現できます。ただし、Retryノードは再実行機構であって、安全に再実行できる条件を自動的に定義するものではありません。

flowchart TD
  A["タスク実行中"] --> B["失敗を検出"]
  B --> C{"危険な兆候または安全機能の作動があるか"}
  C -->|"はい"| H["安全状態へ移行"]
  C -->|"いいえ"| D["現在の状態と安全条件を確認"]
  D --> E{"状態を信頼できるか"}
  E -->|"いいえ"| H
  E -->|"はい"| F{"原因は一時的で再実行は安全か"}
  F -->|"はい"| G["上限付きリトライ"]
  G --> I{"回数・時間・試行予算内か"}
  I -->|"はい"| J["状態を再確認して再実行"]
  J --> A
  I -->|"いいえ"| H
  F -->|"いいえ、前提が変化または不確実"| K["再観測と状態推定の更新"]
  K --> L["制約を反映して再計画"]
  L --> M{"更新後の計画は安全条件を満たすか"}
  M -->|"はい"| N["計画を検証して再開"]
  N --> A
  M -->|"いいえ"| H
  H --> O["失敗情報・観測・試行履歴を提示"]
  O --> P["人への引き継ぎ"]
  P --> Q["介入完了後にロボット・環境・対象物を再検証"]
  Q --> R{"明示的な再開承認と再検証に成功したか"}
  R -->|"はい"| S["検証済みチェックポイントから再開"]
  R -->|"いいえ"| T["タスクを中止"]

失敗原因、状態の信頼性、安全条件、試行予算に基づいて、リトライ・再計画・人への引き継ぎを選択する復旧フロー。

3つの復旧手段の比較

手段	適用条件	必要な確認	主な停止条件	再開条件
リトライ	原因が一時的で、状態と安全条件を確認できる	対象物、ロボット、周囲の状態	回数・時間・総試行予算の超過、副作用の兆候	状態を再確認し、同じ処理が安全に実行可能
再計画	前提条件が変化、または状態が不確実	再観測、状態推定、制約の更新	新しい計画でも安全条件を満たせない	更新後の計画と環境状態を検証
人への引き継ぎ	危険、状態不明、ハードウェア異常、反復失敗	失敗コード、観測データ、試行履歴	人の介入がない、再検証に失敗	介入完了、ロボット・環境・対象物の再検証、明示承認

リトライを設計する条件

リトライは、失敗原因が一時的である場合に限定します。通信タイムアウトのように、対象物やロボットの状態が変わっておらず、安全に再確認できるなら候補になります。ただし、回数、待機時間、バックオフ、総試行予算をあらかじめ設けます。Nav2のRecoveryNodeにも再試行回数を設定する構成がありますが、適切な回数や安全条件はタスクごとに決める必要があります。

ロボットの3D空間表現を選ぶ：ボクセル・TSDF・点群・ニューラル表現の比較

Tue, 22 Sep 2026 13:42:06 +0900

3Dセンサーの入力形式が同じでも、地図と計画が必要とする情報は大きく異なります。

先に結論

ロボットの3D空間表現は、方式の優劣ではなく、下流処理が何を問い合わせるかで選びます。未知・自由・占有を区別する地図や保守的な障害物判定には占有ボクセルが基本候補です。疎な環境や可変解像度を重視する大域地図では、占有確率をオクトツリーで管理するOctoMapを検討します。

表面の融合やメッシュ生成にはTSDF、障害物までの距離や勾配を局所計画で使うならESDF、センサ直結の登録・セグメンテーション・局所認識には点群が適します。ニューラル表現は、視点合成や連続的な形状クエリなど、手法固有の機能が必要な場合の候補です。ただし、安全性が重要なオンライン衝突回避では、占有表現または保守的な距離場との併用と検証が必要です。

なぜ選択が難しいのか

同じ深度カメラやLiDARの入力でも、地図、認識、計画が必要とする情報は異なります。「このセルは占有か」「表面までの距離はいくらか」「観測点の属性は何か」「任意の座標で形状を問い合わせられるか」は別のクエリです。したがって、表現を選ぶ際は、必要なクエリ、未知領域の規則、解像度、更新頻度、メモリ、計画への接続方法を先に決めます。

なお、各方式を同一センサ、同一解像度、同一ハードウェアで横断比較した一次ベンチマークは確認できません。常に最速、最小メモリといった一般化は避けるべきです。

前提となる用語

ボクセルは3D空間をセルに分ける離散化単位です。セルには占有状態、占有確率、距離などを格納できます。占有グリッドは、セルをoccupied、free、unknown、または占有確率で管理する表現です。センサ光線に沿った自由空間の更新や、未知を残した衝突判定に向きます。

OctoMapは、占有確率をオクトツリーで管理する具体的な方式です。均質な領域を上位ノードにまとめるため、固定解像度の密な3D配列に比べ、疎な環境や可変解像度に対応しやすい構成です。ボクセルという一般的な単位と、OctoMapという管理方式は同じ抽象レベルではありません。

TSDFは、各ボクセルに最寄りの表面までの符号付き距離を格納し、一定の帯域で切り詰める表面中心の表現です。深度観測を重み付きで融合できます。ESDFは障害物または表面までのユークリッド距離を空間中に持つ距離場で、クリアランス評価、距離制約、距離勾配を使う軌道最適化に適します。

仕組みと使いどころ

占有ボクセルは、観測をセル単位の状態へ変換します。未知空間を自由空間と区別できるため、探索、ナビゲーション、障害物回避に使いやすい表現です。ただし、未知セルを占有扱いにするなどの判定規則を実装して初めて、保守的な衝突判定を構成できます。解像度を粗くすると細い障害物や狭い通路を識別しにくくなり、細かくするとメモリや更新量とのトレードオフが生じます。

TSDFは「未知かどうか」より「観測された表面がどこにあるか」を扱います。深度センサからの密な表面再構成、メッシュ生成、カメラトラッキングに向く一方、占有確率や未知空間を直接表しません。TSDFだけを安全側の占有地図として使うには、表面抽出や追加の判定規則が必要です。

ESDFは計画器が必要とする距離情報を直接提供します。VoxbloxはTSDFを増分更新し、そこからESDFを構築して計画に利用する構成を示しています。つまり、TSDFとESDFは競合する選択肢ではなく、観測融合と計画で連結できます。符号規約、障害物の定義、未知領域の扱いは実装ごとに確認してください。

点群は点の座標に加え、法線、色、強度などの属性を保持できます。登録、特徴抽出、認識、セグメンテーションなどに直接使いやすい反面、未観測空間が自由か未知か、空間全体の占有確率は点群単体から直接は分かりません。長距離計画や保守的な衝突判定では、占有グリッドや距離場への変換が必要になることが多くなります。

NeRFは位置と視線方向から放射輝度や体積密度を返す連続関数を最適化し、主用途は新規視点画像の合成です。原型のNeRFを、そのまま衝突判定用の幾何表現とはみなせません。一方、ニューラルSDF系はニューラルネットワークで連続的な符号付き距離関数を表し、ロボット向けのオンライン3D再構成や知覚に利用できます。

flowchart LR
  subgraph O["占有表現"]
    O1["セル"] --> O2["occupied / free / unknown"]
    O2 --> O3["占有確率や保守的な判定"]
  end
  subgraph T["TSDF"]
    T1["ボクセル"] --> T2["表面までの符号付き距離"]
    T2 --> T3["切り詰め・重み付き融合"]
    T3 --> T4["表面再構成・メッシュ生成"]
  end
  subgraph E["ESDF"]
    E1["空間上の位置"] --> E2["障害物または表面までの距離"]
    E2 --> E3["距離勾配・クリアランス"]
    E3 --> E4["距離制約・軌道最適化"]
  end
  O -.-> N["未知領域の扱いは安全判定で確認"]
  T -.-> N
  E -.-> N2["符号規約と未知領域の定義は実装ごとに確認"]

占有表現、TSDF、ESDFは保持する情報と得意な問い合わせが異なります。ESDFの符号規約や未知領域の扱いは実装ごとに確認が必要です。

比較表

表現	保持する情報	向く問い合わせ・用途	主な制約
占有ボクセル	occupied/free/unknown、占有確率	探索、大域地図、障害物判定	解像度とメモリ・更新量のトレードオフ
OctoMap	オクトツリー上の占有確率	疎な環境、可変解像度、大域ナビゲーション	細い障害物は解像度に依存
TSDF	表面までの切り詰め符号付き距離	深度融合、表面再構成、メッシュ生成	未知空間や占有確率を直接表さない
ESDF	障害物・表面までの距離	クリアランス、距離制約、軌道最適化	符号規約と未知領域の確認が必要
点群	点の座標と付随属性	登録、認識、セグメンテーション	空間全体の占有を直接表さない
ニューラル表現	放射輝度・密度、または連続SDF	視点合成、連続形状クエリ	近似誤差、更新コスト、未知領域の検証

実装での構成

一つの表現ですべてを賄う必要はありません。深度カメラやLiDARから点群を生成し、点群を占有ボクセルまたはTSDFへ融合します。計画時にはTSDFからESDFを構築し、距離制約や勾配を局所計画へ渡します。認識系では元の点群を登録やセグメンテーションに使い、必要に応じてニューラル特徴やニューラルSDFを並行利用できます。

ロボットの能動視覚設計：認識精度と行動コストから次の視点を選ぶ方法

Mon, 21 Sep 2026 13:40:55 +0900

能動視覚では、見ること自体がロボットの行動になります。次の視点を情報価値で選ぶ考え方を整理します。

結論：最も多く見える場所ではなく、次の判断に効く場所を選ぶ

ロボットの能動視覚で次の視点を選ぶときは、可視面積や未知領域を単純に最大化するのではなく、その観測によって下流タスクの期待損失がどれだけ減るか、または成功確率がどれだけ高まるかを評価します。移動時間、エネルギー、衝突リスク、到達可能性も同時に考慮する必要があります。

実装では、候補視点ごとの期待タスク効用から行動コストを差し引き、観測後に信念状態や地図を更新して再計画する構成が現実的です。能動視覚の本質は、カメラを動かすことではなく、次の認識・推定・制御に必要な情報を取りに行くことにあります。

なぜ視点選択が重要なのか

固定カメラによる受動的な認識では、ロボットは与えられた画像から判断します。能動視覚では、視点やセンサの動作をタスクと結び付け、遮蔽された面を別角度から観測したり、対象姿勢を推定しやすい位置へ移動したりします。知覚は入力処理だけでなく、観測行動を含むループになります。

ただし、視点変更には必ずコストがあります。遠い候補へ移動すれば時間やエネルギーを消費し、経路によっては衝突の危険があります。到達できない視点や、移動しても有効な観測を得られない視点も候補に含まれ得ます。したがって、視覚精度だけではなく、行動を含むシステム全体で選ぶ必要があります。

前提となる用語

信念状態とは、現在までの観測履歴から推定した対象姿勢、地図、自己位置、分類結果などの不確実な状態です。部分観測環境では真の状態を直接知れないため、観測のたびに信念状態を更新します。

**Next-Best-View（NBV）**は、複数の候補視点から、次に観測する場所を選ぶ計画問題です。情報価値には、エントロピー減少、相互情報量、未知ボクセル数、推定共分散の減少などを使えます。ただし、最適な指標は認識、位置推定、再構成、把持などの下流タスクによって変わります。

視点を選ぶ仕組み

まず、現在の信念状態とタスク目標から候補視点を生成します。各候補について、見える領域や観測結果を予測し、期待される情報利得またはタスク効用を評価します。そのうえで、移動距離・時間・エネルギー、撮像時間、安全性、到達可能性を加味します。

実務上の考え方は、次のように表せます。

score(a) = E[ΔJ | a] - λC(a)

a は候補視点またはそこへ移動する行動、E[ΔJ | a] は観測による期待タスク効用の増分、C(a) は行動コスト、λ はコストの重みです。J は認識損失、位置推定誤差、再構成品質、把持判断など、対象タスクに合わせて定義します。

衝突回避や到達可能性は、重み付きペナルティではなくハード制約として候補から除外する設計もあります。危険な動作を許容できない場合は制約にし、それ以外の時間や距離はスコアのコストとして扱う、という分け方が判断しやすいでしょう。

flowchart LR
  B["現在の信念状態\n対象姿勢・地図・自己位置・分類結果"] --> G["候補視点を生成"]
  T["タスク目標"] --> G
  G --> P["観測予測\n可視領域・観測品質・期待結果"]
  P --> U["期待タスク効用を評価"]
  P --> C["行動コストを評価\n移動時間・距離・エネルギー・安全性"]
  C --> F["到達可能性・衝突を確認"]
  U --> S["スコア計算または制約判定"]
  F --> S
  S --> V["次に実行する視点を選択"]
  V --> A["ロボットが移動・撮像"]
  A --> O["画像・深度情報を取得"]
  O --> R["信念状態と地図を更新"]
  R --> G

能動視覚では、視点を一度決めて固定するのではなく、観測後の信念状態と地図の更新を受けて次の視点を再計算します。

観測後は画像や深度情報から信念状態と地図を更新し、次の候補視点を再計算します。遮蔽、自己位置、対象姿勢、未知領域の推定は観測によって変わるため、最初の計画を最後まで固定するより、閉ループで再計画する方が未知環境や予測誤差を扱いやすくなります。

不確実性を扱うロボット把持計画：成功確率に応じて実行と再観測を切り替える

Sun, 23 Aug 2026 01:51:41 +0900

把持の「自信あり」という数値が、実際の成功確率と同じ意味を持つのかが気になるテーマです。

はじめに

ロボットが物体を正しく認識できたように見えても、その把持が成功するとは限りません。姿勢推定の誤差、隠れた形状、摩擦や接触状態のばらつき、照明や視点の変化が、実行結果を左右します。ここで必要なのは、認識モデルのスコアを単純なしきい値で分類することではなく、「いま動く価値があるか」「追加観測で判断が改善するか」「安全のために中止すべきか」を分けて決める層です。

先に結論

把持計画では、生の把持スコアを成功確率として扱わず、対象・センサー・把持条件に合わせて校正した確率と、別々に評価した不確実性・安全信号を使います。実行、再観測、中止の切り替えは、成功確率だけでなく、成功時の価値、失敗や破損の損失、追加観測の時間・移動リスク、ロボットや周辺設備への安全リスクを含む期待効用、または明示的なリスク制約で設計します。

さらに、実行後も視覚などの観測で把持状態を検証し、必要なら再計画します。固定しきい値は実装の出発点にはなりますが、対象の価値やサイクルタイム、安全条件が異なる環境にそのまま移植できる普遍的なしきい値は確認されていません。

なぜ単一の信頼度では足りないのか

把持モデルの出力は、訓練データ、センサー、把持品質の定義、対象分布に依存するモデル出力です。たとえば解析的な把持品質指標から学習した予測値と、行動選択や方策価値を直接学習した出力では、数値が似ていても意味は同じではありません。高いスコアを「実際の成功確率」と解釈するには、別途検証が必要です。

また、不確実性には少なくとも二つの側面があります。観測ノイズや接触ばらつきのように、データ自体に固有の aleatoric uncertainty と、データ不足やモデルの知識不足に由来する epistemic uncertainty です。前者は同じ条件でも結果が揺れる要因、後者は未知の対象や条件に出会ったときに予測が不安定になる要因と考えられます。対応策が異なるため、合計値だけでなく内訳を保持する設計が有用です。

belief として状態を保持する

部分的にしか観測できない物体姿勢、形状、接触状態、摩擦などを、単一の推定値だけで表すと、計画は誤った前提に固定されます。そこで、状態についての信念、すなわち belief として候補や確率分布を保持し、行動と観測によって更新します。把持計画と観測計画を同じ枠組みで扱えば、把持を急ぐべきか、別の視点から見直すべきかを比較できます。

ただし、完全な belief-space 計画は計算量やモデル化の負担が大きくなります。実機では、候補生成、校正、実行ゲート、監視、検証、再計画、中止を状態機械として分離し、必要な範囲で近似する構成が扱いやすいでしょう。

確率校正と分布ずれの確認

意思決定に確率を使うなら、検証用データで校正します。予測確率をいくつかの信頼度ビンに分け、各ビンの平均予測値と実際の成功率を比較する reliability diagram を確認します。ECE や Brier score も、確率の整合性を評価する指標になります。分類精度が高くても、予測確率が実際の成功率と一致するとは限らないためです。

校正データは、学習時と同じ分布だけでなく、実行時に想定される対象、照明、視点、センサー、把持条件を含めて評価します。分布外やデータシフト下では不確実性の品質が変化し、アンサンブル、ベイズ近似、校正手法のいずれかが常に優れるとは限りません。校正済みの値であっても、安全リスクを十分に表すとは限らない点にも注意が必要です。

flowchart TD
  A["観測・状態推定"] --> B["把持候補を生成"]
  B --> C["成功確率を校正し、不確実性を分離"]
  C --> D["期待効用と安全制約を評価"]
  D --> E{"安全制約を満たすか"}
  E -- "いいえ" --> X["中止・退避"]
  E -- "はい" --> F{"追加観測で判断が改善する見込みがあるか"}
  F -- "はい" --> G["再観測"]
  G --> A
  F -- "いいえ" --> H{"実行の期待効用が許容範囲か"}
  H -- "いいえ" --> X
  H -- "はい" --> I["把持を実行"]
  I --> J["実行中の観測と状態監視"]
  J --> K["把持状態を検証"]
  K --> L{"検証に成功したか"}
  L -- "はい" --> M["完了"]
  L -- "いいえ" --> N{"別候補や別経路に価値があるか"}
  N -- "はい" --> O["再計画"]
  O --> A
  N -- "いいえ" --> X

把持候補の評価から再観測、実行、実行後の検証、再計画、中止・退避までを状態機械として示す。成功予測と安全制約は別々の判断信号として扱う。

実行・再観測・中止の判断

候補ごとに、校正済み成功確率、二種類の不確実性、把持余裕、接触や衝突に関する安全信号をまとめます。そのうえで、候補を実行したときの成功時の価値から、失敗・破損・落下・設備損傷などの損失を差し引きます。再観測については、観測によって候補順位や安全判定が変わる見込みと、観測時間、移動リスク、処理コストを比較します。これは「信頼度が低ければ必ず見る」という規則ではありません。

ロボット失敗ログの活用設計：再学習と回帰テストへつなぐデータループ

Sat, 15 Aug 2026 09:17:15 +0900

失敗ログを保存するだけで、次のモデルやテストへ自然に生かせるのかが気になるテーマです。

先に結論

ロボットの失敗ログを活用する中核は、件数を増やすことではなく、どの条件で何が起きたかを追跡できる形にし、同じ失敗を再学習用データと回帰テストへ分岐させることです。改変しない生ログを起点に、エピソード、失敗イベント、失敗パターン、データセット、テストケースをIDで結びます。

候補モデルの評価では、固定ホールドアウトや失敗リプレイ、シミュレーション、必要に応じた実機試験をゲートの例として用います。ただし、どこまで試験すればよいか、自動昇格を許すかは、対象タスクと安全要求に応じて決める必要があります。

なぜデータループが必要か

多くの実機システムでは、失敗時にセンサ入力、ロボット状態、制御指令、環境条件、方策やソフトウェアの版が関係します。必要な信号や版情報を欠くと、原因の切り分けや再現が難しくなり得ます。また、同じシーンのログを大量に追加しても、未見条件を評価できるとは限りません。

そのため、失敗ログは単なるデバッグ記録ではなく、検出、確認、パターン化、選別、評価へ渡す入力として設計します。失敗事例を再学習に使う場合も、効果は失敗ラベル、負例の扱い、学習目的によって変わるため、改善を保証するものとして扱ってはいけません。

前提となるデータ層

ROS 2のrosbag2は、トピックデータの記録と再生を行う仕組みです。センサ、状態、指令を時系列で保存し、後から再生する基盤に利用できます。MCAPはスキーマ、チャネル、メッセージ、メタデータ、添付データなどを持つ時系列データ形式です。

一方、RLDSはエピソードとステップの階層でデータを表し、観測、行動、報酬、終了状態などを扱います。rosbag2やMCAPが主に保存・再生を担うのに対し、RLDSは学習・評価向けの論理表現です。両者を同一スキーマとみなさず、正規化処理で変換します。

層	役割	主な情報
生ログ	原記録の保存・再生	rosbag2またはMCAP、時刻、スキーマ
エピソード	学習・評価単位への正規化	episode_id、観測、行動、終了状態
失敗イベント	失敗区間の記録	event_id、時間窓、検出器、重大度、確認者
失敗パターン	類似失敗の集約	pattern_id、再現条件、代表例
データ・テスト	改善サイクルへの反映	dataset version、テストケース、結果

episode_id、event_id、pattern_id、policy_version、software_version、hardware_idで各層を相互参照し、データと処理の版を管理します。DVCのように、データをGitのコードやメタデータと対応付ける仕組みも利用できます。データセットの動機、構成、収集方法、前処理、用途、制約は、Datasheets for Datasetsの考え方に沿って記録すると判断を追跡しやすくなります。

失敗をパターンへ変換する流れ

最初に、停止理由、安全イベント、タイムアウト、タスク判定など、確認可能なルールで失敗候補を抽出します。失敗した瞬間だけでなく、成功・失敗境界の前後を含む時間窓を切り出し、センサ、行動、環境条件、モデルとソフトウェアの版を付与します。次に、人手で失敗の有無と種類を確認します。

確認済みの事例は、特徴量や埋め込みで類似例を集約し、共通する再現条件を調べます。学習中の正解率、信頼度、予測の変動を使い、典型的・曖昧・困難なデータ例を分析するDataset Cartographyの考え方も診断材料になります。ただし、これはロボットの物理的な重大度や安全リスクを直接測るものではありません。

flowchart LR
  A["生ログを変更せずに収集\nrosbag2 / MCAP"] --> B["エピソードへ正規化\n時刻・モデル・ソフトウェア・ハードウェアの版を付与"]
  B --> C["ルールベースで失敗候補を抽出"]
  C --> D["時間窓・環境条件・センサ・行動を付与"]
  D --> E["人手で失敗の有無と種類を確認"]
  E --> F["類似事例をクラスタリング\n失敗パターンへ集約"]
  F --> G["重大度・未見性・不確実性・代表性・テスト状況で優先順位付け"]
  G --> H["版管理された学習データセット"]
  G --> I["回帰テストケース\n元ログ・再現条件・期待動作・閾値"]
  H --> J["候補モデルを学習"]
  J --> K["固定ホールドアウトと失敗リプレイで評価"]
  I --> K
  K --> L["シミュレーションまたは実機の安全評価"]
  L --> M["段階導入"]
  M --> N["導入後の監視"]
  N --> A
  E -. "未確認・追加確認" .-> D

失敗ログをパターンへ集約し、再学習と回帰テストに分岐させて、導入後の新しいログを再び収集する閉ループを示します。

失敗パターンには、元ログへの参照、再現条件、期待する動作、許容閾値、乱数seedまたは環境固定条件を持たせます。「未確認」「確認済み」「再学習投入」「テスト化」「解消」「再発」といった状態を管理すれば、改善サイクルのどこにあるかを追跡できます。

ロボット視覚サーボ入門：画像ベース制御と位置ベース制御の選択

Fri, 24 Jul 2026 01:33:52 +0900

画像上の誤差と実空間の誤差は、同じ「ずれ」でも制御設計上の意味が異なります。

結論

視覚サーボの方式は、何を誤差として制御したいか、そして対象モデル・校正・深度情報をどの程度信頼できるかで選ぶ。画像上の特徴を目標へ合わせることが主目的で、対象の3Dモデルや絶対姿勢を十分に利用できない場合は、画像ベース視覚サーボ（IBVS）が候補になり得る。一方、対象との相対的な並進位置や回転姿勢を推定し、Cartesian空間の軌道や姿勢制約を設計したい場合は、位置ベース視覚サーボ（PBVS）が候補になる。

ただし、これは一般的な性能順位ではない。深度推定、視野、初期条件、対象モデル、カメラ校正、遅延などによって結果は変わる。画像上の視認性と実空間の軌道精度を両立したい場合は、2.5D視覚サーボや、IBVSとPBVSを段階的・協調的に使うハイブリッド構成も検討対象になる。

なぜ選択が重要か

視覚サーボは、カメラから得た画像特徴、または画像から推定した対象物の姿勢をフィードバックし、ロボットの運動を閉ループ制御する枠組みである。画像を認識に使うだけでなく、制御誤差の定義そのものに組み込む点が特徴だ。

同じ「対象をつかむ」タスクでも、画像中の特徴を所定位置へ移動させたいのか、対象の位置・姿勢を推定してエンドエフェクタを特定の状態へ運びたいのかで、設計は異なる。まず制御したい量を分ける必要がある。

IBVSとPBVS

IBVSは、画像特徴量と目標画像特徴量の差を制御する方式である。画像上の点や輪郭などを特徴量として扱い、対象の完全な3D姿勢を明示的に復元せずに、画像上の誤差を直接小さくする。

ただし、画像特徴の変化とカメラ運動の関係を表す相互作用行列には、対象までの深度、またはその近似値が必要になることが多い。したがってIBVSは、3D情報が一切不要な方式ではない。また、アイ・イン・ハンド構成では、画像特徴の変化をロボットの関節速度やエンドエフェクタ速度へ変換するため、カメラとロボット間の幾何関係が通常必要になる。完全な校正を避ける構成では、オンライン推定や適応的手法が必要になる場合があり、別途検討しなければならない。

PBVSは、画像から対象物の3D姿勢を推定し、現在の状態と目標状態との差をCartesian空間で制御する方式である。並進位置は長さの単位で扱い、姿勢は回転行列、クォータニオン、軸角などで表現する。対象の幾何モデルまたは既知の3D情報、カメラの内部パラメータ、カメラとロボットの外部関係が重要になる。

内部の仕組み

IBVSでは、現在の画像特徴を s、目標特徴を s* とすると、制御器は概念的に s - s* の誤差を使ってカメラまたはロボットの速度を決める。相互作用行列を介して画像特徴の変化と運動を結び付け、得られた運動をエンドエフェクタ速度や関節速度へ変換する。

PBVSでは、画像特徴から対象の3D位置・姿勢を推定し、その誤差をCartesian制御器へ入力する。空間上の位置や回転姿勢を直接目標として扱える一方、推定値の誤差がそのまま制御へ影響する。対象モデル、カメラパラメータ、ハンドアイ変換の品質が前提になる。

flowchart LR
  subgraph IBVS["画像ベース視覚サーボ（IBVS）"]
    I1["カメラ画像"] --> I2["画像特徴の抽出"]
    I2 --> I3["画像特徴の誤差 s - s*"]
    I3 --> I4["制御器・相互作用行列"]
    I4 --> I5["カメラまたはロボットの運動"]
    I5 --> I6["対象との相対運動"]
    I6 --> I1
    D1["深度または深度近似"] --> I4
    G1["カメラとロボットの幾何関係"] --> I4
  end

  subgraph PBVS["位置ベース視覚サーボ（PBVS）"]
    P1["カメラ画像"] --> P2["対象の3D位置・姿勢推定"]
    P2 --> P3["3D位置・姿勢の誤差"]
    P3 --> P4["Cartesian制御器"]
    P4 --> P5["エンドエフェクタまたはロボットの運動"]
    P5 --> P6["対象との相対運動"]
    P6 --> P1
    M1["対象モデル・既知の3D情報"] --> P2
    C1["カメラ内部パラメータ"] --> P2
    H1["ハンドアイ変換"] --> P4
  end

IBVSは画像特徴の誤差、PBVSは推定した3D位置・姿勢の誤差をフィードバックする。どちらも画像からロボット運動への変換に必要な幾何情報や推定情報がある。

方式の比較

観点	IBVS	PBVS
制御誤差	画像特徴の誤差	3D位置・姿勢の誤差
主な入力	画像特徴、深度または深度近似	3D情報、姿勢推定、カメラパラメータ
3Dモデルへの依存	完全なモデルに依存しにくい	対象モデルや既知の3D情報が重要
軌道の表現	画像上の経路	Cartesian空間の経路・姿勢
主な課題	深度誤差、特異性、局所解、視野外逸脱	校正・モデル・姿勢推定誤差、視野内維持
条件付きで候補になる場面	画像上の整列、接近、モデルが不完全なピック	既知対象への挿入、精密組立、姿勢制約の強い動作

タスク別の使いどころ

画像上の位置合わせや把持対象への接近では、対象の正確な3Dモデルがなくても画像特徴を目標へ近付けられるため、IBVSが候補になり得る。ただし、深度が不安定、特徴が遮蔽される、初期誤差が大きいといった条件では、その利点が小さくなる可能性がある。ピックアンドプレースでも、制御目標が「画像上で所定の位置へ合わせること」なのか、把持後の空間姿勢まで厳密に保証することなのかを分けて評価する必要がある。

Physical AIの評価設計：タスク成功率だけでなく安全性と再現性を測る方法

Sat, 04 Jul 2026 01:25:33 +0900

成功率の高さだけで、ロボットAIの実用性を判断してよいのかという疑問から、評価軸を整理しました。

はじめに

Physical AI、特にロボットAIは、画像認識や単回のタスク成功率だけでは実運用への適性を判断できません。安全に動作したか、同じ条件で安定して再現できるか、環境やロボット個体が変わっても性能を保てるかを分けて測る必要があります。

先に結論

評価は「タスク有効性」「安全性」「再現性」の三軸で設計します。成功率は、事前に固定した主成功条件を満たした試行の割合として算出し、部分達成、所要時間、手動介入、リカバリ回数は別指標で報告します。

安全性は、接触、衝突、保護停止、非常停止、安全制約違反、人間の介入、ニアミスをイベントとして記録し、重大度と試行回数または稼働時間で正規化します。再現性は、同一条件での反復性と、乱数種、環境、操作者、ハードウェアなどを変えた再現性に分けます。総合スコアを使う場合も、重み、最低限の安全条件、失敗時の扱いと下位指標を公開します。

なぜ成功率だけでは足りないのか

RLBenchやLIBEROのようなベンチマークは、タスク集合やタスク変動を定義し、タスク成功を主要指標にしています。手法比較には有用ですが、成功条件、試行回数、タスクごとの重み、評価環境、介入の扱いが違えば、異なるベンチマークの数値は単純比較できません。

成功していても、毎回人間の介入が必要、所要時間が長い、危険な接触を伴う、といった問題は残ります。NIST AI RMF 1.0も、妥当性・信頼性、安全性、セキュリティ・レジリエンス、説明可能性・透明性などを区別しています。ロボット評価でも、異なる性質を一つの数値に押し込めない設計が適しています。

用語と成功条件を固定する

タスクごとに、開始状態、対象物、許容操作、主成功条件、失敗条件、最大実行時間を事前に定義します。例えば対象物を指定位置へ移動し、規定姿勢で停止することを主成功条件にするなら、途中まで移動できた試行は部分達成として別に扱います。

成功率 = 主成功条件を満たした試行数 ÷ 予定した全試行数

無効試行を分母から除く場合は、判定基準と理由を記録します。部分達成率、実行時間、介入回数、リカバリ回数、失敗分類も併記し、成功率へ混ぜないことが重要です。

三つの評価軸

タスク有効性

全体の成功率だけでなく、タスク別の成功率、部分達成、所要時間、介入回数、リカバリ回数を記録します。タスクごとの試行数や難易度が異なる場合、平均方法が結果を左右するため、タスク別内訳を公開します。

安全性

安全イベントは成功・失敗とは別のログにします。接触力を測れる構成では接触力も記録し、衝突、予期しない接触、保護停止、非常停止、安全制約違反、介入、ニアミスを分類します。イベントごとに重大度、発生試行、稼働時間、原因、復旧の有無を付与します。

ISO/TS 15066:2016は、協働ロボットシステムと協働運転の安全要求・指針を扱い、パワー・フォース・リミッティングも対象にしています。ただし、これだけで自律移動ロボット、屋外、家庭環境、タスク固有のリスクをすべて評価できるわけではありません。

反復性と再現性

同じモデル、ロボット、環境、手順で複数回試す評価は、同一条件での反復性を見ます。乱数種、学習チェックポイント、初期姿勢、物体配置、照明・背景、操作者、ロボット個体、ソフトウェアやモデルのバージョンを変える試験は、条件変更への再現性を見ます。

ISO 5725-1およびISO 5725-2は、同一条件での反復性と、操作者・装置・場所・時間などを変えた再現性を区別しています。一方、ISO 9283:1998は、産業用マニピュレータの位置姿勢や軌道の精度・反復性、安定時間、オーバーシュートなどを扱います。機構性能の反復性と、学習ポリシーの実験再現性は別の概念です。

flowchart LR
  A["評価対象とタスクを定義"] --> B["開始状態・主成功条件・失敗条件・最大実行時間を事前登録"]
  B --> C["固定条件で複数試行"]
  C --> D["主成功条件を満たしたか判定"]
  D -->|"達成"| E["成功として集計"]
  D -->|"一部達成"| F["部分達成として別集計"]
  D -->|"未達"| G["失敗分類と停止理由を記録"]
  C --> H["安全イベントを独立ログに記録"]
  H --> H1["接触・衝突・保護停止・非常停止・制約違反・介入・ニアミス"]
  H1 --> H2["重大度・発生試行・稼働時間・原因・復旧の有無を付与"]
  C --> I["所要時間・介入回数・リカバリ回数を記録"]
  E --> J["同一条件で反復性を評価"]
  F --> J
  G --> J
  J --> K["乱数種・初期姿勢・物体配置・照明・操作者・個体・バージョンを段階的に変更"]
  K --> L["条件変更後の再現性を評価"]
  J --> M["平均・ばらつきまたは信頼区間を報告"]
  L --> M
  H2 --> M
  I --> M
  M --> N["タスク有効性・安全性・再現性を独立指標として判断"]

タスクの結果、安全イベント、試験条件の変化を別々に記録し、タスク有効性・安全性・再現性の三軸で報告する評価フロー。

評価項目の比較

評価軸	主な指標	条件・ログ	注意点
タスク有効性	成功率、部分達成率、時間、介入、リカバリ	タスク定義、試行数、終了条件	成功率に別指標を混ぜない
安全性	接触・衝突、停止、制約違反、ニアミス	重大度、試行数、稼働時間、原因	成功率と独立集計する
反復性	同一条件での性能のばらつき	同一モデル、個体、環境、手順	機構とポリシーを区別する
再現性	条件変更後の性能維持	乱数種、環境、操作者、個体、版	変更条件を明示する
実機移行	シミュレーションとの差	接触、ノイズ、誤差、物体差	実機結果を別報告する

実機評価プロトコル

最初に、タスク、主成功条件、失敗分類、安全イベント、無効試行の条件を事前登録します。モデル、コード、センサ、ハードウェア、ロボット、環境のバージョンを記録し、同一条件で複数試行します。結果には試行数、成功率、タスク別内訳、所要時間、失敗分類、介入数、停止理由、平均・分散または信頼区間を含めます。

ロボットの世界モデルを制御に使うには：状態推定・予測・行動生成の役割分担

Wed, 24 Jun 2026 01:21:16 +0900

世界モデルを制御へ接続するとき、予測モデルと制御器を同じものとして扱ってよいのかが気になるテーマです。

先に結論

ロボットの世界モデルは、状態推定器や低レベル制御器を全面的に置き換えるものではなく、将来の状態・観測・報酬を予測して候補行動を比較する層として導入するのが現時点では妥当です。実装では、状態推定器が現在の状態または信念状態を高頻度に更新し、世界モデルがタスクレベルの将来を予測し、MPCや従来の制御器が制約付きの短時間実行を担当する階層構成が基本になります。

世界モデルをMPCの予測モデルとして使う場合も、実センサーから得た推定状態で繰り返し再計画します。予測不確実性が高いときは、計画ホライズンを短くする、制約を保守的に設定する、下位の従来制御器へ切り替える、といった設計が必要です。

なぜ役割分担が必要か

ロボット制御では、「いま何が起きているか」と「この行動を取ると何が起きるか」を分けて扱う必要があります。センサー観測はノイズや欠損を含み、カメラだけでは物理状態を直接得られない場合もあります。一方、将来予測はモデルの誤差に左右され、長い予測ほど誤差が蓄積します。

さらに、接触、摩擦、破損、急激な環境変化などでは、予測の小さな誤差が制御失敗へ直結する可能性があります。そのため、学習モデルが高い予測能力を示しても、安定性や制約を検証しやすい制御器を下位層に残す方が、安全性と検証可能性を確保しやすくなります。

前提となる三つの用語

状態推定は、センサー観測とシステムモデルを組み合わせ、現在の状態またはその確率分布を更新する処理です。部分観測環境では、過去の観測と行動から信念状態を形成し、それを意思決定に使います。状態推定そのものの目的は、行動系列を最適化することではありません。

世界モデルは、観測履歴や行動から将来の状態、観測、報酬などを予測する学習モデルを広く指します。必ずしも位置や速度などの物理状態を直接復元するものではなく、画像を圧縮した潜在状態と、その時間発展を学習する構成も含みます。このため、物理状態、信念状態、学習された潜在表現を同じ「状態」と呼ばないことが重要です。

**MPC（モデル予測制御）**は、予測モデルを使って有限時間の最適化問題を繰り返し解き、最初の制御入力だけを実行して、新しい観測を得た後に再計画する方法です。制約を明示的に扱いやすく、短い時間スケールの実行に適しています。

世界モデルは何を予測するのか

画像などの高次元観測をそのまま長期予測するのではなく、観測を潜在状態へ圧縮し、その潜在空間で将来軌道を予測する構成が考えられます。各候補行動列について潜在軌道、報酬、場合によっては予測不確実性を計算し、行動を比較します。

利用方法は大きく二つあります。一つは、世界モデルをオンライン計画器として使う方法です。PlaNetは画像から学習した潜在ダイナミクス上でオンライン計画を行い、PETSは確率的ニューラルネットワークのアンサンブル、軌道サンプリング、MPCを組み合わせています。後者では複数の予測を比較し、不確実性を考慮した行動選択を行います。

もう一つは、世界モデル内の想像ロールアウトを方策や価値関数の学習に使う方法です。Dreamerは潜在世界モデルで将来を想像し、価値関数と方策を学習します。この場合、実行時に毎回長い軌道最適化を行うのではなく、計画計算の一部を学習済み方策へ移せます。したがって、世界モデルはMPCと同義ではありません。

flowchart LR
  A["観測履歴・推定状態"] --> B["世界モデル"]
  B --> C1["潜在状態の時間発展"]
  B --> C2["将来の報酬・不確実性"]

  subgraph P["オンライン計画に使う方式"]
    D1["候補行動列"] --> D2["複数の軌道をロールアウト"]
    D2 --> D3["軌道・報酬・不確実性を比較"]
    D3 --> D4["最初の行動を実行"]
  end

  subgraph L["方策・価値学習に使う方式"]
    E1["想像ロールアウト"] --> E2["価値関数・方策を学習"]
    E2 --> E3["学習済み方策を実行"]
  end

  C1 --> D2
  C2 --> D3
  C1 --> E1
  D4 --> F["新しい実観測"]
  E3 --> F
  F --> A

世界モデルは、オンラインMPCなどで候補行動を比較する方式と、想像ロールアウトを方策・価値学習に利用する方式に分けて利用できます。

方式ごとの比較

構成	主な入力	主な出力	強み	主な制約
状態推定器＋従来制御器	センサー観測、物理モデル	状態・信念分布、制御入力	現在状態の更新と短時間制御を分担しやすい	複雑な視覚予測やデータ駆動の長期予測は別途必要
世界モデル＋オンラインMPC	観測履歴、推定状態、候補行動	潜在軌道、評価値、短期制御入力	画像入力から候補行動を比較でき、再計画できる	オンライン計画の計算量、モデル誤差、不確実性への対応が必要
世界モデル＋方策・価値学習	実データ、観測履歴、想像ロールアウト	方策、価値関数	実行時の計画計算を軽くできる可能性がある	モデルバイアスが方策学習へ伝播し、制約を直接扱いにくい場合がある
階層制御	推定状態、タスク目標、行動候補	上位目標、局所軌道、低レベル入力	世界モデルを上位予測に限定し、下位で制約と安全性を扱える	層間の時間スケール、遅延、故障時挙動を設計・検証する必要がある

実装時のデータフロー

基本構成は、センサー観測を状態推定器へ入力し、得られた信念状態を世界モデルとMPCへ渡す流れです。世界モデルは複数の将来軌道、報酬、不確実性を予測します。MPCはその情報と明示的な制約を使い、短期の制御入力を選択します。実行後に得た新しい観測で状態推定を更新し、同じ処理を繰り返します。

ロボット経路計画の衝突判定設計：安全性・計算量・制御周期をどう両立するか

Thu, 07 May 2026 08:46:36 +0900

衝突判定の周期を一つの数値で決められない点が、このテーマで特に気になるところです。

先に結論

ロボットの衝突判定に、すべての用途で共通する固定周波数はありません。計画時の経路検証、実行時の軌道再検証、保護停止用の監視を分け、それぞれに適した精度と周期を設定します。

周期は単純なHzではなく、判定と判定の間にロボットと障害物が相対的にどれだけ移動するかで決めます。相対移動量が許容マージンを超えるなら、周期を短くするだけでなく、判定の細分化、連続衝突判定、保守的な掃引判定を検討します。

なぜ三つの層に分けるのか

計画層は、将来の状態列として生成された経路全体を、環境モデルと照合する役割を持ちます。実行層は、実行直前や実行中に、現在のロボット状態と最新の環境で軌道を再確認します。監視層はセンサー入力を使い、危険が迫った場合の速度制限や停止を担います。

計画用の判定頻度をそのまま保護監視へ使うことも、監視だけで計画経路全体の安全性を保証することも適切ではありません。再計画は新しい経路を生成する処理であり、衝突判定の代替ではないためです。再計画中もロボットが動くなら、別の監視層でその間を保護します。

前提となる用語と判定の仕組み

状態の有効性判定は、ある時点のロボット姿勢が障害物や自身のリンクと干渉していないかを調べる処理です。一方、モーション検証は二つの状態の間の動きを調べます。

始点と終点だけを判定すると、その間でリンクが障害物を通り抜ける衝突を見逃す可能性があります。OMPLでは状態の有効性判定と状態間のモーション検証を分け、離散的な検証では補間状態を検査します。MoveItのOMPLインターフェースでは、longest_valid_segment_fraction や longest_valid_segment_length により、モーション中に許す最大セグメント長を調整できます。

したがって、計画時の精度は「何Hzか」ではなく、状態空間における最大有効セグメント長として考える方が適切です。ロボット形状、障害物の薄さ、狭い隙間、姿勢変化による掃引領域を基準にします。長いリンクや大きな姿勢変化がある場合、同じ状態空間上の刻みでも空間内の移動量は大きくなり得ます。

flowchart LR
  A["状態A"] --> B["状態間の動き"]
  B --> C{"セグメント長は
形状・運動に対して適切か"}
  C -->|"適切"| D["補間状態を検査"]
  C -->|"長すぎる"| E["セグメントを細分化"]
  E --> D
  D --> F{"障害物・自己リンクとの
干渉を検出"}
  F -->|"衝突なし"| G["次のセグメントへ"]
  F -->|"衝突あり"| H["経路を不 valid として扱う"]
  G --> I["状態B"]
  A -.-> J["端点だけの判定では
途中の衝突を見逃し得る"]
  I -.-> J

端点だけでなく状態間の補間状態を検査し、形状や運動に応じてセグメント長を調整する考え方を示しています。

動的障害物と安全マージン

動的環境では、判定した瞬間に安全でも、次の判定までにロボットや障害物が接近します。相対速度を v_rel、判定周波数を f_check、許容距離を d_allow とすると、周期設計の概念的な目安は次のように表せます。

v_rel / f_check ≤ d_allow

ロボット学習の合成データ戦略：実機データとの境界をどう設計するか

Wed, 15 Apr 2026 00:45:58 +0900

合成データを増やせば実機データを減らせる、という単純な関係ではない点が気になるテーマです。

先に結論

ロボット操作向けの合成データは、実機データを一律に置き換えるものではない。視覚的なばらつきや、シミュレータで正確に生成できる状態・ラベルが成否を左右するなら、視覚認識の事前学習や一部の方策学習で実機データを代替できる。一方、摩擦、接触順序、柔軟性、センサー雑音、アクチュエータ遅延などが支配的な操作では、実機の成功・失敗例を基準データとして残し、合成データで拡張したうえで実機微調整と独立評価を行うべきだ。

したがって、設計の単位は「合成データ何％」ではなく、視覚・物理・センサー・ラベルという要因ごとの再現可能性である。タスクを分解し、実機で固定すべき分布と、シミュレーションで広げる分布を決めることが出発点になる。

なぜ代替条件の切り分けが必要か

合成データは、実機では収集しにくい大量の画像、状態、軌道を生成できる。しかし、生成量が増えても、シミュレータに含まれない失敗要因は学習できない。反対に、現実の一例へ過度に合わせたシミュレーションは、別の照明、背景、物体配置、物理条件で性能を落とす可能性がある。

また、先行研究の「合成データ」は同じものではない。画像のドメインランダム化、物理パラメータのランダム化、実機デモンストレーションから生成した合成軌道など、方式と目的が異なる。そのため、研究間の性能値を単純に並べて、普遍的な混合比率を導くことはできない。

前提となる用語

ドメインランダム化は、テクスチャ、照明、姿勢、背景、物体配置などをシミュレーション中に変化させ、実環境の見え方に対する頑健性を学習させる方法である。シミュレーション画像だけで学習した物体認識モデルを実環境へ移転した実証がある。

ダイナミクスランダム化は、質量、摩擦、遅延などの力学パラメータを変化させる方法である。単一の物理モデルへ過適合することを避け、複数の条件に対応する方策を学習する。研究対象となったロボット制御タスクでは、追加の実機学習なしで実機へ移転した例も報告されている。

実機アンカーとは、実際のカメラ、物体、治具、ロボットで取得した成功・失敗データを、学習や評価の基準として使う考え方である。シミュレーションの分布を広げる場合でも、現実にどのような見え方や接触が起きるかを判断する基準になる。

合成データが機能する仕組み

視覚認識では、実運用で起こり得る照明、背景、姿勢、物体配置を広くランダム化することで、特定の画像条件への依存を抑える。物体の位置や形状をシミュレータが管理していれば、認識対象のラベルも一貫して生成できる。この領域では、実機画像を使わずに学習したモデルの実環境移転が示されている。

制御では、質量や摩擦、遅延といったパラメータを一つに固定せず、分布として扱う。さらに、接触を伴う器用な手内操作についても、視覚と物理ダイナミクスをランダム化して学習した方策を実機で評価した事例がある。ただし、これらは特定のロボット、タスク、ランダム化設定での実証であり、別の構成にそのまま一般化できるとは限らない。

別の方法として、少数の実機による人間デモンストレーションを種データにし、シミュレーション内で物体配置や軌道を変換してデモンストレーションを増やす方式がある。これは実機データを排除するのではなく、現実の操作構造を保ったまま合成データで規模と多様性を補う設計である。

flowchart LR
  A["タスクを要因に分解"] --> B{"シミュレータで再現・ラベル生成しやすいか"}
  B -->|"比較的しやすい"| C["視覚認識・照明・背景・姿勢・状態ラベル"]
  C --> D["合成データ中心を検討"]
  B -->|"一部は再現可能"| E["質量・摩擦・遅延を含む制御"]
  E --> F["ダイナミクスランダム化と実機移転確認"]
  B -->|"再現しにくい要因が支配的"| G["接触順序・柔軟性・センサー雑音・固有差"]
  G --> H["実機アンカーと実機微調整を重視"]
  D --> I["独立した実機評価"]
  F --> I
  H --> I
  I --> J["失敗モードと未カバー領域を確認"]

合成データの比率ではなく、視覚・物理・センサー・接触など各要因の再現可能性でデータの役割を判断する。

要因別に見る選択基準

対象要因・タスク	合成データの役割	実機データの扱い	初期判断
視覚認識、照明・背景・姿勢のばらつき	ドメインランダム化で広く拡張	独立した実機評価に使用	合成中心を検討
物体配置や状態ラベル	状態とラベルを大量生成	実機分布との対応を確認	代替可能性が比較的高い
質量・摩擦・遅延を含む制御	ダイナミクスランダム化で条件を拡張	実機の移転性能と失敗を確認	タスク依存で併用
接触豊富な把持・手内操作	視覚・物理条件をランダム化	成功・失敗例をアンカーにする	混合を基本にする
柔軟物、摩擦、接触順序が支配的な操作	稀な条件や失敗条件を補う	実機データと実機微調整を重視	実機併用が必要
実機デモからの軌道生成	配置や軌道を変換して拡張	少数の種データを保持	ハイブリッドを検討

この表は固定的な処方箋ではない。特に、カメラの視野・ノイズ、アクチュエータの遅延、物体や治具の公差、柔軟性をシミュレータがどの程度表現できるかで判断は変わる。

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

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を上書きせず、変換元と変換処理のバージョンを追跡できるようにします。

VLAと低レベル制御の責務分担：安全で実装しやすいロボット構成とは

Wed, 04 Feb 2026 00:09:03 +0900

VLAの出力が細かな動作指令まで扱えるようになるほど、制御器との境界をどこに置くかが設計上の論点になります。

先に結論

一般的な実機システムでは、VLAをトルク・電流・PWMなどの低レベル制御ループへ直接接続するべきではありません。VLAには、画像や言語からのタスク理解、サブゴール生成、スキル選択、目標姿勢、またはアクションチャンクの生成を担当させ、その下に軌道計画、逆運動学（IK）、局所サーボ、ハードウェアインターフェース、安全監視を分離する構成が妥当です。

これはVLAの能力を制限するためではありません。VLAは連続アクションや短いアクションチャンクを生成できますが、推論の遅延やジッタを管理し、関節制限・衝突制約を守り、通信断や異常時に停止する責任は、決定性を重視した専用層に置く方が安全で実装しやすいためです。

なぜ責務の境界が問題になるのか

ロボットでは、「何をするか」を決める処理と、「その動作を物理的に安全に実行する」処理が異なります。VLAは視覚と言語を手掛かりに、対象物や作業の意味を解釈し、ロボットの行動を選ぶ方策として利用できます。一方、サーボ制御では、入力を一定の周期で処理し、遅延やジッタを抑えながら関節や手先を追従させなければなりません。

実時間処理では、予測可能な実行時間、遅延とジッタの管理、実時間スレッドでのメモリ確保回避などが重要です。したがって、一般的な推論処理をサーボループや非常停止と同じ層に置くと、モデルの計算時間や通信状態が物理動作の安全性へ直接影響します。特定のVLA、ロボット、GPU、センサー構成で許容できる推論周期や遅延の上限は一律には決められず、システム全体で検証する必要があります。

VLAの出力は一種類ではない

VLAを「テキスト命令を出すモデル」とだけ捉えると、接続設計を誤ります。RT-2は、視覚・言語・ロボット動作を同じトークン系列として扱い、離散化したアクショントークンを対象ロボットのアクション空間へデコードします。OpenVLAの標準的な出力は、エンドエフェクタの位置・姿勢とグリッパ操作を含む7次元のロボットアクションです。これは一般的なモータ電流やPWMを直接出力するインターフェースではありません。

一方、π0のように、連続値のロボットアクションを単一ステップではなくアクションチャンクとして生成する研究もあります。つまり、VLAを上位のタスク方策として使う構成だけでなく、より細かな動作指令を生成させる構成も可能です。ただし、アクションを生成できることと、モータレベルの安全責任を負わせることは別問題です。

VLAごとに出力表現が異なるため、ロボット固有のアクション空間への変換、正規化、速度・関節・衝突などの制約処理が必要になります。

flowchart TB
  subgraph upper["上位の認識・方策層"]
    I["カメラ画像・言語指示"] --> V["VLA\nタスク理解・サブゴール生成・スキル選択"]
    V --> O["目標姿勢・アクションチャンクなど\nモデル固有の出力"]
  end

  subgraph bridge["ロボット固有の変換・計画層"]
    T["アクション変換・正規化\n座標系・単位・範囲の検証"]
    P["軌道計画・逆運動学（IK）"]
  end

  subgraph lower["決定性を重視する制御層"]
    S["局所サーボ\nインピーダンス・PIDなど"]
    H["ハードウェアインターフェース"]
  end

  V --> T
  O --> T
  T --> P --> S --> H

  subgraph safety["VLAから独立した安全監視"]
    M["関節・速度・衝突制約\nウォッチドッグ・通信断監視"]
    E["非常停止・安全状態への遷移"]
    M --> E
  end

  M -.-> T
  M -.-> S
  M -.-> H
  E -.-> H

VLAはタスク理解や目標・アクション生成を担当し、変換、計画、局所サーボ、ハードウェア接続、安全監視を専用層に分離する構成例。具体的な周期や遅延の許容値は、対象モデルと実機システムごとに検証が必要です。

推奨する制御階層

上位では、カメラ画像や言語指示をVLAへ入力し、タスク理解、サブゴール生成、スキル選択を行います。VLAが返す目標姿勢やアクションチャンクは、ロボット固有の変換層で関節空間などへ対応付けます。その下の軌道計画器やIKが、実行可能な経路と関節目標を生成します。

ロボットに触覚と力覚を加える設計判断：視覚との役割分担

Sun, 25 Jan 2026 00:05:01 +0900

視覚に情報を集約する設計は分かりやすい一方、接触した瞬間から別の観測が必要になる点が気になります。

先に結論

ロボットに触覚・力覚センサーを追加する価値は、視覚を置き換えることではなく、接触後に増える観測の曖昧さを減らし、制御を切り替えられる点にある。視覚は対象の大域的な位置や形状を非接触で捉える。一方、指先などの触覚センサーは接触部の圧力、変形、局所形状を捉え、手首の力覚センサーは手先に作用する合力・合トルクを捉える。

したがって、対象への接近と大域的位置決めには視覚、接触検出と荷重監視には力覚、把持面の状態や滑り兆候の推定には触覚を使い分ける構成が基本になる。ただし、視覚だけで接触状態を間接推定できる場合もあるため、採用は作業の接触性、必要精度、損傷リスク、実装負荷を比較して決めるべきである。

なぜ視覚だけでは不十分になりやすいのか

カメラは対象全体の位置や形状を把握するのに向いている。しかし、手や対象に隠れた接触面、接触パッチの形状、接触圧力の分布は、視覚から直接観測しにくい。把持後に物体が正しい位置にあるように見えても、指先の接触が偏っていたり、滑り始めていたりする可能性がある。

また、挿入や嵌合では、目標位置が分かっていても、部品同士がどの方向で接触しているか、押し付けが強すぎないかを位置情報だけで判断しにくい。接触力やトルクを監視しながら、硬く位置を追従する状態から、環境になじむコンプライアンス制御へ切り替える必要がある。

「視覚では解けない」という表現は絶対的ではない。既知の対象、十分な視認性、適切な物理モデル、学習済みの推定器があれば、視覚から把持成否や力を間接的に推定できる場合もある。触覚・力覚は、視覚の全面的な代替ではなく、接触状態を観測する追加チャネルと考えるのが適切だ。

前提となるセンサーの違い

触覚センサーは、指先やハンド表面など、接触に近い場所で局所的な情報を取得する。方式によって、法線力、せん断力、圧力分布、接触形状など、得られる物理量は異なる。光学式触覚センサーの一例では、接触によるエラストマー表面の変形を画像として取得し、接触形状や力を推定する。

力覚センサーは、代表的には手首に配置され、Fx、Fy、FzとTx、Ty、Tzの6成分を扱う。複数の接触が手先に与える総合的な荷重を監視できる一方、センサー単独で接触点や圧力分布を一意に復元できるとは限らない。局所接触に強い触覚と、手先全体の荷重監視に強い力覚は代替関係ではない。

センサー	主な観測対象	強い場面	苦手・制約
視覚	大域的な位置・形状	接近、対象認識、初期位置決め	遮蔽された接触面や圧力分布を直接観測しにくい
指先触覚	局所圧力、変形、接触形状、接触状態	把持成否、接触位置、滑り兆候の推定	局所情報が中心で、手先全体の合力・合トルクは直接表さない
手首6軸力覚	手先に作用する合力・合トルク	接触検出、荷重監視、挿入・嵌合	接触点や圧力分布を単独では一意に決めにくい

内部の仕組みとデータフロー

実装では、センサーを常時同じ目的で使うのではなく、作業状態に応じて役割を切り替える。まず視覚で対象の位置と形状を推定し、ロボットを接触直前まで移動させる。次に力覚の変化から接触を検出し、位置制御からインピーダンス制御やハイブリッドな位置・力制御へ移行する。これにより、押し付け力や接触時の剛性を調整できる。

接触後は、指先触覚から局所的な接触分布や把持状態を確認する。把持が不十分、または滑りの兆候があると判断した場合は、把持力や手の姿勢を調整し、必要なら再把持する。視覚と触覚から把持成否を予測して再把持する方策は、研究上も提案・評価されている。最後に、視覚と接触情報を組み合わせ、作業完了、異常、再試行を判定する。

flowchart LR
  A["視覚で対象の位置・形状を推定"] --> B["接触直前まで接近・初期位置決め"]
  B --> C["力覚の変化を監視"]
  C --> D{"接触を検出したか"}
  D -- "いいえ" --> B
  D -- "はい" --> E["位置制御からインピーダンス制御・ハイブリッド位置力制御へ切り替え"]
  E --> F["押し付け力・接触時の剛性を調整"]
  F --> G["指先触覚で局所接触分布・把持状態を確認"]
  G --> H{"把持不十分または滑り兆候ありか"}
  H -- "はい" --> I["把持力・手の姿勢を調整"]
  I --> J{"再把持が必要か"}
  J -- "はい" --> I
  J -- "いいえ" --> K["力覚で荷重・嵌合異常を監視"]
  H -- "いいえ" --> K
  K --> L["視覚と接触情報を組み合わせて結果判定"]
  L --> M{"作業結果"}
  M -- "完了" --> N["作業完了"]
  M -- "異常・再試行" --> O["停止・退避または再試行"]

視覚は接近と初期位置決め、力覚は接触検出と荷重監視、触覚は局所的な把持状態の確認に使い、観測結果に応じて制御や再試行を切り替える。

この流れでは、センサー値を単に追加するだけでは足りない。どの観測をどの状態遷移の条件に使うか、また力の異常を停止、退避、再試行のどれに結び付けるかを制御仕様として定義する必要がある。