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と転送、モデル入出力、計画・制御コマンド、アクチュエーターのフィードバックまでを連続した契約として捉えます。各境界にスキーマ、座標系、時刻、品質、バージョンを置くと、変更箇所と影響範囲を追跡しやすくなります。

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

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、反復ピッキング、固定部品	安全性と柔軟性を両立したい場面
未知物体	候補化できるが、未知拒否は別機能	対象外として定義しやすいが、未知発見は弱い	候補生成後に拒否・検証できる
データ追加	カテゴリ追加時の教師データ負担を抑えやすい	アノテーションや再学習が必要になりやすい	追加対象だけを段階的に検証できる
主な注意点	プロンプト、視点、照明、遮蔽への依存	校正不良、対象外の誤受理、語彙外への対応	段数増加による遅延と設計複雑化
評価	未知誤受理率、候補再現、拒否性能	既知精度、校正、拒否性能	最終行動成功率と各段の失敗率

実装での使い分け

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

ROS 2実行時パラメータ設計：動的変更・検証・適用境界をどう決めるか

Wed, 04 Nov 2026 15:01:42 +0900

実行中に設定を変えられるROS 2の柔軟性は、適用境界をどう設計するかで安全性が変わります。

結論

ROS 2の実行時パラメータ変更は、再起動なしの運用に役立ちます。ただし、変更できることと、安全に運転中へ即時反映できることは別です。影響範囲が限定された値だけを動的変更の対象にし、型・値域・単位・相互依存関係を検証したうえで、関連パラメータを原子的に更新します。

制御ゲイン、速度・加速度上限、衝突判定閾値などは、安全な制御周期境界、またはLifecycle NodeのInactive状態で反映する設計が基本です。資源の再確保、通信設定、QoS、コンポーネント構成の変更を伴う値は、Lifecycle遷移や再起動を適用境界にします。認証・認可、監視、監査、ロールバックまでを一つの運用フローとして設計することが、運用性と安全性を両立する条件です。

なぜ適用境界が必要か

ROS 2のパラメータはノードに関連付けられ、ノードのパラメータサービスから取得・設定できます。変更はParameterEventとして通知できるため、再起動せずにセンサー閾値や診断設定を調整し、変更を監視できます。

一方、パラメータ機構が支援するのは、主に型やAPIレベルの整合性です。制御安定性、機械的安全、停止距離、センサー間の依存関係まで自動判定するわけではありません。数値として正しいゲインでも、ロボットの機構や制御周期との組み合わせによって安全とは限らないため、「変更可能か」と「運転中に反映できるか」を分けて判断します。

パラメータ変更の仕組み

パラメータは宣言して使用し、宣言時に型や説明を付与します。ParameterDescriptorでは、read_only、動的型付け、整数・浮動小数点の範囲、追加制約などを記述できます。ただし、メタデータだけでドメイン固有の安全条件が満たされるわけではありません。必要な値域や組み合わせ条件は、対象ディストリビューションのAPI仕様を確認し、ノード側の検証処理でも明示します。

ノードにはパラメータ変更コールバックを登録できます。コールバックは値が確定する前に候補を検証し、要求を受け入れるか拒否する場所です。ここでアクチュエータを操作したり、再帰的に別のパラメータ変更を呼び出したりせず、検証と実際の適用を分離します。

複数のパラメータが関係する場合は、通常のset_parametersではなくset_parameters_atomicallyを使います。set_parametersは非原子的で、各パラメータの結果を個別に返します。これに対し、set_parameters_atomicallyは候補のいずれかが失敗した場合、パラメータ全体を変更しません。ゲインと上限値など、組み合わせの整合性が必要な変更に適しています。

ただし、この原子性はパラメータ設定に関するものです。外部ハードウェア、制御器内部状態、すでに送信した指令まで自動的に元へ戻す仕組みではありません。

flowchart LR
  A["変更要求"] --> B["認証・認可"]
  B --> C["型・値域・単位・相互依存を検証"]
  C --> D{"検証に成功?"}
  D -- "いいえ" --> E["変更を拒否して記録"]
  D -- "はい" --> F["set_parameters_atomicallyで候補を更新"]
  F --> G{"適用境界を満たす?"}
  G -- "いいえ" --> H["安全な制御周期境界またはInactiveまで保留"]
  H --> I["実値へ適用"]
  G -- "はい" --> I
  I --> J["動作・制御状態・異常を監視"]
  I --> K["ParameterEventと外部監査ログを記録"]
  J --> L{"異常を検知?"}
  L -- "いいえ" --> M["変更後状態を継続監視"]
  L -- "はい" --> N["旧設定へ復元、停止、または再起動"]
  K --> M
  N --> O["復旧結果を記録"]

パラメータの受付、検証、原子的更新、適用、監視、監査、異常時の復旧を分離した安全な変更フロー。

Lifecycleと適用タイミング

Lifecycle Nodeには、Unconfigured、Inactive、Activeなどの状態と、configure、activate、deactivate、cleanupなどの遷移があります。どの状態でパラメータを適用し、どの資源を再構成するかはノード実装が定義します。Inactive状態だから自動的にアクチュエータ出力が停止する、という保証もありません。

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

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、固定時間刻み、サブステップ	トンネリング、衝突時刻、衝突インパルス
押し付け・把持・挿入	接触剛性・減衰、摩擦、位置拘束反復	侵入量、接触力、関節トルク、滑り遷移
組立・準静的操作	接触コンプライアンス、収束許容値、時間刻み	力の再現性、拘束残差、軌道の収束
積み重ね・多接触	ソルバー方式、反復回数、時間刻み	ドリフト、拘束残差、計算時間
モデルベース制御	積分器、拘束ソルバー、接触パラメータ	制御入力と接触応答の再現性

収束試験の進め方

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

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

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

学習方策を安全に動かすランタイム保証：監視・シールド・フォールバックの設計

Thu, 29 Oct 2026 14:33:48 +0900

学習モデルの出力を、そのまま物理系へ渡してよいのか。ランタイム保証は、この素朴な疑問を実装可能な層構造へ変換する設計課題です。

先に結論

学習ベースのロボット方策は、アクチュエータへ直接接続せず、独立したランタイム監視層を間に置く構成が基本です。監視層は現在状態だけでなく、方策の出力と短時間先の予測状態を、速度・トルク・接触・関節限界などの制約と照合します。その結果に応じて、通常の指令を許可する、指令を安全側へ修正する、検証済みのリカバリ方策へ切り替える、または停止する、という経路を選びます。

ただし、シールドや制御バリア関数（CBF）があるだけで安全性が自動的に保証されるわけではありません。モデル、状態推定、入力制約、計算時間、フォールバックの妥当性が前提を満たす必要があります。実機では、監視器そのものの故障、センサー欠測、通信遅延、アクチュエータ飽和まで含めて設計対象にします。

なぜランタイム保証が必要か

VLA、模倣学習、強化学習の方策は、認識やタスク遂行を柔軟に扱える一方、出力をそのまま物理系へ適用できるとは限りません。モデルの意味的な信頼度やOODスコアだけでは、接触力、関節限界、急激な速度変化といった低レベルの危険を十分に判定できるか確認できません。

そこで、学習方策の性能と安全性を同じモジュールに背負わせず、独立した安全側の仕組みを設けます。Simplex型の考え方では、高機能だが事前に信頼性を証明しにくいコントローラと、より単純で検証しやすい安全コントローラを併用し、監視と切り替えによって安全側を選択します。

用語と方式の違い

安全シールドは、環境モデルと安全仕様を使い、危険な行動を実行前または状態遷移前に抑止する仕組みです。離散的な状態遷移やアクションの安全性を扱いやすい一方、連続ロボットの物理ダイナミクスへ適用するには、モデル化の範囲を明確にする必要があります。

CBFは、安全集合の前向き不変性を保つ条件を制御入力の制約として表現します。方策が出した入力を、二次計画問題（CBF-QP）などで安全条件を満たす入力へ修正する設計に利用できます。

リカバリ方策は、通常方策とは別に、安全側へ戻すための方策を持つ方式です。危険領域や高リスク状態を検出したとき、通常のタスク方策からリカバリ方策へ切り替えます。安全フィルタの修正だけでは状態を戻せない場合に選択肢となります。

flowchart LR
  S["センサー"] --> E["状態推定"]
  E --> P["学習方策\nVLA・模倣学習・強化学習"]
  P --> M["独立したランタイム監視器"]
  E --> M
  M --> C["現在状態・方策出力・予測状態を制約評価"]
  C --> A["通常指令を許可"]
  C --> F["安全側へ指令を修正\nCBF-QP・速度制限・トルク制限"]
  C --> R["リカバリ方策へ切り替え"]
  C --> X["停止"]
  A --> W["ウォッチドッグ確認"]
  F --> W
  R --> W
  W --> O["制約検査済み指令"]
  X --> O
  O --> Act["アクチュエータ"]

学習方策をアクチュエータへ直接接続せず、独立した監視層で指令を評価・修正する構成を示します。

1制御周期の処理

実装では、監視器をアクチュエータ指令の直前に置きます。概念的なデータフローは、センサー取得、状態推定、学習方策の推論、短時間先の予測、制約評価、指令の許可または修正、ウォッチドッグ確認、アクチュエータ出力です。

監視対象は少なくとも次の三つに分けます。

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

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、特異性の継続監視、二次目的による解選択、軌道全体の検証を行う実装フロー。固定的な普遍順序ではなく、実用上の評価構成を示しています。

特異点をどう評価するか

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

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

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

ロボット通信の決定論設計：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側の予約やスケジュールは決まりません。

ロボットのオンラインシステム同定：実機の変化を制御モデルへ反映する設計

Sun, 18 Oct 2026 13:15:09 +0900

実機の変化を追従する仕組みほど、更新しない経路の設計が安全性を左右します。

結論

ロボットのオンラインシステム同定は、推定モデルを制御器へ直接書き込む機能ではなく、監視・検証・更新を担う監督層として組み込むべきです。まずシャドーモードで入力・出力、残差、推定共分散、物理的なパラメータ範囲を確認し、条件を満たした場合だけ、非安全系の限定されたパラメータを段階的に反映します。

安全停止、速度・トルク上限、保護領域、フォールバック制御は推定器から分離します。更新に失敗した場合は、直前の有効モデルまたは保守的な安全モデルへ戻せる構成にします。オンライン同定の採用判断では、追従性だけでなく、推定の確からしさ、安定性の仮定、変更管理まで確認する必要があります。

なぜオンライン同定が必要か

ロボットの動特性は導入時のモデルから変化します。積載物、温度、摩擦、減速機の状態などが変われば、同じ入力に対する速度やトルクの応答も変わり得ます。固定モデルとの不一致が大きくなると、追従性能や外乱・接触検出の信頼性に影響します。

一方、観測された変化が摩耗によるものとは限りません。接触、外乱、負荷変化、センサーずれ、モデル誤差も似た残差を生みます。したがって、同定器は原因を自動的に断定する装置ではなく、変化の兆候と推定の不確かさを継続的に評価する仕組みとして扱います。

前提となる用語と仕組み

システム同定とは、入力と出力のデータから対象の動特性を表すモデルやパラメータを推定することです。オンライン同定では、データを逐次処理して推定値を更新します。再帰的最小二乗法や予測誤差法は、その代表的な考え方です。

忘却係数を使うと、古いデータの影響を相対的に小さくし、時間変化する動特性への追従を狙えます。ただし、忘却を強くすると変化への追従性が高まる反面、ノイズへの感度や推定バイアスが増える可能性があります。十分な励起、信号品質、推定不確かさの監視が欠かせません。

残差は、測定トルクとモデルから予測したトルクとの差のように、実測値とモデル出力の差を示します。外力や衝突の検出に利用できますが、残差だけで劣化、負荷変化、接触を一意に識別できるわけではありません。励起が不足した運転では、異なる原因が同じ残差を生む可能性があります。

推奨アーキテクチャ

高速の制御ループと、低速の推定・保全ループを分離します。高速ループは既知の安定モデルと安全制約で動作させ、低速ループは温度、負荷、摩擦、残差、推定パラメータを蓄積します。候補モデルは妥当性検証を通過した場合だけ、非安全系の制御パラメータへ反映します。

検証項目は、少なくとも次の通りです。

