Robotics on Physical AI Hub

Physical AIのインターフェース互換性管理：センサーから制御まで変更に強い設計を作る

Sat, 07 Nov 2026 14:46:34 +0900

ロボットの長期運用では、型が一致しているだけで安全に接続できるとは限りません。

先に結論

ロボットを長期間保守するには、インターフェースをデータ型だけでなく、データの意味、単位、座標系、時刻、品質、通信条件、モデル入出力、変更手順まで含む契約として管理します。センサー、認識、計画、制御の各境界で契約を分け、互換性を層別に判定することが基本です。

実装では、バージョン付きスキーマ、旧版と新版の並行運用、変換アダプター、契約テスト、実データのリプレイを組み合わせます。コンパイルが成功しても、単位や座標系の変更、QoSの不一致、モデル前処理の差、制御系の遅延増加までは検出できません。

なぜ互換性管理が難しいのか

Physical AIの処理系は、センサー、通信ミドルウェア、推論モデル、計画器、制御器、アクチュエーターが連鎖しています。一つの変更が複数チームと実行環境に波及するため、「フィールドが同じ型か」だけでは判断できません。

数値型が同じでも、単位がメートルからミリメートルに変われば値の意味は変わります。座標フレームが変われば、受信側は同じ数値を別の位置として解釈します。計測時刻と受信時刻の混同、欠測値と有効性フラグの扱いの違いも、型互換でありながら機能を壊す要因です。

管理すべき契約

ROS 2にはmsg、srv、actionがあり、定義から複数言語向けの型と関連コードが生成されます。ただし通信の可否は型だけでなくQoSにも依存します。reliability、durability、history、depth、deadline、lifespanなどの設定がPublisherとSubscriberの間で互換しなければ、通信が成立しない場合があります。

DDS-XTypesは、型の拡張性、メンバーの識別、型の割り当て可能性などを扱います。しかし、実際の利用可能範囲は、ROS 2の型サポート、RMW実装、DDSミドルウェア、設定に依存します。仕様上可能な拡張を、そのまま対象環境へ適用できるとは限りません。

データ契約には、少なくとも次を記録します。

フィールド名、型、必須性、既定値
単位、値の範囲、精度
座標系、フレーム名、軸の向き、回転表現
計測時刻、生成時刻、受信時刻など時刻の意味
共分散、有効性、欠測、品質の表現
QoS、許容遅延、deadlineなどの通信条件
モデルの入力・出力テンソルの型、形状、前処理、後処理
変更理由、サポート期間、廃止予定日

単位や座標の規約にはREP-103 、モバイルロボットのフレーム関係にはREP-105 を参照できます。

推論モデルもインターフェースである

モデルファイルのバージョンだけでは不十分です。ONNXでは、モデル形式のIRバージョン、演算子セットのバージョン、演算子仕様の変更を区別しています。入力テンソルの形状・型に加え、前処理、量子化、キャリブレーション、後処理も契約として記録します。

テンソル形状や演算子セットが互換でも、前処理や学習データの変更による認識精度、さらに制御性能の維持までは仕様書から保証できません。モデル形式の互換性と、モデルを利用した機能の性能維持は別に検証します。

flowchart LR
  S["センサー"] --> SC["センサー契約\n意味・単位\n座標系・時刻\n品質・バージョン"]
  SC --> M["ROS 2 msg / srv / action\n型・必須性・既定値"]
  M --> QC["通信契約\nQoS・転送条件\n遅延・deadline・lifespan"]
  QC --> I["認識モデル\n入力・出力テンソル\n形状・型・前処理・後処理"]
  I --> PC["計画・制御契約\nコマンド・制約\n許容遅延・欠測・ジッター"]
  PC --> A["アクチュエーター"]
  A --> F["フィードバック\n計測値・時刻・品質"]
  F -. "契約テスト・リプレイ・影響追跡" .-> SC
  B1["各境界で管理する項目\nスキーマ\n座標系\n時刻\n品質\nバージョン"] -. "境界横断の契約" .-> M
  B1 -. "境界横断の契約" .-> I
  B1 -. "境界横断の契約" .-> PC

センサーからアクチュエーターまで、データの意味、通信条件、モデル入出力、制御条件を連続したインターフェース契約として管理する流れを示します。

センサーの意味・単位からROS 2の型、QoSと転送、モデル入出力、計画・制御コマンド、アクチュエーターのフィードバックまでを連続した契約として捉えます。各境界にスキーマ、座標系、時刻、品質、バージョンを置くと、変更箇所と影響範囲を追跡しやすくなります。

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

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などで台車・アーム・把持物・環境の衝突を判定し、安定性評価を加えた全身計画または軌道最適化を行います。最後に補間された軌道全体を検証し、環境やロボット状態が変化した場合は再計画します。

自律ドッキングの実装設計：位置合わせ・接近制御・充電接続を分解する

Sun, 01 Nov 2026 14:47:08 +0900

自律ドッキングは、接触できたかどうかだけでは成功を判断できない点が設計上の要所です。

先に結論

ロボットの自律ドッキングでは、不確実性を一度に解消しようとせず、段階的なゲートとして扱うのが基本です。まず地図と自己位置推定を使って充電ステーション周辺のステージング地点へ移動し、次にドックに対する相対位置と姿勢を精密化します。その後、低速で接近し、接触またはドッキング状態を確認してから、最後に電気的な充電成立を検証します。

「ドックへ到達した」と「充電できている」は同じ状態ではありません。したがって、成功条件は物理接触だけでなく、許容姿勢、停止状態、ドック状態、充電状態、タイムアウトを個別に評価する設計が適しています。条件を満たせない場合は前進を続けず、停止または後退、再位置推定、制限回数内の再試行、最終的な異常通知へ遷移させます。

なぜ段階分けが必要か

充電ステーションまでの移動は、通常のナビゲーションが得意とする問題です。一方、接触直前の位置合わせでは、地図上の自己位置だけでは扱いにくい局所的な誤差や、ドック設置位置のずれが問題になります。そのため、ステージング地点を境に、地図・大域自己位置推定からドック固有の相対センサーへ重心を移します。

さらに、接触したように見えても、端子の位置ずれや接続状態によって充電が成立しない可能性があります。ドッキング判定と充電判定を分離すれば、ロボットが物理的には停止しているものの、充電できていない状態を検出できます。

前提となる用語

大域自己位置推定：地図上でロボットがどこにいるかを推定する機能。ステーション周辺までの経路走行に使います。
ステージング地点：ドック固有の近距離処理へ切り替えるための待機位置です。
相対位置・姿勢推定：ロボットから見たドックの距離、横方向のずれ、向きなどを推定する処理です。
ドッキング判定：物理的にドックへ到達し、所定の姿勢や停止条件を満たしたかを確認する処理です。
充電判定：ドックとの電気的な接続が成立し、充電状態になったかを確認する処理です。

内部の仕組み：不確実性を順にゲート化する

代表的な構成は、通常のナビゲーションでステージング地点へ移動し、その後にドック固有の処理を実行する段階構成です。汎用フレームワークでは、ステージング位置の取得、相対位置の精密化、最終接近、ドッキング状態、充電状態を別々の処理として設計できます。一方、組み込み型ロボットでは、これらが一つのDockアクションに隠蔽されることもあります。抽象化の違いであり、段階的に確認する考え方と矛盾しません。

相対位置推定に使うセンサーは一つに決まりません。実装に応じて、赤外線、カメラ、レーザー・距離センサー、LiDAR、接触センサーなどが候補になります。重要なのは、センサー名を先に固定することではなく、各段階で何を観測し、どの状態を確定させるかを明確にすることです。

flowchart LR
  A["ステーション同定・大域自己位置推定"] --> B["ステージング地点へ移動"]
  B --> C["ドック相対座標系へ切り替え"]
  C --> D["相対位置・姿勢を精密化"]
  D --> E["低速接近"]
  E --> F["接触・ドッキング状態を検証"]
  F --> G["充電状態を検証"]
  G --> H["ドッキング成功"]

  B -->|"到達不可・タイムアウト"| R["停止または再位置推定"]
  D -->|"姿勢誤差・観測不安定"| S["停止または後退"]
  E -->|"障害物・異常接触・タイムアウト"| S
  F -->|"停止・姿勢・ドック状態が未成立"| T["後退して制限回数内で再試行"]
  G -->|"充電未成立・タイムアウト"| T
  S --> R
  T -->|"再位置推定後"| C
  T -->|"再試行上限超過"| U["異常通知または遠隔介入"]
  R -->|"復旧可能"| B

大域自己位置推定からドック相対位置合わせへ段階的に切り替え、ドッキングと充電を分離して検証する制御フロー。

図では、ステーションの同定と大域移動から始め、ステージング地点でドック基準の相対座標へ切り替えます。相対位置・姿勢を確認した後に低速接近し、接触・ドッキングを検証します。最後に充電状態を確認し、途中で条件を満たせなければ後退または再位置推定へ戻ります。

接触作業向けロボットシミュレーションの選び方：物理エンジンと接触計算を比較する

Sat, 31 Oct 2026 14:18:48 +0900

接触計算は、エンジンの名称よりも評価方法で結果が変わる点が気になります。

先に結論

接触を伴うロボットシミュレーションに、普遍的に最適な物理エンジンや時間刻みはありません。高速衝突、持続接触・準静的操作、多接触・閉ループ拘束にタスクを分類し、接触力、侵入量、摩擦遷移、拘束残差、衝突時刻、計算時間で比較するのが基本です。

高速衝突では、連続衝突検出（CCD）と細かい固定時間刻み、またはサブステップを候補にします。押し付け、把持、挿入、組立では、見た目の安定性だけでなく、接触力や静止摩擦から滑りへの遷移を確認します。積み重ねや多接触では、ソルバー反復回数と時間刻みを別々に変え、収束性とコストの組み合わせを評価します。

なぜエンジン名だけで選べないのか

物理エンジンの速度、精度、安定性は、エンジン名だけでは決まりません。接触状態、形状や質量などのモデル、評価指標、積分器、時間刻み、接触ソルバー、反復回数、収束許容値、接触の柔らかさや剛性、摩擦モデルが相互に影響します。あるシーンで安定した設定が、別のロボットや材質でも同じ結果になるとは限りません。

また、異なるエンジンの「反復回数」や「摩擦係数」は、同じ数値でも同じ意味を持ちません。設定値をそろえることは比較条件の一つですが、物理挙動がそろうことを意味しないため、接触力誤差、侵入量、拘束残差、滑り判定、計算時間などの出力で比較します。

前提となる用語

時間刻みは、シミュレーションを一度進める時間幅です。固定時間刻みは再現性や制御周期との関係を確認しやすい一方、細かくするほど計算量が増えます。サブステップは、制御側の経過時間を複数の小さな計算に分ける方法です。

接触ソルバーは、物体の貫通を抑え、摩擦や拘束条件を満たすための数値計算を担います。反復回数を増やすと拘束残差やドリフトが改善する可能性がありますが、計算量も増えます。CCDは、離散的な衝突判定だけでは見落としやすい高速物体や薄い形状を扱うための仕組みです。CCD、固定時間刻み、サブステップは異なる機構であり、単純な代替策ではありません。組み合わせや代替の効果は対象タスクで確認します。

エンジンごとの設定項目

本稿で参照する範囲は、PhysX 5.4.1、MuJoCo stable documentation（リリース番号は資料上で固定されていない）、Bullet3 master の User Manual（参照コミットは資料上で固定されていない）です。MuJoCoとBulletについては、再現性のために利用する実装のリリースやコミットを別途固定してください。固定されていない資料から、特定版同士の性能順位を断定することはできません。

MuJoCoでは、時間刻みと積分器に加え、Newton、CG、PGSなどの拘束ソルバー、反復回数、収束許容値を設定できます。接触をソフトな制約として扱い、solref、solimp、摩擦パラメータ、接触形状も調整対象です。モデルベース制御で接触パラメータを明示的に調整したい場合の候補ですが、設定値を他エンジンへそのまま移植できるとは限りません。

PhysX 5.4.1では、PGSとTGS、位置方向・速度方向のソルバー反復回数、接触オフセット、静止オフセット、CCDを個別に設定できます。既存基盤に合わせてこれらを調整したい場合の候補ですが、TGSの特徴から他エンジンを含む総合順位を推定してはいけません。

Bulletでは、stepSimulation の maxSubSteps と fixedTimeStep により、経過時間を固定時間刻みに分割できます。ソルバー反復回数や連続衝突検出も設定対象です。Bullet3 master はコミット未固定の資料であるため、実装を比較に使う場合は対象コミットを記録します。

flowchart TD
  A["接触タスクを分類"] --> B{"主な接触レジームは？"}
  B -->|"高速衝突・飛翔物体"| C["CCD、固定時間刻み、サブステップを確認"]
  C --> D["トンネリング、衝突時刻、衝突インパルスを比較"]
  B -->|"持続接触・押し付け・把持・挿入"| E["接触剛性・減衰、摩擦、位置拘束反復を確認"]
  E --> F["侵入量、接触力、関節トルク、滑り遷移を比較"]
  B -->|"準静的操作・組立"| G["接触コンプライアンス、収束許容値、時間刻みを確認"]
  G --> H["力の再現性、拘束残差、軌道の収束を比較"]
  B -->|"多接触・積み重ね"| I["ソルバー方式、反復回数、時間刻みを確認"]
  I --> J["反復回数と時間刻みを独立に変えて収束試験"]
  D --> K["同じモデル、初期条件、制御入力で比較"]
  F --> K
  H --> K
  J --> K
  K --> L["実機パラメータを校正し、許容する挙動と計算コストで選択"]

