ROS 2のQoS設計入門：センサー通信と制御通信の信頼性・遅延をどう両立するか

QoSは設定項目が多く、通信できない原因と遅延の原因が同じ場所に見えやすい点が気になります。

先に結論

ROS 2のQoSは、通信の種類ではなく「古いデータを待つべきか」「欠落を許せるか」「一定時間届かなければ停止すべきか」で決める。カメラ、LiDAR、IMUなどの高頻度センサーは、最新データを処理し続けることを優先し、まずはSensorDataQoS（KEEP_LAST、深度5、BEST_EFFORT、VOLATILE）を候補にする。一方、cmd_velのような制御指令は、受信側との互換性を確認したうえで、浅いキュー、RELIABLE、VOLATILEを出発点に検討する。ただし、再送による古い指令の到着を避けたい場合は、BEST_EFFORTや短いLIFESPANの方が適することもある。

RELIABLEを設定するだけでハードリアルタイム性や安全性が得られるわけではない。DEADLINE、LIFESPAN、受信タイムアウト、ウォッチドッグを、アプリケーションやモーター制御側の停止処理へ接続して初めて、通信断や古い指令に対する動作を設計できる。

なぜQoSの使い分けが必要か

ROS 2のQoSは、パブリッシャーとサブスクライバーという各通信エンドポイントに設定される。メッセージ型やトピック名が同じでも、両者のQoSが互換でなければ通信は成立しない。反対に、通信が成立しても、キューに古いデータを蓄積したり、再送を待ったりする設定では、ロボットの処理に必要な鮮度を失う可能性がある。

センサーと制御指令では、失われたデータの意味が異なる。高頻度センサーでは、処理が追いつかないときに過去のフレームを順番に処理するより、最新フレームへ追従したい場合が多い。制御指令では、確実な配送が必要な場面がある一方、停止後の古い指令を遅れて適用することも避けなければならない。したがって、信頼性と低遅延を単純な優劣で比較するのではなく、データの有効時間と欠落の影響を基準にする。

QoSポリシーの基本用語

VOLATILEは過去データを新規参加者へ引き渡す用途ではなく、現在流れているデータを扱う通信に向く。設定値は単独で意味を持つのではなく、送信周期、処理能力、ネットワーク条件と組み合わせて評価する。

センサー通信の設計

JazzyのSensorDataQoSは、KEEP_LAST、深度5、BEST_EFFORT、VOLATILEを基本値とする事前定義プロファイルである。カメラやLiDARのようにデータ量と頻度が大きい通信では、多少の欠落よりも処理の停滞や古いデータの蓄積を避けることが優先される場合がある。そのため、浅いキューとBEST_EFFORTを出発点にし、処理が常に新しい入力へ追従できるかを確認する。

ただし、すべてのセンサーに同じ設定を適用してよいわけではない。欠落が許されないセンサー入力や安全判断に使う低頻度データでは、RELIABLEを個別に検討する。DEPTHを大きくすれば一時的な処理遅延を吸収できる可能性があるが、古いサンプルを処理する時間も増える。実機や対象ネットワークを確認せず、深度の最適値を決めることはできない。

制御通信の設計

cmd_velには、ROS 2全体で強制された単一のQoS標準値はない。ドライバーやノードが選択したQoSに依存するため、トピック名だけからRELIABLEやBEST_EFFORTを推定してはいけない。

初期案としては、RELIABLE、VOLATILE、KEEP_LASTの深度1が考えられる。これは制御指令を確実に届けることと、キューに多数の古い指令を残さないことを両立させる方向である。ただし、通信損失時の再送で古い指令が遅れて届くことを避けたいシステムでは、BEST_EFFORTや短いLIFESPANも候補になる。最終判断は、受信側の要求QoS、ネットワーク損失、指令の有効時間、モーターコントローラーのタイムアウト仕様を確認して行う。