推定に必要な励起が確保されているか
残差が想定範囲に収まっているか
推定共分散または信頼区間が過大でないか
パラメータが物理的な範囲にあるか
一回の更新幅と更新頻度が制限内か
独立した安全監視が介入していないか

flowchart LR
  subgraph DATA["観測・入力データ"]
    S["センサー値"]
    U["制御入力"]
  end

  subgraph EST["低速の推定・検証ループ"]
    P["データ前処理"]
    I["オンライン推定器"]
    V["妥当性検証\n励起・残差・共分散・物理範囲"]
    C["更新候補モデル"]
    G["更新ゲート"]
  end

  subgraph CTRL["制御系"]
    M["既知の安定モデル"]
    K["制御器"]
    R["非安全系のモデル補正"]
  end

  subgraph SAFE["独立した安全系"]
    L["安全監視"]
    T["速度・トルク上限"]
    E["非常停止"]
    F["フォールバック制御\n直前の有効モデルまたは安全モデル"]
  end

  S --> P
  U --> P
  P --> I
  I --> V
  V --> C
  C --> G
  G -->|"検証済みの場合のみ"| R
  M --> K
  R -.->|"非安全系に限定"| K
  K -->|"制御出力"| T
  T -->|"許可された出力"| ROBOT["ロボット"]
  L --> T
  L --> E
  L --> F
  G -.->|"失敗時は反映しない"| F
  F -.-> K

オンライン推定の結果を直接制御器へ書き込まず、妥当性検証と更新ゲートを経て非安全系に限定して反映する。安全監視とフォールバック制御は推定器から独立させる。

モデル更新は、BASELINE_MODEL → SHADOW_ESTIMATION → VALIDATING → CANDIDATE_MODEL → ACTIVE_MODEL のような状態で管理できます。励起不足、残差異常、共分散の過大化、物理範囲からの逸脱、安全監視の介入があれば候補モデルを有効化せず、ベースラインまたは安全モデルへ戻します。ROS 2のライフサイクル状態は、Inactive状態で更新を準備し、遷移時に有効化する実装パターンの参考になります。ただし、それだけで機能安全が保証されるわけではありません。

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

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時刻は一時停止、速度変更、時刻ジャンプの影響を受けるため、受信時刻や単調増加する経過時間と混同しない設計が必要です。

ロボットビジョンのシャッター方式選定：動体歪み・同期・画質を比較する

Fri, 16 Oct 2026 13:17:57 +0900

ロボットの速度だけでは、カメラ画像の歪みを判断できない点が気になります。

先に結論

グローバルシャッターとローリングシャッターは、ロボットの関節速度や公称フレームレートだけで選ぶべきではありません。判断の中心は、画像面上の速度 v_img、センサーの実効読み出し時間 T_read、そして認識・計測で許容できる画素誤差です。

一次評価では、ローリングシャッターの行間位置ずれを v_img × T_read で見積もります。この値が許容誤差を超える可能性がある場合、特に高速な視覚サーボ、急な回転や加減速を伴う動作、数画素単位の外観検査では、グローバルシャッターを第一候補にします。対象がほぼ静止している、相対速度が低い、または許容誤差が大きい用途では、ローリングシャッターも実測を前提に選択肢になります。

なぜシャッター方式が重要か

グローバルシャッターは、フレーム内の画素を同時刻に近いタイミングで露光します。一方、ローリングシャッターはセンサーの行または行群を順番に露光するため、上の行と下の行で撮像時刻が異なります。厳密な露光開始・終了や読み出しの時間差はセンサーによって異なるため、仕様確認が必要です。

カメラまたは対象が露光中に動くと、ローリングシャッターでは行ごとに対象の位置が変わります。その結果、直線の傾き、対象形状の変形、姿勢推定のバイアスなどが生じます。視覚サーボでは画像特徴の位置が制御入力に使われ、検査では輪郭や寸法が判定に使われるため、この幾何歪みは単なる見た目の問題ではありません。

仕組みと一次評価

ローリングシャッターの歪みは、ロボットの関節速度だけでは決まりません。カメラと対象の相対運動が画像面でどれだけの速度になるか、カメラと対象の距離・姿勢、レンズの画角、行方向の読み出し時間、対象の深度差が関係します。同じ関節速度でも、作動距離や画角が変われば画像面速度は変化します。

一次近似として、行間の位置ずれは次式で表せます。

位置ずれ ≈ v_img × T_read

ここで v_img は画像面上の速度、T_read はフレームの実効読み出し時間です。これは選定初期の目安であり、回転、加減速、深度変化を含む実際の動作では動的試験が必要です。ROIやビニングによって読み出し時間が変わる場合もあるため、カメラの設定条件をそろえて確認します。

flowchart TB
  T0["FrameStartトリガー"] --> G
  subgraph G["グローバルシャッター"]
    G1["行1：露光開始"]
    G2["行2：露光開始"]
    G3["行3：露光開始"]
    G1 --- G2 --- G3
    GE["全行の露光区間が同時刻に近く重なる"]
    G1 --> GE
    G2 --> GE
    G3 --> GE
  end
  T0 --> R
  subgraph R["ローリングシャッター"]
    R1["行1：時刻 t0 に露光"]
    R2["行2：時刻 t0 + Δt に露光"]
    R3["行3：時刻 t0 + 2Δt に露光"]
    R1 --> R2 --> R3
    RE["上端と下端で撮像時刻が異なる"]
    R3 --> RE
  end
  G --> GT["実効読み出し時間 T_read と露光時間を仕様確認"]
  R --> RT["行時間・総読み出し時間 T_read・読み出し方向を仕様確認"]

FrameStartを同期しても、ローリングシャッターでは行ごとの露光時刻の差が残る。実効読み出し時間や行時間は実際の撮像設定とセンサー仕様で確認する。

露光時間によるモーションブラーは、行間の幾何歪みとは別の現象です。露光時間を短くすれば露光中のブラーは減りますが、ローリングシャッターの行間時間差や読み出し由来の歪みが自動的に消えるわけではありません。グローバルシャッターでも、露光中の移動、レンズ歪み、振動、照明フリッカーは残り得ます。

ロボットの電力制約をタスク計画へ反映する：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つの閾値にまとめると、通常の充電判断と安全上の限界が混同されます。まず距離や作業時間から予算を置き、実測データでモデルを校正する構成が現実的です。

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

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

実装の流れ

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

異種ロボットを同じ現場で動かすフリート連携：タスク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

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

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

人協働ロボットの近接安全設計：人の動きを推定して速度制限へつなげる方法

Fri, 09 Oct 2026 14:54:15 +0900

人の動きを予測できても、安全判断では予測の不確実性をどう扱うかが問われます。

先に結論

人と協働するロボットの近接安全は、「人を検知したら停止する」か「AIの予測に任せる」かの二択ではない。人体の占有領域をロボットの危険源と同じ座標系で扱い、検出遅延、遮蔽、位置誤差、相対速度、ロボットの停止距離を含めて保護分離距離を継続評価することが基本になる。

分離距離を保証できる間は通常速度または制限速度で運転し、制限速度でも境界を維持できない場合は保護停止へ移行する。センサー故障、追跡断絶、通信・同期異常などで保証が失われた場合は、最後の推定値や予測値で運転を継続しない。予測軌道は先回りした速度制限の補助には使えるが、それだけを安全バリアとして扱うべきではない。

なぜ動的な評価が必要か

協働ロボットでは、人が作業領域に入ること自体が直ちに異常とは限らない。ロボットの速度、工具の形状、人体との距離、制動性能に応じて、通常動作、速度制限、保護停止を使い分ける必要がある。一方、検出から制動開始までに時間がかかれば、検知時点では安全に見えても、ロボットはその間に人体へ接近する。

そのため設計対象は人体検出器だけではない。センサー、推定器、通信、制御器、ドライブ、ブレーキを含む安全機能全体を、リスクアセスメントと安全関連制御系の要求に結び付ける必要がある。ISO/TS 15066は速度・分離監視などの協働運転方式を扱い、ISO 12100は危険源の同定、リスク低減、妥当性確認を含む設計プロセスを示している。

位置・速度・予測軌道の扱い

人体の位置は一点ではなく、人体または身体部位の占有領域として表現する。人体、ロボットの危険点、工具、周辺設備を共通座標系へ変換し、センサーの位置誤差、時刻同期と検出の遅延、遮蔽、複数人の識別不確実性を危険側に評価する。

安全レーザースキャナなどが保護フィールドへの侵入状態だけを出力する場合、その出力から連続的な位置や速度を直接得られるとは限らない。連続トラッキングを利用する場合は、時刻付きの位置推定から危険源への相対速度、つまり接近速度を算出する。平滑化や外れ値除去を行う場合も、更新遅延、推定誤差、トラッキング断絶を考慮し、瞬間値をそのまま安全入力にしない。

予測軌道は、将来位置を示す一本の確定線ではない。人の動きは周囲の人、物体、環境、相互作用、作業意図に依存し、予測ホライズンが長いほど不確実性が増す。したがって短時間先の複数の軌道候補を包絡する占有領域として扱い、最大接近速度と位置不確実性を含めてロボットの停止包絡との重なりを評価する。遮蔽、信頼度低下、追跡断絶、想定外の加速度が起きた場合は、予測を無効化して保守側へ遷移させる。

flowchart LR
  A["センサー入力\n時刻付きデータ"] --> B["時刻同期・共通座標系への変換"]
  B --> C["人体・身体部位の\n占有領域を推定"]
  C --> D["追跡・接近速度・\n不確実性を推定"]
  D --> E["短時間の複数軌道を\n占有包絡として評価"]
  E --> F["ロボットの停止包絡と\n保護分離距離を評価"]
  F --> G{"分離距離を\n保証できるか"}
  G -->|"余裕がある"| H["通常動作"]
  G -->|"制限速度なら保証可能"| I["速度制限"]
  G -->|"保証できない"| J["安全関連の保護停止"]
  D --> K{"追跡・同期・検出系に\n異常があるか"}
  K -->|"いいえ"| E
  K -->|"はい"| L["保守側へ遷移"]
  L --> I
  L --> J
  E -.-> M["予測は補助情報\n安全バリア単独ではない"]
  M -.-> F

人体の位置・接近速度・不確実性とロボットの停止性能を継続的に評価し、分離距離を保証できる範囲で速度を制限し、保証できない場合は保護停止へ移行する概念フロー。

分離距離から速度制限へ

保護分離距離の考え方では、人体の接近速度、システム全体の応答時間、ロボットの停止距離、人体または身体部位の侵入距離、センサーと位置推定の不確実性を考慮する。ISO 13855の基本関係は、接近速度をK、総応答時間をT、侵入距離をCとして S=K×T+C で表される。

ロボットソフトウェアの安全な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の三機能で整理しています。これはロボットの物理安全全体を直接規定するものではありませんが、更新設計の基本的な分解として利用できます。

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

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

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

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

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

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

計画に反映する選択肢

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

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

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

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

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

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

ロボットAIの電力・熱設計：長時間運用で推論性能を安定させる監視方法

Sun, 27 Sep 2026 14:06:14 +0900

短時間のベンチマークで良好に見えるロボットAIが、長時間運用でも同じ応答性を保てるとは限りません。

先に結論

Jetsonなどのエッジ計算機を搭載したロボットでは、平均FPSだけで長時間運用の安定性を判断してはいけません。温度、電力、CPU・GPU・メモリ帯域の利用率と周波数、アプリケーション遅延を同じ時系列で記録し、p95・p99遅延、最大遅延、期限超過率、キュー長を重視します。

温度上昇や電力制約と実効クロック低下が、p99遅延の増加と同時に起きていれば、熱または電力に起因する性能低下を疑います。温度やクロックが安定しているのにキューだけが伸びる場合は、CPU競合、メモリ帯域、I/O、前処理・後処理などを追加で調べます。状態が悪化したときは、推論レート、処理対象フレーム、入力解像度、モデル品質を段階的に下げる閉ループ制御が有効です。

なぜ長時間の監視が必要か

短時間のベンチマークは、起動直後の温度や一時的な冷却条件を反映します。一方、実際のロボットでは筐体や周囲の温度、電力モード、センサー入力、制御処理などが時間とともに変化します。Jetsonの熱管理機構は温度センサー、thermal zone、冷却デバイス、トリップポイントを使い、条件に応じて周波数制御やスロットリングを行うことがあります。

