31. ROS2通信とロボットソフトウェアアーキテクチャ
Seeed Physical AI Beginner's Course 第31章 — ROS2通信とロボットソフトウェアアーキテクチャ：なぜロボットにROS2が必要なのか、ノード、Topic / Service / Action のメカニズム、メッセージインターフェース、QoS、パラメータサーバ、Launchファイル、rosbagツール、そしてロボットソフトウェアがなぜこのようなモジュール構造で作られるのかを学びます。
このステージで必要なハードウェア
このステージのために準備するものです。各ステージの完全な一覧は第3章にあります。
メイン制御ユニット
| 項目 | 購入 | 数量 |
|---|---|---|
| reComputer Robotics J4012 | 🛒 | 1 |
| NVIDIA Jetson AGX Thor 128G | 🛒 | 1 |
デスクトップまたはノートPCも必要です：Ubuntu 22.04、GTX 4080 以上で12GB以上のVRAM、16GB以上のRAM。
このステージ用
| 項目 | 購入 | 数量 |
|---|---|---|
| reBot Arm B601 DM/RS | 🛒 | 1 |
31.1 なぜロボットにROS2が必要なのか？
現代のロボットは通常、さまざまな複雑なハードウェアで構成されています。「見る」ためのカメラ、「考える」ためのコンピュータ、「動く」ためのモータです。もしそれぞれのハードウェアが単独で動くだけなら、ロボットは一歩も動けません。ROS2（Robot Operating System 2）は、Windows や Linux のような従来型のOSではなく、ロボットの「神経系」あるいは「通信ブリッジ」です。標準化された通信ルールのセットを提供することで、認識（目）、計画（脳）、制御（手足）モジュール同士が効率的かつスムーズに情報をやり取りできるようにします。
ROS2と前世代のROS1との中核的な違い（QoSへの布石）：
- ROS1の痛点（集中管理型）：
roscoreと呼ばれる「マネージャ」に依存しています。この「マネージャ」が落ちると、ロボット全体の通信が崩壊します。また、高品質なネットワーク環境を要求し、Wi-Fi が少し弱いだけで切断が発生します。 - ROS2の進化（DDSによる分散型）： 「マネージャ」を完全に排除し、ノード同士がDDS技術に基づいてポイントツーポイントで直接通信します。単一障害点のリスクがなくなるだけでなく、QoS（Quality of Service）が導入され、極めて悪いネットワーク環境や厳しいリアルタイム性が求められる産業シナリオにも適応できます。
31.2 ノード：ロボットの基本作業単位
ROS2の世界では、**ノードは独立したエンティティ（プロセス／プログラム）**です。ロボットソフトウェアアーキテクチャにおける最も基本的な作業単位です。
- 特徴： 1つのタスクにつき1つの専門機能。よく設計されたロボットシステムは、多くの単一目的ノードで構成されます。
- 例： 「カメラノード」は画像を取得するだけ、「モータノード」は車輪を駆動するだけです。これらは独立して動作し、たとえカメラノードがクラッシュしても、モータノードは正常に動作し続けます。
ノードは独立しているのに、どのように協調するのでしょうか？ ここから、ノード間の3つの主要な通信方法の話になります。
31.3 ノード間の通信（メカニズム）：ノード同士がやり取りするための「インターフェース種別」
ノード間の通信は主に3種類に分類されます：Topic、Service、Actionです。
A. Topic
| Topic | Service | Action | |
|---|---|---|---|
| 何か | Publish/Subscribe 型。公式アカウント（WeChatのパブリックフィード）のようなもの | Client/Server 型。電話で道を聞くようなもの | Topic と Service を組み合わせたもので、複雑なタスク向け。アプリで出前を注文するようなイメージ |
| 特徴 | 非同期で一方向のデータフロー。1つのPublisherに対して複数のSubscriberが付き、読み手はいつでも購読解除できる | 同期的で双方向：1リクエスト1レスポンスで、クライアントは通常、応答を待つ間ブロックされる | 進捗フィードバックと途中キャンセルが可能な非同期通信。Goal、Feedback、Result を持つ |
| 例 | 温度センサノードが「現在の温度」を天気アカウントのように配信し、エアコンノードが購読して28度を超えたら冷房を開始する | 電話で道を聞くイメージ：1つの質問に1つの答え。応答が速く、「アームのグリッパを開く」といったタスクに使われる | 出前を注文するイメージ：待っている間に進捗が届き、問題があればキャンセルでき、最後に結果が届く |
| ユースケース | 即時の返信を必要としない、高頻度で連続的なデータ：カメラ映像、LiDAR点群、リアルタイム関節角度 | 明確な結果が必要な短く高速なコマンド：バッテリ残量の問い合わせ、グリッパの開閉、動作モードの切り替え | いつでも中断されうる長時間の複雑な物理動作：アームをAからBへ動かす処理などで、進捗とキャンセルが必要な場合 |
B. Service
Service は Client/Server モデルです。1リクエスト1レスポンスで、クライアントは通常、応答を待つ間ブロックされます。詳細は上の表の Service 列を参照してください。
C. Action
Action は、長時間タスク向けにTopicとServiceを組み合わせたもので、Goal、Feedback、Result の3つの部分から構成されます。詳細は上の表の Action 列を参照してください。
これでノード間の通信方法は分かりました。しかし、実際には何を送っているのでしょうか？ どんなルールに従っているのでしょうか？ 次に登場するのが Message で、情報交換の際に使われる「標準形式」あるいは「共通言語」（データフォーマット）です。
31.4 Message：ノード同士のやり取りのための「輸送フォーマット」
「ノードがどう話すか」（Topic/Service/Action）を理解したら、次は「何をどの形式で話すか」を決める必要があります。ここで登場するのが Message です。
- 何か： ノード間でデータを受け渡しするための標準化されたデータ構造（厳密にフォーマットされた表のようなもの）。
- なぜ必要か： カメラノードが画像データをフォーマットAで送信し、脳ノードがフォーマットBしか理解できなければ、通信は成立しません。ROS2は、汎用画像や汎用速度コマンドなど、膨大な標準Messageをあらかじめ定義しています。全員がこの標準に従ってフォームを埋めさえすれば、どのメーカーのハードウェアでもシームレスに接続できます。
- 3つのメカニズムに対応するMessageフォーマット：
.msg** ファイル（Topic用）：** シンプルなデータパケットです。例えば「速度メッセージ」には、直線速度（前進の速さ）と角速度（どれくらい鋭く曲がるか）だけが含まれます。.srv** ファイル（Service用）：** 上下2つの部分に分かれます。上側がリクエスト（Request）フォーマット、下側がレスポンス（Response）フォーマットを定義し、---で区切られます。.action** ファイル（Action用）：** 3つの部分に分かれ、Goal、Result、連続的なFeedbackのデータフォーマットを定義し、同様に---で区切られます。
通信フォーマットを統一したあと、ノード間通信の品質を維持するのは誰でしょうか？ ROS1と比べて、ROS2のQoSメカニズムがノード通信の安定性とリアルタイム性を維持します。
31.5 QoS（Quality of Service）：ノード間通信の「交通指揮官」
上記の通信の安定性を保証するために、ROS2はQoSを導入しています。通信方法ごとに異なる伝送ルールを設定できます。
- Reliable モード： WeChatメッセージを送るようなもので、相手が必ず受信しなければなりません。下層の仕組みが成功するまで自動的に再送します。
- ユースケース： アームの緊急停止コマンド（Service）など、絶対に失われてはならないもの。
- Best Effort モード： ビデオ通話のようなもので、フレームが1〜2枚落ちても構いません。それよりも極めて低いレイテンシを維持することが重要です。
- ユースケース： 高頻度のカメラフレーム（Topic）。
ここまでで、単一ノードの動作とノード間通信はかなり整ってきました。しかし実際のエンジニアリングでは、多数のセンサやコントローラがあるため、複雑なロボットには数十〜数百のノードが搭載されます。もし起動のたびにそれらを1つずつ手動で立ち上げなければならないとしたら、現実的ではありません。この面倒を解決するために、ROS2はLaunchとParameterのメカニズムを提供しています。
31.6 パラメータサーバとLaunch
A. Launch（Launchメカニズムファイルと自動デプロイ）
- 痛点： 今日のロボットシステムは非常に複雑です。例えば自動運転ロボットを起動するには、LiDARノード、カメラノード、アーム制御ノード、経路計画ノードなど、数十個のノードを一度に立ち上げる必要があるかもしれません。エンジニアが毎回、数十個のターミナルウィンドウを開き、数十個のコマンドを入力しなければならないとしたら、気が狂いそうになりますし、エラーも起きやすくなります（例えば、目のノードより先に脳のノードを起動してしまい、データが取れずに失敗するなど）。
- 何か： ロボットシステムの「ワンクリック起動ボタン」または「交響楽の指揮者」です。Python（またはXML/YAML）で書かれた自動オーケストレーションスクリプトです。
- 特徴（中核的な利点）： カメラ、モータ、経路計画アルゴリズムなど、関連するすべてのノードを「パッケージ化」して一括起動でき、起動順序（ライフサイクル）を管理し、設定済みのパラメータを起動時に一括で配布できます。これにより、開発とデプロイの効率が大幅に向上します。
- 例： スマートホームの「シアターモード」のようなものです。カーテンを閉め、メインライトを消し、テレビをつけ、スピーカーを調整するのを1つずつ手動で行うのではなく、ボタン1つ（1つのLaunchファイルを実行）で、すべてのデバイスがあらかじめ決められた順序と状態で一斉に連携し始めます。
- 実際のユースケース：
- すべてをワンクリックでオーケストレーション： 1つのコマンドで、ロボットの認識・判断・制御システム全体を起動します。
- シナリオ間の高速切り替え： 開発中には2つのLaunchファイルを書くことができます。1つは
sim.launch.py（ノードに仮想環境用のパラメータを割り当ててシミュレーションを行う）、もう1つはreal.launch.py（実機制御用に実ハードウェアのパラメータを割り当てる）です。実行するファイルを変えるだけで、コアコードを一切変更せずに環境をシームレスに切り替えられます。
B. Parameter（パラメータ機構と動的設定）
- 課題感: 例えば、アームをデバッグしていて「動きが速すぎる」と気づいたとします。もし速度を変えるたびに C++ や Python のソースコードを編集し、数分かけて再コンパイルし、プログラムを再起動しなければならないとしたら、開発効率は極端に低くなってしまいます。
- 何か: ノードの実行時の「グローバル設定ディクショナリ」または「コントロールパネル」です。ノードが外部に対して調整可能な変数を公開できるようにします。
- 特徴（中核的な利点）: 最大の特徴は「動的に変更でき、その場で反映される」ことです。基盤となるコードを変更したり再コンパイルしたりすることなく、ロボットの挙動を動的に変更できます。Parameters を使えば、パラメータをその場で調整し、効果をリアルタイムで確認できます。
- 例え: 3D ゲームをプレイしているときのようなものです。設定を変えるためにゲームを終了してコードを変更することはありません。プレイ中に ESC を押して設定メニューを開き、「graphics quality」を下げ、「mouse sensitivity」を上げて保存すると、ゲーム画面は即座に変化します。
- 実際のユースケース:
- ロボットの「グローバル設定ファイル」として: 各モジュールの初期設定を一元管理します。
- ハードウェアパラメータのチューニング: 例えば、カメラの露光や画像解像度、LiDAR のスキャン周波数を動的に調整します。
- リアルタイムなアルゴリズムチューニング: アームの「最大速度」を Parameter にすることができます。テスト中は Launch ファイルから初期値を与えつつ、実行中にコマンドラインから動的に調整し、アームの動きの変化を目視で確認できます。Parameters によって、チューニングは直感的かつ効率的になります。
ロボットが起動して安定して動作するようになったあと、そのロボットが生成するすべてのデータを記録して、後から振り返ったりバグ調査をしたりしたくなったらどうすればよいでしょうか？そこで登場するのが rosbag です。
31.7 rosbag ツール：ロボットの「ドライブレコーダー」
ロボットの開発やデバッグでは、よく次のような課題に直面します。屋外テスト中に予期せぬ事象が発生したのに、研究室に戻ると二度と再現できない。あるいは、実機ロボットのハードウェアは非常に高価で電力消費も大きいため、アルゴリズムを 24 時間 365 日動かし続けることができない、などです。
これらの問題を解決するために、ROS2 は強力な rosbag ツールを提供しています。
- 何か: システム内の任意の Topic 上を流れる Message（LiDAR の点群、カメラ画像、モータ速度など）を、タイムスタンプ付きでありのままローカルファイル（ROS2 では通常 SQLite3 データベース）に記録できます。ロボットの「ドライブレコーダー」のように、後から再生してオフラインデバッグできるよう、Topic 上のすべてを記録します。
- 「だまし」の原理: rosbag ファイルを再生すると、その Topic 群を元の時間順序と周波数で再パブリッシュします。下流のアルゴリズムノード（物体検出や経路計画など）から見ると、データが実際のハードウェアセンサから来ているのか、rosbag のリプレイから来ているのかを区別することはできません。
主要なユースケース
- オフラインでのアルゴリズムデバッグ（最も一般的）: アルゴリズムエンジニアは、炎天下でロボットに付き添う必要はありません。テスターが屋外で多様なシーンを含む rosbag を記録しておけば、エアコンの効いたオフィスでそのデータを何度でも再生し、認識アルゴリズムやナビゲーションアルゴリズムを検証・チューニングできます。
- 現場での事象再現（バグハンティングの切り札）: ロボットが走行中に突然壁に衝突した場合、その瞬間の rosbag を再生することで、開発者はフレームごとに確認できます。カメラは障害物を見落としていなかったか？プランニングノードは誤った軌道を計算していなかったか？それともシャーシが停止コマンドの実行に失敗したのか？といった具合です。
- AI データセット収集: 近年のロボットはディープラーニングモデルに大きく依存しています。rosbag を使えば、後のモデル学習のために大量の実センサデータを簡単に収集できます。
31.8 モジュール化されたロボットシステム
上記のメカニズムを通じて、ROS2 はロボットソフトウェアを非常にモジュール化されたものにします。「LiDAR ノード」を別メーカーのレーダーノードにいつでも置き換えることができ、同じ Message 形式をパブリッシュしている限り、下流の頭脳（プランニングノード）のコードを一切変更する必要はありません。これこそが、現代のロボットソフトウェアアーキテクチャの核心的な魅力です。まとめ: 独立した Node が標準化された Topic/Service/Action 通信を行い、さらに Launch による統一的なオーケストレーションが加わることで、ROS2 は極めてモジュール化されたソフトウェアアーキテクチャを形成し、ロボット開発を LEGO ブロックを組み立てるかのように柔軟なものにします。
章の橋渡し：「神経系」から「機械モデル」へ
もし第 31 章がロボットの「神経系」（通信メカニズム）を構築したのだとすれば、第 32 章ではコンピュータにロボットの「物理的実体」を認識・制御する方法を教え、コンピュータが機械の存在の仕方や空間位置の変換を真に感じ取れるようにします。