接触レジームごとに確認すべき設定と評価指標を分け、共通条件で比較する選定フロー。

用途別の選定基準

接触レジーム	優先して確認する設定	主な評価指標
高速衝突・飛翔物体	CCD、固定時間刻み、サブステップ	トンネリング、衝突時刻、衝突インパルス
押し付け・把持・挿入	接触剛性・減衰、摩擦、位置拘束反復	侵入量、接触力、関節トルク、滑り遷移
組立・準静的操作	接触コンプライアンス、収束許容値、時間刻み	力の再現性、拘束残差、軌道の収束
積み重ね・多接触	ソルバー方式、反復回数、時間刻み	ドリフト、拘束残差、計算時間
モデルベース制御	積分器、拘束ソルバー、接触パラメータ	制御入力と接触応答の再現性

収束試験の進め方

時間刻みは、単一の推奨値から決めません。基準値を置き、それを半分にした条件を作ります。各条件で軌道、接触力、最大侵入量、イベント時刻、実行速度を記録し、結果の変化が許容範囲に収まる値を候補にします。具体的な許容値は、タスクと実機の計測系に依存するため、資料だけから共通の閾値を設定できません。

冗長ロボットの逆運動学設計：可到達性・特異点・関節限界を評価する順序

Tue, 27 Oct 2026 13:48:35 +0900

冗長マニピュレーターでは、IKの成否だけでなく、その解を軌道全体で維持できるかが設計上の焦点になります。

先に結論

冗長マニピュレーターの逆運動学では、可到達性、特異点、関節限界に普遍的な固定順序があるわけではありません。実装上は、まず目標姿勢のフレームや表現を確認し、粗い幾何的可到達性で明らかな失敗を除外します。その後、関節限界をハード制約として含むIKを解き、反復中から生成軌道までヤコビ行列の特異性を継続的に監視する構成が実用的です。

7自由度以上の機構では、同じ手先姿勢に複数の関節解が存在し得ます。そこで冗長自由度を、関節限界からの距離、操作性、姿勢の望ましさ、軌道の連続性といった二次目的に使います。解が見つかったかだけでなく、その解が実機で継続的に動かせるかを評価することが重要です。

なぜ評価順序が問題になるのか

「目標位置に届くか」と「指定した条件で実行できるか」は同じではありません。幾何的なワークスペース内に目標があっても、必要な姿勢を取る関節ベクトルが関節範囲の外にある場合、その目標は実行可能とはいえません。また、候補解が関節限界内にあっても、特異点の近傍なら微小な手先変化に大きな関節速度が必要になり、数値計算や軌道追従が不安定になる可能性があります。

したがって、可到達性を最初に調べるとしても、それは通常、粗い必要条件のチェックです。最終的な可到達性は、位置・姿勢制約、関節制約、許容誤差などを同時に満たす解が存在するかで判断します。

前提となる用語

幾何的可到達性は、機構の形状から見て目標位置や姿勢に届く可能性を指します。一方、制約付きの実行可能性は、関節位置境界などの制約も満たす関節ベクトルが存在することです。両者は一致しません。

特異点は、ヤコビ行列による手先速度と関節速度の関係が悪化する状態として扱えます。代表的な評価には、最小特異値、条件数、Yoshikawaの操作性指標などがあります。指標や危険とみなす閾値に普遍的な一つの答えはありません。

冗長性とは、タスクに必要な自由度より関節自由度が多い状態です。主タスクを維持したまま、余った自由度を二次目的に割り当てられます。

推奨する評価フロー

目標の入力を検証する
目標姿勢の座標フレーム、位置、姿勢表現を確認します。ここが誤っていると、IKソルバーを変更しても正しい解は得られません。
粗い可到達性を確認する
明らかに機構の範囲外にある目標を、反復計算の前に除外します。これは最終判定ではなく、高コストなIKを不要な対象へ実行しないためのスクリーニングです。
関節限界付きでIKを解く
関節の下限・上限は、解を得た後の検査項目ではなく、可能ならソルバー内のハード制約にします。制約を満たす解がなければ、幾何的に到達可能でも実行可能な目標ではありません。
反復中に特異性を監視する
最終候補だけでなく、反復計算中や複数の冗長解を比較する段階でもヤコビ行列を確認します。特異点近傍では擬似逆行列による更新が不安定になり得るため、減衰最小二乗法などで発散を抑える方法があります。ただし減衰を強くするとタスク誤差が残るというトレードオフがあります。
二次目的で候補解を選ぶ
複数解がある場合は、関節限界までの余裕、操作性、望ましい姿勢、直前解との連続性などを評価します。主タスクの誤差を満たすことが前提であり、二次目的だけで主タスクを犠牲にしてはいけません。
軌道全体を検証する
1点のIK解が妥当でも、軌道の途中で関節限界に近づいたり、特異点に入ったりすることがあります。最終的には軌道上の関節限界余裕、特異性、速度、加速度を確認します。衝突、ケーブル干渉、トルク限界などは、この三項目とは別の制約として追加評価が必要です。

flowchart TD
  A["目標姿勢の入力を検証\n座標フレーム・位置・姿勢表現"] --> B["粗い幾何的可到達性を確認"]
  B --> C{"明らかな範囲外か"}
  C -->|"はい"| X["対象外として除外"]
  C -->|"いいえ"| D["関節限界をハード制約に含めてIKを実行"]
  D --> E["反復中にヤコビ行列の特異性を監視"]
  E --> F{"特異点近傍または数値不安定か"}
  F -->|"はい"| G["減衰や更新方法を調整\nタスク誤差とのトレードオフを確認"]
  G --> D
  F -->|"いいえ"| H{"制約を満たす候補解があるか"}
  H -->|"いいえ"| Y["実行可能な解なし\n初期値・条件・目標を再検討"]
  H -->|"はい"| I["複数の冗長解を比較"]
  I --> J["二次目的を評価\n関節限界余裕・操作性・姿勢・連続性"]
  J --> K["候補解を選択"]
  K --> L["軌道全体を検証\n関節限界余裕・特異性・速度・加速度"]
  L --> M{"軌道全体が実行可能か"}
  M -->|"いいえ"| N["再計画または別の候補解を検討"]
  N --> I
  M -->|"はい"| O["実行候補として採用"]

粗い可到達性を前段のスクリーニングとして使い、関節限界付きIK、特異性の継続監視、二次目的による解選択、軌道全体の検証を行う実装フロー。固定的な普遍順序ではなく、実用上の評価構成を示しています。

特異点をどう評価するか

ヤコビ行列の特異値を使う場合、最小特異値が小さい状態や条件数が悪化した状態を、特異点に近い候補として扱えます。操作性指標も候補解の比較に利用できます。ただし、どの指標を採用するか、どの値を危険と判定するかは、ロボットの構造や制御条件に依存します。安全閾値を一般値として固定するのではなく、対象機の制御周期、速度制限、エンコーダ分解能、剛性などを踏まえて決める必要があります。

ロボット通信の決定論設計：TSN・DDS・制御ネットワークの役割分担

Tue, 20 Oct 2026 13:36:07 +0900

先に結論

ロボット通信を決定論的に設計するには、TSN、DDS、専用制御ネットワークを同じ機能として扱わず、層と責任範囲を分けます。DDSはデータモデルと通信契約、TSNはEthernet上の時刻同期・送信スケジュール・帯域制御、専用制御ネットワークはサーボやI/Oなど厳しい制御経路の分離を担当させます。

センサ、状態共有、計画、監視、診断はDDS over TSNの候補です。一方、周期やジッターの制約が厳しいサーボ・モーション通信は、EtherCATなどの専用フィールドネットワーク、またはDDS通信から独立したTSNトラフィッククラスに分けます。ただし、TSNやDDS QoSを設定しただけで、アプリケーションから見たエンドツーエンドの決定性が保証されるわけではありません。

なぜ層の分担が必要なのか

ロボットでは、センサから処理器、制御器、アクチュエータへデータが届くまでの遅延とジッターが動作に影響します。ネットワーク内の送信が予定どおりでも、NIC、ドライバ、OSスケジューラ、DDS実装、executor、コールバック処理、メモリ割り当てなどが遅延要因になり得ます。

したがって、「DDSを使えばリアルタイムになる」「TSNを導入すれば制御周期が保証される」と単純化するのは危険です。先に制御周期、許容ジッター、最大遅延、損失への許容度を定め、その要求を各層の設定と実機検証へ割り当てます。

前提となる用語

TSN

TSNは単一のプロトコルではなく、IEEE 802.1を中心とする標準群です。802.1ASはブリッジドネットワーク内の時刻同期、802.1Qbvは時間に基づくゲート制御によるスケジュール通信、802.1Qccはストリームの予約や構成を扱います。必要に応じてキュー制御やフレームプリエンプションも組み合わせます。

TSNは主にEthernetのスイッチ、ブリッジ、NICなどのインフラ側で、共通時刻を使い、通信をどのタイミングでどのキューから送るかを制御します。

DDS

DDSはデータ中心のpublish/subscribe型ミドルウェアです。Reliability、History、Deadline、LatencyBudget、LivelinessなどをQoSポリシーとして表現し、データの更新契約やミドルウェアの振る舞いを定義します。ROS 2のDDSベース通信でも、PublisherとSubscriberのQoS互換性が通信可否に影響します。

一方、DDSのDeadlineやLatencyBudgetは、単独で物理ネットワークの帯域予約や802.1Qbvのゲート制御リストを設定するものではありません。DDSI-RTPSなどの転送はIP/Ethernet上で動作し、TSNはその下位のネットワークインフラとして位置づけます。

専用制御ネットワーク

専用制御ネットワークはOSIの特定の一層ではなく、サーボ、モーション、I/Oの通信を他のトラフィックから分離するアーキテクチャ上の選択です。物理的に別ネットワークへ分ける方法、VLANやTSNトラフィッククラスで論理分離する方法、EtherCATのような専用フィールドネットワークを使う方法があります。

内部の仕組みと構成

基本構成では、アプリケーションが扱うデータ型と通信契約をDDSに置き、DDSI-RTPSなどの転送をIP/Ethernet上で動かします。その下でTSNが共通時刻、送信スケジュール、ストリーム、キューを管理します。

まず802.1ASなどでネットワーク内の共通時刻を整え、通信周期や送信ウィンドウに合わせてQbvのゲート制御を構成します。必要に応じてストリームの予約や構成も行います。スケジュールはスイッチだけで完結せず、TSNブリッジやエンドポイントの設定にも依存します。

サーボ経路をDDSと同じ共有ネットワークへ載せる場合は、周期、帯域、最大フレーム長、キュー、優先度、再送や輻輳時の挙動を個別に予算化します。要求が厳しい場合は、専用フィールドネットワークか独立したTSNトラフィッククラスとして、DDSの輻輳や構成不整合の影響範囲を抑えます。

flowchart TB
  subgraph APP["ロボットアプリケーション"]
    S["センサ・状態共有・監視・計画・診断"]
    C["サーボ・モーション・I/O制御"]
  end

  subgraph DDSL["DDS通信層"]
    DM["データモデルと通信契約"]
    Q["QoS: Deadline・Reliability・History・LatencyBudget"]
    RTPS["DDSI-RTPS"]
  end

  subgraph TSNL["TSN対応Ethernet層"]
    TIME["802.1AS 共通時刻"]
    SCHED["802.1Qbv スケジュール・ゲート"]
    RES["ストリーム予約・キュー制御"]
    NET["TSNブリッジ・スイッチ・NIC"]
  end

  subgraph FIELD["専用制御経路"]
    FC["専用フィールドネットワーク"]
    IO["サーボ・アクチュエータ・I/O"]
  end

  S --> DM
  DM --> Q
  Q --> RTPS
  RTPS --> NET
  TIME --> NET
  SCHED --> NET
  RES --> NET
  NET --> S

  C --> FC
  FC --> IO
  FC -. "状態・監視データを必要に応じて変換" .-> DM

  NOTE["DDSのQoS設定だけでは、TSNの帯域予約やQbvゲート制御は自動的に決まらない"]
  Q -.-> NOTE
  NET -.-> NOTE

DDSはデータモデルと通信契約、TSNはEthernet上の時刻同期と送信制御、専用制御ネットワークは厳しい周期・ジッター制約の制御経路を担当する。

選択肢の比較

対象	主な役割	向いている通信	主な確認事項
DDS	データモデル、publish/subscribe、通信契約	状態共有、センサ、監視、計画、診断	QoS互換性、実装、再送や輻輳の挙動
DDSI-RTPS／IP/Ethernet	DDSデータのネットワーク転送	DDSトピックの配送	経路、最大フレーム長、下位ネットワークとの整合
TSN	時刻同期、送信スケジュール、帯域・キュー制御	周期性が必要な共有通信、独立した制御クラス	スイッチ・NIC対応、同期誤差、スケジュール
専用フィールドネットワーク	サーボ、モーション、I/Oの分離	厳しい周期・ジッター制約の制御ループ	ゲートウェイ、障害範囲、DDSとのデータ変換