そのため、瞬間的な推論時間やFPSだけでは制御周期を守れるか分かりません。安全制約や周期処理を持つシステムでは、平均値よりも遅延分布の上側を見ます。p99遅延、最大遅延、期限超過率、連続した欠落フレーム数の許容値は、対象ロボットの制御仕様と安全要求から決めます。製品、冷却方式、筐体条件が異なるため、温度や電力の一律な閾値は設定できません。

監視するメトリクス

Jetsonのシステム状態は、tegrastatsで一定間隔に取得できます。RAM、SWAP、CPU・GPU・EMCなどの利用率と周波数、温度、電力情報が対象です。電力監視ではVDD_INなどの入力・レール単位の値を利用できますが、利用可能なセンサー名や値の意味は、モジュール、キャリアボード、ソフトウェア設定によって異なります。VDD_INがモジュール入力だけを示すのか、キャリアボードや周辺機器を含むのかは、対象機の回路構成とセンサー実装を確認してください。

温度の調査では、tegrastatsの温度値に加えてthermal sysfsを確認します。Linuxのthermal frameworkは、thermal zoneの温度、冷却デバイス、トリップポイントをsysfs経由で公開します。これにより、単に温度が高いかだけでなく、温度管理機構の状態を確認できます。

推論レイテンシはtegrastatsだけでは測れません。アプリケーション側で、入力受付、キュー待ち、前処理、推論、後処理、出力にタイムスタンプを付け、p50・p95・p99、スループット、期限超過率、キュー長を記録します。NVTXの範囲を付ければ、Nsight SystemsでCPU・CUDA・GPUのタイムラインと処理区間を対応付けられます。

flowchart TB
  S["同じ時刻軸で記録"]
  S --> T["温度センサー・thermal zone"]
  S --> P["利用可能な電力センサー\n例: VDD_IN"]
  S --> C["CPU・GPU・メモリ帯域の利用率と実効クロック"]
  S --> M["RAM・SWAP"]
  S --> A["入力受付から出力までのアプリケーション区間"]
  A --> Q["キュー待ち・前処理・推論・後処理・出力"]
  Q --> L["p95・p99・最大遅延\n期限超過率・キュー長・欠落フレーム"]
  T --> R["時間相関を確認"]
  P --> R
  C --> R
  L --> R
  R --> H{"温度上昇・クロック低下・遅延増加が重なるか"}
  H -->|"はい"| X["熱または電力制約の候補として調査"]
  H -->|"いいえ。キューだけ増加"| Y["CPU競合・メモリ帯域・I/O・前後処理を追加調査"]

温度、電力、実効クロック、キュー長、p99遅延などを同じ時系列に置くと、熱・電力制約とソフトウェア要因を切り分けやすくなります。VDD_INなどの電力値は、対象モジュールや回路構成に応じて測定範囲を確認します。

指標と取得手段の比較

指標・手段	主な対象	用途	注意点
tegrastats	温度、利用率、周波数、RAM・SWAP、電力	長時間の状態監視	製品やボードで項目が異なる
thermal sysfs	thermal zone、冷却デバイス、トリップポイント	熱制御とスロットリングの調査	対象機でセンサー構成を確認する
アプリ計測	キュー、前処理、推論、後処理、出力	エンドツーエンド性能の評価	推論単体の値とは一致しない
Nsight Systems	CPU・CUDA・GPUのタイムライン	競合や遅延区間の原因分析	常時監視より詳細調査向け
p95・p99遅延	遅延分布の上側	制御周期の評価	平均値だけでは見えない遅延を捉える

電力モードとクロック設定

nvpmodelはJetsonの電力モードを選択し、jetson_clocksはCPU、GPU、EMCなどのクロックを制御します。性能評価時と実運用時の設定を明示し、異なる条件の結果を混同しないことが必要です。

ROS 2のセキュリティ設計入門：DDS-Securityの適用範囲と性能評価

Sat, 26 Sep 2026 13:45:27 +0900

ROS 2の通信保護では、暗号化の有無だけでなく、どの情報を誰に許可するかまで設計する必要があります。

先に結論

ROS 2の通信を保護する場合は、SROS 2を入口としてDDS-SecurityをDDSのDomainParticipantとRTPS通信に適用します。ただし、すべての通信を一律に暗号化するのではなく、発見情報、RTPSメタデータ、トピックデータごとに保護レベルを選ぶことが重要です。

性能は「有効・無効」の二択では評価できません。認証のみ、完全性保護、暗号化、発見情報の保護などを段階的に比較し、採用するROS 2ディストリビューション、RMW実装、DDS実装、メッセージ特性、ハードウェアを固定して測定します。運用負荷も、初期設定だけでなく証明書・秘密鍵・権限ファイルの更新や障害対応まで含めて判断します。

なぜ適用範囲の設計が必要か

ロボットでは、センサーデータ、制御指令、状態情報などがDDSを通じて交換されます。通信相手が正しい参加者か、特定のノードにpublishやsubscribeを許すか、内容を第三者から読めなくするかは別々の課題です。認証に成功した参加者へ、すべてのトピックへのアクセスを許可する必要はありません。

また、「暗号化を有効にした」という説明だけでは保護範囲が分かりません。DDS-Securityでは、発見情報、liveliness、RTPSメタデータ、トピックデータに異なる保護レベルを指定できます。署名にとどめるか暗号化まで行うかは、機密性、完全性、性能、運用負荷を合わせて決めます。

用語と役割

DDS-Securityは、DDSのDomainParticipantとRTPS通信層に適用されるセキュリティモデルです。認証、アクセス制御、暗号、ロギングなどをプラグインとして構成します。

認証は参加者の識別と相互認証を担います。アクセス制御、つまり認可は、ドメイン、トピック、パーティションなどについて、その参加者がどの操作を実行できるかを判定します。暗号プラグインは、通信の暗号化や完全性保護を担当します。認証できたことと、アクセスを許可することは同じではありません。

ROS 2ではSROS 2がDDS-Securityを利用するツールと統合機能を提供します。キーストアに証明書、秘密鍵、ガバナンス文書、権限文書などを格納し、エンクレーブをノードの論理的なセキュリティ境界として利用します。実行時には、キーストア、エンクレーブ、セキュリティ戦略などを環境変数やCLIで指定します。

内部の仕組みと適用範囲

処理の流れは、参加者の起動、証明書の検証と認証ハンドシェイク、権限検証、発見情報の保護、エンドポイントの許可、トピックデータの署名または暗号化という順序で整理できます。ガバナンス設定はドメインや保護対象の方針を定め、権限ファイルは参加者やエンクレーブ単位のアクセス範囲を定めます。

flowchart LR
  node["ROS 2ノード"] --> rclrmw["rcl / RMW"]
  rclrmw --> dp["DDS DomainParticipant"]

  subgraph sec["DDS-Security"]
    auth["認証プラグイン"]
    access["アクセス制御プラグイン"]
    crypto["暗号プラグイン"]
  end

  dp --> auth
  dp --> access
  dp --> crypto

  subgraph ks["キーストア"]
    cert["Identity certificate"]
    key["Private key"]
    gov["Governance文書"]
    perm["Permissions文書"]
  end

  cert --> auth
  key --> auth
  gov --> access
  perm --> access

  auth --> participant["参加者の識別・相互認証"]
  access --> endpoint["ドメイン・トピック・パーティションの権限"]
  crypto --> discovery["発見情報・RTPSメタデータ"]
  crypto --> topic["トピックデータ"]

  participant --> rtps["DDSを経由するRTPS通信"]
  endpoint --> rtps
  discovery --> rtps
  topic --> rtps

  bypass["DDSをバイパスする経路\n独自トランスポート・実装依存のプロセス内通信など"] -.-> out["DDS-Securityの適用範囲外の可能性\n実装仕様の確認が必要"]

ROS 2のDDS通信に対するDDS-Securityの適用範囲と、キーストア資材およびDDSを経由しない経路の扱いを示します。

DDS-Securityで自動的に保護されるのは、基本的にDDSを経由する通信です。独自トランスポートや、実装によってDDS通信をバイパスするプロセス内通信・共有メモリ経路まで保護されるとは限りません。コンポーネントコンテナや共有メモリを使う場合は、実際の経路をRMWとDDS実装の仕様で確認します。

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

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, 20 Sep 2026 23:22:26 +0900

ロボットのクラウド利用は、計算資源の問題だけでなく、通信が途切れた瞬間の振る舞いまで含めて考える必要があります。

先に結論

ロボットのクラウド推論は、通信遅延や切断が起きても安全性と制御性能を損なわない、非同期・非安全系の処理に限定するのが基本です。アクチュエータの最終制御、緊急停止、衝突回避の最終判断、ウォッチドッグ、最低限の状態推定はロボット上に残します。一方、学習、ログの再処理、フリート分析、モデルや地図の配布、遅延を許容できる高位計画はクラウドと相性がよい領域です。

クラウドを制御ループの一部に使う場合は、単に平均遅延を測るだけでは不十分です。許容遅延、ジッター、結果の有効期限、タイムアウト、通信断時の動作、古い結果の破棄条件、ローカルフォールバックをタスクごとに定義し、故障時の挙動まで検証する必要があります。

なぜ配置の境界が問題になるのか

クラウドロボティクスは、ロボット単体では不足する計算資源や知識をクラウド側で補完し、遠隔計算やデータ共有を利用する考え方です。大規模な計算や複数ロボットのデータを集約できる一方、通信接続、遅延、帯域幅、信頼性、セキュリティが制約になります。

エッジコンピューティングは、データ生成源の近くに計算資源を置く方式です。クラウドへの往復を減らし、遅延、通信量、クラウド接続への依存を抑えやすい点に意味があります。プライバシーの観点でも、すべてのセンサーデータを遠隔へ送らず、近傍で処理する構成を検討できます。

つまり設計上の対立は、クラウドかエッジかの二択ではありません。計算資源や知識共有を得る代わりに通信へ依存するか、応答性と接続独立性を優先してロボットや近接エッジへ処理を置くか、というトレードオフです。

前提となる用語

ここでいうオンデバイスは、センサーやアクチュエータを持つロボット本体で処理することです。構内エッジや地域エッジは、ロボットに近いネットワーク上の計算資源を指します。クラウドは、ロボットから離れた計算・ストレージ基盤です。

また、安全系とは、処理の遅延や失敗が安全な停止や危険回避に直接影響する機能を指します。非安全系とは、結果が遅れたり利用できなかったりしても、ロボットの安全な基本動作を直ちに損なわない処理です。

内部の仕組みと分担

安全系の基本経路は、センサー、ローカル状態推定、衝突監視、ローカル制御器、アクチュエータという閉ループにします。クラウドへの接続状態に左右されず、最低限の状態推定と停止判断を継続できることが前提です。リアルタイム処理では、予測不能なメモリ割り当て、ブロッキング、非決定的な処理を避け、期限内に完了できる実装が重視されます。

クラウド側には、センサーデータの要約やログ、学習用データ、フリート全体の分析を送ります。クラウド推論の結果は、高位計画やモデル更新などに利用できます。ただし、結果を受け取っただけで直ちにアクチュエータを動かすのではなく、期限内か、現在の状態と整合するかを確認し、無効なら破棄してローカル側へ戻します。

画像理解や意味認識のように計算負荷が高い処理はクラウドに置ける場合があります。しかし閉ループで利用するなら、ロボット側に低遅延の代替処理、安全な停止、または低機能モードを用意できることが条件です。

flowchart TD
  A["処理対象"] --> B{"安全性に直接影響するか"}
  B -->|"はい"| C["オンデバイスに配置"]
  B -->|"いいえ"| D{"許容遅延・ジッター・有効期限が厳しいか"}
  D -->|"はい"| E["オンデバイスまたは近接エッジに配置"]
  D -->|"いいえ"| F["クラウド配置を検討"]
  F --> G["タイムアウトを定義"]
  G --> H["期限切れの結果を破棄"]
  H --> I["ローカルフォールバックまたは安全停止"]

処理の安全性、許容遅延、ジッター、結果の有効期限を基準に、オンデバイス・近接エッジ・クラウドの配置を判断する。

処理カテゴリ別の配置

