ROS 2 on Physical AI Hub

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

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