ROS 2のQoS (Quality of Service) を試す (1)

DDS (Data Distribution Service) とは、でも取り上げたように、ROS 2で採用された通信ミドルウェアDDSにはQoS (Quality of Service) という新しい考え方が導入されます。

Quality of Service (QoS) と呼ぶいくつかのパラメータを使って通信の信頼性を制御します。 リアルタイムのような応答速度を考慮するなら、DDSはUDPのように調整されます。通信の欠損を許すような通信制御もQoSパラメータの変更で対応できます。

今回と次回は、このQoSを実際にデモを実行して試してみます。

https://github.com/ros2/ros2/wiki/Quality-Of-Service

まず、QoSの制御方法について学んでいきます。

https://github.com/ros2/ros2/wiki/About-Quality-of-Service-Settings

QoSポリシー

QoSを直接制御するオプションをQoSポリシーと呼び、以下の4種類が用意されています。

History

• Keep last: N個分のサンプルを保存します。DepthオプションでNを制御します。
• Keep All: DDSミドルウェアのリソース最大制限まですべてのサンプルを保存します。

Depth

Historyオプションが"Keep last"の場合、そのキューのサイズを決定します。

Reliability

• Best effort: サンプルを配信しますが、ネットワークが不安定な場合、欠損する可能性があります。
• Reliable: サンプルが配信されることを保証します。このため、複数回リトライが起こるかもしれません。

Durability

• Transient local: 遅いタイミングでSubscribeした相手に配信するために、Publish時に最後のサンプルを保持しておきます。ROSのlatched topicと同じですね。
• Volatile: サンプルは保持されません。

QoSプロファイル

上記QoSポリシーを毎回すべて設定していると面倒です。ROS 2はあらかじめ、特定のユースケースに沿って、デフォルトのQoSポリシーの値を設定しているQoSプロファイルを提供しています。

Default

ROS 1のデフォルト設定のPub/Sub通信とほぼ同じQoSポリシーになります。

Services

Defaultと比べ、Volatileの持続性になります。

ROS Serviceはリクエスト・レスポンス形式の呼び出しであるため、期限切れのリクエストに返答することは好ましくありません。

Sensor data

センサデータは、すべてのデータが送受信されるよりも、時刻（タイムスタンプ）に対して厳密でなくてはなりません。

そのため、Best effortの信頼性で、小さいキューサイズに設定されます。

System Default

すべてのQoSポリシーのシステム初期値です。

QoS互換性

QoSプロファイルはPublisherとSubscriberの両方が設定します。両者の接続は、お互いのQoSプロファイルに互換性がある場合のみ成功します。 基本的なルールはSubscriberのQoSプロファイルの方が、PublisherのQoSプロファイルより厳しくなければ互換性があると判断されます。

DurabilityとReliabilityのみ、

https://github.com/ros2/ros2/wiki/About-Quality-of-Service-Settings#qos-compatibilities

から転載します。

Durability

Publisher	Subscriber	Connection	Result
Volatile	Volatile	Yes	Volatile
Volatile	Transient local	No	-
Transient local	Volatile	Yes	Volatile
Transient local	Transient local	Yes	Transient local

Reliability

Publisher	Subscriber	Connection	Result
Best effort	Best effort	Yes	Best effort
Best effort	Reliable	No	-
Reliable	Best effort	Yes	Best effort
Reliable	Reliable	Yes	Reliable

次回

ROS 2のQoSの考え方は、これから非常に大事になってくる勘所ですので、説明が長くなってしまいました。

次回、実際にこのQoSの効果を検証するデモを動かしてみたいと思います。