処理	基本配置	理由・条件
アクチュエータ制御	オンデバイス	通信遅延や切断を前提にできない
緊急停止・衝突回避の最終判断	オンデバイス	安全動作をローカルで完結させる
ウォッチドッグ	オンデバイス	接続状態に依存せず異常を検出する
最低限の状態推定	オンデバイス	制御継続に必要な状態を確保する
高負荷の画像理解・意味認識	エッジまたはクラウド	代替処理や安全停止を用意できる場合に限定
高位計画	エッジまたはクラウド	結果の遅延を許容できる場合
ログ再処理・フリート分析	クラウド	即時の安全動作を決めない
学習・モデルや地図の配布	クラウド	集約計算と配布に向く

通信品質に応じたフォールバック

クラウド推論を採用する処理には、まず結果の有効期限を設定します。期限を過ぎた結果は、通信が復旧して届いたとしても現在の状態に対して古い可能性があるため、破棄します。要求を送ってから一定時間以内に返らない場合も、待ち続けるのではなく、代替モデル、速度制限、低機能モード、安全停止、手動介入など、あらかじめ定めた動作へ遷移させます。

ロボット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より実行コストが高い
実機ベンチ	センサー較正、遅延・ジッタ、電源、接触、摩擦	リリース候補、安全・接触・実環境に関わる変更	実際の機械・電気条件を確認できる	実行時間、設備、人的安全管理が必要
限定環境試験	実環境での安全挙動と運用範囲	実機ベンチ合格後、段階的に実施	現場条件での挙動を確認できる	リスク管理と中止手順が不可欠

実機へ進める出口条件

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

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

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または環境固定条件を持たせます。「未確認」「確認済み」「再学習投入」「テスト化」「解消」「再発」といった状態を管理すれば、改善サイクルのどこにあるかを追跡できます。

ロボット自己位置推定のセンサーフュージョン設計：カメラ・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の可観測性設計：センサー・推論・制御を横断して失敗を追跡する方法

Wed, 29 Jul 2026 09:10:27 +0900

ロボットの「遅い」「失敗した」という記録を、原因の追跡につながる観測へ変えるには何が必要かを整理します。

先に結論

ロボットの遅延や失敗を再現可能な形で調べるには、単一ノードのログではなく、センサー取得からアクチュエータ応答までを一つの実行単位として記録します。各境界に run_id、trace_id、span_id、親子関係、メッセージのシーケンス番号、複数の時刻、処理状態を付与し、分散トレースとメッセージ記録を組み合わせるのが基本です。

遅延は推論時間だけでなく、センサー取得、通信、キュー待ち、前処理、推論、制御計算、出力送信まで分解します。コード、モデル、設定、キャリブレーション、QoS、ファームウェア、乱数種、クロック設定も同じ調査単位に保存します。これにより、認識誤り、通信遅延、制御逸脱、安全停止の発生箇所と条件を追跡しやすくなります。

なぜ横断的な観測が必要か

Physical AIでは、センサー、ROS 2通信、前処理、推論、計画、制御、ドライバ、アクチュエータが別々の処理として動きます。「入力を受けた」というノードの記録は、センサーの露光時刻を示すとは限りません。同様に、制御コマンドをpublishした時刻と、アクチュエータが実際に受け付けた時刻も異なる可能性があります。

そのため「推論が遅い」という症状だけでは、原因が通信、executorの待ち時間、キュー滞留、前処理、推論、出力送信のどこにあるか分かりません。処理経路を共通の相関情報で結び、区間ごとの時間と状態を比較できるようにします。

前提となる仕組み

OpenTelemetryのトレースは、処理経路を複数の span の集合として表します。spanには開始・終了時刻、属性、イベント、ステータスを付けられます。ログが個別の出来事、メトリクスが集計値を扱うのに対し、トレースは一回の処理経路を表します。

W3C Trace Contextは、trace-id や parent-id などを分散コンポーネント間で伝播する標準形式を定義しています。ただし、ROS 2のDDS通信でこのコンテキストが自動的に伝播するとは確認できません。ROS 2ノード、メッセージ、middleware、またはブリッジ側で接続方法を設計する必要があります。

ROS 2には、LTTngとROS 2固有のtracepointを使い、ノード、通信、コールバック、executorなどを時系列で観測する ros2_tracing があります。アプリケーション固有の前処理、推論、制御には追加の計測点を設けます。rosbag2 はROS 2のトピックメッセージを記録・再生する仕組みで、トレースとは異なり、入力や中間メッセージを再利用するための記録系です。

計測する境界とデータフロー

個別のspanまたはイベントとして、次の境界を計測します。

センサー取得、ドライバ内のcapture
middlewareへのpublishと受信
キューへの投入・取り出し、callbackの開始・終了
前処理、推論、計画またはポリシー出力の開始・終了
制御計算、制御出力の生成
アクチュエータへの送信と応答

各記録には、ノード名、トピック名、入力・出力時刻、成功・失敗・期限超過などの状態も含めます。高頻度センサーのペイロードをトレースへ常時埋め込むのではなく、参照ID、ハッシュ、要約統計を置き、完全なデータは別の記録系で保持する構成が扱いやすくなります。

flowchart LR
  A["センサー取得・ドライバcapture"] --> B["middleware publish"]
  B --> C["middleware受信"]
  C --> D["キュー投入・取り出し"]
  D --> E["callback開始・終了"]
  E --> F["前処理"]
  F --> G["推論"]
  G --> H["計画・ポリシー出力"]
  H --> I["制御計算・出力生成"]
  I --> J["アクチュエータ送信"]
  J --> K["アクチュエータ応答"]
  M["共通の相関情報\nrun_id または episode_id\ntrace_id・span_id・親span\nシーケンス番号・処理状態"] -.-> A
  M -.-> B
  M -.-> C
  M -.-> D
  M -.-> E
  M -.-> F
  M -.-> G
  M -.-> H
  M -.-> I
  M -.-> J
  M -.-> K
  T["時刻の併記\nSteady Time: 経過時間\nROS Time: 再生・シミュレーション\nSystem Time: ホスト間相関"] -.-> A
  T -.-> K

センサーからアクチュエータ応答までの各境界を、run_id、trace_id、span_id、シーケンス番号、処理状態、複数の時刻で相関させる設計を示します。

時刻を用途別に分ける

遅延や経過時間の計測には、単調増加を前提とするSteady Timeを使います。シミュレーションや再生上の時系列にはROS Timeを使いますが、外部クロックやシミュレーション時間を扱える一方、クロック更新や時間のジャンプが起こり得ます。複数ホストの相関や人間向けの記録にはSystem Timeを併記します。

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

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

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

評価項目の比較

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

実機評価プロトコル

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

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

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軸力覚、外力・外トルク推定、手先運動
調整対象	仮想質量、ダンピング、剛性	仮想質量、ダンピング、剛性
典型的な構成	力学特性をトルク制御型ロボットで実現	力覚センサを外側ループに置き、位置・速度制御器へ接続
主な注意点	トルク計測・推定と内側ループの帯域	センサノイズ、遅延、位置指令の帯域
単独方式が不十分な場合	方向別の力・位置制御を追加	方向別の力・位置制御を追加

選定の手順

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

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

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はその情報と明示的な制約を使い、短期の制御入力を選択します。実行後に得た新しい観測で状態推定を更新し、同じ処理を繰り返します。

ROS 2 Lifecycle Nodeの実践設計：起動順序・停止処理・異常復旧を状態機械で管理する

Tue, 16 Jun 2026 08:57:52 +0900

実機では、ノードの状態とアクチュエータの物理状態を同じものとして扱わない設計が特に気になります。

先に結論

ROS 2の実機システムでは、Lifecycle Nodeを単なる起動・停止フラグではなく、設定、実行、安全停止、再初期化を分ける状態機械として設計します。基本の起動経路は Unconfigured → Inactive → Active、通常停止は Active → Inactive → Unconfigured、最終終了は Finalized へ進める構成です。遷移中の失敗や例外は ErrorProcessing に分離します。

ただし、Lifecycle Node単体が複数ノードの依存関係やプロセス再起動を管理するわけではありません。実機ではLifecycle Managerなどの外部オーケストレータで順序と監視を管理し、物理的な安全停止はハードウェアやコントローラ側にも実装します。

なぜ状態遷移が必要か

通常のNodeでは、プロセス起動後に処理や通信が始まり、設定未完了のセンサーや、依存先が準備できていない制御器が動き出す可能性があります。Lifecycle Nodeは「設定済みだがまだ処理・出力を有効化していない状態」と「実際に動作する状態」を分離します。これにより、起動順序、段階的なアクティベーション、停止後の再初期化を外部から明示できます。

状態照会と遷移要求には、ChangeState、GetState、GetAvailableStates、GetAvailableTransitions などの標準インターフェースを利用できます。

状態と標準遷移

Lifecycle Nodeの主要状態は次の4つです。

Unconfigured: 設定前、またはクリーンアップ後
Inactive: 設定済みだが、処理や出力は未有効化
Active: 処理と出力が有効
Finalized: 終了処理後で、通常の再利用経路から外れた状態

移行中には Configuring、CleaningUp、Activating、Deactivating、ShuttingDown、ErrorProcessing があります。Configureは Unconfigured から Inactive へ、Activateは Inactive から Active へ進めます。Cleanupは Inactive から Unconfigured へ戻し、Shutdownは主要状態から Finalized へ移します。

遷移コールバックは成功、失敗、エラーの結果を返します。成功なら次の状態へ進み、失敗なら原則として遷移前の主要状態へ戻ります。エラーの場合は ErrorProcessing に進み、エラー処理の結果で再初期化または終了へ分岐します。

flowchart LR
  U["Unconfigured"] -->|"Configure"| C["Configuring"]
  C -->|"成功"| I["Inactive"]
  I -->|"Activate"| AT["Activating"]
  AT -->|"成功"| A["Active"]
  A -->|"Deactivate"| D["Deactivating"]
  D -->|"成功"| I
  I -->|"Cleanup"| CL["CleaningUp"]
  CL -->|"成功"| U
  U -->|"Shutdown"| S["ShuttingDown"]
  I -->|"Shutdown"| S
  A -->|"Shutdown"| S
  S -->|"完了"| F["Finalized"]
  C -.->|"エラー"| E["ErrorProcessing"]
  AT -.->|"エラー"| E
  D -.->|"エラー"| E
  CL -.->|"エラー"| E
  S -.->|"エラー"| E
  E -->|"復旧成功"| U
  E -->|"処理失敗・継続不可"| F
  classDef main fill:#e8f1ff,stroke:#3674c5,color:#111;
  classDef transition fill:#fff4d6,stroke:#c28a00,color:#111;
  classDef error fill:#ffe5e5,stroke:#c33,color:#111;
  class U,I,A,F main;
  class C,AT,D,CL,S transition;
  class E error;

Lifecycle Node単体の起動、段階的な停止、遷移エラー時の復旧経路を示す。通常の遷移失敗では遷移前の主要状態へ戻る場合があるため、ErrorProcessingへの分岐はエラー結果を表す。

コールバックの責務を分ける

コールバック	主な責務	設計上の注意
`on_configure`	設定読み込み、デバイス接続、リソース確保	通常出力はまだ有効化しない
`on_activate`	処理・出力の有効化	設定済みの機能だけを実行状態にする
`on_deactivate`	処理・出力の停止	Activeから安全に停止する
`on_cleanup`	確保済みリソースの解放	再Configureできる境界を作る
`on_shutdown`	終了処理	ノードを終了状態へ移す
`on_error`	異常処理	再利用可能性を判定する

センサーの設定や通信資源の確保は on_configure、データ処理や出力の開始は on_activate に置きます。停止時は on_deactivate で処理と出力を止め、再利用しない場合は on_cleanup または on_shutdown で資源を解放します。役割を混在させないことが、再初期化のしやすさにつながります。

リアルタイムなロボットAI基盤：推論・制御・通信の実行予算を設計する

Sun, 14 Jun 2026 01:15:54 +0900

AI推論のベンチマーク値だけで、ロボット全体のリアルタイム性を判断できるのかが気になるテーマです。

先に結論

ロボットのAI処理に、制御30%、推論50%といった普遍的な固定比率はありません。先に制御ループの期限を予約し、センサー入力、アクチュエータ出力、ROS 2通信、スケジューリング干渉、安全余裕を見積もります。その残りをAIに割り当てるのではなく、AIにも独立した周期と期限を設定し、制御が推論の完了を同期的に待たない構成にするのが基本です。

