ROS 2ノードのライフサイクルを理解する (1)
前回、前々回はROS 2のデモの一つであるQoS (Quality of Service) を試す記事を投稿しました。
技術的にも新しく学びも多かったため、今回から以降のデモも一つずつ取り上げていこうと思います。 毎回、初めに技術紹介、次にデモ実行というルーチンで基本的に進んでいきます。
https://github.com/ros2/ros2/wiki/Tutorials#ros-2-demos
本日は、ROS 2ノードのライフサイクルに関する以下の二つの記事を日本語に要約、意訳していきます。
ライフサイクルといえば大体こうなるのでしょうが、OpenRTMのライフサイクルの状態遷移と非常に似通っています。
ノードのライフサイクル
ROSシステムをより良く制御するため、管理されたライフサイクルをROS 2ノードに導入します。 これにより、roslaunchはコンポーネント同士の実行開始、接続順序を制御し、正しく起動させることができるようになります。 これは、ROS 1でたまに問題になる部分でした。
一番重要なコンセプトは、ライフサイクルの状態遷移に沿って実行できれば、それ以外の部分（つまり状態の実装）は完全にブラックボックスになる点です。
ノードのライフサイクルには、4つの主要状態があります。
- Unconfigured: 構成前
- Inactive: 未活動状態
- Active: 活動状態
- Finalized: 終了処理後
主要状態を遷移するには外部からの処理呼び出しが必要です。 ただし、Active状態からのエラー検出時のみ自動で遷移します。
主要状態以外に6つの中間状態があります。
- Configuring: 構成中
- CleaningUp: 終了処理中
- ShuttingDown: 停止中
- Activating: 活動状態へ移行中
- Deactivating: 未活動状態へ移行中
- ErrorProcessing: エラー処理中
これらの中間状態のときに、onCleanupなどのユーザ定義のコールバック関数が呼び出されます。
Unconfigured
ノードの起動後、すぐに遷移する状態です。エラーが起きた時にも、この状態に戻ります。
Inactive
ノードが何も処理を行っていない状態です。 ノードのパラメータを変えたり、トピックのPub/Sub構成を変えたりするために、ノードを（再）Unconfigured状態にさせるために用いられます。
この状態では、トピックやサービスリクエストが届いても、読み込み、データ処理、サービスリクエストの返答といったことはできません。 QoSポリシーに従い、これらのトピックやサービスリクエストは保留されます。
Active
ノードの一番メインとなる状態です。 この状態では、トピック、サービスの入出力、データ処理が行われます。
もし、ノードもしくはシステムで解決できないエラーを検出した場合、自動的にShuttingDown状態に遷移します。
Finalized
ノードが破棄される直前に遷移する状態です。この状態からは破棄以外、他の状態に遷移できません。
この状態は、デバッグや自己検証（訳注：introspection）のためにあります。ノードの破棄を可視化することができます。
Comments powered by Disqus.