使いどころと判断基準

状態共有、監視、計画、診断のように、データ中心の接続性と柔軟な購読関係が重要な通信ではDDSが適しています。DDS over TSNを採用する場合は、Deadline、LatencyBudget、Reliabilityなどを、TSNの周期、ゲート、帯域、キュー、最大フレーム長へ具体的に割り当てます。QoS名を設定するだけでは、TSN側の予約やスケジュールは決まりません。

ロボットのデジタルツイン実装：実機状態とシミュレーションを同期する設計原則

Sat, 17 Oct 2026 13:08:07 +0900

デジタルツインの同期を「高頻度にすればよい」と考えると、ログの再現性や安全境界を見落としやすい点が気になります。

結論：同期周期は一つに統一しない

ロボットのデジタルツインでは、すべてのデータを同じ周期で同期するのではなく、データクラスごとに同期粒度、更新トリガー、許容遅延、欠損時の動作を定義するのが基本です。

関節位置・速度・トルク、ベース姿勢・速度、インターロックなど、制御や安全に直結する状態は、実機の制御・計測周期または状態変化イベントに近い粒度で扱います。環境・シーン、ロボット形状、質量や摩擦などのモデルパラメータ、劣化・保全情報は、状態変更、再キャリブレーション、保全イベント、モデル再同定などを契機に更新します。運用ログは最新値への上書きではなく、後から時系列を再現できる記録として保存します。

つまり、問うべきなのは「何Hzで同期するか」だけではありません。何の時刻を表すデータか、どの値を正当な実機状態とみなすか、遅延や欠損が起きたときどう扱うかを、データクラス別の同期契約として明文化することが重要です。

なぜ同期粒度が重要か

ISO 23247は、製造要素、デジタルツイン、サービスや利用者の関係を整理する参照枠組みを示しています。一方で、すべてのロボットやデータに共通する同期周期を規定しているわけではありません。ロボットの制御周期、通信構成、シミュレータ、利用目的によって適切な粒度は変わります。

また、文献によってデジタルモデル、デジタルシャドウ、デジタルツインの区分も異なります。一般には、実体からデジタル側への一方向のデータ連携と、デジタル側から実体への自動反映を含む双方向連携を区別します。監視のための読み取りと、実機へ影響を与える書き戻しを同じ経路で扱うと、権限や安全性の境界が曖昧になります。

四つのデータクラスに分ける

制御・安全状態

関節状態、ベース状態、インターロックなどは、シミュレーションの状態推定や安全判断に直接影響します。値には取得時刻とシーケンス番号などの順序情報を付け、受信時刻だけで実機状態の時刻を表さないようにします。

OPC UAのデータモデルにあるSourceTimestampとServerTimestampのように、値が生成された時刻とサーバーが受け付けた時刻を分ければ、通信遅延や到着順を分析できます。

環境・シーン情報

周囲の物体、作業空間、配置、経路などは、制御状態と同じ周期で送る必要があるとは限りません。配置変更やシーン再構成をイベントとして同期し、シミュレーション側では、どの時点の環境を表す情報かを保持します。

モデル・保全情報

ロボットの形状、質量、摩擦などのパラメータ、再キャリブレーション結果、劣化状態、保全履歴は、モデル再同定や保全イベントを更新トリガーにします。高頻度に送るより、変更理由、適用範囲、バージョンを管理する方が、検証と保全に向いています。

運用ログ

運用ログには、実機側の取得時刻、受信時刻、クロックの種類、シーケンス番号、通信状態、モデル・設定バージョンを残します。シミュレーション入力用のデータと、改変しない原記録を分離すれば、再生検証と監査に利用できます。

flowchart LR
  subgraph Physical["実機"]
    Sensor["センサー・計測"]
    Controller["制御器"]
    RobotState["関節・姿勢・トルク・安全状態"]
    Scene["環境・シーン情報"]
    Model["モデル・保全情報"]
    Events["イベント・運用ログ"]
    Sensor --> RobotState
    Controller --> RobotState
    Scene --> Events
    Model --> Events
    RobotState --> Events
  end

  subgraph Ingest["収集・記録"]
    Collector["データ収集"]
    Timestamp["時刻・順序付与\nSourceTimestamp / ServerTimestamp / シーケンス番号"]
    RawLog["不変の原記録\n取得時刻・受信時刻・通信状態・版情報"]
    Collector --> Timestamp
    Timestamp --> RawLog
  end

  subgraph Gate["同期契約・判定"]
    Contract["データクラス別の同期契約\n更新トリガー・鮮度上限・欠損時動作・権威性"]
    QoS["QoS判定\nReliability・Deadline・Durability・History・Liveliness"]
    Freshness["鮮度・順序・版の検査"]
    Contract --> QoS --> Freshness
  end

  subgraph Twin["シミュレーション"]
    SimInput["シミュレーション入力"]
    SimTime["シミュレーション時刻"]
    Sim["デジタルツイン"]
    SimInput --> SimTime --> Sim
  end

  RobotState --> Collector
  Scene --> Collector
  Model --> Collector
  Events --> Collector
  Timestamp --> Contract
  Timestamp --> RawLog
  Freshness --> SimInput
  RawLog --> Replay["再生・監査・再現検証"]
  Sim --> CommandGate["コマンドゲート\n認証・認可・妥当性検査・範囲制限・監査"]
  CommandGate -. "双方向反映が必要な場合のみ" .-> Controller

データクラスごとに時刻、順序、鮮度、QoS、権威性を検査し、シミュレーション入力と改変しない原記録を分離する同期構成。

時刻と実行方式を分ける

シミュレーション時刻は壁時計時刻と同一ではありません。ROS 2ではシステム時刻、安定した経過時間を扱う時刻、ROS時刻を区別でき、シミュレーション時には/clockでROS時刻を提供できます。ROS時刻は一時停止、速度変更、時刻ジャンプの影響を受けるため、受信時刻や単調増加する経過時間と混同しない設計が必要です。

ロボットの電力制約をタスク計画へ反映する：3層設計の考え方

Wed, 14 Oct 2026 13:39:56 +0900

電池残量を計画に組み込むとき、どこまで細かくモデル化すべきかが設計上の焦点になります。

結論

ロボットの電力制約は、単一の計画器に集約せず、タスク割り当て、経路・作業単位のエネルギー計画、実行時の再計画という3層に分けて設計するのが妥当です。上位層では、タスクの消費量だけでなく、終了後に充電地点や待機地点へ戻るエネルギー、充電時間、安全余裕を含めて実行可能性を判断します。中位層では、距離だけでなく速度、加減速、勾配、床面、積載量、停止回数、センサーなどの補機負荷を区間ごとに見積もります。下位層では、SOC、電流、温度、実測消費を取り込み、予測との差に応じて計画を更新します。

SOCや残量パーセントだけでタスクを選ぶと、残量表示は十分でも帰還できない、負荷変動で作業途中に停止する、といった問題を扱いにくくなります。一方、すべてを高精度な電池モデルで計画する必要もありません。機体や運用環境に応じて、上位は粗く、中位は必要な作業単位で、下位は実測に反応できる粒度に分けることが判断の基本です。

なぜ残量表示だけでは不十分か

ROS 2のBatteryStateメッセージは、電圧、電流、充電量、容量、設計容量、残量パーセント、電源状態、健全性、セル電圧などを扱います。計画器が参照する電池状態も、SOC単独ではなく、利用可能容量や電源状態、健全性を含む状態ベクトルとして定義できます。

ただし、SOCは直接観測する値ではありません。クーロンカウント、電圧、電流、電池モデルなどを組み合わせて推定され、電池モデルと拡張カルマンフィルタを用いる方法もあります。負荷条件やモデル誤差によって推定値は変わるため、SOCをそのまま「今後使えるエネルギー」とみなすのは危険です。百分率、正規化容量、実容量、利用可能容量は実装によって意味が異なる場合もあります。

3つの計画粒度

1. タスク割り当て層

搬送や巡回などのタスクをどのロボットに割り当てるかを決める層です。判定には、タスクそのものの予測消費量、終了後の帰還エネルギー、充電に要する時間、予測誤差を吸収する安全余裕を含めます。

「SOCが閾値以上なら割り当てる」という方式では、帰還経路や充電待ち時間を評価できません。複数台を運用する場合は、充電器の競合や代替ロボットの有無も判断材料になります。Open-RMFでは、フリートの状態、走行、タスク、充電を運用モデルの一部として扱い、電池容量、消費、充電、状態変化を扱う関連パッケージも提供されています。

2. 経路・作業単位のエネルギー計画層

タスクを経路や作業区間に分け、各区間のエネルギーコストを予測します。距離または時間に比例させるモデルは実装しやすい一方、速度、加減速、勾配、床面、積載量、停止回数、センサーやマニピュレーターの負荷を表現しにくい制約があります。

移動ロボットの運動計画では、距離や時間だけでなくエネルギー消費を目的関数に含める考え方があります。最短経路と最小エネルギー経路は一致しない場合があるため、経路評価を距離だけに固定しないことが重要です。環境と負荷が安定しているなら距離・時間比例モデルから始め、影響が大きい条件を実測データや電池モデルで段階的に追加します。

3. 実行時制御・再計画層

タスク開始時に電力計画を固定すると、実際の電流、温度、積載状態、路面が予測と異なった際に破綻します。実行層では、現在のSOC、電流、温度、実測消費を取り込み、残タスク、経路、充電判断を再評価します。

再計画の契機は、実測消費が予測を上回った、帰還用リザーブを下回る見込みになった、充電器の利用状況が変わった、といった状態変化です。下位層は安全停止や低電力動作への移行を担い、上位層はタスク中断、再割り当て、充電後の再開を担うように責務を分けます。普遍的な再計画周期は確認できないため、機体の応答性と予測誤差に合わせて決めます。

flowchart LR
  S["電池・運用状態"] --> A
  A["タスク割り当て層\nタスク、充電、帰還余裕、予測誤差を評価"] --> B
  B["経路・作業単位のエネルギー計画層\n速度、加減速、勾配、床面、積載量、補機負荷を考慮"] --> C
  C["実行時制御・再計画層\nSOC、電流、温度、実測消費を短周期で監視"]
  C --> D["実行・走行・作業"]
  D --> E["実測値と予測誤差"]
  E --> C
  C -->|"帰還余裕低下・予測超過・充電状況の変化"| A
  A --> F["充電または待機の判断"]
  F --> G["充電後のタスク再開・再割り当て"]
  G --> A

タスク割り当て層は充電と帰還余裕を含めて仕事の実行可能性を判断し、経路・作業層は区間エネルギーを予測し、実行層は実測値と予測誤差を使って再計画します。

図では、タスク割り当て層が充電と帰還余裕を含めて仕事を選び、経路・作業層が区間エネルギーを予測し、実行層が実測値で予測を更新する循環を示します。

設計方式の比較

方式	主な入力	長所	制約
残量パーセント中心	SOC、電源状態	実装と監視が容易	負荷、温度、劣化、帰還エネルギーを表しにくい
状態ベクトル中心	電圧、電流、SOC、容量、健全性など	電池状態を多面的に扱える	推定誤差と各項目の定義管理が必要
距離・時間比例モデル	距離、走行時間	初期実装が簡単	速度、勾配、積載、補機負荷への対応が限定的
物理・電池モデル	電流、電圧、温度、負荷	条件変化を反映しやすい	モデル化と校正のコストが高い
実行時再計画	実測消費、SOC、残タスク	予測ずれに対応できる	再計画の契機と安全動作が必要

充電判断と実装の進め方

最初の実装では、タスクごとのエネルギー予算、帰還用リザーブ、充電開始条件、緊急停止または低電力モードへの移行条件を分離すると扱いやすくなります。これらを1つの閾値にまとめると、通常の充電判断と安全上の限界が混同されます。まず距離や作業時間から予算を置き、実測データでモデルを校正する構成が現実的です。

異種ロボットを同じ現場で動かすフリート連携：タスクAPI・交通管制・設備接続の分離

Mon, 12 Oct 2026 14:44:01 +0900

異なるメーカーのロボットを同じ現場で動かすとき、標準プロトコルだけで全てが解決するのかが設計上の焦点になります。

先に結論

複数メーカーのAMRや搬送ロボットを同じ現場で運用するには、単一の巨大なAPIへ機能を集約するのではなく、業務タスク、フリート・交通管制、ロボット固有の実行、設備接続を別レイヤーに分けることが基本です。VDA 5050などの標準は、上位の制御システムとロボットを接続するアダプターの境界で使い、メーカー差分をアダプター内に閉じ込めます。

ドア、エレベーター、コンベヤーなどは、タスク層からPLCやメーカー固有コマンドを直接呼び出さず、設備アダプターを介して共通リソースとして公開します。通路や交差点を複数フリートが共有する場合は、予約と交通管制の権限を一つの調停主体へ集約する構成を有力な候補として検討します。