判断には平均推論時間ではなく、前処理、メモリ転送、GPU実行、同期、後処理、ROS 2メッセージ処理まで含むエンドツーエンドのp99.9、最大値、ジッター、期限超過率を使います。AIが期限に間に合わない場合は、直近の有効な結果を使うか、安全なフォールバックへ切り替えます。

なぜ実行予算が必要か

ロボットでは、平均的に速い処理より、まれな期限超過をどう扱うかが重要です。AIが通常は短時間で完了しても、CPUやGPU、メモリ帯域、ドライバ、ログ処理などの競合で一部の周期が遅れれば、制御の決定性は崩れます。実行予算は、周期や締切の中で各処理が使える時間を明示するための枠組みです。

ハードリアルタイム経路では、処理時間の上限を見積もり、動的メモリ割り当て、ページフォールト、無制限に待つロック、非リアルタイムなシステムコールを避けます。これらは平均値には表れにくい遅延要因です。

前提となる仕組み

ROS 2のExecutorは、待機集合から実行可能なサブスクリプション、タイマー、サービス、アクションなどを取り出してコールバックを実行します。SingleThreadedExecutorは単一スレッド、MultiThreadedExecutorは複数スレッドを使います。ただし、一般的なExecutorはハードな優先度順やFIFO実行を保証しません。

Callback Groupには、同時実行を制限するMutually Exclusiveと、同時実行を許すReentrantがあります。これはコールバック間の関係を制御しますが、設定だけで締切やリアルタイム性が保証されるわけではありません。

QoSにはReliability、History、Deadline、Lifespan、Livelinessなどがあります。通信の信頼性、キュー保持、更新期限、データ鮮度を設計できますが、QoSのDeadlineはデータ更新を監視する機能であり、Executorのコールバック開始時刻や処理完了時刻を保証するものではありません。

予算の分け方

まず制御周期を定め、次の順で予算を予約します。

制御計算、センサー入力、アクチュエータ出力
リアルタイム通信処理
スケジューリングや共有資源による干渉
安全・ジッター余裕
AIの前処理、推論、後処理

AIを制御周期の「残り時間」に詰め込むと、推論遅延が制御期限を直接圧迫します。制御スレッドまたはリアルタイム向けExecutorはAIの結果を待たず、利用可能な結果の鮮度を確認して使う構成にします。AIの前処理やROS 2通信は別の実行資源に分け、GPU推論は可能な範囲で非同期に投入します。

設計上の仮置きとして、100 Hz、10 ms周期なら、制御とI/Oを2 ms、ROS 2通信処理を1 ms、AIのエンドツーエンド処理を6 ms、安全・ジッター余裕を1 msと置けます。ただし、これは標準値でも推奨値でもありません。対象のCPU、GPU、モデル、I/O、ROS 2構成を測定して再設定する必要があります。

flowchart LR
  subgraph CYCLE["100 Hz・10 ms周期の仮置き例"]
    CTRL["制御・I/O\n2 ms"] --> COMM["ROS 2通信処理\n1 ms"]
    COMM --> AI["AIエンドツーエンド処理\n6 ms"]
    AI --> MARGIN["安全・ジッター余裕\n1 ms"]
  end
  SENSOR["センサー入力"] --> CTRL
  AI -->|"期限内に取得"| FRESH["鮮度を確認して\n制御で利用"]
  AI -->|"期限超過"| FALLBACK["直近の有効値\nまたは安全なフォールバック"]
  FRESH --> ACT["アクチュエータ出力"]
  FALLBACK --> ACT
  CTRL -.->|"AIの完了を同期的に待たない"| FRESH

制御とI/O、通信、安全余裕を先に確保し、AIを独立した期限で実行する予算設計の仮置き例。2・1・6・1 msは推奨標準値ではなく、対象ハードウェアでの計測後に再設定する。

何を測るべきか

AIの計測点は、センサー取得、ROS 2受信、前処理開始、ホストからデバイスへの転送、GPUカーネルの開始・終了、同期、デバイスからホストへの転送、後処理、制御入力、アクチュエータ出力です。GPU処理は非同期に実行できるため、推論APIの呼び出し時間だけでは実際の完了時間を表しません。

ROS 2のノード合成を使い分ける：コンポーネント、ゼロコピー、障害分離の設計

Wed, 20 May 2026 08:53:24 +0900

ROS 2の「ゼロコピー」は、配置やミドルウェアの条件を分けて考える必要がある点が気になります。

結論：高速化と障害分離は、処理チェーンごとに境界を決める

ROS 2 Jazzyを前提にすると、カメラ画像やLiDAR点群のような大容量データを連続処理する場合、関連するComposable Nodeを同一プロセスのコンポーネントコンテナへ配置し、Intra-process Communicationを使う構成が有力です。通常のプロセス間DDS通信で必要になるシリアライズや外部トランスポート経由の処理を避けられるため、コピー回数、CPU負荷、通信経路上の待ち時間を減らす方向に働きます。

一方、同一プロセス化は障害分離を弱めます。さらに、ゼロコピーは一律に保証されず、メッセージ型、QoS、RMW実装、基盤ミドルウェア、APIの対応状況に左右されます。したがって、通信量の大きい安定した処理チェーンは合成し、実験的なアルゴリズム、頻繁な再起動が必要なノード、障害時にも残したい機能は別プロセスまたは別コンテナへ分ける、という判断が現実的です。

なぜノードの配置が重要なのか

画像や点群の処理では、センサー取得、前処理、認識、記録など複数のノードがデータを受け渡します。このとき、通信方式や実装に応じた経路・保持領域が関係し、処理段数や購読者数は遅延、CPU負荷、メモリ使用量に影響します。

別プロセスに配置したノード間では、通常、ROS 2のDDS/RMW通信経路を通ります。プロセス境界を越えるためのシリアライズやバッファリングが発生しますが、プロセス単位で影響範囲を分けやすい利点があります。逆に、低遅延だけを優先して多数のノードを一つのプロセスへ集約すると、あるノードのクラッシュで同じプロセス内の複数ノードが停止し得ます。

前提となる用語

Composable Node は、ノードを共有ライブラリとしてビルドし、コンポーネントコンテナへ動的にロードする仕組みです。複数のノードを同一プロセスで動かせます。

Intra-process Communication は、同一プロセス内のPublisherとSubscription間で使える通信経路です。通常のプロセス間通信とは異なり、同一プロセス内でメッセージを受け渡し、シリアライズを避けられる場合があります。ただし、別プロセスの購読者へ配信する場合は、DDS経路が必要です。

loaned message は、PublisherがRMWや基盤ミドルウェアからメモリを借りてメッセージを生成する方式です。同一プロセス内でメッセージの所有権を移動する方式とは異なります。

内部の仕組みとデータ経路

同一コンテナ内のPublisherとSubscriptionでIntra-process Communicationを有効にすると、メッセージは通常のプロセス間DDS経路を通らずに処理されます。その結果、プロセス間転送用のシリアライズ、デシリアライズ、外部トランスポート経由の処理を避けられます。これは遅延とCPU負荷を下げる方向に働きますが、ROS 2全体で共通する削減値が決まっているわけではありません。

また、同一プロセス内でもコピーや保持領域が完全になくなるとは限りません。Intra-process Managerの保持領域、QoSの履歴深度、キュー長、購読者数、メッセージの所有権方式によって、メッセージの保持やコピーの挙動が変わります。プロセス間転送用の中間コピーを削減できても、同一プロセス化が常にRSSを減らすとは限りません。

「ゼロコピー」を判断する際は、次の経路を区別します。第一は、同一プロセス内でメッセージの所有権を移動する経路です。第二は、RMWや基盤ミドルウェアからメモリを借りるloaned messageです。第三は、共有メモリトランスポートを利用するプロセス間通信です。これらは実装上の条件が異なり、一般に同じ意味でゼロコピーと呼べるわけではありません。第四の通常のシリアライズによるプロセス間通信は、ゼロコピー方式ではなく比較対象です。

loaned messageは、RMW実装、基盤ミドルウェア、メッセージ型、Publisher APIが対応している場合に利用できます。条件を満たさなければ、通常のメッセージ確保やコピーへフォールバックします。共有メモリ転送も、実装・設定依存であり、ROS 2アプリケーション全体で自動的に有効になるものではありません。

flowchart LR
  subgraph COMPOSED["同一プロセスのComposable Container"]
    C["カメラ"] -->|"Intra-process経路"| P["画像前処理"]
    P -->|"Intra-process経路"| R["認識"]
    P -.->|"外部購読者へはDDS経路"| E["記録・監視ノード"]
    C:::inside
    P:::inside
    R:::inside
  end

  subgraph SEPARATED["別プロセス構成"]
    C2["カメラプロセス"] -->|"DDS/RMW"| P2["前処理プロセス"]
    P2 -->|"DDS/RMW"| R2["認識プロセス"]
    R2 -->|"DDS/RMW"| E2["記録・監視プロセス"]
    C2:::process
    P2:::process
    R2:::process
    E2:::process
  end

  X["プロセス障害"] -.->|"同一アドレス空間のノードへ波及し得る"| COMPOSED
  Y["プロセス障害"] -.->|"プロセス単位で影響範囲を分けやすい"| SEPARATED

  classDef inside fill:#e8f3ff,stroke:#3777b8,stroke-width:1px
  classDef process fill:#f5f5f5,stroke:#666,stroke-width:1px
  style COMPOSED fill:#f2f8ff,stroke:#3777b8,stroke-width:2px
  style SEPARATED fill:#fafafa,stroke:#666,stroke-width:2px

同一プロセス化ではプロセス間転送を減らせる一方、クラッシュ時の影響範囲が広がり得ます。別プロセス化ではDDS/RMW経路が必要になりますが、障害境界を分けやすくなります。外部プロセスへの配信には、合成構成でもDDS経路が発生します。

graph LR
  subgraph COMPOSED[同一プロセス：Composable Container]
    C[カメラ] --> P[前処理]
    P --> R[認識]
  end
  E[記録・監視ノード\n外部プロセス]
  R -->|DDS/RMW\nプロセス間経路| E
  P -.->|Intra-process| R

図では、カメラ、前処理、認識を同一プロセスへ合成し、外部の記録・監視ノードEをプロセス境界の外に置いています。PからEへ出る経路は、同一プロセス内の受け渡しではなく、DDS/RMWなどを経由するプロセス間通信です。

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

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

Jetsonの推論性能を決める量子化・メモリ・電力の最適化手順

Tue, 05 May 2026 00:55:40 +0900

量子化や高クロック化は、設定を変えるだけで結果が決まるわけではありません。実機で何を測るかが、最初の分岐になります。

先に結論

Jetsonの推論最適化は、一般的な速度倍率を当てはめず、実機でモデル単体とエンドツーエンドの両方を計測して決めます。まず入力形状を固定し、FP16・バッチ1を基準にします。その後、INT8の精度とレイテンシ、バッチサイズ、メモリ転送と同期、CUDA Graph、電力モードを一項目ずつ比較します。

INT8はメモリ使用量や推論時間を削減できる可能性がありますが、常にFP16より高速になるわけではありません。ロボット制御のように応答時間を優先するなら小さいバッチ、高スループット処理なら大きいバッチを候補にします。最終判断では、レイテンシ、スループット、精度、ピークメモリ、消費電力、温度、連続稼働時の安定性を同時に確認します。

なぜ実機計測が必要か

TensorRTの性能は、精度モードだけでなく、レイヤー実装、workspace、選択されたtactic、入出力形状、データ変換の組み合わせで決まります。対象Jetsonの世代、JetPack、TensorRT、CUDAの組み合わせによって、INT8演算子の対応やTensor Coreの利用可否も異なります。したがって、モデルの種類だけから最適設定を決めることはできません。

JetsonではCPUとGPUが物理メモリを共有します。離散GPUのようなPCIe転送だけでなく、共有DRAMの帯域競合、キャッシュ、バッファの再配置、同期も性能に影響します。モデル単体のベンチマークが良くても、カメラ取得、前処理、後処理を含めると別の場所がボトルネックになる場合があります。

用語と仕組み

FP32、FP16、INT8は、計算やテンソルを表す精度の選択肢です。低精度化によって、条件によっては演算量やテンソルのメモリ使用量を減らせます。INT8では、キャリブレーションでスケールを推定する方式と、モデルにQ/DQノードを含めて量子化を明示する方式があります。いずれも量子化後のモデル精度を評価しなければなりません。

