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

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

先に結論

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;

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

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

複数ノードの起動と停止

Lifecycle仕様は基本的にノード単位の状態機械です。センサー、制御器、ナビゲーションなど複数ノードの依存関係や起動順序を自動的に保証しません。

したがって、依存される下位ノードを先にConfigure・Activateし、依存する上位ノードを後からActivateする列を外部から管理します。たとえば、ハードウェアインターフェース、センサー、制御器、プランナー、アプリケーションの順に起動し、停止時は逆順にDeactivateします。Cleanupも依存関係の逆順で行い、最後にShutdownします。

Nav2のLifecycle Managerは、管理対象ノードの順序付きBringupとShutdown、Lifecycle Serviceの呼び出し、Bondによるノード状態監視を提供します。ただし、遷移失敗を自動解決する機能ではありません。再接続や再試行の方針は、ノードとオーケストレータの構成として定義します。

停止処理と物理安全

停止では、Activeな出力系ノードを先にDeactivateして安全側へ移し、その後に依存関係を逆順で停止・Cleanupします。上位処理だけを止め、下位の出力が残る状態を避けるためです。

ただし、Inactive になったことだけで、モータやアクチュエータが物理的に安全になるとは限りません。on_deactivate、下位のハードウェア・コントローラ、または安全系回路側で、出力停止、トルク遮断、ブレーキなどの動作を明示的に実装する必要があります。Lifecycleの状態と、実際の安全機能が成立するかは分けて確認します。

異常復旧の判断基準

ErrorProcessing の処理が成功すれば、通常は Unconfigured に戻してConfigure・Activateを再試行できます。エラー処理自体が失敗またはエラーになった場合は、Finalized へ移行する設計が定義されています。

一時障害と再利用不能障害を同じ再試行ループに入れないことが判断の基準です。プロセス死の検出や再起動も、外部オーケストレータやプロセス管理機構の責務として分けます。

採用判断のチェックポイント

Lifecycle Nodeの採用価値が高いのは、設定完了と実行開始を分けたい場合、出力を段階的に有効化したい場合、異常後に再初期化する可能性がある場合です。単純な常駐処理で状態分離の効果が小さいなら、通常のNodeの方が構成を簡潔にできます。

設計時は次を決めます。

1. Configureで確保する資源と、Activateで有効化する処理を分ける
2. Deactivateで処理と物理出力をどう安全化するか決める
3. Cleanup後に再Configureできる資源境界を定義する
4. ノード間の依存関係を起動順・停止逆順として記述する
5. 一時障害、再利用不能障害、プロセス消失の復旧先を分ける
6. 採用するROS 2ディストリビューションとオーケストレータの挙動を確認する

まとめ

ROS 2 Lifecycle Nodeは、Unconfigured → Inactive → Active を起動経路、Active → Inactive → Unconfigured → Finalized を段階的な停止経路として使うと整理しやすくなります。コールバックごとに資源確保、出力有効化、停止、解放、終了を割り当て、異常は ErrorProcessing で復旧可能性を判断します。

複数ノードの順序制御とプロセス消失の検出は外部オーケストレータ、物理的な安全停止はハードウェアやコントローラが担います。この責務分担が、実機の起動・停止・異常復旧を再現可能にする基準です。

参考情報

• Managed nodes - ROS 2 Design
• Managed nodes - ROS 2 Documentation
• rclcpp_lifecycle::LifecycleNode Class Reference
• lifecycle_msgs/msg/Transition Documentation
• Lifecycle Manager - Nav2 Documentation
• nav2_lifecycle_manager README

外部オーケストレータによる依存順序と安全停止の責務分担

flowchart TB
  O["外部オーケストレータ\nLifecycle Managerなど"]
  H["ハードウェアインターフェース"]
  S["センサー"]
  C["制御器"]
  P["プランナー"]
  A["アプリケーション"]
  Safe["ハードウェア・コントローラ・安全系回路\n出力停止、トルク遮断、ブレーキなど"]

  O -->|"起動: 下位から順にConfigure・Activate"| H
  O -->|"依存順序"| S
  O -->|"依存順序"| C
  O -->|"依存順序"| P
  O -->|"依存順序"| A
  A -.->|"停止: 上位から下位へDeactivate・Cleanup・Shutdown"| O
  O -.->|"停止要求"| C
  O -.->|"停止要求"| S
  C -->|"物理出力の安全化を実装"| Safe
  S -->|"デバイス・通信状態"| Safe

  classDef orchestrator fill:#e8f1ff,stroke:#3674c5,color:#111;
  classDef node fill:#eef8ee,stroke:#4d9650,color:#111;
  classDef safety fill:#fff0e0,stroke:#c77700,color:#111;
  class O orchestrator;
  class H,S,C,P,A node;
  class Safe safety;

状態遷移を細かく定義するほど、復旧できる障害と停止すべき障害の境界も明確にする必要があります。

AI利用に関する注記

本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。