Post

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)のためにあります。ノードの破棄を可視化することができます。

This post is licensed under CC BY 4.0 by the author.

Comments powered by Disqus.