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

Mon, 16 Mar 2026 00:29:08 +0900

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ポリシーの基本用語

ポリシー	意味	設計時の問い
`HISTORY`	保存方式。`KEEP_LAST`は直近の一定数を保持する	過去データをどれだけ残すか
`DEPTH`	`KEEP_LAST`で保存するサンプル数	処理遅延を許容して何件待つか
`RELIABILITY`	配送保証の方式。`RELIABLE`は再送を含む保証、`BEST_EFFORT`は届いたものを扱う	欠落と待ち時間のどちらを重く見るか
`DURABILITY`	新しく参加した受信者へ過去データを保持する方式	購読開始前の値が必要か
`DEADLINE`	データ到着間隔への期待値	周期が途切れたことを検知したいか
`LIFESPAN`	サンプルが有効でいられる期間	古いデータを破棄したいか
`LIVELINESS` / `LEASE_DURATION`	送信者の生存確認に関する設定	送信ノードの停止を監視するか

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は初期候補であり、単一の標準解を示すものではない。