urg_node2_nlの紹介とLifecycleについて考えてみた

はじめに

こんにちは。
大阪大学Robohanという学生ロボコンチームの2025年リーダーでした、れぎっとと申します。(アドカレ遅れてすみません！TOEIC勉強とロボコンの板挟みで多忙すぎました😇)
今回は思いつきでLifecycleなしのLiDARのROS 2ドライバを作成したので紹介させていただこうと思います！
紹介できることは少ないかもしれませんが、Lifecycleの有用性についても再考した記事となっているのでぜひみていってください！

今回作ったものの紹介

今回作ったのは、urg_node2_nlというものです。
北陽電機株式会社様のLiDARをLifecycle
北陽の2DLiDARを動かすCライブラリのurg_libraryをつかい、LifeCycleなしで起動し、データを取得できるようにしています。
特徴としては、

• ROS2 Component・ゼロコピー通信対応
  全てUniquePtrでPublishしています。ゼロコピー通信については以下の記事を参照してください。
  重いLiDARの通信をゼロコピーによって一気に改善することができる可能性があります。
• Lifecycleなし・自動起動
  Launchで呼び出せば即時起動し、接続しているLiDARデバイスに接続してデータを取得できます。

使い方

今回は北陽電機株式会社様よりチームに貸し出していただいたUST-30LXを使わせていただきたいと思います。
めちゃくちゃコンパクトで、かつ30mの範囲を正確に測定できるので、自動ロボットの制作に追いて非常に重宝しています。

イーサネット接続タイプの場合

こちらのparams_ether.yamlをROS2のパラメーターファイルとして、IPアドレスとポートを使用するLiDARに合わせて使ってください。(なお、LiDAR本体のIPアドレス変更にはWindows向けのIP Discoveryなどのツールが必要です。北陽公式サイトに載っています。)

USB接続タイプの場合

こちらのparams_serial.yamlをROS2パラメーターのファイルとして、serial_portを接続したLiDARのシリアルポート(大抵/dev/ttyACM0とか)に合わせてください。
また、シリアルポートは接続する順番に応じて変化するので、2台使いたい場合などには注意してください。

実際に動作させる

今回使うUST-30LXはイーサネット接続タイプです。
PCのネットワークアドレスをLiDARと同じアドレスに合わせてから、イーサネットの線をPCに接続します。
そして、urg_node2_nlをビルドしてから、

source install/setup.bash
ros2 launch urg_node2_nl urg_node2.launch.py

でもう動作します。
rviz2で見ると、こんな感じに実際に動作していることがわかります。
Lifecycle Nodeだと起動後もros2 lifecycleコマンドを打たなければいけなかったり、結構煩雑なのでかなり楽ですね！！

(No image)
※すみません今画像が消えたので明日撮りますorz

注意点

本家urg_node2に存在するintensityやmultiecho機能は使えるようにしているつもりですが実機では未テストです。もし、使えた、使えなかったなどありましたらIssue投げていただければ対応します。

そもそも、Lifecycle Nodeって何？

さて、ここからは一時少しtwitter上でも話題に上がりましたが、LifecycleNodeの是非について考えてみたいと思います。
まずは、軽くLifecycle Nodeの紹介からしたいと思います。
ROS 2におけるLifecycle Nodeは、ROS 2のNodeに状態をもたせ、状態管理をすることで制御をしやすくしたノードとなっています。
以下の画像のような状態を持ち、インターフェース経由で状態を制御できます。

(ROS 2 Design "Managed Nodes"より引用)

主な状態としては、

• Unconfigured
• Inactive
• Active
• Finalized

が存在し、これに加えてトランジション中の

• Configuring
• CleaningUp
• ShuttingDown
• Activating
• Deactivating
• ErrorProcessing

という6状態が存在します。
これらを、主にService通信経由で

実際の書き方や使い方はこちらの記事がわかりやすかったです。

実装例

Lifecycle Nodeを積極的に使って状態管理している例として、有名ナビゲーションパッケージのNavigation2(Nav2)が挙げられます。
Navigation2ではほぼ全てのNodeがLifecycle Nodeで作られており、Lifecycle Managerという管理ノードによって起動順等を制御しています。
参考：

Lifecycle Nodeのいいところ

インターフェースが統一されている

インターフェースが統一されていることにより、ros2 lifecycle ~~~というコマンド経由でLifecycle状態を遷移できたり、Lifecycle共通のメソッドがあり、特に調べずともそのノードの管理ができます。

起動順が制御できる

起動順を制御することで、データが受け取れていないなどの問題を明示的に防ぐことができます。
Launchは複雑なことをしない限り一気にすべてのノードを起動してしまうため、起動タイミングによって挙動が変化するなどを抑止できます。

安全に終了できる

終了時もLifecycleのお作法に従えば、安全な終了動作を実現できます。

Lifecycle Nodeのよくないところ

とにかく状態が多すぎて複雑すぎる

先程書いたとおり、遷移中の状態も合わせると10状態も存在します。そして、上記画像の通り、遷移もかなり複雑なものとなっています。
ロボットの中では場合によっては20ノード以上が動くこともよくあります。
1ノードが10状態も持ってしまったら、複雑過ぎて追いきれません。
また、コードも長くなるため、自分のコードで状態を作ったほうがきれいに済むこともあります。

ROS 2 Componentとの相性が悪い

ROS 2にはComponentという、Nodeをpluginとして複数読み込み、１つのプロセスで動作させることで通信による遅延を防いだり、ゼロコピー通信をすることのできる機能が存在します。LiDAR等の場合、データが大きいため通信するのではなく、こういった方法LiDARのデータを軽量に通信したいことが多いです。
しかしながら、Lifecycle NodeとComponentの相性は悪く、使えないことはないのですがLifecycleをLaunchから遷移できなかったり等、微妙に整備されていない印象です。

１コマンドで起動しない

普通のROS 2ノードはros2 runコマンドでかんたんにノードを即時実行することができます。
この手軽さがROS 2の利便性を支えていると思うのですが、Lifecycleノードはrunした後もros2 lifecycleコマンドを打つなどして状態を遷移してやる必要があります。また、順番を間違えると失敗します。

どういう人にLifecycleが有用なのか

tbd

おわりに

少し話す内容がブレてしまった気はしますが、urg_node2_nlの紹介とLifecycleの是非の検討を行いました。
Nav2のように、Lifecycleを全体のシステムに組み込み、しっかり管理するのであれば非常に有用な存在ですが、単一のパッケージとして出す場合は落とし穴が多い存在だと思っています。
Lifecycleを使うか使わないかを判断する際は、ぜひこれを参考に検討してほしいなと思います。