なぜインターフェースを分けるのか

WMSやMESなどの業務システムが扱うのは、搬送、ピッキング、充電といった業務要求です。ロボットの走行には、機体の能力、地図、経路、状態、手動介入などの情報が必要になります。さらに複数フリートが同じ空間を共有する場合は、通路、交差点、ステーション、エレベーターの予約と交通協調が必要です。

設備も単純な「開ける」「呼び出す」コマンドではありません。利用要求、予約またはリース、使用開始、完了、解放、タイムアウト、異常という状態を持つ共有資源です。業務アプリケーションと機器を直結すると、メーカー変更や設備更新の影響が上位の業務ロジックまで及びます。

標準技術の役割

VDA 5050は、上位のMaster ControlとAGV・AMRの間の通信インターフェースを定義し、MQTTを介してJSON形式のメッセージを交換します。2.0.0相当の仕様では、NodeとEdgeによる経路表現やAction、注文識別子を含むOrder、State、InstantActions、Visualization、Factsheetなどを扱います。ただし、現場全体で誰が最終的な交通管制権限を持つかまでは一律に決めません。

Open-RMFは、複数のロボットフリートや建物設備を協調させる枠組みです。ベンダーごとのFleet ManagerをFleet Adapterで接続し、RMF側の要求や交通協調の情報を各フリート固有APIへ変換するとともに、ロボットの状態や進捗をRMFへ戻します。

MassRobotics AMR Interoperability Standardは、AMRの位置、状態、バッテリーなどを、他のAMRや周辺システムと共通形式で共有することを主な対象とします。注文を送り実行させるVDA 5050と、完全に同じ範囲ではありません。

MQTTは軽量なPublish/Subscribe型プロトコルで、トピックやQoSなどの配送機能を定義しますが、ロボットタスクや設備占有の意味論は定義しません。OPC UAは情報モデル、サービス、クライアント・サーバー通信、PubSubなどを定義するため、設備側の共通インターフェースを構築する基盤候補です。ただし、設備が必要な情報モデルや仕様を実装しているかは個別確認が必要です。

推奨アーキテクチャ

最上位にWMS、MES、または業務オーケストレーターを置き、その下にタスク正規化層を設けます。ここではタスク識別子、搬送元・搬送先、必要な能力、優先度などを扱います。

次に交通・リソース調停層を配置します。共有通路、交差点、ステーション、エレベーターの予約を管理し、各フリートへ利用許可や交通上の要求を伝えます。ローカル制御だけで共有資源を扱う場合は、競合解決の方法と責任境界を明示します。

その下にメーカー別Fleet Adapterを置き、共通タスクや交通上の要求をVDA 5050、ベンダー独自API、または対象フリートの実装へ変換します。ロボット固有の走行制御、状態、Action、手動介入の差は、この境界で吸収します。

設備側には設備リソースAPIと設備アダプターを置きます。設備リソースAPIは、ドアやエレベーターを共有資源として公開し、その下でOPC UA、MQTT、PLC接続、メーカー独自インターフェースを設備ごとに扱います。

flowchart TB
  subgraph business["業務層"]
    WMS["WMS・MES・業務オーケストレーター"]
  end

  subgraph common["共通制御・正規化層"]
    TASK["タスク正規化層\nタスクID・搬送元/先・能力・優先度・期限"]
    TRAFFIC["交通・リソース調停層\n共有通路・交差点・ステーション・エレベーター"]
    RESOURCE["設備リソースAPI\n要求・予約・占有・完了・解放・異常"]
  end

  subgraph fleet["ロボット連携層"]
    FA1["メーカー別Fleet Adapter A"]
    FA2["メーカー別Fleet Adapter B"]
    VDA["VDA 5050またはベンダー独自API"]
    ROBOT1["ロボットフリート A"]
    ROBOT2["ロボットフリート B"]
  end

  subgraph equipment["設備接続層"]
    EA["設備アダプター"]
    CONNECT["OPC UA・MQTT・PLC接続・設備固有インターフェース"]
    DEV["ドア・エレベーター・コンベヤーなど"]
  end

  WMS --> TASK
  TASK --> TRAFFIC
  TASK --> FA1
  TASK --> FA2
  TRAFFIC --> FA1
  TRAFFIC --> FA2
  FA1 --> VDA
  FA2 --> VDA
  VDA --> ROBOT1
  VDA --> ROBOT2
  TRAFFIC --> RESOURCE
  TASK --> RESOURCE
  RESOURCE --> EA
  EA --> CONNECT
  CONNECT --> DEV

業務タスク、共有空間の交通・リソース調停、メーカー別ロボット実行、設備接続を別レイヤーに分離した推奨構成。

設備利用の流れは、要求、予約またはリースの取得、ロボットの到着、使用開始、完了、解放です。到着できない、設備が応答しない、通信が切れるといった場合は、タイムアウトや異常として通知し、占有をいつ解放するかを定義します。

ロボットソフトウェアの安全なOTA設計：互換性・段階展開・ロールバックの実践

Wed, 07 Oct 2026 14:41:10 +0900

ロボットの更新では、配布できたことと安全に復旧できることを分けて考える必要があります。

結論

ロボットのOTAを安全にするには、イメージの署名検証だけでは不十分です。機体互換性をマニフェストで定義し、サーバーと機体の双方で適用可否を確認したうえで、少数のカナリアから段階展開します。さらに、起動後のセンサー、アクチュエータ、通信、バッテリー、制御ループなどをヘルスゲートとして監視し、異常時には許可された既知の正常版へ戻せるようにします。

復旧方式としては、対応するブートローダーとストレージ構成がある場合、A/Bまたはデュアルバンクが有力です。ただし、運用上のロールバックと、脆弱な旧版へのダウングレードを防ぐアンチロールバックは別の制御として設計しなければなりません。

なぜ機体互換性が難しいのか

同じ製品系列のロボットでも、ハードウェアリビジョン、接続されたセンサーやアクチュエータ、MCUファームウェア、OS、ブートローダーが異なることがあります。アプリケーションが起動しても、通信プロトコルやファームウェアABIが合わなければ、制御系全体を正常に動かせるとは限りません。

また、アプリケーションだけを旧版へ戻しても、設定・データスキーマの移行、ブートローダー更新、他ECUとのプロトコル変更が残れば復旧は不完全です。OTAの単位は単一バイナリではなく、依存関係と適用順序を含むリリースとして定義する必要があります。

互換性契約をマニフェスト化する

更新マニフェストと機体インベントリを比較し、適用対象を限定します。契約に含める項目は、少なくとも次のように整理できます。

製品系列、機体モデル、機体識別子
ハードウェアリビジョン、センサー・アクチュエータ構成
ブートローダー、OS、カーネル、ファームウェアABI
接続ECUと通信プロトコル
更新対象コンポーネント、依存関係、適用順序
設定・データスキーマ
シーケンス番号、最低限必要なセキュリティバージョン

RFC 9124は、ベンダーID、クラスID、コンポーネント、依存関係、シーケンス番号、条件、検証アルゴリズムなどをマニフェストで表す情報モデルを定義しています。Uptaneは、一般的な更新情報と、個別の車両やECUに対する適用指示を分離する構成を示しています。

サーバー側では属性やインベントリによって対象を絞り込み、機体側でも受信後に再検証します。サーバーの選定だけに頼ると、古いインベントリや誤登録による誤配布を止められません。

flowchart LR
  A["更新イメージとマニフェストを生成"] --> B["署名・ハッシュ・メタデータを検証"]
  B --> C["サーバー側で対象機体を選定"]
  C --> D["機体側でインベントリと互換性契約を再検証"]
  D -->|"不一致"| X["インストール拒否"]
  D -->|"一致"| E["更新前の安全条件を確認"]
  E --> F["カナリア機へ展開"]
  F --> G["起動後ヘルスゲート"]
  G --> H{"異常があるか"}
  H -->|"いいえ"| I["次のコホートへ拡大"]
  I --> J{"全コホート完了か"}
  J -->|"いいえ"| F
  J -->|"はい"| K["展開完了"]
  H -->|"はい"| L["新規展開を停止"]
  L --> M["許可された既知の正常版へロールバック"]
  M --> N["復旧状態を確認"]
  N -->|"復旧"| O["再開または中止を判断"]
  N -->|"未復旧"| P["リカバリー手順へ移行"]

署名検証だけでなく、互換性契約、更新前後の安全条件、段階展開、ヘルスゲート、ロールバックを組み合わせるOTAの全体フロー。

署名だけに依存しない検証

安全なOTAは、未承認変更を防止する、変更を検出する、信頼できる状態へ復旧する、という多層構成で考えます。NIST SP 800-193は、プラットフォームファームウェアの保護をprevent、detect、recoverの三機能で整理しています。これはロボットの物理安全全体を直接規定するものではありませんが、更新設計の基本的な分解として利用できます。

ロボット制御を実機に合わせる：アクチュエーター制約をモデル化して計画へ反映する方法

Mon, 05 Oct 2026 14:22:52 +0900

実機でだけ現れる追従誤差は、制御器の調整不足だけでなく、制約の表現方法にも原因があります。

結論：制約は一つの上限値にまとめない

ロボットの軌道がシミュレーションでは追従できるのに、実機では誤差が増えたり停止したりする場合、アクチュエーターの非理想特性を層ごとに分けて扱う必要があります。基本となる流れは、指令値、量子化、出力制限、伝達機構、実機状態を分離してモデル化し、シミュレーターと低レベル制御器の両方に同じ制約を適用することです。

上位計画には、位置だけでなく速度、加速度、ジャーク、動力学から得られるトルク制約を入れます。さらに、量子化による誤差やバックラッシュの不確実性は、安全余裕、方向反転の回避、またはロバストな可到達集合として反映します。

問いが重要な理由

幾何学的に正しい経路でも、時間の割り当てが速すぎれば、必要なトルクや加速度が実機の能力を超えます。また、指令値を細かく変化させても、通信や制御テーブルの分解能を下回れば、実際の出力は変化しません。減速機などにバックラッシュがあれば、方向を反転した直後の指令が出力軸の運動に直結しないこともあります。

これらを低レベル制御だけで吸収すると、上位計画が「実行できない軌道」を生成し続けます。制約を計画層まで伝えることで、軌道生成の段階で実行可能性を判定できます。

前提となる用語

飽和は、入力または出力が上限・下限に達し、それ以上増えない状態です。制御入力のクリップ、アクチュエーター内部で生成できる力・トルクの制限、関節へ実際に伝達される力・トルクの制限は、同じものではありません。

量子化は、連続値を有限の刻みで表現する処理です。指令値側とセンサー側を分け、量子化幅、丸めまたは切り捨て、ゼロ次ホールド、サンプリングや遅延を確認します。

バックラッシュは、伝達機構の遊びによって入力と出力の関係が方向依存になる現象です。単純な加法ノイズではなく、入力方向、相対変位、接触状態を持つヒステリシスやプレイ演算子として扱うのが適切です。

内部の仕組み：制約を層に分解する

第一に、コントローラーが生成した指令を量子化します。指令単位が粗い場合、微小な補正は同じ離散値に丸められます。第二に、速度リミッターや電流リミッター、入力範囲の制限を適用します。第三に、アクチュエーターが生成できる力・トルクを制限します。最後に、減速機などの伝達機構を通して関節へ出力される力・トルクを計算します。

この分離が必要なのは、入力をクリップしても、実際の出力トルクが同じ割合で制限されるとは限らないためです。MuJoCoのアクチュエーター機構でも、制御入力、生成力、関節へ伝達される力が別の段階として扱われています。一方、標準的なロボット制御インターフェースでは、位置・速度・加速度・ジャーク・努力量などは扱えても、量子化幅やバックラッシュ状態まで標準化されているとは限りません。伝達機構とハードウェア固有の非線形性は、追加のモデルとして実装します。

計画側では、経路上の位置を時間パラメータ化し、速度・加速度と動力学的なトルク制約を同時に評価します。時間スケーリングを遅くすれば、必要トルクが下がる場合がありますが、速度依存の限界や制御遅延があるため、単純に低速化すれば十分とは限りません。

flowchart LR
  P["上位計画"] -->|"位置・速度・加速度・ジャーク・トルク制約を適用"| T["時間パラメータ化された軌道"]
  T --> C["低レベル制御器"]
  C --> Q["指令値量子化"]
  Q --> R["速度・入力範囲の制限"]
  R --> E["電流・努力量の制限"]
  E --> A["アクチュエーターの生成力・トルク制限"]
  A --> B["バックラッシュ・伝達機構モデル"]
  B --> J["関節出力"]
  J --> M["実機状態"]
  M --> S["センサー量子化・サンプリング・遅延"]
  S --> C
  M --> I["実機同定・検証"]
  I -.->|"制約値と不確実性を更新"| P
  I -.->|"層ごとのモデルを更新"| Q

制約を入力、アクチュエーター、伝達機構、観測の層に分け、同じモデルを計画器と低レベル制御器に反映する流れ。

計画に反映する選択肢

