ロボット制御 on Physical AI Hub

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

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

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

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

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

特異点をどう評価するか

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

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

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状態で更新を準備し、遷移時に有効化する実装パターンの参考になります。ただし、それだけで機能安全が保証されるわけではありません。

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

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

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

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 で表される。

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

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

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

計画に反映する選択肢

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

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

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

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	フランジから工具先端への変換	工具姿勢を変えた先端位置	姿勢変更時の先端ずれ
カメラ内部	焦点距離、主点、歪み	複数姿勢の平面パターン画像	画像位置の系統誤差
ハンドアイ外部	カメラとフランジまたはベースの変換	相対運動とカメラ観測	構成と変換方向の整合
非幾何要因	たわみ、温度、バックラッシなど	条件を変えた独立計測	姿勢・方向・時間への依存

実務での校正手順

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

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

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を並行利用できます。

ロボット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

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

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

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

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

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

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などを経由するプロセス間通信です。

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

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

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不一致の場合は、各種の遅延調整以前に通信経路そのものが成立しない。

ロボットセンサーの時刻同期設計：カメラ・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などを有効にしても、センサーのタイムスタンプ経路や取得時刻の意味は別途確認が必要です。

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

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が適しています。