flowchart LR
  S["カメラ・LiDAR・IMUなどのセンサー入力"] --> SQ["SensorDataQoSの初期候補\nKEEP_LAST・深度5\nBEST_EFFORT・VOLATILE"]
  SQ --> SP["処理ノード\n最新データへ追従"]
  SP --> SF["センサー処理"]

  C["cmd_velなどの制御指令"] --> CQ["制御QoSの初期候補\nRELIABLE・VOLATILE\nKEEP_LAST・深度1"]
  CQ --> CM["受信側の要求QoSと互換性を確認"]
  CM -->|"互換"| CT["期限管理\n短いLIFESPANやDEADLINEを検討"]
  CT --> WD["受信タイムアウト・ウォッチドッグ\n停止処理へ接続"]
  WD --> A["アクチュエーター側の停止動作"]
  CM -->|"非互換"| X["通信経路が成立しない\nQoSを確認・調整"]

  R["要件に応じた再評価\n欠落・遅延・古いデータの影響"] -.-> SQ
  R -.-> CQ
  CQ -.->|"古い指令の到着を避けたい場合"| BE["BEST_EFFORTや短いLIFESPANも候補"]
  BE -.-> CT

図では、センサー経路を「最新データの継続処理」、制御経路を「指令の期限管理と停止監視」として分けると理解しやすい。QoS不一致の場合は、各種の遅延調整以前に通信経路そのものが成立しない。

通信種別ごとの比較

互換性と不具合の切り分け

QoS互換性は、パブリッシャーが提供するQoSと、サブスクライバーが要求するQoSの組み合わせで決まる。たとえば、BEST_EFFORTを要求するサブスクライバーは、RELIABLEを提供するパブリッシャーとも接続できる。一方、RELIABLEを要求するサブスクライバーは、BEST_EFFORTを提供するパブリッシャーとは互換にならない。

通信が見えないときは、まず次の順で確認する。

1. ros2 topic info <topic> --verboseで、実際のパブリッシャーとサブスクライバーのQoSを確認する。
2. RELIABILITYとDURABILITYの非互換を確認する。
3. DEPTHとキューの蓄積、送信周期、受信側の処理遅延を確認する。
4. LIFESPANが短すぎないか、受信タイムアウトが厳しすぎないかを確認する。
5. DEADLINEイベントやタイムアウトを、停止処理へ接続できているか確認する。

SYSTEM_DEFAULTに依存する設定は、RMW実装やミドルウェア設定に左右される可能性がある。重要なセンサー経路や制御経路では、対象ディストリビューション、RMW実装、ネットワーク条件を固定して、QoSを明示的に設定・確認する方が再現性を確保しやすい。

採用判断の基準

まず、データが欠落したときに「次のサンプルで置き換えられるか」を判断する。置き換えられるなら、BEST_EFFORT、VOLATILE、浅いKEEP_LASTが候補になる。欠落が重大ならRELIABLEを検討するが、再送による待ち時間と古いデータの到着を評価する。

次に、データの有効時間を決める。期限を超えたサンプルを使うべきでないならLIFESPAN、期待周期の途切れを検知したいならDEADLINEを使う。ただし、どちらもモーターを自動停止する機能ではない。受信タイムアウト、ゼロ指令、アプリケーション側の停止処理、またはハードウェアウォッチドッグへ明示的に接続する必要がある。

まとめ

ROS 2のQoS設計では、センサーを常にBEST_EFFORT、制御を常にRELIABLEと決め打ちしないことが重要である。センサーは鮮度、制御は指令の有効時間と停止動作を中心に考え、提供QoSと要求QoSの互換性を実行時に確認する。特にcmd_velの設定には全体共通の正解がない。QoSの値、実際の通信状態、タイムアウト時の安全動作を一体として設計することが、信頼性と遅延を両立する基本になる。

参考情報

• ROS 2 Documentation: About Quality of Service settings
• ros2/rmw: Predefined QoS profiles
• rclcpp API: class rclcpp::SensorDataQoS
• Object Management Group: Data Distribution Service, Version 1.4
• ROS 2 Documentation: Understanding ROS 2 topics

最終的なQoSの妥当性は、値の選択だけでなく、期限切れや通信断の際にロボットがどう停止するかまで含めて確認したいところです。

AI利用に関する注記

本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。