対象	推奨するモデル	上位計画への反映
連続トルク限界	通常運転で継続可能な値	基本の動力学制約として使用
短時間ピーク限界	時間や条件付きの上限	短い区間に限定し、連続値と分離
指令値量子化	指令単位、丸め、保持	微小な指令変化を実行可能とみなさない
センサー量子化	観測値の刻みと更新周期	状態推定の不確実性や余裕に反映
バックラッシュ	プレイ演算子、ヒステリシス、伝達機構モデル	方向反転回避、余裕、ロバスト計画
温度・電圧・速度依存	条件ごとの限界値	運転状態に応じて保守的な制約を選択

制約値は、定格値、連続許容値、短時間ピーク値を区別します。メーカーが示す最大トルクや最大電流は瞬間的なピーク値の場合があり、計画にそのまま使うと連続運転で余裕を失う可能性があります。通常の計画には、同定誤差と制御遅延を含む保守的な連続許容値を使い、ピーク値は時間や条件を限定して扱います。

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

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に加え、長期的なマッピング、既存地図を用いたローカライゼーション、地図・ポーズグラフの保存と再利用を扱うソフトウェアとして提供されています。ただし、どの変化を恒久地図へ昇格させるかは、利用側のポリシーとして定義する必要があります。

学習ベースのロボット機能を説明可能にする安全ケースの作り方

Thu, 01 Oct 2026 14:38:11 +0900

学習モデルの評価結果を、現場で成立する安全の説明へどう接続するかが気になるテーマです。

結論

学習ベースのロボット機能の安全ケースは、AIモデル単体の精度を証明する文書ではありません。最上位に「定義した運用範囲と制約の中で、対象機能が許容可能な安全性を満たす」という主張を置き、危険源、安全目標、安全要求、実装上の防護、検証結果、残留リスク、運用監視へ分解します。

各主張は、要求仕様、データセット、モデル、ソフトウェア構成、テスト条件、判定結果、運用記録へ追跡できるようにします。学習モデルを安全機能上の唯一の防護層とせず、異常時に停止、減速、退避などの安全側状態へ移行できる仕組みを含めることが基本です。

なぜモデル単体の評価では不十分か

ロボットの危険は、認識モデルの出力だけで決まりません。対象物、人との距離、作業空間、速度、力、照明、センサー、通信、ソフトウェア構成などが組み合わさって、実際のリスクになります。平均精度やテストデータ上の結果だけでは、どの環境で、どの失敗が起こり得て、失敗時に何が動作を制限するのかを説明できません。

ISO 12100:2010は、意図する使用と合理的に予見可能な誤使用を含む機械の限界を定め、危険源の同定、リスクの見積もり・評価、リスク低減を反復する一般原則を示しています。学習機能を含む場合も、まずこの分析を出発点にし、AI固有の不確実性、データやモデルの変更、導入後の監視をライフサイクルへ接続します。

安全ケースを構成する枠組み

安全ケースとは、安全性に関する主張と、それを支える論拠・証拠を構造化したものです。GSN（Goal Structuring Notation）では、ゴール、戦略、コンテキスト、前提、証拠などを用いて、主張がどの条件で成立するかを表します。ただし、GSN自体はモデル精度や残留リスクの合格値を定めません。

参照する枠組みの役割は分けて扱います。ISO 12100は機械の危険源分析とリスク低減、IEC 61508は安全関連の電気・電子・プログラマブル電子システムの安全ライフサイクルや検証、ISO 10218-1:2011は産業用ロボットの安全要求を扱います。NIST AI RMF 1.0はGovern、Map、Measure、Manageの4機能でAIリスク管理を整理し、ISO/IEC 23894:2023はAIのリスク特定、分析、評価、処置、監視のガイダンスを示します。

これらは同じ適用範囲の規格ではありません。AIリスク管理の文書は一律の合格閾値や認証を定めず、ISO 10218-1もサービスロボットや移動ロボット、特定の学習機能へそのまま適用できるとは限りません。対象機械、用途、法域、国内採用版との対応を確認する必要があります。

最上位主張から証拠まで分解する

実務では、次の順に整理するとレビューしやすくなります。

運用範囲と前提：許容される環境、対象物、人との距離、速度・力の上限、センサー状態、通信条件、モデルの適用範囲を定める。
危険源と安全目標：誤認識、制御の逸脱、センサー異常、通信断、適用範囲外の入力などを危険源として整理し、避けるべき危害や安全目標へ結び付ける。
安全要求：機能要求、性能要求、環境制約、フェイルセーフ要求、監視要求、変更管理要求を記述する。
実装上の防護：学習モデル、制限器、監視器、安全関連制御系、停止・減速・退避などが、どの要求に対応するかを明確にする。
検証と妥当性確認：要求ごとに方法、条件、合格基準、結果を記録する。解析、単体試験、シミュレーション、シナリオ試験、実機試験、故障注入などを要求の性質に応じて使い分ける。
残留リスクと運用監視：残った前提、監視指標、インシデント対応、再評価条件、変更時の停止条件を明示する。

これは各規格が定める一律の文書一覧ではなく、対象システムに合わせた実務上の構成方法です。

flowchart TD
  G["最上位主張：定義した運用範囲と制約の中で、機能が許容可能な安全性を満たす"]
  C["運用範囲・前提：環境、対象物、人との距離、速度・力、照明、センサー、通信、モデル適用範囲"]
  H["危険源と安全目標：誤認識、制御逸脱、センサー異常、通信断、適用範囲外入力"]
  R["安全要求：機能、性能、環境制約、フェイルセーフ、監視、変更管理"]
  P["実装上の防護：学習モデル、制限器、監視器、安全関連制御系、停止・減速・退避"]
  V["検証・妥当性確認：単体試験、シミュレーション、シナリオ試験、実機試験、故障注入、解析"]
  L["残留リスクと運用監視：前提、監視指標、インシデント対応、再評価条件、変更時の停止条件"]
  E["証拠：試験結果、解析記録、要求との対応、構成管理情報"]
  G --> C
  G --> H
  H --> R
  C --> R
  R --> P
  R --> V
  P --> V
  V --> E
  V --> L
  L --> E

安全ケースを、成立条件と防護、検証、残留リスク、証拠まで追跡可能な形に分解した構造です。GSN風の概念図であり、特定の合格基準を定めるものではありません。

トレーサビリティを証拠の中心に置く

検証結果を安全ケースの証拠として利用するには、その結果を生んだ構成を固定できなければなりません。要求仕様、データセット、ラベル、モデル、ソフトウェア、推論ハードウェア、テスト条件、判定結果をライフサイクル成果物として版管理し、相互に追跡可能にします。ISO/IEC 5338:2023は、AIシステムの概念化、開発、検証・妥当性確認、導入、運用、保守、廃止を含むライフサイクルプロセスを扱います。

ロボットの幾何キャリブレーション実践：関節誤差・工具座標・カメラ座標をどう校正するか

Wed, 30 Sep 2026 14:21:31 +0900

ロボットの位置ずれは、単一の補正値だけでは説明できないことが多い点が気になります。

先に結論

ロボットの位置決め精度を改善するには、最初にベース、関節、フランジ、工具、カメラ、対象物の座標系と変換方向を定義する。そのうえで、関節オフセット、リンク幾何、工具先端点（TCP）、カメラ内部パラメータ、ハンドアイ変換を別々の誤差源として校正する。推定には十分な姿勢分布と外部計測器を用い、校正に使っていない姿勢で位置決め精度と繰返し精度を検証することが基本である。

校正後の性能は、平均誤差だけで判断してはならない。最大誤差、試行間のばらつき、位置と姿勢の誤差、温度・荷重・速度、計測不確かさを併記し、対象工程の許容差と照合する必要がある。

なぜ誤差を分解するのか

指令した工具位置と実際の位置がずれる原因には、関節のゼロオフセット、リンク長・ねじれ・関節配置、フランジから工具先端までのTCP、カメラの内部パラメータ、ロボットとカメラの外部関係などがある。これらは異なる座標変換や観測量に関係するため、一つの補正値にまとめると別の姿勢で誤差が再び現れやすい。

たとえばTCPの誤差をリンクパラメータへ吸収すると、校正に使った姿勢では残差が小さくても、工具の向きを変えたときにずれが現れる可能性がある。カメラのレンズ歪みをハンドアイ変換で補正する場合も、誤差源の管理が不明確になる。誤差の種類ごとに推定・保存・検証することが再利用の前提となる。

座標系と運動学モデル

まず、各座標系の名称、親子関係、単位、変換行列の向きを記録する。ベースから関節列、フランジ、TCPへ至る関係に加え、カメラがフランジに取り付くeye-in-handか、作業空間に固定されるeye-to-handかも明示する。対象物やワールド座標系についても、どの座標からどの座標へ変換するかを定義する。

運動学モデルには標準DH、修正DH、指数積形式などがある。同じ「リンク長」や「ねじれ」という名称でも、モデルが違えばパラメータの意味や符号は一致しない。したがって、数値だけを別のコントローラやソフトウェアへ移植してはならない。座標系規約、DH規約、単位、カメラ内外部パラメータの定義、コントローラとソフトウェアのバージョンを一緒に管理する。

内部の仕組み：モデルと実測の差を推定する

幾何キャリブレーションでは、関節角から順運動学モデルが予測する工具位置と、外部計測器が測定した実位置との差を残差として扱う。複数の姿勢について残差を集め、関節ゼロオフセットやリンク幾何などの未知パラメータを含むモデルを、最小二乗推定などで調整する。

姿勢が似ていたり、狭い作業範囲に偏っていたりすると、関節オフセットとリンク幾何誤差が相互に代償する。校正データ上の残差が小さくても、未使用の姿勢で誤差が増えることがある。推定したいパラメータが観測に現れるよう、作業領域全体から姿勢を分布させることが必要だ。

カメラ内部校正はロボット運動学とは分けて行う。焦点距離、主点、レンズ歪みは、平面パターンを複数の姿勢から撮影して推定できる。次に、フランジ装着カメラとロボットの関係、または固定カメラとロボットベースの関係をハンドアイ校正で求める。これは相対運動から剛体変換を推定するAX=XB型の問題として表せるが、eye-in-handとeye-to-handでは行列の定義と変換方向が異なる。式を流用せず、座標系の定義に合わせて確認する。

TCPはフランジ座標系から工具座標系への変換として扱う。リンク幾何やカメラ外部パラメータへ混ぜず、工具姿勢を変えても同じTCPが対象点を表すかを独立に確認する。

flowchart LR
  B["ベース座標系"] -->|"順運動学"| J1["関節1"]
  J1 --> J2["関節2 … 関節列"]
  J2 --> F["フランジ座標系"]
  F -->|"T_フランジ→TCP"| TCP["工具座標系（TCP）"]

  F -->|"取り付け関係・ハンドアイ変換"| CEH["カメラ座標系\neye-in-hand"]
  B -->|"ベース→カメラ外部変換"| CETH["カメラ座標系\neye-to-hand"]

  W["ワールド座標系"] -->|"対象物の配置"| T["対象物座標系"]
  CEH -->|"画像観測"| T
  CETH -->|"画像観測"| T

  K["カメラ内部パラメータ\n焦点距離・主点・歪み"] --> CEH
  K --> CETH
  N["各変換の向き・単位・規約を文書化"] -.-> B
  N -.-> TCP
  N -.-> CEH
  N -.-> CETH

ロボットの幾何キャリブレーションでは、関節列からTCPまでの運動学、カメラ内部パラメータ、カメラ外部変換、対象物との関係を分けて管理し、各変換の向きと単位を明示する。

校正対象と確認方法の比較

対象	推定・管理するもの	主な観測・計測	検証時の着眼点
関節オフセット	関節角の基準ずれ	外部計測した複数姿勢	姿勢に依存する系統ずれ
リンク幾何	長さ、ねじれ、配置	外部計測器と運動学モデル	作業領域全体の残差傾向
TCP	フランジから工具先端への変換	工具姿勢を変えた先端位置	姿勢変更時の先端ずれ
カメラ内部	焦点距離、主点、歪み	複数姿勢の平面パターン画像	画像位置の系統誤差
ハンドアイ外部	カメラとフランジまたはベースの変換	相対運動とカメラ観測	構成と変換方向の整合
非幾何要因	たわみ、温度、バックラッシなど	条件を変えた独立計測	姿勢・方向・時間への依存

実務での校正手順

切り分けを重視するなら、次の順序が扱いやすい。

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

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シーン内の空間関係を使って候補集合を作り、候補が一意になるかを確認します。

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

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

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

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

ロボットAIの検証パイプライン：シミュレーションからHIL・実機試験へ移す方法

Sat, 05 Sep 2026 09:21:36 +0900

実機を使わずに検証できる範囲を広げるほど、実機でしか分からない差分を見落とさない設計が重要になります。

先に結論

ロボットAIの検証は、シミュレーション、Hardware-in-the-Loop（HIL）、管理された実機試験の順に段階化するのが基本です。シミュレーションで大量のシナリオを反復し、HILで実時間性やI/O、ドライバ、計算負荷を確認し、その後に実機でセンサー較正、接触、電源、通信、安全挙動を検証します。

ただし、これは一方向に進む固定工程ではありません。変更がハードウェアや安全機能に関係する場合はHILや実機試験を前倒しし、失敗時にはシミュレーションやソフトウェア統合テストへ戻るフィードバックループを設けます。判断の軸は、変更のリスク、実機との差分、再現性、安全要求です。

