ROS 2 on Physical AI Hub

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

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

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

先に結論

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

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

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

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

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

管理すべき契約

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

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

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

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

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

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

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

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

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

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

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

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状態だから自動的にアクチュエータ出力が停止する、という保証もありません。

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

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

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ノードのプラグインを利用する構成を提供している。行動木を実行オーケストレーション層に置く実例として捉えられる。

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実装の仕様で確認します。

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, 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、現在の予約、再計画要求、キャンセル結果などを明示的なインターフェースとして定義するとよいでしょう。予約できない候補を割り当てない、遅延が大きくなれば別の候補を再評価する、といった反復が可能になります。

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

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