<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>階層型制御 on Physical AI Hub</title>
    <link>https://physicalaihub.net/tags/%E9%9A%8E%E5%B1%A4%E5%9E%8B%E5%88%B6%E5%BE%A1/</link>
    <description>Recent content in 階層型制御 on Physical AI Hub</description>
    <generator>Hugo</generator>
    <language>ja-jp</language>
    <lastBuildDate>Tue, 29 Sep 2026 14:33:23 +0900</lastBuildDate>
    <atom:link href="https://physicalaihub.net/tags/%E9%9A%8E%E5%B1%A4%E5%9E%8B%E5%88%B6%E5%BE%A1/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>ロボットのタスク実行アーキテクチャ：行動木・状態機械・プランナーの選択基準</title>
      <link>https://physicalaihub.net/posts/robot-task-execution-behavior-tree-state-machine-planner/</link>
      <pubDate>Tue, 29 Sep 2026 14:33:23 +0900</pubDate>
      <guid>https://physicalaihub.net/posts/robot-task-execution-behavior-tree-state-machine-planner/</guid>
      <description>&lt;p&gt;ロボットのタスク実行では、分岐を増やすほど設計方式の選択が難しくなる点が気になった。&lt;/p&gt;&#xA;&lt;h2 id=&#34;結論&#34;&gt;結論&lt;/h2&gt;&#xA;&lt;p&gt;再利用性と検証性を両立しやすいのは、三つの方式から一つを選ぶ構成ではなく、責務を分ける階層型のハイブリッド構成である。タスクの分解と手順の再生成をプランナー、実行・リトライ・回復を行動木、安全モードとノードのライフサイクルを状態機械に担当させる。&lt;/p&gt;&#xA;&lt;p&gt;ただし、常にプランナーを導入する必要はない。固定された状態と安全制約が中心なら状態機械、共通スキルの組み合わせと失敗復帰が中心なら行動木、目標・資源・物体状態に応じて手順を動的に変えるならプランナーを優先する。選定では、再利用単位と検証対象を先に定義し、各層の契約を明示することが判断の軸になる。&lt;/p&gt;&#xA;&lt;h2 id=&#34;なぜ方式の分担が必要か&#34;&gt;なぜ方式の分担が必要か&lt;/h2&gt;&#xA;&lt;p&gt;サービスロボットのタスクには、環境に応じた分岐、並行実行、タイムアウト、キャンセル、リトライ、回復、安全モードへの移行が同時に現れる。これらを一つの巨大な状態機械に詰め込むと、タスク種類や例外、再試行条件の増加に伴って状態と遷移の組み合わせが増え、保守と網羅検証の負担が大きくなり得る。&lt;/p&gt;&#xA;&lt;p&gt;一方、行動木だけで高位のタスク選択まで表現すると、資源や環境の変化に応じた手順の再生成を、多数の分岐として作り込むことになる。プランナーも万能ではない。記号モデルと実世界の状態推定が一致しなければ、生成された計画の妥当性を保てないからである。三方式は競合する実装形式というより、異なる抽象化として比較する方が適切だ。&lt;/p&gt;&#xA;&lt;h2 id=&#34;三つの方式の基本&#34;&gt;三つの方式の基本&lt;/h2&gt;&#xA;&lt;p&gt;&lt;strong&gt;状態機械&lt;/strong&gt;は、状態と遷移を明示的に列挙するモデルである。許可された遷移、到達可能性、モードごとの不変条件を検証計画に落とし込みやすい。ドアの開閉、充電、緊急停止、手動介入、ナビゲーションの有効・無効など、相互排他的で有限個の運用モードに向く。Statechartsのように階層、直交並行性、履歴を備えた拡張もある。&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;行動木&lt;/strong&gt;は、複合ノードを階層的に組み合わせて実行フローを表す。Sequenceは順番に処理し、Fallbackは代替経路を扱い、Decoratorは条件や実行規則を付加する。ノードはSuccess、Failure、Runningなどの結果を返す。サブツリーやノードプラグインを単位に、ナビゲーション、認識、把持、回復処理などの実行パターンを分割し、再利用できる。&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;タスクプランナー&lt;/strong&gt;は、目標に至る手順をモデルから生成する。PDDL系では、ドメインと問題を分離し、アクションの前提条件と効果を記述する。PDDL 2.1では、時間制約、持続アクション、数値フルエントも扱える。目標、利用可能な資源、物体状態、作業順序が変わるタスクで、手順を再生成しやすい。&lt;/p&gt;&#xA;&lt;h2 id=&#34;内部の仕組みと責務分担&#34;&gt;内部の仕組みと責務分担&lt;/h2&gt;&#xA;&lt;p&gt;ハイブリッド構成では、まずプランナーが「何を、どの順序で達成するか」を決める。次に、計画の各ステップを行動木のアクションやスキルへ対応付ける。行動木は実行中の失敗を検知し、Fallback、リトライ、タイムアウト、キャンセルなどを扱う。必要なら実行結果をもとに、プランナーへ再計画を要求する。&lt;/p&gt;&#xA;&lt;p&gt;状態機械は、細かな作業手順ではなく、システム全体の運用モードを管理する。安全停止や手動介入中は行動木の実行を許可せず、条件が整った場合だけ再開させる、といった境界を明示できる。ROS 2のmanaged nodeも、Unconfigured、Inactive、Activeなどのライフサイクル状態と遷移を定義し、ノードの設定、起動、停止、クリーンアップを状態機械として管理する。&lt;/p&gt;&#xA;&lt;figure class=&#34;mermaid-figure&#34;&gt;&#xA;    &lt;pre class=&#34;mermaid&#34; role=&#34;img&#34; aria-label=&#34;タスクプランナーは手順生成、行動木は実行と回復、状態機械は安全・運用モードと実行可否を担当する。実行結果や状態変化は監視され、必要に応じて再計画される。&#34;&gt;flowchart TD&#xA;  G[&#34;目標・物体状態・利用可能な資源&#34;] --&gt; P[&#34;タスクプランナー\nドメイン・問題・アクションから手順を生成&#34;]&#xA;  P --&gt; T[&#34;計画されたタスク手順&#34;]&#xA;  T --&gt; B[&#34;行動木\n実行・リトライ・Fallback・タイムアウト・キャンセル&#34;]&#xA;  B --&gt; N[&#34;再利用可能なスキル\nナビゲーション・認識・把持&#34;]&#xA;  N --&gt; R[&#34;実機上の実行&#34;]&#xA;  R --&gt; M[&#34;実行結果・状態推定&#34;]&#xA;  M --&gt; B&#xA;  M -. &#34;計画が不成立または状態が変化&#34; .-&gt; P&#xA;&#xA;  S[&#34;安全・運用モードの状態機械\n安全停止・手動介入・充電など&#34;] --&gt;|&#34;実行可否を制御&#34;| B&#xA;  S --&gt;|&#34;モード遷移と不変条件&#34;| R&#xA;  L[&#34;ノードのライフサイクル状態\n設定・起動・停止・クリーンアップ&#34;] --&gt; S&#xA;&#xA;  classDef planner fill:#dbeafe,stroke:#2563eb,color:#111827;&#xA;  classDef bt fill:#dcfce7,stroke:#16a34a,color:#111827;&#xA;  classDef state fill:#ffedd5,stroke:#ea580c,color:#111827;&#xA;  class P,T planner;&#xA;  class B,N,R,M bt;&#xA;  class S,L state;&lt;/pre&gt;&lt;figcaption&gt;タスクプランナーは手順生成、行動木は実行と回復、状態機械は安全・運用モードと実行可否を担当する。実行結果や状態変化は監視され、必要に応じて再計画される。&lt;/figcaption&gt;&lt;/figure&gt;&lt;h2 id=&#34;選択肢の比較&#34;&gt;選択肢の比較&lt;/h2&gt;&#xA;&lt;table&gt;&#xA;  &lt;thead&gt;&#xA;      &lt;tr&gt;&#xA;          &lt;th&gt;方式&lt;/th&gt;&#xA;          &lt;th&gt;主な抽象化&lt;/th&gt;&#xA;          &lt;th&gt;得意な変化&lt;/th&gt;&#xA;          &lt;th&gt;再利用単位&lt;/th&gt;&#xA;          &lt;th&gt;検証の中心&lt;/th&gt;&#xA;          &lt;th&gt;失敗・回復&lt;/th&gt;&#xA;      &lt;/tr&gt;&#xA;  &lt;/thead&gt;&#xA;  &lt;tbody&gt;&#xA;      &lt;tr&gt;&#xA;          &lt;td&gt;状態機械&lt;/td&gt;&#xA;          &lt;td&gt;状態と遷移&lt;/td&gt;&#xA;          &lt;td&gt;固定モード、安全条件&lt;/td&gt;&#xA;          &lt;td&gt;状態、遷移、階層状態&lt;/td&gt;&#xA;          &lt;td&gt;到達可能性、遷移、不変条件&lt;/td&gt;&#xA;          &lt;td&gt;遷移先として明示&lt;/td&gt;&#xA;      &lt;/tr&gt;&#xA;      &lt;tr&gt;&#xA;          &lt;td&gt;行動木&lt;/td&gt;&#xA;          &lt;td&gt;ノードと階層フロー&lt;/td&gt;&#xA;          &lt;td&gt;分岐、順序、回復&lt;/td&gt;&#xA;          &lt;td&gt;サブツリー、ノードプラグイン&lt;/td&gt;&#xA;          &lt;td&gt;ノード契約、フロー、結果&lt;/td&gt;&#xA;          &lt;td&gt;Fallback、リトライ、タイムアウト&lt;/td&gt;&#xA;      &lt;/tr&gt;&#xA;      &lt;tr&gt;&#xA;          &lt;td&gt;プランナー&lt;/td&gt;&#xA;          &lt;td&gt;ドメイン、問題、アクション&lt;/td&gt;&#xA;          &lt;td&gt;目標、資源、環境、手順&lt;/td&gt;&#xA;          &lt;td&gt;ドメイン、アクション、スキル&lt;/td&gt;&#xA;          &lt;td&gt;前提条件、効果、計画妥当性&lt;/td&gt;&#xA;          &lt;td&gt;実行監視と再計画&lt;/td&gt;&#xA;      &lt;/tr&gt;&#xA;      &lt;tr&gt;&#xA;          &lt;td&gt;ハイブリッド&lt;/td&gt;&#xA;          &lt;td&gt;三方式の責務分担&lt;/td&gt;&#xA;          &lt;td&gt;動的性と安全要求の両立&lt;/td&gt;&#xA;          &lt;td&gt;各層の契約単位&lt;/td&gt;&#xA;          &lt;td&gt;層ごとの限定モデル&lt;/td&gt;&#xA;          &lt;td&gt;行動木の回復と再計画&lt;/td&gt;&#xA;      &lt;/tr&gt;&#xA;  &lt;/tbody&gt;&#xA;&lt;/table&gt;&#xA;&lt;h2 id=&#34;ros-2での利用場面&#34;&gt;ROS 2での利用場面&lt;/h2&gt;&#xA;&lt;p&gt;ROS 2では、Nav2のBT NavigatorがBehavior Treeでナビゲーションタスクを実行し、XMLで記述されたツリーとBTノードのプラグインを利用する構成を提供している。行動木を実行オーケストレーション層に置く実例として捉えられる。&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