なぜ三つの段階を分けるのか

実機だけで全テストを行うと、設備を占有し、再現性のある大量試験や並列実行が難しくなります。一方、シミュレーションだけでは、実機の遅延やジッタ、センサーの較正状態、機械的な接触・摩擦、電源状態、通信障害を十分に再現できません。

そこで、検証対象を分解します。ソフトウェアの論理や制御方策はシミュレーションで広く確認し、実際の制御ハードウェアとリアルタイムの入出力はHILで確認します。最後に、シミュレーションモデルで表現しにくい物理条件と安全挙動を、管理された実機環境で確認します。

用語と役割

**SIL（Software-in-the-Loop）**は、制御ソフトウェアや複数ノードの統合を、シミュレーション環境で検証する段階です。ROS 2のlaunch_testingのように、複数ノードを起動してプロセス間の相互作用を検証する方法は、CIで実行するソフトウェア統合テストに利用できます。

シミュレーションでは、物理条件、環境、センサー入力を変化させ、再現可能なシナリオを大量に実行します。視覚・環境パラメータを変えるドメインランダム化や、質量、摩擦、遅延などを変えるダイナミクスランダム化は、シミュレーションと現実の差に対するロバスト性を高める手法です。ただし、これらは実機性能や安全性を保証するものではありません。

HILは、少なくとも制御ソフトウェアまたは対象ハードウェアを実機側で動かし、プラント、センサー、アクチュエータなどの一部をシミュレータで置き換える構成です。実際の制御ハードウェアとリアルタイムシミュレーションを接続するため、実時間性、通信、I/O、ドライバ、計算資源を、実機投入前に検証できます。資料によってHILの範囲は異なり、実フライトコントローラを中心に指す場合と、制御ECU、I/O、リアルタイムのプラントモデルを含む全体を指す場合があります。

推奨する検証フロー

変更を起点に、まず高速な単体テストとSILスモークテストを実行します。ここでは、プルリクエストやコミット単位で、制御ロジック、ノード間連携、代表的な異常処理を確認します。次に、広いシナリオ集合を使ったSIL回帰を、夜間または定期的に実行します。環境やセンサー入力を変えたケースを含めることで、単一の正常系だけでは見つけにくい問題を調べられます。

そのうえで、実時間性やハードウェア依存コード、通信プロトコル、センサー・アクチュエータI/O、故障処理、計算資源に影響する変更をHILへ送ります。HILでは、シミュレータからセンサー入力を与え、実際の制御ハードウェアから出力を取り出し、タイミング、通信、I/O、故障注入への応答を確認します。

HILを通過した変更、またはセンサー較正、接触、安全機能、電源、実環境の通信に関係する変更は、実機ベンチへ進めます。安全に関わる試験では、通常の機能回帰とは別のテストスイートとして管理し、保護機構、中止手順、低速・低エネルギー条件、段階的な運用範囲の拡大を紐付けます。

flowchart LR
  A["コミット・変更"] --> B["単体テスト"]
  B --> C["SILスモーク"]
  C --> D["SIL回帰\n大量シナリオ"]
  D --> E["HIL\n実時間性・通信・I/O・故障処理"]
  E --> F["実機ベンチ\n較正・接触・電源・安全挙動"]
  F --> G["限定環境試験\n段階的な運用範囲"]
  B -. "失敗・修正" .-> H["修正・再テスト"]
  C -. "失敗・修正" .-> H
  D -. "失敗・修正" .-> H
  E -. "失敗・修正" .-> H
  F -. "失敗・修正" .-> H
  H --> A
  A -. "変更リスクに応じて前倒し" .-> E
  A -. "安全・接触・実環境に関係" .-> F

検証はSIL、HIL、実機試験へ段階的に進めるが、失敗時やリスクの高い変更時には前段階へ戻るフィードバックループを設けます。

段階ごとの使い分け

段階	主な検証対象	推奨トリガー	強み	主な制約
SILスモーク	制御ロジック、ノード連携、基本的な異常処理	コミット、プルリクエスト	高速、反復可能、CIに組み込みやすい	実機のI/O、遅延、接触を確認できない
SIL回帰	多様な環境・物理条件・センサー入力	夜間、定期実行、リリース前	大量シナリオを低コストで実行できる	モデル誤差が結果に影響する
HIL	実時間性、通信、ドライバ、I/O、計算負荷、故障処理	ハードウェア依存変更、定期実行、リリース前	実制御ハードウェアを含めて再現性を保てる	設備構築が必要で、SILより実行コストが高い
実機ベンチ	センサー較正、遅延・ジッタ、電源、接触、摩擦	リリース候補、安全・接触・実環境に関わる変更	実際の機械・電気条件を確認できる	実行時間、設備、人的安全管理が必要
限定環境試験	実環境での安全挙動と運用範囲	実機ベンチ合格後、段階的に実施	現場条件での挙動を確認できる	リスク管理と中止手順が不可欠

実機へ進める出口条件

実機試験への移行条件は、単一の性能値で決めるのではなく、検証目的ごとに定義します。少なくとも次の項目を記録します。

ロボット自己位置推定のセンサーフュージョン設計：カメラ・LiDAR・IMUの役割分担

Thu, 13 Aug 2026 01:47:13 +0900

センサーを増やすほど自己位置推定が安定するのか、環境条件から考え直せる点がこのテーマの面白さです。

導入

ロボットの自己位置推定で、カメラ・LiDAR・IMUを常にすべて使えばよいとは限りません。選択の基本は、IMUを短時間の運動伝播に使い、カメラは視覚特徴、LiDARは距離と幾何形状の拘束に使うことです。明るく特徴の多い環境ではカメラ+IMU、暗所や照明変動下で幾何が豊富な環境ではLiDAR+IMUが有力です。視覚と幾何のどちらか一方が失敗しやすく、冗長性も必要なら3センサー構成を検討します。

ただし、センサー数の多さだけで精度が決まるわけではありません。時刻同期、外部パラメータ、座標系、IMUバイアスを整合でき、追加される計算量と実装負荷を許容できることが前提です。

なぜ組み合わせの判断が必要か

自己位置推定は、各センサーの観測を同じ状態推定問題へ取り込む処理です。センサーには得意な時間スケールと失敗条件があります。IMUは高レートですが、バイアスやノイズを積分するため、単独では時間とともにドリフトします。カメラは再観測による相対的な拘束を与えられますが、照明やテクスチャに左右されます。LiDARは照明そのものではなく形状を観測できますが、幾何的に特徴の少ない場所や点群が疎になる条件では位置合わせが退化します。

したがって設計の問いは「どのセンサーが最も高性能か」ではなく、「対象環境でどの観測が残り、どの失敗を別の観測で補えるか」です。

各センサーが提供する情報

IMU：高レートの短期伝播

IMUは角速度と比力を取得し、姿勢・速度・位置の短時間の伝播を支えます。カメラやLiDARの観測間をつなぎ、高速運動時にも状態を更新できる点が役割です。一方、慣性積分だけでは誤差が蓄積するため、カメラやLiDARからの拘束でバイアスと状態を補正します。

カメラ：特徴と外観による相対拘束

カメラは画像特徴の追跡と、外観情報の再観測を利用します。十分な照明、視覚テクスチャ、適度なモーションがある環境では、IMUと組み合わせたVisual-Inertial Odometry（VIO）が機能します。画像特徴を一時的に追跡できない場合でも、IMUが短時間の運動拘束を提供しますが、視覚観測が長く失われれば慣性ドリフトを抑えにくくなります。

LiDAR：距離と幾何による拘束

LiDARは点群の距離・幾何形状を使い、スキャン間またはスキャンと地図の位置合わせを行います。暗所や照明変動の影響を受けにくい環境では、IMUと組み合わせたLiDAR-Inertial Odometry（LIO）が候補になります。IMUは短時間の運動推定だけでなく、点群のモーションデスクューにも利用できます。ただし、広く平坦な場所など幾何的な手掛かりが少ない環境では、LiDARの拘束が弱くなる可能性があります。

flowchart LR
  I["IMU\n角速度・比力"] --> P["高レートの短時間伝播\n姿勢・速度・位置"]
  C["カメラ\n画像特徴・再観測"] --> V["視覚拘束"]
  L["LiDAR\n距離・点群・幾何形状"] --> G["幾何拘束\nスキャン間または地図との位置合わせ"]
  I --> D["点群のモーションデスクュー"]
  D --> G
  P --> E["状態推定器"]
  V --> E
  G --> E
  E --> S["状態・IMUバイアスの補正"]
  E -.-> Q["品質指標の監視\n残差・イノベーションなど"]
  E --> M["推定状態"]
  K["EKF系または因子グラフ・平滑化系"] --> E

IMUによる短時間伝播に、カメラの視覚拘束とLiDARの幾何拘束を組み合わせる概念図。実際の性能や処理順序は実装に依存します。

代表的な構成の比較

構成	主な観測	向く条件	主な失敗条件・負荷
IMU単独	角速度・比力の積分	高レートの短期伝播	バイアスとノイズによるドリフト
カメラ+IMU（VIO）	画像特徴、再観測、慣性	明るく視覚特徴が豊富な屋内外	暗所、照明変動、テクスチャ不足、視覚追跡喪失
LiDAR+IMU（LIO）	点群の距離・幾何、慣性	暗所、照明変動下、幾何が豊富な場所	幾何的特徴の不足、点群が疎な条件
カメラ+LiDAR+IMU	視覚、幾何、慣性	視覚と幾何の一方が失敗しやすい環境、冗長性が必要な長時間運用	計算量、実装・校正負荷、同期や座標整合の複雑化

3センサー構成は、カメラとLiDARの観測が相互補完になるときに意味があります。たとえば照明条件が不安定でも形状が豊富ならLiDARが支え、幾何が一時的に弱くても視覚特徴が残っていればカメラが補います。ただし、3センサーの優位性をあらゆる条件で示す一般的な比較結果があるわけではなく、採用判断は環境、実装、計算資源に依存します。

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["タスク有効性・安全性・再現性を独立指標として判断"]

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

評価項目の比較

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

実機評価プロトコル

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

接触作業のロボット制御設計：インピーダンス制御とアドミッタンス制御の選び方

Mon, 29 Jun 2026 09:02:33 +0900

接触作業の制御方式は、名称よりも信号の流れを見ると選びやすくなります。

先に結論

接触を伴うロボット作業でインピーダンス制御とアドミッタンス制御を選ぶときは、方式名の優劣ではなく、ロボットの下位制御器に何を入力できるか、力・トルクをどのように取得できるかを最初に確認する。トルクまたは電流指令を直接扱え、関節トルクを高い帯域で計測・推定できるなら、インピーダンス制御が自然な候補になる。一方、位置指令を主に扱うロボットに外部6軸力覚センサを組み合わせるなら、測定した力を位置・速度指令へ変換するアドミッタンス制御が実装しやすい。

ただし、接触の安定性や作業の成否は、インピーダンスかアドミッタンスかだけでは決まらない。ロボットと環境の剛性、仮想ダンピング、制御周期、通信・計算遅延、センサの特性、指令の飽和、安全機構を含む閉ループ全体で検証する必要がある。

なぜ選定が難しいのか

組立、研磨、挿入、押し付けでは、対象物に触れた後も手先を動かし続けなければならない。完全な位置制御では、位置誤差や幾何公差によって過大な接触力が発生し得る。そこで、手先の運動と接触力の関係を柔らかく設計する力・運動制御が使われる。

難しさは、同じ「コンプライアンス」や「力制御」という名称でも、実装の信号経路が異なる点にある。文献や製品の説明では、位置制御器を介した外側ループまで広義のインピーダンス制御と呼ぶことがある。そのため、名称ではなく、入力、出力、センサ、内側ループの構成を確認する必要がある。

2つの制御方式の前提

インピーダンス制御は、手先の運動と環境との接触力・トルクの間に、目標質量、ダンピング、剛性で定めた動的関係を実現する制御である。概念的には、目標運動と実際の運動の差から、仮想的なばね・ダンパ・質量に相当する力またはトルクを計算し、それをロボットのトルク系へ渡す。

アドミッタンス制御は逆向きの構成である。測定または推定した外力・外トルクを入力とし、仮想質量、ダンピング、剛性のモデルを通じて、位置、速度、加速度の指令を生成する。その指令を下位の位置・速度制御器へ渡し、ロボットを動かす。外部6軸力覚センサを手先に配置する構成は、この方式と組み合わせやすい。

この違いは、数式上の分類にとどまらない。実務では「力・トルクを出力しやすいか」「運動指令を出力しやすいか」というロボットAPIや内側制御器との適合性が、実装のしやすさを大きく左右する。

