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

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 で資源を解放します。役割を混在させないことが、再初期化のしやすさにつながります。