ROS 2 公式文書（英語） 日本語訳シリーズです。
本ブログの日本語翻訳版のトップページは以下のリンクを参照下さい。
※2019/05/06 現在のものです。
概要
ROS 2 は、ノード間の通信を調整することを可能にする多種多様なサービス品質（QoS）ポリシーを提供します。適切な一連の QoS ポリシーを使用すると、ROS 2 は TCP と同等の信頼性があり、かつ UDP と同程度のベストエフォートが期待できます。
主にTCPのみをサポートする ROS 1 とは異なり、ROS 2 では以下のような状況で、基盤となるDDS転送の柔軟性が発揮されます。
- 「Best effort」ポリシー（後述）がより適しているような損失の多いワイヤレスネットワーク環境
- QoS の期限を厳格に守らなければならないような、適切な品質が要求されるリアルタイムコンピューティングシステム（この場合「Reliable」ポリシーが適している。後述。）
QoS「ポリシー」のセットを統合し、QoS「プロファイル」を形成します。ただし、所与のシナリオに対して正しい QoS ポリシーを選択することは容易ではないので、ROS 2 では一般的なユースケース（例：センサデータ）のための所定の QoS プロファイルを一つ提供しています。もちろん、QoS ポリシーの特定のプロファイルをユーザ側で制御することも可能です。
QoS プロファイルは、パブリッシャ、サブスクライバ、サービスサーバ、およびクライアントに対して指定できます。 QoS プロファイルは、前述の実体（ノード）の各インスタンスに個別に適用できますが、異なるプロファイルが使用されていると、接続できない可能性があります。
QoS ポリシー
基本 QoS プロファイルには現在、次のポリシーの設定が含まれています。
History (履歴)
- keep last：最大 N サンプルまで保存します。N はキューの Depth オプションで設定可能です。
- keep all：すべてのサンプルを保持します。上限は、基盤ドルウェアの構成済みリソース制限に従います。
Depth (深さ)
- Size of the queue："keep last" と一緒に使用した場合にのみ有効です。
Reliability (信頼性)
- Best Effort：サンプルの配信を試みますが、ネットワークが堅牢でないとサンプルを失う可能性があります。
- Reliable：サンプルが配達されることを保証します。場合のよっては複数回再試行します。
Durability (耐久性)
- Transient local：パブリッシャは「遅れて参加する」サブスクライバのサンプルを待ちます。
- Volatile：上記のようなサンプルを待ちません。
各ポリシーには、"system default" というオプションもあります。これは、DDS ベンダーツール（XML 設定ファイルなど）を介して定義される、基礎ミドルウェアのデフォルト値を使用します。 DDS 自体には、設定可能な幅広いポリシーがあります。これらのポリシーは ROS 1 の機能と類似しているため公開されています。将来、ROS 2 ではより多くのポリシーが公開される可能性があります。
ROS 1 との比較
ROS 2 の History ポリシーと Depth ポリシーを組み合わせることで、ROS 1 のキューサイズに似た機能が提供されます。
ROS 2 の Reliability ポリシーは、"best effort" の場合はUDPROS（roscppのみ）、"reliable" の場合はTCPROS（ROS 1のデフォルト）といったイメージです。ただし、ROS 2 の "reliable" ポリシーも UDP を使用して実装されているため、必要に応じてマルチキャストが可能になります。
例えば、Depth を1とし、 Durability ポリシーを有効とすれば、「ラッチ」と同様の挙動をします。
QoS プロファイル
プロファイルを使用すると、QoS 設定を一切気にせずにアプリケーション開発に集中することができます。 QoS プロファイルでは、特定のユースケースでうまく動作することが期待できる一連のポリシーが定義されています。
現在定義されている QoS プロファイルは次のとおりです。
パブリッシャとサブスクライバのデフォルトの QoS 設定
ROS 1からROS 2に移行するには、同様のネットワーク動作で実行することが望ましいです。ROS 2 のデフォルトでは、パブリッシャとサブスクライバのオプションは Reliability を "reliable"に、Durability を "volatile" に、History を "keep last" にしています。
サービス
パブリッシャやサブスクライバと同じように、サービスの Reliability は "reliable" です。また、再起動したサービスサーバーが期限切れの要求を受け取る可能性があるため、サービスの Durability を "volatile" に設定することは特に重要です。
クライアントは複数の応答を受信することはありませんが、サーバーは期限切れの要求を受信するというリスクがあるためです。
センサーデータ
センサーデータの場合、ほとんどの場合、それらすべてを確実に受信するのではなく、適切なタイミングで測定値を受信することが重要です。つまり、開発者はどこかで欠落が生じてしまうリスクを許容しつつ、キャプチャされたらすぐに最新のサンプルを入手する必要があります。そのため、センサーデータプロファイルについては、Reliability を "best effort" に、Depth の "Size of queue" を小さくしてあります。
パラメーター
ROS 2 のパラメータはサービスに基づいているため、サービスと同様のプロファイルを持っていますが、違いがあります。
たとえば、パラメータクライアントがパラメータサービスサーバにアクセスできない場合に、要求が失われないように、パラメータがはるかに大きいキュー項目数を使用することです。（サービスでは逆で、時間切れの要求を破棄している。）
システムのデフォルト
全てのポリシーにおいて、システムデフォルト設定が適用されます。
上記のプロファイルで使用されている特定のポリシーについては、ここをクリックしてください。これらのプロファイルの設定は、コミュニティからのフィードバックに基づいて、さらに調整される可能性があります。
ROS 2 は一般的なユースケースに対していくつかの QoS プロファイルを提供しております。DDS で定義されているポリシーを使用することで、ROS ユーザーは特定のユースケースに対して QoS プロファイルを構成することもできます。そのポリシーは既存の DDS 資料に基づく膨大な知識をベースとしており、この恩恵に預かることができます。
QoSの互換性
注：このセクションではパブリッシャとサブスクライバについて説明しますが、その内容はサービスサーバ・クライアントについても同様に適用されます。
QoS プロファイルは、パブリッシャとサブスクライバに対して個別に設定できます。パブリッシャとサブスクライバ間の接続はペアが互換性のある QoS プロファイルを持っている場合にだけ行われます。
QoS プロファイルの互換性は、「要求 vs 提供者」モデルに基づいて決定されます。要求者側の要求するポリシーが、提供者のポリシーよりも厳しくない場合にのみ接続が行われます。両者のうち、厳しくない方のポリシーが接続で適用されます。
ROS 2 で公開されている QoS ポリシーのうち、互換性に影響を与えるものは、Durability と Reliability のポリシーです。次の表は、さまざまなポリシー設定とその結果の互換性を示しています。
QoS Durabiity プロファイルの互換性：
| パブリッシャ Offerer側 |
サブスクライバ Request側 |
接続 | 結果 | 備考 |
|---|---|---|---|---|
| Volatile | Volatile | OK | Volatile | 両者同一 |
| Volatile | Transient local |
NG | 無し | Request 側 が厳しい |
| Transient local | Volatile | OK | Volatile | Offerer 側 が厳しい |
| Transient local |
Transient local |
OK | Transient local | 両者同一 |
QoS Reliability プロファイルの互換性：
| パブリッシャ Offerer側 |
サブスクライバ Request側 |
接続 | 結果 | 備考 |
|---|---|---|---|---|
| Best effort | Best effort | OK | Best effort | 両者同一 |
| Best effort | Reliable | NG | 無し | Request 側 が厳しい |
| Reliable | Best effort | OK | Volatile | Offerer 側 が厳しい |
| Reliable | Reliable | OK | Transient local | 両者同一 |
接続を確立するには、互換性に影響するすべてのポリシーに互換性がある必要があります。つまり、パブリッシャとサブスクライバのペアが互換性のある信頼性 QoS プロファイルを持っていても、互換性のない耐久性 QoS プロファイルを持っていると、接続は確立されず、その逆も同様です。