flowchart LR
  subgraph IMP["インピーダンス制御"]
    I1["目標運動・状態誤差"] --> I2["仮想質量・ダンピング・剛性"]
    I2 --> I3["力・トルク指令"]
    I3 --> I4["トルク／電流系の下位制御器"]
    I4 --> R1["ロボット"]
  end

  subgraph ADM["アドミッタンス制御"]
    A1["外力・外トルク"] --> A2["外部6軸力覚センサまたは外力推定"]
    A2 --> A3["仮想質量・ダンピング・剛性"]
    A3 --> A4["位置・速度・加速度指令"]
    A4 --> A5["位置・速度系の下位制御器"]
    A5 --> R2["ロボット"]
  end

  R1 --> E["接触環境"]
  R2 --> E
  E -. "接触力・運動のフィードバック" .-> I1
  E -. "外力・外トルク" .-> A1

インピーダンス制御とアドミッタンス制御の概念的な信号方向と、適合しやすい下位制御器の違いを示します。実際の実装では、外力推定、内側ループ、座標変換などの構成が異なる場合があります。

インピーダンスとアドミッタンスの比較

観点	インピーダンス制御	アドミッタンス制御
基本的な関係	運動から力・トルクを生成	力・トルクから運動を生成
主な出力	力指令・トルク指令	位置・速度・加速度指令
適合しやすい下位IF	トルク指令、電流指令	位置指令、速度指令
主な計測・推定	関節トルク、外力推定、手先運動	外部6軸力覚、外力・外トルク推定、手先運動
調整対象	仮想質量、ダンピング、剛性	仮想質量、ダンピング、剛性
典型的な構成	力学特性をトルク制御型ロボットで実現	力覚センサを外側ループに置き、位置・速度制御器へ接続
主な注意点	トルク計測・推定と内側ループの帯域	センサノイズ、遅延、位置指令の帯域
単独方式が不十分な場合	方向別の力・位置制御を追加	方向別の力・位置制御を追加

選定の手順

第一に、利用可能な指令インタフェースを確認する。トルクまたは電流指令を扱えるロボットで、関節トルクの計測・推定が十分に利用できるなら、インピーダンス制御を候補にする。タスク空間で設計した力学特性を関節トルクへ変換できるためである。

ロボットのセンサー異常処理設計：検出から安全な縮退運転まで

Fri, 15 May 2026 01:02:32 +0900

センサーが値を返し続けているときほど、通信監視だけでは異常を見逃しやすい点が気になります。

先に結論

ロボットのセンサー異常は、単一の監視箇所に集約せず、通信・データ取得、値の妥当性、状態推定、センサー間整合性、行動・安全監視の複数層で検出する設計が適しています。各層で観測できる異常が異なるためです。

欠損、異常値、不一致は同じ故障として扱いません。欠損や遅延は鮮度低下、範囲外や急激な外れ値は測定拒否、センサー間不一致は比較と故障候補の隔離として扱います。安全機能を維持できるなら速度や機能を制限し、代替観測が使えなければ停止へ移行します。

なぜ検出層を分けるのか

センサーが停止した場合、メッセージの到着間隔や通信相手の生存性を監視する層で検出しやすくなります。しかし、センサーが値を送り続けていても、固定値や環境に対してもっともらしい誤値を出すことがあります。通信が正常でも、値の意味まで正常とは限りません。

逆に、状態推定層で観測値を拒否できても、複数センサーの不一致や、安全機能に必要な観測が残っているかは別途確認が必要です。異常検出と行動決定を分け、どの層がどの種類の異常を検出したかを診断情報として伝える構成が扱いやすくなります。

前提となる用語

本稿では、欠損をメッセージが届かない、または許容される鮮度を失った状態、範囲外を扱える値域から外れた状態、外れ値を推定状態などから大きく乖離した値、不一致を複数センサーや推定結果が整合しない状態とします。

ROSの診断メッセージ仕様であるREP-107は、診断状態をOK、WARN、ERROR、STALEに分類します。ただし、各状態で停止するか、速度を制限するか、継続するかまでは規定していません。診断状態と行動ポリシーは、システム側で対応付けます。

各層の検出責務

通信・データ取得層

メッセージが期待周期で届くか、通信相手が生存しているかを確認します。ROS 2のDeadline QoSは、連続するメッセージ間の許容最大時間を定義し、期限超過をイベントとして検出できます。Liveliness QoSは、パブリッシャーなど通信相手の生存性を監視します。

これらは到着間隔や生存性を扱う機能であり、値の妥当性やタイムスタンプの意味まで検証するものではありません。

センサー値の妥当性層

型、値域、更新状態、センサー固有の自己診断などを確認し、明らかに利用できない値を上位へ渡さない層です。ただし、範囲内に収まる固定値や誤値は、この検査だけでは十分に検出できません。

状態推定層

推定状態と観測値の差を調べます。robot_localizationの資料では、マハラノビス距離による拒否しきい値を設定し、予測状態から大きく外れたpose、twist、accelerationの測定値を拒否できます。通信が正常でも、推定と整合しない観測を取り込まないための方法です。

整合性・安全監視層

冗長センサーがあれば、複数入力の整合性を比較できます。PX4には、センサーの状態や整合性を監視し、投票で使用センサーを選び、不健全なセンサーを投票から除外し、必要に応じてフェイルセーフへ移行する実装があります。

Nav2 Collision Monitorには、入力が一定時間届かない場合にソースをstaleとして扱い、速度指令の制限や停止へ移行させる実装があります。いずれも特定のソフトウェア構成に依存する実装例であり、すべてのロボットへそのまま一般化できるわけではありません。

flowchart LR
  A["センサー入力"] --> B["通信・データ取得層\n到着周期・生存性・タイムアウト"]
  B --> C["センサー値の妥当性層\n型・範囲・更新状態"]
  C --> D["状態推定層\n予測状態との差・外れ値拒否"]
  D --> E["センサー間整合性監視層\n冗長入力・推定結果の比較"]
  E --> F["行動・安全監視層\n安全機能の可用性を判定"]

  B -. "欠損・遅延・配信停止" .-> G["STALEとして診断"]
  C -. "範囲外" .-> H["異常値を上位へ渡さない"]
  D -. "推定と大きく乖離" .-> I["測定値を推定更新から除外"]
  E -. "センサー間不一致" .-> J["故障入力を隔離・冗長系を検討"]

  F --> K{ "安全機能を維持できるか" }
  K -->|"維持できる"| L["速度・加速度・可動範囲・自律機能を制限"]
  K -->|"代替観測を利用できる"| M["冗長センサーへ切替"]
  K -->|"必要な観測を確保できない"| N["停止"]

  G --> F
  H --> F
  I --> F
  J --> F

センサー異常を単一の監視ノードで判定せず、検出責務を複数層に分けて行動ポリシーへ結び付ける構成を示します。

異常種別と行動の比較

異常の種類	主な検出層	処理の例	行動の例
欠損・到着間隔超過	通信・安全監視	STALE相当として鮮度を評価	速度制限、機能停止、停止
範囲外	値の妥当性	入力から除外	代替入力の検討、継続可否判定
急激な外れ値	状態推定	イノベーションや距離で拒否	推定更新から除外、機能制限
センサー間不一致	整合性監視	比較、故障候補の隔離	冗長系切替、必要なら停止
安全観測の喪失	行動・安全監視	安全機能の可用性を評価	保守的状態、停止

表の状態名と行動の対応は、REP-107の一般規則ではありません。許容時間や安全上の意味を、対象システムごとに定義する必要があります。

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

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

マルチロボットシステムの設計：タスク割り当てと経路調整を分離する方法

Thu, 30 Apr 2026 08:41:28 +0900

複数台のロボットを動かすと、個体の性能だけでなく、共有空間の調整が設計上の焦点になります。

複数台の移動ロボットでは、タスク割り当て、共有空間の交通管制、個体ごとの局所制御を別の層に分けるのが基本です。業務システムが作業の優先度や期限を示し、フリート／タスク管理層が担当ロボットを選び、交通管制層が通路や交差点を予約し、各ロボットがセンサーに基づいて近傍の障害物を回避します。

先に結論

「誰が何をするか」と「どの空間をいつ通るか」は関連していますが、同じ問題ではありません。前者は能力、作業コスト、バッテリーなどを考慮するタスク割り当て、後者は複数エージェントの衝突、時間、依存関係を扱う経路調整です。

したがって、単一の巨大な最適化器にすべてを集約するより、機能を分離したうえで、移動コスト、ETA（到着予測時刻）、予約可否、混雑度を相互にフィードバックする疎結合または反復型の構成が現実的です。施設全体に関わる競合は交通管制層で扱い、ロボット近傍の急な障害物は各ロボットに任せます。

なぜ層分けが必要か

タスク割り当ては、複数のロボットと複数のタスクを対応付ける問題です。ロボットの能力、作業コスト、協調条件などが制約になります。一方、Multi-Agent Path Finding（MAPF）では、複数エージェントに衝突しない経路を割り当てます。代表的な衝突には、同じ地点を同じ時刻に占有する頂点衝突と、同じ区間を逆方向に通過するエッジ衝突があります。

この二つは独立ではありません。遠いロボットを割り当てれば移動コストが増え、混雑した通路を選べばETAが延びます。しかし、目的関数と制約が異なるため、責務を明示しないと、再割り当てのたびに経路予約を壊したり、局所回避に頼ってデッドロックを招いたりします。

推奨する責務分担

上位のWMSやMESは、作業内容、優先度、期限、実行条件を定義します。ここでは通常、特定ロボットの細かな経路を直接決めません。

フリート／タスク管理層は、候補ロボットの能力、現在位置、バッテリー、実行中タスクなどを使って担当を選びます。タスクのキューイング、ディスパッチ、実行状態の管理もこの層の責務です。

交通管制層は、共有通路、交差点、エレベーター、狭い出入口など、施設全体の状態を参照しなければ扱えない競合を調整します。軌道、時間、依存関係、予約や交渉を管理し、衝突やデッドロックを避けるための計画を提供します。

各ロボットのナビゲーション層は、交通管制から受け取った経路を実行し、センサーに基づいて局所的な障害物に対応します。ROS 2のNav2は、経路を生成するPlanner Serverと、経路追従の速度指令を生成するController Serverなどを分けており、上位の経路生成と近傍での実行を分離する設計例です。

flowchart TB
  WMS["WMS／MES\n作業内容・優先度・期限・実行条件"] --> FM["フリート／タスク管理層\n候補選定・キュー・ディスパッチ・実行状態"]
  FM --> FA["Fleet Adapter\nフリート接続"]
  FA --> NAV["各ロボットのナビゲーション層"]
  NAV --> PLAN["Planner\n経路生成"]
  PLAN --> CTRL["Controller\n経路追従・速度指令"]
  SENSOR["センサー\n近傍障害物"] --> CTRL
  CTRL --> ACT["ロボットの移動"]
  FM -->|"予定経路・候補情報"| TC["交通管制層\n共有空間・交差点・時間窓・予約"]
  TC -->|"予約可否・ETA・混雑度"| FM
  TC -->|"予約済み経路・時間条件"| FA
  FA -->|"状態・位置・実行結果"| FM
  classDef layer fill:#e8f1ff,stroke:#3569a8,stroke-width:1px;
  classDef robot fill:#eef8ee,stroke:#4d8b57,stroke-width:1px;
  class WMS,FM,TC layer;
  class FA,NAV,PLAN,CTRL,SENSOR,ACT robot;

タスク割り当て、交通管制、ロボットの局所制御を分離し、ETA、移動コスト、予約可否、状態を層間で交換する構成。

タスク層と交通層の間には、能力、バッテリー、位置、ETA、現在の予約、再計画要求、キャンセル結果などを明示的なインターフェースとして定義するとよいでしょう。予約できない候補を割り当てない、遅延が大きくなれば別の候補を再評価する、といった反復が可能になります。

カメラとLiDARの外部キャリブレーション：点群と画像を正しく重ねる方法

Sat, 25 Apr 2026 00:51:08 +0900

画像と点群のずれは、外部変換だけでなく時刻やレンズ歪みにも現れます。切り分けを手順に組み込めるかが気になったテーマです。

結論

カメラとLiDARの融合で最初に固定すべきなのは、校正アルゴリズムよりも座標系、変換方向、単位、時刻基準です。そのうえで、カメラの内部パラメータとレンズ歪みを先に校正し、同期した観測からLiDAR座標系をカメラ座標系へ写す剛体変換を推定します。最後に、校正に使っていない姿勢・距離・視野・速度のデータへ点群を再投影し、誤差の大きさと分布を確認します。

校正時の残差が小さいだけでは不十分です。画像上のずれが内部パラメータ、外部変換、時間オフセット、LiDARの走査遅延のどれに由来するかを条件別に切り分け、用途に応じた合格基準を定める必要があります。

なぜ外部キャリブレーションが重要か

カメラは画素、LiDARは3次元点として同じ対象を観測します。しかし、それぞれの座標原点や軸方向は異なります。外部パラメータに誤りがあると、LiDAR点を画像へ重ねたときに、物体の輪郭から一定方向へずれたり、距離によってずれが変化したりします。物体検出への深度付与、障害物の位置推定、画像と点群の対応付けでは、この空間的な不整合が直接結果に影響します。

前提となる用語

外部パラメータは、LiDAR座標系の点をカメラ座標系へ変換する回転と並進、つまり剛体変換として管理します。実装では、変換をどちら向きに適用するのか、フレーム名、長さの単位、時刻基準を明示します。フレーム間の関係は一貫したフレームツリーで管理し、同じ数値を別の座標軸定義へそのまま移植しないことが重要です。