バッチサイズは一度に処理する入力数です。大きくするとGPU利用効率やスループットが向上する可能性がある一方、1リクエストあたりの待ち時間、キューイング遅延、メモリ使用量が増えます。リアルタイム制御ではバッチ1または小さいバッチ、まとめ処理では大きいバッチを比較します。

入力形状が一定なら固定形状のエンジンを優先します。可変形状が必要な場合は、TensorRTのoptimization profileに最小・最適・最大形状を設定し、実際に使う形状ごとに測定します。

メモリ転送と実行制御

基本的な流れは、入力取得、前処理、TensorRT推論、後処理、出力受け渡しです。前処理から後処理までのテンソルをGPU側に保持し、バッファを再利用できれば、毎フレームのCPU・GPU間コピーや不要な形式変換を減らせます。ただし、Jetsonではゼロコピーや共有バッファが常に最速とは限りません。アクセスパターンと同期コストを実測します。

ホストとデバイス間の移動が必要なら、ページロックされたホストメモリ、非同期コピー、CUDA streamを候補にします。コピーと前処理、またはコピーと推論を重ね合わせられるかを確認します。Nsight Systemsでは、CPU処理、CUDA API、メモリ転送、カーネル、同期を同じタイムラインで確認できます。

入力形状、バッファアドレス、実行経路が安定した反復推論では、TensorRTのCUDA Graphも候補です。実行シーケンスを再利用して、カーネル起動や実行制御のオーバーヘッドを削減できる可能性があります。動的形状や実行時に変化するアドレスがある場合は、適用条件を確認します。

flowchart LR
  A["条件を固定\nJetson型番・JetPack・TensorRT・CUDA\n入力形状・評価データ・電力設定"] --> B["FP16・バッチ1を基準測定"]
  B --> C["モデル単体を測定"]
  B --> D["エンドツーエンドを測定"]
  C --> E["INT8を構築・精度検証"]
  D --> E
  E --> F["バッチサイズを比較\nレイテンシ・スループット・キューイング遅延・ピークメモリ"]
  F --> G["転送と同期をプロファイリング\nCPU・CUDA API・コピー・カーネル・同期"]
  G --> H["バッファ再利用・非同期化・GPU側保持を評価"]
  H --> I["条件が合えばCUDA Graphを評価"]
  I --> J["電力モードとクロック設定を比較"]
  J --> K["総合判断\nレイテンシ・精度・メモリ・電力・温度・連続稼働時の安定性"]
  K --> L{"目標要件を満たすか"}
  L -- "いいえ" --> F
  L -- "はい" --> M["設定と測定結果を記録"]

実機で条件を固定し、モデル単体とエンドツーエンドを測定したうえで、量子化、バッチ、メモリ転送、CUDA Graph、電力設定を一項目ずつ評価する流れ。

再現性のある評価手順

条件を固定する：Jetson型番、JetPack、TensorRT、CUDA、入力形状、評価データ、電力設定を記録します。
基準を測る：FP16・バッチ1を、trtexecなどでモデル単体として測定し、続いて前処理・推論・後処理を含むエンドツーエンドで測ります。
INT8を検証する：キャリブレーションまたはQ/DQ方式で構築し、精度、レイテンシ、変換処理、対応演算子を確認します。
バッチを比較する：バッチ1、小さいバッチ、大きいバッチを、レイテンシ、スループット、キューイング遅延、ピークメモリで比較します。
転送と同期を調べる：GPU側テンソル保持、非同期化、stream、共有バッファ、必要に応じてCUDA Graphを一つずつ比較します。
電力と連続稼働を測る：nvpmodelの電力モードとjetson_clocksのクロック設定を比較し、温度やサーマルスロットリングも確認します。

選択肢の比較

選択肢	向いている要件	利点	注意点
FP16	基準測定、低レイテンシ	比較の出発点にしやすい	INT8よりメモリや計算量が大きい場合がある
INT8	メモリ制約、速度・省電力の改善	低精度化の効果を期待できる	精度、演算子対応、再量子化を検証する
バッチ1・小バッチ	制御、カメラ入力	待ち時間とキューイングを抑えやすい	スループットが伸びない可能性がある
大きいバッチ	まとめ処理、分析	GPU利用効率とスループットに有利な可能性	レイテンシとピークメモリが増える
固定形状	入力サイズが一定	条件を限定して測定しやすい	可変入力には向かない
動的形状	入力サイズが変化	複数形状を扱える	profileごとの性能測定が必要
GPU側保持・非同期化	前処理から後処理までGPUを使う構成	コピーや同期を減らせる可能性	共有バッファの同期を確認する
低電力モード	バッテリー、温度、連続稼働重視	電力と熱を抑える候補になる	目標レイテンシを満たすか測る

制約と判断基準

「INT8なら必ず高速」「バッチを増やせば必ず高性能」と決めつけてはいけません。対象演算子のINT8対応、Tensor Coreの利用可否、再量子化や入出力変換、TensorRT tacticによって結果は変わります。固定形状と動的形状の差、ゼロコピーの効果、CUDA Graphの改善幅も、モデルと実装によって異なります。

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

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点をカメラ座標系へ移し、深度が正の点だけを残します。その後、内部行列と歪みモデルで画像へ再投影し、次の項目を記録します。

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

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["失敗モードと未カバー領域を確認"]

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

要因別に見る選択基準

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

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

Physical AIのモデル更新を監視する：評価・カナリアリリース・ロールバック設計

Sun, 05 Apr 2026 00:41:46 +0900

ロボットAIの更新では、精度の改善がそのまま安全な運用を意味するのかが気になります。

先に結論

Physical AIのモデル更新は、オフラインの認識精度だけで合否を決めてはいけません。更新前に固定シナリオ、シミュレーション、実機リプレイなどで基準性能と安全限界を記録し、更新後はタスク結果、安全イベント、入力変化、推論・通信の健全性を継続的に比較します。リリースはシャドー実行から低リスクのロボットや作業へ段階的に広げ、異常時には独立した安全系で停止またはフォールバックしたうえで、モデルだけでなく関連する実行環境を含む既知の正常版へ戻します。

なぜモデル更新の監視が難しいのか

Webサービスなら、エラー率やレイテンシーをリクエスト単位で追跡しやすい一方、ロボットの性能は環境、個体、作業シナリオ、センサー状態、通信状態に左右されます。入力分布が変わってもタスク結果が維持される場合があり、反対に入力変化が小さくても制御遅延やキャリブレーションのずれが危険動作につながる場合があります。

NISTのAI RMF 1.0も、AIのリスクと性能はデプロイ前だけでなく運用中も測定・監視し、問題への対応や変更管理を行う考え方を示しています。したがって、更新を「モデルファイルの交換」ではなく、変更を観測し、止め、戻せる運用プロセスとして設計する必要があります。

前提となる用語

データセットシフトは、学習時と運用時でデータの分布が変わる現象です。共変量シフト、事前確率シフト、概念シフトなどに分けられます。ただし、入力や予測の分布変化を検出しただけでは、タスク性能の低下や安全リスクを直接証明できません。

カナリアリリースは、新版を一部の対象に限定して投入し、旧版との差を確認してから展開範囲を拡大する方法です。ロボットでは、単純なリクエスト比率ではなく、ロボット個体、拠点、作業シナリオ、危険度を単位にするほうが安全側です。

シャドー実行は、新版を判断や制御への作用なしに動かし、出力や遅延を観測する段階です。実際の作業へ影響を与えない構成にできるなら、低リスクな初期評価になります。

監視すべき指標は一層では足りない

監視項目は、少なくとも次の層に分けて設計します。

入力層：センサー分布、欠損、異常値、OOD（学習分布外）兆候
モデル層：信頼度、予測分布、アクションの飽和や異常な偏り
タスク層：タスク成功率、完了時間、人手介入率
安全層：衝突、ニアミス、接触力や軌道の制約違反
システム層：推論遅延、通信欠落、QoSのdeadline違反、liveliness

これらは更新前の基準値および既知の正常版と比較します。成功率が維持されていても、介入率や推論遅延が増えていれば、将来の失敗や安全余裕の縮小を示す可能性があります。逆に入力ドリフトだけを理由に直ちにロールバックするのではなく、タスク、安全、システムの観測と組み合わせて判断します。共通の閾値や必要サンプル数は製品ごとに異なるため、固定の標準値として扱ってはいけません。

flowchart LR
  subgraph input["入力層"]
    I1["センサー分布"]
    I2["欠損・異常値"]
    I3["OOD兆候"]
  end
  subgraph model["モデル層"]
    M1["信頼度"]
    M2["予測分布"]
    M3["アクションの飽和・偏り"]
  end
  subgraph task["タスク層"]
    T1["タスク成功率"]
    T2["完了時間"]
    T3["人手介入率"]
  end
  subgraph safety["安全層"]
    S1["衝突"]
    S2["ニアミス"]
    S3["接触力・軌道の制約違反"]
  end
  subgraph system["システム層"]
    Y1["推論遅延"]
    Y2["通信欠落・Deadline違反"]
    Y3["Liveliness"]
  end
  I1 --> G["旧版・基準値との比較"]
  I2 --> G
  I3 --> G
  M1 --> G
  M2 --> G
  M3 --> G
  T1 --> G
  T2 --> G
  T3 --> G
  S1 --> G
  S2 --> G
  S3 --> G
  Y1 --> G
  Y2 --> G
  Y3 --> G
  G --> H["リリース・安全ゲート"]
  H --> D["継続監視・展開判断"]

入力分布やモデル出力だけでなく、タスク結果、安全イベント、システム健全性を旧版および更新前の基準値と比較する。

更新から全体展開までの流れ

まず、モデル、前処理・後処理、設定、制御ソフト、依存ライブラリ、キャリブレーション、実行環境を識別できる形で記録します。その組み合わせで固定シナリオと実機・シミュレーションの評価を行い、品質ゲートと安全ゲートを分けて判定します。スループットやコストの改善があっても、衝突、危険動作、安全制約違反を防ぐゲートを通過しなければ展開しません。

ROS 2のQoS設計入門：センサー通信と制御通信の信頼性・遅延をどう両立するか

Mon, 16 Mar 2026 00:29:08 +0900

QoSは設定項目が多く、通信できない原因と遅延の原因が同じ場所に見えやすい点が気になります。

先に結論

ROS 2のQoSは、通信の種類ではなく「古いデータを待つべきか」「欠落を許せるか」「一定時間届かなければ停止すべきか」で決める。カメラ、LiDAR、IMUなどの高頻度センサーは、最新データを処理し続けることを優先し、まずはSensorDataQoS（KEEP_LAST、深度5、BEST_EFFORT、VOLATILE）を候補にする。一方、cmd_velのような制御指令は、受信側との互換性を確認したうえで、浅いキュー、RELIABLE、VOLATILEを出発点に検討する。ただし、再送による古い指令の到着を避けたい場合は、BEST_EFFORTや短いLIFESPANの方が適することもある。

RELIABLEを設定するだけでハードリアルタイム性や安全性が得られるわけではない。DEADLINE、LIFESPAN、受信タイムアウト、ウォッチドッグを、アプリケーションやモーター制御側の停止処理へ接続して初めて、通信断や古い指令に対する動作を設計できる。

なぜQoSの使い分けが必要か

ROS 2のQoSは、パブリッシャーとサブスクライバーという各通信エンドポイントに設定される。メッセージ型やトピック名が同じでも、両者のQoSが互換でなければ通信は成立しない。反対に、通信が成立しても、キューに古いデータを蓄積したり、再送を待ったりする設定では、ロボットの処理に必要な鮮度を失う可能性がある。

センサーと制御指令では、失われたデータの意味が異なる。高頻度センサーでは、処理が追いつかないときに過去のフレームを順番に処理するより、最新フレームへ追従したい場合が多い。制御指令では、確実な配送が必要な場面がある一方、停止後の古い指令を遅れて適用することも避けなければならない。したがって、信頼性と低遅延を単純な優劣で比較するのではなく、データの有効時間と欠落の影響を基準にする。

QoSポリシーの基本用語

