ROS 2 Quality of Serviceは、出版社とサブスクリプション間で交渉される配信およびタイミングのポリシーのセットです。有用なプロファイルは、データが欠落している、遅れている、重複している、または古くなった場合の意味に依存します。すべてのトピックで「信頼できる」を選択すると、ロボットの行動を安全にせずにキューを増やしてしまいます。
連続カメラやライダーサンプルは新鮮さや有界キューを重視することが多い一方で、構成状態は遅れたジョイナーに提供される必要がある場合があります。ロボットコマンドには、トランスポートの信頼性を超えた認識、妥当性、タイムアウトの意味論が必要です。申請契約をそれに関わる DDS メカニズムから切り離してください。
ROS 2リアルタイム制御ガイドとROS 2 DDSセキュリティガイドと一緒に読んでください。選択したプロファイルを実際のROSディストリビューション、RMW実装、ネットワークおよびエグゼキュータ構成でテストします。
古くなったり欠損したデータの結果から選ぶ
各トピックについて、生産率、最大有効年数、許容される損失、遅れた加入者が過去のデータを必要とするかどうか、更新が停止した際に消費者が何をすべきかを明記します。これらの要件は、あらかじめ定義されたセンサーデータやサービスプロファイルから始めるよりも明確です。
失われた画像は、次のフレームが迅速に届くなら無害かもしれません。遅延速度コマンドは、操作者が操作を解除した後も有効のままであれば危険です。マップの修正が抜けていると、ロボットの一貫性がなくなることがあります。トランスポート設定を選択する前に、アプリケーションレスポンスを設計してください。
QoSを一連の通信ポリシーとして捉える
信頼性は、配達の再試行を制御します。歴史と深度制御によってサンプルが保持されました。耐久性は保存されたサンプルが遅れた結合者に届くかどうかを制御します。締め切り、寿命、活気度は異なるタイミングや終点条件を明らかにします。一つのプロファイルは、これらの選択肢とその期間の組み合わせです。
デフォルトはROSのAPI、プロファイル、ミドルウェアによって異なる場合があります。YAMLファイルだけを信用するのではなく、実行時に効果的なエンドポイントポリシーを記録しましょう。現在の ROS 2 QoS 概念のドキュメント は、ポリシーの意味論や要求されたものと提供されたものの互換性について説明しています。
| 方針 | 質問に答えました | 共通リスク | 証拠 |
|---|---|---|---|
| 信頼性 | 再挑戦か許可負けか? | 損失の積み残し | 納入および熟成サンプル |
| 歴史と深さ | 何個のサンプルが待っているのですか? | キューレイテンシ | 深さとコールバック年齢 |
| 耐久性 | 遅れて入社した人はデータを保存しますか? | 一時的な状態 | 再起動動作 |
| 締め切りや寿命 | タイミングが無効になるのはいつですか? | 静かで古臭い使用(サイレント・アンド・デール・ユース) | 出来事と拒否 |
| 活気ある | 作家は生きていると見なされますか? | 誤った健康推定 | リースと申請の心拍 |
適合性は要望および提供されたポリシーに従って行われます
出版社は一定のサービスレベルを提供し、サブスクリプションはそれを求めます。ある組み合わせはコミュニケーションを取るものもあれば、そうでないものもあります。信頼性は方向性があります。信頼できる出版社はベストエフォートの依頼を満たすことができますが、ベストエフォートの出版社は信頼できるリクエストを満たすことはできません。耐久性も同様に要求されたものと提供されたものの関係があります。
ディスカバリーは有益な交換を保証するものではありません。トピック名、タイプ、ドメイン、名前空間、セキュリティ権限、そして関連するすべての QoS ポリシーを比較してください。エンドポイントインフォツールを使って両側を検査してください。互換性警告は証拠として扱い、実際のデータフローとタイミングを確認してください。
信頼できる配達は新鮮さを完成感と交換してしまうことがあります
信頼性の高いトランスポートは、ミドルウェアの挙動やリソース制限に応じて失われたデータをリトライします。混雑や損失のあるリンクでは、リトライや遅いリーダーが新しいサンプルの遅延を引き起こすことがあります。ロボットはすべての保持メッセージを受け取るかもしれませんが、もはや最新でない観測に基づいて行動します。
ソースタイムスタンプを測定し、受信時間と消費時間を測定します。キューをバウンディングし、古いサンプルを破棄すべきかどうかを定義します。信頼性の高いものはイベント、状態遷移、低レートコマンドには適切ですが、ロボットが意図された動作を実行したことをエンドツーエンドで確認するものではありません。
連続センサーにはベストエフォートが適切です
Best Effortは再伝を避け、新しいサンプルが間もなく失われたサンプルに代わる際に流量を維持できます。高速カメラ、ライダー、制限されたリンク上でのテレメトリなどでよく有用です。選択は依然としてタスクに依存します。低レートの安全性関連測定は単なるセンサーのトピックとして片付けることはできません。
最新の状態だけが重要な場合は小さなKeep Last depthを使い、コールバックがそれに追いついているか確認しましょう。ドロップシーケンスや過剰な年齢を検出し、劣化したデータを可視化します。滑らかな可視化では推定量が必要な時間的パターンを受け取ったことを証明できません。
| データクラス | スタートプロフィール | 適用ルール | ストレステスト |
|---|---|---|---|
| 高速カメラ | ベストエフォート、深さは小さい | 最新の有効なフレームを使います | 損失と帯域幅圧 |
| ロボットの状態推定 | タスク固有の信頼性 | 過剰な年齢を拒否する | 低速な消費者およびCPU負荷 |
| 離散モード変換 | 信頼できる | 適用状態を確認する | 再起動と重複配送 |
| 速度指令 | 設計上は信頼性の高いベストエフォート | 短時間有効性と監視犬 | リンクロスと遅延パケット |
| 静的構成 | 信頼性が高く、必要に応じてトランジェントもローカル化 | バージョンと検証 | 後期の結合と置き換え |
ロボットのコマンドには妥当性と認識が必要です
トランスポートの信頼性はミドルウェアの配信動作を示すに過ぎません。受信コントローラーがコマンドを受け入れ、適用、または完了したことを証明するものではありません。コマンド識別子、作成時間、有効性間隔、運用モード、およびアプリケーションプロトコルに必要なシーケンスやエポックを含めてください。
ストリーミングコマンドでは、新規有効な入力が停止すると定義された状態に移行する受信側のウォッチドッグを使用します。目標や取引については、明示的な受け入れ、進捗、完了を返します。再接続後は、保持キューを再生する代わりに、以前のセッションのコマンドを拒否します。
履歴や深さは隠れた遅延を生み出します
深さNで最後を保つと、サンプル数が制限されます。すべてのサンプルを保持しようとする試みはリソース制限内に収めてください。消費者がパブリッシャーより遅い場合、ディープキューは計算過負荷を明らかな低下ではなく、着実に増加するデータ時代へと変えることができます。
プロット、キューの占有率、そしてコールバック開始時の年齢を。ブロックされたコールバック、CPU競合、バーストパブリッシャーを使ってテストします。すべてのサンプルを処理しなければならない場合、資源と背圧のサイズを明示的に設定します。もし最新状態だけが重要な場合は、深さでスループットが解決するのではなく、古い作業をドレインまたは上書きしてください。
耐久性は再起動や遅延ジョイナーの挙動を定義します
Transient Local Durabilitysは、ライターが利用可能な間、互換性のある遅れた購読者のためにサンプルを保持できるようにします。これはマップ、キャリブレーション状態、またはラッチ構成に適しています。また、バージョン設定やライフサイクルの意味論が弱い場合、プロセス再起動後に旧情報を提供することもあります。
パブリッシャー先、購読者前、購読者前、ライター再起動、リーダー再スタート、設定交換のテスト。保持状態にバージョン、タイムスタンプ、有効ドメインを付けます。ホスト障害を乗り越えた回復が必要な場合、耐久性を永続的な真実の代替として使わないでください。
タイミングポリシーは異なる故障を露呈します
デッドラインはサンプル間の期待される間隔を示し、契約が届かないとイベントが発生することがあります。寿命はサンプルが配達対象となる期間を制限します。リビネスは、出版社が選択されたリースおよびアサーションモデルの下で生きているかどうかを追跡します。安全なロボット反応を自動的に定義するものはありません。
各イベントをアプリケーションロジックや観測性に結びつけます。期限を逃すと動作の劣化が求められることがあり、コマンドの期限切れは停止を強制することもあります。リビングプロセスは無効なデータを公開する可能性があるため、必要に応じてミドルウェアイベントとレンジチェック、タイムスタンプ、アプリケーションのハートビートを組み合わせて活用しましょう。
トランスポートは意味論を確認した後のみチューンします
DDS実装は、動作に影響を与えるトランスポート、ディスカバリー、ソケット、メモリ設定を公開します。ROS 2 DDSチューニングガイドはプラットフォームの考慮事項をカバーしていますが、ベンダーのノブは互換性のないプロファイルや公開期間を超えて時間がかかるコールバックを修正することはできません。
まずエンドポイントの互換性とアプリケーションの年齢制限を確立します。その後、パケットロス、再送信、キュー占有、コールバックスケジューリング、CPU負荷を1つのタイムラインでキャプチャします。一度に一層ずつ変更し、テストレコードにはRMW、 DDS ベンダー、構成を正確に保持してください。
録音と再生には独自の QoS プランが必要です
レコーダーは別のサブスクリプションであり、出版社と互換性がある必要があります。Playbackは、読者にマッチするプロフィールを持つもう一つの出版社となります。バッグにはメッセージが入っていても、一時的な状態や締め切り、元の配達時に見られた正確な配信パターンを再現できないことがあります。
記録されたメタデータを検査し、正当化されたプロファイルをオーバーライドし、ターゲットのリプレイトポロジーをテストします。デプロイされたブランチについては rosbag2のソースとドキュメント を読むべきです。ソースのタイムスタンプと設定を記録し、オフライン評価時にリプレイタイミングと物理的なタイミングを混同しないようにします。
制御された故障注入で検証
標準的な負荷、パケットロス、遅延、再順序、帯域幅圧、遅いサブスクリプション、ブロックされたエグゼキュータ、パブリッシャーの再起動、加入者の再起動、そしてエンドポイントの消失をテストしてください。受信シーケンス、サンプル年齢、キュー深度、締め切りイベント、活気度イベント、ロボット応答を測定します。
インターフェース定義の横にトピックコントラクトを公開してください。これにより展開が再現可能になり、将来のノードが通信動作を静かに変えるのを防ぐことができます。
- 文書率、年齢制限、損失許容度。
- 効果的な出版社およびサブスクリプションポリシーを記録しましょう。
- 配達数だけでなく、サンプルの年齢を測定してください。
- ネットワーク、エグゼキュータ、再起動のテスト失敗を。
- バージョン QoS トピックの応用セマンティクスを含んでいます。
よくある質問
すべてのセンサートピックでBest Effortを使うべきでしょうか？
いいえ。正しいポリシーは、サンプル率、置換挙動、損失許容度、そして欠損データの結果に依存します。
Reliableはコマンドの実行を保証しますか？
いいえ。これはミドルウェアの配信に関するものです。アプリケーションには受理、妥当性、ウォッチドッグおよび完了のセマンティクスが必要です。
異なる信頼性設定が常に接続を妨げるのでしょうか？
いいえ。適合性は方向性があります。信頼できるオファーはベストエフォートの要請を満たすことができますが、ベストエフォートのオファーは信頼できる要望を満たすことはできません。
キューの深さが大きいことでデータ損失は防げますか？
より多くのサンプルを保持するかもしれませんが、消費者が遅い場合には遅延が増え、リソースを消耗させることもあります。
なぜ相性が良いトピック QoS 遅くなるのでしょうか？
トランスポートの混雑、コールバックスケジューリング、ロック、CPU負荷、シリアライズ、ディープキューなどは、互換性確立後の消費遅延を引き起こすことがあります。
QoS 行動と安全の境界
QoS 動作はROS配布、RMW実装、ベンダー、オペレーティングシステム、ネットワーク、エグゼキュータの設計 DDS に依存します。完全な申請を検証すること;ミドルウェアの設定だけでは安全機能ではありません。