内部パラメータは焦点距離や主点など、カメラ内部の投影特性を表します。レンズ歪みモデルも画像投影に関係するため、外部変換とは分けて推定し、外部キャリブレーションの前に妥当性を確認します。内部行列と歪みモデルが不正確なままでは、外部変換を調整しても再投影誤差を正しく解釈できません。

推奨する校正手順

1. センサーを剛体として固定する

カメラとLiDARの取り付けを固定し、校正中に相対位置が変わらない状態を作ります。振動や取り付け部の変形が疑われる場合、得られた変換はその時点の状態に限られる可能性があります。

2. 座標系と時刻を確認する

各センサーのフレーム名、軸方向、単位、変換の保存方向を記録します。さらに、ハードウェア同期の有無、LiDAR点ごとのタイムスタンプ、走査中の運動補償の有無を確認します。移動中に時間同期が不足すると、時間オフセットが空間的な外部パラメータ誤差として現れます。必要なら時間オフセットを別パラメータとして推定・検証します。

3. カメラ内部を校正する

平面パターンなどを複数の視点から撮影し、内部パラメータ、歪み、各撮影姿勢を推定します。単一画像だけに依存せず、複数視点の観測で結果を確認します。ここで得た投影モデルを固定してから、カメラとLiDARの外部変換へ進みます。

4. 対応を集めて初期値を求める

既知形状のターゲットを使う場合、LiDAR側の3次元特徴と画像側の2次元特徴、またはターゲット平面を対応付けます。十分な姿勢や視点の違いを含む観測から、まず外部変換の初期値を求めます。初期値の品質が低いと、後段の非線形最適化が適切な解へ到達しない場合があります。

5. SE(3)上で最適化する

初期変換を出発点に、3次元点をカメラ座標系へ変換し、内部パラメータと歪みモデルを適用して画像へ投影します。3D-2Dの再投影残差、点と平面の残差など、利用できる対応に応じた目的関数を最適化します。

flowchart LR
  A["センサーを剛体として固定"] --> B["座標系・単位・変換方向・時刻を確認"]
  B --> C["カメラ内部パラメータと歪みを校正"]
  C --> D["同期した観測データを収集"]
  D --> E["3D-2Dまたは特徴・平面の対応を作成"]
  E --> F["外部変換の初期値を推定"]
  F --> G["SE(3)上で再投影・幾何残差を最適化"]
  G --> H["未使用データで再投影・幾何・時間整合を検証"]
  H --> I["条件別の誤差を診断して合否基準を判断"]
  I -. "運動時のみ誤差が増える場合" .-> B

外部キャリブレーションは、内部校正と座標・時刻の確認を分けたうえで、初期推定、SE(3)最適化、独立データによる検証の順に進めます。

ターゲット方式とターゲットレス方式

既知ターゲット方式は、対応する幾何が明確で、初期推定と残差の意味を説明しやすい方法です。一方、設置や撮影の準備が必要で、ターゲットの見え方や配置が観測条件を制限します。

ターゲットを設置しない方式では、LiDAR点群の反射強度や投影情報と、画像の明るさ・外観との相互情報量を最大化する方法が提案されています。また、画像エッジなどの視覚特徴とレーザー点の幾何を使い、運用中に外部パラメータを調整する方式もあります。ただし、シーンのテクスチャ、反射率、天候、動的物体による安定性は個別データで確認する必要があります。

方式	準備	強み	注意点
既知ターゲット	ターゲット設置と対応抽出	幾何的に解釈しやすく、初期推定を作りやすい	設置条件と視点の設計が必要
相互情報量によるターゲットレス	専用ターゲット不要	実環境の観測を利用できる	外観や反射特性への依存を確認する必要がある
画像エッジとレーザー特徴	運用中の特徴観測	固定ターゲットに依存せず更新を目指せる	特徴の量と動的環境の影響を受ける
時空間キャリブレーション	同期状態を含む観測	空間変換と時間オフセットを同時に扱える	固定・同期済みのシステムでは必要な自由度を見極める必要がある

融合結果の検証方法

推定した変換でLiDAR点をカメラ座標系へ移し、深度が正の点だけを残します。その後、内部行列と歪みモデルで画像へ再投影し、次の項目を記録します。

イベントカメラをロボットに使う判断：高速動作・HDR・低遅延の実装上の利点と限界

Fri, 06 Feb 2026 08:13:12 +0900

高速動作を撮るカメラでは、画像の鮮明さだけでなく、いつ変化を捉えたかが判断を左右します。

先に結論

イベントカメラは、視覚処理の中心が「絶対的な画像」ではなく「時間的な輝度変化」にある場合に、フレームカメラより有利になり得ます。高速搬送物の追跡、回転体の運動推定、移動ロボットの急旋回時の光フロー、視覚オドメトリ、視覚慣性オドメトリ、明暗差の大きい環境での動体検出が代表例です。

一方、静止物体の外観、色、テクスチャ、絶対輝度を使う認識では、そのまま置き換えられません。実装では、運動推定をイベントカメラ、外観認識をフレームカメラに分担させる併用構成を優先して検討するのが現実的です。

なぜ選択が重要なのか

フレームカメラは一定周期で画像全体を取得します。高速に動く対象では、露光中の移動によるモーションブラーや、フレーム間にある時間情報の欠落が問題になり得ます。逆に、対象がほぼ静止していて色や表面模様を認識するなら、画像全体を得られるフレームカメラのほうが扱いやすいでしょう。

したがって、判断すべきなのは「どちらが高性能か」ではありません。対象タスクが必要とする情報が、時間変化なのか、絶対的な外観なのかを分けることが出発点になります。

前提となる仕組み

イベントカメラは、一定周期でフルフレームを出力するのではなく、各画素で対数輝度の変化を監視します。変化がしきい値を超えると、画素位置、発生時刻、極性、つまり明るくなったか暗くなったかを持つイベントを非同期に出力します。

そのため、静止した一様な領域からは基本的にイベントが発生しません。イベントを一定時間窓で集めて画像状に表示することはできますが、それは絶対輝度画像そのものではありません。イベント列から画像や極性画像を生成するほか、時刻と位置を直接使って光フロー、エッジ追跡、特徴点追跡、動体の速度推定を行う構成も考えられます。

flowchart LR
  subgraph F["フレームカメラ"]
    F1["一定周期で露光"] --> F2["フルフレームを読み出し"] --> F3["画像処理・推論"] --> F4["認識または運動推定"]
    F1 -.-> F5["露光条件によってモーションブラーが生じ得る"]
    F2 -.-> F6["絶対輝度や色を画像として取得しやすい"]
  end

  subgraph E["イベントカメラ"]
    E1["各画素で対数輝度の変化を監視"] --> E2["しきい値を超えた輝度変化を検出"] --> E3["位置・時刻・極性付きイベントを非同期出力"] --> E4["イベント列を処理"] --> E5["光フロー・追跡・速度推定・オドメトリ"]
    E1 -.-> E6["静止した一様領域からは基本的にイベントが出にくい"]
    E3 -.-> E7["変化が疎ならデータ量を減らせる可能性"]
    E3 -.-> E8["振動・全面運動・明滅ではイベントレートが増え得る"]
  end

  E5 --> H["ロボットの認識・制御"]
  F4 --> H
  E3 -.-> D["センサの時間性能"]
  E4 -.-> D
  D -.-> L["推論・通信・制御周期を含むエンドツーエンド遅延とは別に評価"]

フレームカメラはフルフレームと絶対的な外観情報を扱いやすく、イベントカメラは画素単位の時間情報を利用して運動推定を行う。センサの時間性能だけでなく、推論・通信・制御を含むエンドツーエンド遅延も評価する必要がある。

センサ内部の短い応答遅延と画素単位のタイムスタンプは、高速運動時の時間分解能を高め、フレーム撮影に伴うブラーを抑えやすくします。ただし、センサの時間性能はシステム全体の遅延ではありません。イベント処理、ノイズ除去、特徴抽出、推論、通信、制御周期まで含めて評価する必要があります。

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

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["停止・退避または再試行"]

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

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

AIロボットの安全設計：非常停止とAI判断を分離する理由

Thu, 15 Jan 2026 00:01:44 +0900

編集コメント：AIが危険を検知できることと、機械の安全機能を担えることは同じではありません。両者の責任分界を設計段階で明確にする必要があります。

先に結論

Physical AIやAI搭載ロボットでは、非常停止をAIの判断だけに依存させるべきではありません。非常停止入力、保護センサ、安全ロジック、アクチュエータ停止までの安全関連経路を、AIの通常制御・推論経路から機能的に独立させるのが基本です。AIはカメラやセンサから危険を検知し、追加の停止要求を出す補助層として扱います。

ここでいう「分離」は、必ずしも別CPUや別配線を意味しません。必要な安全性能、故障時の安全状態、共通原因故障への耐性をリスクアセスメントで確認できるなら、安全コントローラや安全認証済みネットワークを使った統合も候補になります。ただし、AI系の停止要求が失敗しても、人間の非常停止や保護センサから安全状態へ移行する経路が機能しなければなりません。

なぜAI判断と非常停止を分けるのか

AIの認識や行動計画は、入力データ、推論処理、通信、ソフトウェアの状態に依存します。危険を認識できない場合だけでなく、推論や通常制御が停止した場合にも、安全機能まで失われる構成は避ける必要があります。

機能安全で評価する対象は、AIの認識精度だけではありません。安全関連制御部に要求される性能、故障の検出、故障時にどの安全状態へ移行するか、ソフトウェアを含む設計と統合を確認します。したがって、AIモデルの精度評価やAIリスク管理の文書だけで、非常停止回路の安全妥当性を示すことはできません。

用語を分けて仕様化する

ISO 13850:2015では、非常停止機能は単一の人間の操作で開始される機能として扱われます。すべての運転モードで利用可能かつ作動可能で、他の機能や操作より優先され、リセットだけで再起動してはなりません。また、非常停止は安全防護の代替ではなく、補完的な安全機能です。

一方、AIが自動的に出す停止要求を製品資料などで「E-stop」と呼ぶことがあります。しかし、仕様上は少なくとも次を区別する必要があります。

非常停止：人間の操作で開始され、他の操作より優先される安全機能
保護停止：センサなどが危険条件を検知したとき、安全状態へ移行する機能
通常停止：タスク完了や運用指示に基づく停止
AIによる停止要求：AIの危険検知を起点とする追加の停止要求

AIによる停止要求を、非常停止の代替として扱うのではなく、保護停止や追加のリスク低減層として要件、故障時挙動、検証方法を別途定義することが妥当です。

内部の仕組み

基本構成では、非常停止ボタン、ガードスイッチ、安全スキャナなどを安全ロジックへ接続します。安全ロジックは安全関連の出力を介して、安全対応ドライブやブレーキなどを制御し、機械を定義済みの安全状態へ移行させます。AI側はカメラやセンサを入力として推論し、必要に応じて安全系へ停止要求を入力しますが、AI側から安全系を無効化する経路は設けません。

安全状態がモータトルク遮断、ブレーキ適用、電源遮断、保持状態のいずれになるかは、ロボットの機構、負荷、落下や挟圧の危険によって異なります。対象機械の情報がない段階で、停止カテゴリ、停止時間、制動距離、要求PLやSILを一律に決めることはできません。

flowchart LR
  subgraph SAFETY["安全関連経路"]
    E["非常停止ボタン"] --> SL["安全ロジック"]
    G["ガードスイッチ"] --> SL
    S["安全スキャナ"] --> SL
    SL -->|"安全関連出力"| D["安全対応ドライブ"]
  end

  subgraph AICTRL["AI・通常制御経路"]
    C["カメラ・センサ"] --> INF["AI推論"]
    INF --> P["タスクプランナ"]
    P --> NC["通常コントローラ"]
    NC -->|"通常の駆動指令"| D
    INF -->|"補助的な停止要求"| SL
  end

  D --> A["アクチュエータ"]
  A --> SS["定義済みの安全状態"]

非常停止と保護センサを含む安全関連経路を、AIの推論・通常制御経路から機能的に分けた基本構成。AIは安全系への追加の停止要求を出せるが、安全系を無効化する経路は設けない。

系統ごとの比較

系統・方式	主な開始者	役割	AIへの依存	設計・検証の焦点
非常停止	人間	危険な機能を優先的に停止	依存させない	常時利用可能性、優先性、リセット後の再起動防止
保護停止	保護センサや安全ロジック	検知した危険条件から安全状態へ移行	安全センサを使う場合は安全系として評価	故障検出、安全状態、要求性能
通常停止	運用者やタスク制御	通常の動作終了	通常制御に依存	停止手順と運用上の再開条件
AIによる停止要求	AIの危険検知	追加のリスク低減層	認識・推論に依存	未検知、誤検知、停止要求失敗時の挙動

物理分離か、機能的な分離か

設計判断では、まず「別CPUかどうか」ではなく、安全機能がAI系の故障に妨げられないかを確認します。AIの通常制御と安全関連制御を別の機能として定義し、入力、処理、出力、故障時挙動、検証責任を分けることが出発点です。