ポリシー	意味	設計時の問い
`HISTORY`	保存方式。`KEEP_LAST`は直近の一定数を保持する	過去データをどれだけ残すか
`DEPTH`	`KEEP_LAST`で保存するサンプル数	処理遅延を許容して何件待つか
`RELIABILITY`	配送保証の方式。`RELIABLE`は再送を含む保証、`BEST_EFFORT`は届いたものを扱う	欠落と待ち時間のどちらを重く見るか
`DURABILITY`	新しく参加した受信者へ過去データを保持する方式	購読開始前の値が必要か
`DEADLINE`	データ到着間隔への期待値	周期が途切れたことを検知したいか
`LIFESPAN`	サンプルが有効でいられる期間	古いデータを破棄したいか
`LIVELINESS` / `LEASE_DURATION`	送信者の生存確認に関する設定	送信ノードの停止を監視するか

VOLATILEは過去データを新規参加者へ引き渡す用途ではなく、現在流れているデータを扱う通信に向く。設定値は単独で意味を持つのではなく、送信周期、処理能力、ネットワーク条件と組み合わせて評価する。

センサー通信の設計

JazzyのSensorDataQoSは、KEEP_LAST、深度5、BEST_EFFORT、VOLATILEを基本値とする事前定義プロファイルである。カメラやLiDARのようにデータ量と頻度が大きい通信では、多少の欠落よりも処理の停滞や古いデータの蓄積を避けることが優先される場合がある。そのため、浅いキューとBEST_EFFORTを出発点にし、処理が常に新しい入力へ追従できるかを確認する。

ただし、すべてのセンサーに同じ設定を適用してよいわけではない。欠落が許されないセンサー入力や安全判断に使う低頻度データでは、RELIABLEを個別に検討する。DEPTHを大きくすれば一時的な処理遅延を吸収できる可能性があるが、古いサンプルを処理する時間も増える。実機や対象ネットワークを確認せず、深度の最適値を決めることはできない。

制御通信の設計

cmd_velには、ROS 2全体で強制された単一のQoS標準値はない。ドライバーやノードが選択したQoSに依存するため、トピック名だけからRELIABLEやBEST_EFFORTを推定してはいけない。

初期案としては、RELIABLE、VOLATILE、KEEP_LASTの深度1が考えられる。これは制御指令を確実に届けることと、キューに多数の古い指令を残さないことを両立させる方向である。ただし、通信損失時の再送で古い指令が遅れて届くことを避けたいシステムでは、BEST_EFFORTや短いLIFESPANも候補になる。最終判断は、受信側の要求QoS、ネットワーク損失、指令の有効時間、モーターコントローラーのタイムアウト仕様を確認して行う。

flowchart LR
  S["カメラ・LiDAR・IMUなどのセンサー入力"] --> SQ["SensorDataQoSの初期候補\nKEEP_LAST・深度5\nBEST_EFFORT・VOLATILE"]
  SQ --> SP["処理ノード\n最新データへ追従"]
  SP --> SF["センサー処理"]

  C["cmd_velなどの制御指令"] --> CQ["制御QoSの初期候補\nRELIABLE・VOLATILE\nKEEP_LAST・深度1"]
  CQ --> CM["受信側の要求QoSと互換性を確認"]
  CM -->|"互換"| CT["期限管理\n短いLIFESPANやDEADLINEを検討"]
  CT --> WD["受信タイムアウト・ウォッチドッグ\n停止処理へ接続"]
  WD --> A["アクチュエーター側の停止動作"]
  CM -->|"非互換"| X["通信経路が成立しない\nQoSを確認・調整"]

  R["要件に応じた再評価\n欠落・遅延・古いデータの影響"] -.-> SQ
  R -.-> CQ
  CQ -.->|"古い指令の到着を避けたい場合"| BE["BEST_EFFORTや短いLIFESPANも候補"]
  BE -.-> CT

センサー通信では最新データへの追従を、制御通信ではQoS互換性、指令の有効期限、停止監視を重視する設計の流れを示す。図中の制御QoSは初期候補であり、単一の標準解を示すものではない。

図では、センサー経路を「最新データの継続処理」、制御経路を「指令の期限管理と停止監視」として分けると理解しやすい。QoS不一致の場合は、各種の遅延調整以前に通信経路そのものが成立しない。

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

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

ロボットセンサーの時刻同期設計：カメラ・LiDAR・IMUのデータを正しく重ねる方法

Fri, 06 Mar 2026 00:23:05 +0900

センサー融合では、値の精度だけでなく「いつ取得した値か」の定義が結果を左右します。

先に結論

カメラ・LiDAR・IMUの時刻同期では、近いタイムスタンプのメッセージを組み合わせるだけでは不十分です。まず、各センサーがどのクロックを使い、タイムスタンプが取得時刻、露光時刻、スキャン時刻、受信時刻のどれを表すのかを確認します。そのうえで、可能な範囲ではPTP、PPS、外部トリガーなどを使って共通の時間基準を構築し、残った固定オフセットやドリフトをログから推定します。

補正では、センサー時刻を基準時刻へ変換し、IMUの状態補間、LiDARのデスキュー、カメラの露光時刻モデルを適用します。最後に、共通イベントの時刻差、運動信号の相関、推定残差、再投影誤差を確認します。ROS 2のApproximateTimeはメッセージの対応付けには使えますが、センサー内部の時計を直す機能ではありません。

なぜ時刻同期が問題になるのか

センサーフュージョンでは、同じ「時刻」のデータを重ねているつもりでも、実際には異なる時間基準、単位、エポックを参照していることがあります。センサーが生成した時刻をドライバがホスト受信時刻に置き換えている場合もあります。

ずれは、主に四つに分けて考えます。一定に近い固定オフセット、クロック周波数の差によるドリフト、通信・ドライバの可変遅延、タイムスタンプが示す物理的な時刻の違いです。最後の問題は、数値に固定値を加えるだけでは解消できません。角速度をω、時刻誤差をΔtとすると、短時間近似では角度誤差は概ね|ω|×|Δt|に比例します。高速回転や急加速、動体追跡、点群の画像投影ほど同期ずれの影響が大きくなります。

前提となる時刻の意味

ROS 2ではSystem Time、Steady Time、ROS Timeが区別されます。ROSの時刻とセンサーのハードウェア時刻が自動的に同一になるわけではありません。IMUメッセージのHeader stampは測定時刻として扱われますが、メッセージ定義だけでは、センサーのクロックやドライバが時刻を付与した位置までは保証されません。

カメラでは、フレーム時刻が露光開始、露光中心、露光終了、転送完了のどれを示すかを確認します。ローリングシャッターでは行ごとに露光時刻が異なるため、フレーム全体を単一時刻の観測として扱えるとは限りません。

LiDARの1スキャンも瞬間的な観測とは限りません。ビーム、列、パケットなどで取得時刻が異なる場合があるため、点ごとの時刻、またはセンサー固有のスキャン時刻モデルを使って運動補正します。時刻の提供粒度は機種、ファームウェア、データ形式、ドライバによって異なります。

同期の仕組みと検出方法

PTP（IEEE 1588）は、ネットワーク上のクロック間のオフセットと遅延を測定して同期する標準です。ハードウェアタイムスタンプを使える実装では、ソフトウェアだけで時刻を取得する場合より不確実性を抑えやすくなります。ただし、精度はネットワーク遅延の対称性、タイムスタンプ方式、プロファイル、実装に依存します。ptp4lでネットワーク上のクロックを同期しても、LinuxのPHC、システムクロック、センサーのタイムスタンプ経路まで自動的に同一になるわけではありません。

PPSは時刻基準をそろえる手段、外部トリガーは取得イベントをそろえる手段です。ただし、対応機種、ファームウェア、ドライバによって意味が異なります。同期パルスを入力できても、センサー内部の取得からアプリケーション到着までの遅延は別途検証します。

flowchart LR
  subgraph S1["センサー側の時刻"]
    C["Camera Clock\n露光時刻モデル"]
    L["LiDAR Clock\n点・パケット・スキャン時刻"]
    I["IMU Clock\n測定時刻"]
  end

  P["PTP・PPS・外部トリガー\n利用可能な同期手段"]
  R["Reference Clock\n共通の基準時刻"]
  T["時刻変換\nt_ref = α_i × t_i + β_i"]
  X["共通タイムライン\n対応付け・補間・融合"]

  P -. "クロックまたは取得イベントを同期" .-> C
  P -. "クロックまたは取得イベントを同期" .-> L
  P -. "クロックまたは取得イベントを同期" .-> I
  C --> T
  L --> T
  I --> T
  R --> T
  T --> X

  D["固定オフセット β_i\nクロックレート差 α_i"]
  D -. "ログから推定" .-> T

各センサーの時計とタイムスタンプを共通の基準時刻へ変換し、共通タイムラインでデータを対応付ける概念図。PTPなどを有効にしても、センサーのタイムスタンプ経路や取得時刻の意味は別途確認が必要です。

検出の第一歩は、複数センサーで共通イベントを観測することです。同期パルスや外部イベントについて、各センサーが記録した時刻差を複数回測定し、平均値と分散を求めます。平均的な差は固定オフセット、分散はイベント検出や通信のばらつきを考える材料になります。

Sim-to-Realの性能劣化を分解する：物理パラメータ・センサー・制御の補正手順

Sat, 14 Feb 2026 00:12:29 +0900

シミュレーション上の成功が実機で崩れるとき、物理モデルだけを疑う前に、ログと時間の整合性を確認したくなります。

先に結論

Sim-to-Realで性能が落ちたとき、いきなり摩擦や質量を調整するのは得策ではありません。まず単位、座標系、アクションスケール、時刻、制御周期などのインターフェースを確認し、次にセンサーと遅延、アクチュエータと低レベル制御、剛体・運動学、接触・環境の順で補正します。その後、残る不確実性に対してダイナミクスランダム化、実機データによる分布更新、オンライン適応、方策の再調整を検討します。

この順序は、すべてのロボットやタスクで保証された標準手順ではありません。各段階で学習に使っていない実機ログを検証し、残差のパターンが変わったかを確認することが前提です。

なぜ原因分解が必要か

実機で方策が失敗すると、物理モデルが間違っていると考えがちです。しかし性能差は、観測・レンダリング、時間同期と通信遅延、アクチュエータと低レベル制御、剛体・接触ダイナミクス、環境分布、方策の汎化誤差に分かれます。複数の要因が同じ軌道誤差を生むこともあるため、単一種類のログだけではパラメータを一意に決められない場合があります。

たとえば、定常的な位置や角度のずれはゼロ点や座標系、位相遅れはタイムスタンプ・通信・制御遅延、自由空間での振幅差はゲイン・摩擦・慣性を優先的に疑います。接触時の衝撃や滑りは摩擦、剛性、接触形状の不一致と結び付きやすく、視覚入力時だけ失敗するならカメラやレンダリング分布の差を調べます。

まず確認する用語

システム同定は、実機の入力と状態のログから、質量、摩擦、遅延などのモデルパラメータを推定する考え方です。ダイナミクスランダム化は、質量、摩擦、モーター出力などをエピソードごとに変化させ、単一モデルへの過適合を避ける方法です。視覚系ではテクスチャ、照明、カメラ姿勢、背景、オブジェクト配置などを変化させます。

オンライン適応は、実機の履歴から環境やダイナミクスの潜在状態を推定し、方策を適応させる方法です。固定パラメータの精密化だけでは扱いにくい、時間変化する差への選択肢になります。

実機データでの補正手順

1. ログとインターフェースを監査する

最初に、単位、座標系、アクションのスケール、飽和処理、ログ時刻、制御周期をそろえます。センサー、制御入力、状態推定、時刻情報は同一試験単位で保存し、後から再生できる形にします。ROS 2ではros2 bagに指定トピックを記録・再生できます。

ここが崩れていると、後段で物理パラメータを調整しても、入力と観測の対応がずれたままになります。まず再生ログとシミュレーションの入出力インターフェースが一致するかを確認します。

2. センサー、座標系、時間を合わせる

センサーのバイアス、ゼロ点、外部パラメータ、ノイズ、観測遅延を調べます。視覚入力を使う場合は、テクスチャ、照明、カメラ姿勢、背景、物体配置の差も対象です。実機画像に近い観測分布を作るだけでなく、視覚以外の状態推定値についても、シミュレーションと同じ前処理になっているか確認します。

3. アクチュエータと低レベル制御を合わせる

指令値が同じでも、モーターの応答、トルク制限、内部制御器、フィルタ、遅れによって実際の運動は変わります。脚ロボットなどでは、アクチュエータモデルをシミュレーションに含めることが、剛体パラメータを合わせることとは別の補正対象になります。

