Topic・Service・Actionは、名前を覚えるより通信契約の違いから考えると整理しやすいテーマです。
先に結論
ROS 2の通信方式は、処理時間だけでなく、クライアントが何を必要とするかで選びます。基本的な判断は次のとおりです。
- Topic：センサー値や状態など、継続的に流れるデータ
- Service：短時間で完了する単発の要求と応答
- Action：進捗・結果・キャンセルを扱う長時間の処理
「何秒以上ならAction」というROS 2共通の時間閾値はありません。完了通知、途中経過、キャンセル、再実行、複数Goalの扱いまで含むインターフェース契約で判断するのが基本です。
なぜ使い分けが必要なのか
ロボットでは、カメラ画像やオドメトリのように継続的に届く情報と、リセットやモード変更のような一度きりの操作が同時に存在します。さらに、ナビゲーションや軌道実行では、開始後も処理が続き、状態を確認したり途中で中断したりする必要があります。
これらを一つの通信方式で表すと、通信の意味と実装が合わなくなります。長時間処理をServiceにすると進捗やキャンセルを表現しにくくなり、単純な状態配信をActionにすると構成が過剰になります。
前提となる3つの用語
Topic：継続的なデータ配信
Topicは、ノード間でメッセージを交換する名前付きの通信チャネルです。Publisherが発行し、Subscriberが受け取るPublish/Subscribeモデルで、複数のPublisherとSubscriberを疎結合に接続できます。
センサー値、画像、関節状態、自己位置、オドメトリなど、継続的に更新されるデータが代表例です。通常は、個々のメッセージに対する完了応答ではなく、到着したデータを継続的に利用します。
ただし、Topicを選んだだけで通信品質が決まるわけではありません。Reliability、Durability、History、DepthなどのQoSをデータの性質に合わせて設定し、PublisherとSubscriberの互換性も確認する必要があります。
Service：短時間の要求と応答
Serviceは、クライアントがRequestを送り、サーバーがResponseを返す通信です。基本的に一つの要求に対して一つの応答を返すため、短時間で完了する単発処理に向いています。ROS 2の公式ドキュメントも、長時間実行される処理ではなく、短時間で完了する計算にServiceを使うよう説明しています。
移動ロボットのリセットやモード切替、マニピュレータの設定変更、即時に返せる状態照会などが適用例です。
なお、「Serviceは同期通信」という説明では、通信モデルとクライアントの待機方法を区別しなければなりません。通信契約はRequest/Responseですが、rclpyには応答をFutureで受け取るcall_async APIもあります。呼び出し側が非同期APIを使っても、Serviceの契約自体は変わりません。
Action：長時間タスクの実行管理
Actionは、長時間実行される処理を対象とします。クライアントはGoalを送り、実行中にFeedbackを受け取り、最後にResultを取得できます。Goalのキャンセル要求も扱えます。
ROS 2のActionプロトコルは、Goal送信、Result取得、キャンセル要求の3つのServiceと、FeedbackおよびStatusの2つのTopicで構成されます。利用者はAction ClientとAction Serverを通じて、タスクのライフサイクルを扱います。
flowchart TD
A["通信対象を確認"] --> B{"継続的にデータを配信するか"}
B -->|"Yes"| C["Topicを選ぶ"]
C --> D["QoS設定と通信相手との互換性を確認"]
B -->|"No"| E{"短時間で一つの応答を返す単発処理か"}
E -->|"Yes"| F["Serviceを選ぶ"]
E -->|"No"| G{"長時間タスクで進捗・結果・キャンセルのいずれかを扱うか"}
G -->|"Yes"| H["Actionを検討する"]
H --> I["キャンセル、複数Goal、Goal切替のポリシーを確認"]
G -->|"No"| J["必要な通信契約を再整理"]3方式の比較
| 観点 | Topic | Service | Action |
|---|---|---|---|
| 通信モデル | Publish/Subscribe | Request/Response | Goal/Feedback/Result |
| 主な対象 | 継続的なデータ、状態 | 短時間の単発要求 | 長時間のタスク |
| 完了応答 | 標準的には持たない | 一つのResponse | Resultを取得 |
| 進捗通知 | 標準機能として持たない | 標準機能として持たない | Feedbackを扱える |
| キャンセル | 契約に含まれない | 契約に含まれない | キャンセル要求を扱える |
| 移動ロボットの例 | センサー、オドメトリ | リセット、モード切替 | ナビゲーション、ドッキング |
| マニピュレータの例 | 関節・センサー状態 | 設定変更、状態照会 | 把持、搬送、軌道実行 |
| 主な注意点 | QoS互換性 | 長時間処理に不向き | 停止やGoal管理は実装依存 |
ロボット機能への適用
移動ロボットでは、センサーノードから認識・制御ノードへ送るセンサー情報、オドメトリ、関節状態などをTopicにします。操作画面からのリセットやモード切替は、短時間で結果を返せるならServiceが候補です。目的地までのナビゲーション、ドッキング、経路追従は、実行中の状態や中断を扱うためActionが適しています。
マニピュレータでは、現在の関節状態やセンサー状態をTopicで配信します。即時に返せる設定変更や状態照会はService、把持・搬送・軌道実行のように実行時間と進捗を伴う処理はActionが自然です。これらは通信モデルの性質に基づく一般的な設計例であり、特定製品の必須仕様ではありません。
制約と失敗しやすい点
第一に、長時間処理をServiceへ詰め込まないことです。処理終了まで待つだけの契約では、途中経過やキャンセル、失敗時の状態を扱いにくくなります。これらが必要ならActionを検討します。
第二に、Actionのキャンセルを物理的な即時停止と同一視しないことです。キャンセルを受け付けるか、いつ実際の動作を止めるか、複数Goalを同時実行するか、先行Goalを中断して新しいGoalへ切り替えるかは、Actionサーバー、下位ドライバ、コントローラ、安全機構の実装と運用ポリシーに依存します。
第三に、TopicのQoSを後回しにしないことです。欠損を許容するか、過去の値を新規購読者へ届けるか、履歴をどれだけ保持するかはQoSに関係します。具体的な設定値は、センサーの性質、ネットワーク、RMW実装、リアルタイム要件によって変わります。
採用判断のチェックリスト
- 継続的なデータ配信か：Topic
- 一回の要求に短時間で一つの応答を返せばよいか：Service
- 処理中の進捗や最終結果が必要か：Action
- 実行途中のキャンセルや再実行を契約に含めるか：Actionを検討
- 複数Goalの同時実行や先行Goalの中断方針を定義したか
- TopicのQoSが通信相手と互換になっているか
- ServiceのRequest/Response契約と、クライアントの待機方法を混同していないか
まとめ
Topicは継続的なデータ、Serviceは短時間の単発要求、Actionは進捗・結果・キャンセルを伴う長時間タスクに使い分けます。中心となる判断材料は処理時間だけではなく、完了通知、途中経過、キャンセル、再実行、複数Goalの扱いです。
移動ロボットならセンサーやオドメトリをTopic、リセットやモード変更をService、ナビゲーションをActionにする構成が出発点になります。マニピュレータでも、状態配信はTopic、即時の照会や設定はService、把持や軌道実行はActionという整理ができます。最後にQoS、キャンセル後の停止、下位コントローラとの関係を確認して通信契約を固めます。
参考情報
- About Topics — ROS 2 Jazzy Documentation
- About Services — ROS 2 Jazzy Documentation
- About Actions — ROS 2 Jazzy Documentation
- Actions in ROS 2 — ROS 2 Design
- rclpy.client — ROS 2 Jazzy API Documentation
- About Quality of Service Settings — ROS 2 Jazzy Documentation
- Creating an Action Server and Client — ROS 2 Jazzy Documentation
ロボットの停止や再実行まで含めて考えると、通信方式の選択が実装の安全性にもつながります。
AI利用に関する注記
本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。