4. 剛体・運動学を調整する

質量、重心、慣性、関節減衰などを確認します。重力姿勢や自由空間の運動を使い、剛体モデルと運動学の誤差を切り分けます。MuJoCoのモデル定義では、ボディ、関節、アクチュエータ、センサー、接触・摩擦関連の要素を個別に設定でき、パラメータをカテゴリ別に管理する際の参照になります。

5. 接触と環境を調整する

接触時だけ残差が増える場合は、摩擦、接触剛性、反発、接触形状、床など環境側の条件を調べます。自由空間の運動が合っていても、接触ダイナミクスがずれていれば、滑りや衝撃を再現できません。

flowchart LR
  A["実機で性能劣化"] --> B["残差パターンを観測"]
  B --> C["定常的な位置・角度オフセット"]
  B --> D["位相遅れ"]
  B --> E["自由空間での振幅差"]
  B --> F["接触時の衝撃・滑り"]
  B --> G["視覚入力時だけの失敗"]
  B --> H["時間変化する差"]
  C --> C1["ゼロ点・座標系・初期姿勢"]
  D --> D1["時刻・通信・制御遅延"]
  E --> E1["ゲイン・摩擦・慣性・アクチュエータ"]
  F --> F1["摩擦・剛性・接触形状・環境"]
  G --> G1["カメラ・レンダリング分布・前処理"]
  H --> H1["オンライン適応・履歴からの状態推定"]

実機ログに現れる残差パターンを手掛かりに、優先して確認する原因カテゴリを切り分ける。

6. 不確実性と方策を扱う

点推定したモデルで実機を再現できない場合は、同定値の周囲に不確実性を持たせたダイナミクスランダム化を行います。実機ロールアウトとシミュレーション軌道の差を使い、ランダム化分布やシミュレーションパラメータを更新する方法もあります。それでも時間変化する差が残るなら、オンライン適応や残差方策を追加し、最後に方策自体を再調整します。

イベントカメラをロボットに使う判断：高速動作・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["推論・通信・制御周期を含むエンドツーエンド遅延とは別に評価"]

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

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

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

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

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

ROS 2通信設計の基本：Topic・Service・Actionをどう使い分けるか

Sun, 18 Jan 2026 08:02:39 +0900

Topic・Service・Actionは、名前を覚えるより通信契約の違いから考えると整理しやすいテーマです。

先に結論

ROS 2の通信方式は、処理時間だけでなく、クライアントが何を必要とするかで選びます。基本的な判断は次のとおりです。

Topic：センサー値や状態など、継続的に流れるデータ
Service：短時間で完了する単発の要求と応答
Action：進捗・結果・キャンセルを扱う長時間の処理

「何秒以上ならAction」というROS 2共通の時間閾値はありません。完了通知、途中経過、キャンセル、再実行、複数Goalの扱いまで含むインターフェース契約で判断するのが基本です。

なぜ使い分けが必要なのか

ロボットでは、カメラ画像やオドメトリのように継続的に届く情報と、リセットやモード変更のような一度きりの操作が同時に存在します。さらに、ナビゲーションや軌道実行では、開始後も処理が続き、状態を確認したり途中で中断したりする必要があります。

これらを一つの通信方式で表すと、通信の意味と実装が合わなくなります。長時間処理をServiceにすると進捗やキャンセルを表現しにくくなり、単純な状態配信をActionにすると構成が過剰になります。

前提となる3つの用語

Topic：継続的なデータ配信

Topicは、ノード間でメッセージを交換する名前付きの通信チャネルです。Publisherが発行し、Subscriberが受け取るPublish/Subscribeモデルで、複数のPublisherとSubscriberを疎結合に接続できます。

センサー値、画像、関節状態、自己位置、オドメトリなど、継続的に更新されるデータが代表例です。通常は、個々のメッセージに対する完了応答ではなく、到着したデータを継続的に利用します。

ただし、Topicを選んだだけで通信品質が決まるわけではありません。Reliability、Durability、History、DepthなどのQoSをデータの性質に合わせて設定し、PublisherとSubscriberの互換性も確認する必要があります。

Service：短時間の要求と応答

Serviceは、クライアントがRequestを送り、サーバーがResponseを返す通信です。基本的に一つの要求に対して一つの応答を返すため、短時間で完了する単発処理に向いています。ROS 2の公式ドキュメントも、長時間実行される処理ではなく、短時間で完了する計算にServiceを使うよう説明しています。

移動ロボットのリセットやモード切替、マニピュレータの設定変更、即時に返せる状態照会などが適用例です。

なお、「Serviceは同期通信」という説明では、通信モデルとクライアントの待機方法を区別しなければなりません。通信契約はRequest/Responseですが、rclpyには応答をFutureで受け取るcall_async APIもあります。呼び出し側が非同期APIを使っても、Serviceの契約自体は変わりません。

Action：長時間タスクの実行管理

Actionは、長時間実行される処理を対象とします。クライアントはGoalを送り、実行中にFeedbackを受け取り、最後にResultを取得できます。Goalのキャンセル要求も扱えます。

ROS 2のActionプロトコルは、Goal送信、Result取得、キャンセル要求の3つのServiceと、FeedbackおよびStatusの2つのTopicで構成されます。利用者はAction ClientとAction Serverを通じて、タスクのライフサイクルを扱います。

flowchart TD
  A["通信対象を確認"] --> B{"継続的にデータを配信するか"}
  B -->|"Yes"| C["Topicを選ぶ"]
  C --> D["QoS設定と通信相手との互換性を確認"]
  B -->|"No"| E{"短時間で一つの応答を返す単発処理か"}
  E -->|"Yes"| F["Serviceを選ぶ"]
  E -->|"No"| G{"長時間タスクで進捗・結果・キャンセルのいずれかを扱うか"}
  G -->|"Yes"| H["Actionを検討する"]
  H --> I["キャンセル、複数Goal、Goal切替のポリシーを確認"]
  G -->|"No"| J["必要な通信契約を再整理"]

処理時間だけでなく、継続配信、応答、進捗、結果、キャンセルといった通信契約を基準に方式を選択する。

3方式の比較

観点	Topic	Service	Action
通信モデル	Publish/Subscribe	Request/Response	Goal/Feedback/Result
主な対象	継続的なデータ、状態	短時間の単発要求	長時間のタスク
完了応答	標準的には持たない	一つのResponse	Resultを取得
進捗通知	標準機能として持たない	標準機能として持たない	Feedbackを扱える
キャンセル	契約に含まれない	契約に含まれない	キャンセル要求を扱える
移動ロボットの例	センサー、オドメトリ	リセット、モード切替	ナビゲーション、ドッキング
マニピュレータの例	関節・センサー状態	設定変更、状態照会	把持、搬送、軌道実行
主な注意点	QoS互換性	長時間処理に不向き	停止やGoal管理は実装依存

ロボット機能への適用

移動ロボットでは、センサーノードから認識・制御ノードへ送るセンサー情報、オドメトリ、関節状態などをTopicにします。操作画面からのリセットやモード切替は、短時間で結果を返せるならServiceが候補です。目的地までのナビゲーション、ドッキング、経路追従は、実行中の状態や中断を扱うためActionが適しています。

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の通常制御と安全関連制御を別の機能として定義し、入力、処理、出力、故障時挙動、検証責任を分けることが出発点です。

Jetson上でVLMと物体検出を組み合わせる推論パイプライン設計

Mon, 05 Jan 2026 23:57:34 +0900

JetsonでVLMを使うとき、毎フレーム処理させるべきか、それとも役割を分けるべきかが設計上の分岐点になります。

先に結論

Jetsonでカメラ認識システムを構築するなら、物体検出モデルを高頻度で動かす一次視覚ループ、VLMを必要時だけ呼び出す二次推論ループとして分離するのが基本です。検出器は物体の位置、既知クラス、信頼度、追跡情報を継続的に供給し、VLMは未知物体の説明、属性や関係性の解釈、自然言語による確認を担当します。

VLMを毎フレーム実行すると計算量やメモリ使用量、レイテンシが増えやすくなります。一方、検出器だけでは説明や文脈理解が難しい場合があります。両者を同期処理で直列化するのではなく、検出器とトラッカーを継続させたままVLMを非同期実行することが、リアルタイム性と柔軟な認識を両立する判断になります。

なぜ分担が必要なのか

物体検出器は、既知クラスについて画像中の位置、クラス、信頼度を取得する処理に向きます。ロボットが周囲の物体を追跡し、制御系へ一定間隔で位置情報を渡す用途では、検出器を一次ループに置くのが自然です。

VLMは画像と言語を組み合わせ、画像の説明、質問応答、属性理解、物体間の関係性の解釈などを扱います。したがって、両者は完全な代替ではなく補完関係です。ただし、テキストでカテゴリを指定するオープンセット検出器もあるため、境界は固定的ではありません。必要な出力が「どこに何があるか」なのか、「どのような状態で、何と関係しているか」なのかを先に分けます。

基本用語と内部の仕組み

一次ループは、カメラ入力から前処理、物体検出、トラッキングまでを高頻度で処理する経路です。ここで座標、クラス、信頼度、追跡ID、時刻情報を更新します。二次ループは、一次ループが発生させたイベントを契機に、VLMへ画像と質問や指示文を渡す経路です。

呼び出し条件には、検出信頼度の低下、未知クラス候補、属性や関係性の確認要求、シーン変化、一定間隔の再評価を使えます。毎フレームではなく、不確実性や変化が生じたときに実行することで、VLMの処理量を抑えられます。

VLMへは毎回フルフレームを渡す必要はありません。検出器が得たROI、クラス候補、信頼度、追跡ID、時刻情報を優先し、周囲との位置関係など空間的文脈が必要な場合だけフルフレームを追加します。ROIは対象を絞れますが、周辺情報を失う可能性があるため、質問の内容に応じて切り替えます。

flowchart LR
  A["カメラ入力"] --> B["前処理"] --> C["物体検出"] --> D["トラッカー"]
  D --> E["検出メタデータ更新\n座標・クラス・信頼度・追跡ID・時刻"]
  E --> F["結果統合"]
  E --> G["イベント判定"]
  G --> G1["信頼度低下・未知物体候補\n属性や関係性の確認・シーン変化"]
  G1 --> H["非同期キュー"]
  E --> I["ROI・クラス候補・信頼度\n追跡ID・時刻情報"]
  A -. "空間的文脈が必要な場合" .-> J["フルフレーム"]
  I --> H
  J --> H
  H --> K["VLM推論\n画像またはROI＋質問・指示文"]
  K --> L["VLM結果をメタデータとして追加"]
  L --> F
  F --> M["安全監視"] --> N["制御系・状況理解・オペレーター向け情報"]
  D -. "VLM処理中も継続動作" .-> E

物体検出器とトラッカーを高頻度で継続動作させ、イベント発生時だけVLMを非同期実行する構成。VLMの出力は検出結果を置き換えず、メタデータとして統合します。

VLMの結果は検出結果を置き換えるのではなく、メタデータとして統合する設計が扱いやすいでしょう。VLM処理中も検出器とトラッカーを動かします。DeepStreamのようなGStreamerベースの基盤では、映像入力、前処理、推論、トラッキング、メタデータ処理を接続できます。キューで検出経路とVLM経路を分離すれば、VLMの遅延が検出器や制御系を停止させにくくなります。ただし、特定のVLMプラグインが標準提供されることや、VLMを毎フレーム処理できることを意味しません。

このサイトについて

Thu, 01 Jan 2026 09:00:00 +0900

サイトの目的

Physical AI Hub は、Physical AI・Embodied AI・ロボティクス領域の技術情報を日本語で整理して届ける技術ブログです。ニュースの速報性よりも、長期的に参照できる「技術的な問いへの答え」を重視しています。

AI生成コンテンツの扱い

記事は生成AIを用いて作成されているため、誤りが含まれる可能性があります。重要な技術判断を行う前に、記事内で提示している一次情報を必ずご確認ください。アイキャッチなどの生成画像には「AIによるイメージ画像」であることを明示しています。実機の写真や実測結果として提示することはありません。

免責事項

本サイトの情報の利用によって生じた損害について、運営者は責任を負いません。記載されている製品名・サービス名は各社の商標または登録商標です。