ROS 2 服務質量是一套由釋出端與訂閱端商定的交付和時序策略。有用的設定檔取決於資料在缺失、遲交、重複或陳舊時的含義。為每個主題選擇“可靠”可以增加佇列，同時不保證機器人行為安全。
連續攝影機或光達取樣通常更有利於新鮮性和有界佇列，而設定狀態可能需要傳遞給後加入者。機器人命令需要確認、有效性和超時語意，而不僅僅是傳輸可靠性。將應用合約與承載它的 DDS 機制分開。
請閱讀 ROS 2 即時控制指南 和 ROS 2 DDS 安全指南。在實際 ROS 發行版、 RMW 實現、網路和致動器設定上測試所選設定檔。
從陳舊或缺失資料的後果中選擇
對於每個主題，請說明生產速率、最大使用壽命、可接受損失、遲到的使用者是否需要之前的資料，以及更新停止時消費者應採取的措施。這些要求比從預設的感測器資料或服務設定檔開始更為清晰。
如果下一影格及時到達，丟失的影像可能無害。延遲速度命令如果操作員鬆開控制後仍有效，則可能存在危險。缺少地圖修訂可能導致機器人不一致。在選擇傳輸設定前，先設計應用反應。
把 QoS 理解為一組策略
可靠性控制是否重試送達。歷史和深度控制保留樣本。耐久性控制儲存樣本是否能到達晚接合者。截止時間、壽命和活力揭示了不同的時間或終點條件。其中一種設定是這些選擇及其持續時間的組合。
預設值可能因 ROS API、設定檔和中介軟體而異。在執行時記錄有效的端點策略，而不是僅信任 YAML 檔案。目前的 ROS 2 QoS 概念檔案描述了策略語意以及請求與提供的相容性。
| 策略 | 問題已解答 | 常見風險 | 證據 |
|---|---|---|---|
| 可靠性 | 重試還是允許失敗？ | 虧損積壓 | 交付和陳化樣品 |
| 歷史與深度 | 有多少樣本要等？ | 佇列延遲 | 佇列深度與回呼時資料時效 |
| 耐久性 | 晚加入的人會獲得儲存的資料嗎？ | 過時瞬態 | 重啟行為 |
| 截止日期或使用壽命 | 什麼時候時機無效？ | 無言陳舊使用 | 事件與拒絕 |
| 活力 | 作者被認為是活著的嗎？ | 錯誤健康推斷 | 租賃與申請心跳 |
相容性遵循所請求和提供的策略
釋出者提供一定的服務水平，訂閱者則請求相應的服務。有些組合能夠溝通，有些則不會。可靠性是方向性的：一個可靠的釋出者可以滿足盡力而為的請求，而盡力而為的釋出者則無法滿足可靠的請求。耐久性與請求與提供之間的關係類似。
發現並不保證有用的交換。比較主題名稱、類型、域、名稱空間、安全權限及所有相關 QoS 策略。使用端點資訊工具檢查雙方。將相容性警告視為證據，但確認實際資料流和時間。
可靠的交付可能會用新鮮感換取完成度
可靠的傳輸會根據中介軟體行為和資源限制重試丟失的資料。在擁塞或有損鏈路上，重試和讀取速度慢可能會延遲新樣本。機器人可能接收所有保留的訊息，但對已不再目前的觀測資料採取行動。
測量源時間戳、接收時間和消耗時間。繫結佇列並定義是否應丟棄舊樣本。可靠適用於事件、狀態轉換或低速率命令，但無法提供機器人執行預定動作的端對端確認。
對於連續感測器，盡力而為是正確的
“盡力而為”（Best Effort）模式避免重傳，並在新樣本很快會替代丟失的樣本時保持流量。它通常適用於高速攝影機、光達和受限鏈路遙測。選擇仍取決於任務：低速率安全相關測量不能僅作為感測器主題。
當只有最新狀態重要時，使用較小的“保持最後”深度，並確認回呼是否跟上。檢測遺漏序列和過高老化，使退化資料可見。平滑的視覺化無法證明估計器是否獲得了所需的時間模式。
| 資料類 | 起始簡介 | 應用規則 | 壓力測試 |
|---|---|---|---|
| 高速攝影機 | 盡力而為，深度小 | 使用最新的有效影格 | 損耗與頻寬壓力 |
| 機器人狀態估計 | 任務特定可靠性 | 拒絕過度衰老 | 低消費和 CPU 負載 |
| 離散模式轉換 | 可靠 | 確認已應用狀態 | 重啟與重複交付 |
| 速度指令 | 設計上是可靠或盡力而為 | 短有效期加看門狗 | 鏈路丟失與延遲資料包 |
| 靜態設定 | 可靠且需要臨時本地 | 版本與驗證 | 遲來的加入與替換 |
機器人命令需要有效性和確認
傳輸可靠性僅表示中介軟體交付行為。它並不證明接收端控制器接受、應用或完成了命令。請在應用協議中包含命令身份、建立時間、有效性間隔、操作模式以及所需的序列或紀元。
對於流式命令，使用接收端看門狗，當新有效輸入停止時，該看門狗會移動到定義狀態。對於目標或事務，返回顯式的接受、進度和完成。重新連線後，拒絕之前會話的命令，而不是重放保留的佇列。
歷史和深度可能導致隱藏的延遲
保持最後，深度為 N 保留的樣本數量有界。保持所有嘗試保留每個樣本在資源限制內。如果消費者速度比釋出者慢，深度佇列可以將計算過載轉化為資料年齡的穩步增加，而非明顯的下降。
在回呼開始時繪製佇列佔用率和年齡。測試阻塞回呼、 CPU 爭用和突發釋出。如果每個樣本都必須處理，則明確調整資源大小和背壓；如果只有最新狀態重要，則用排水或覆蓋舊工作，而不是假裝深度能解決吞吐量問題。
耐久性定義了重啟和晚加入者的行為
瞬態本地耐久性允許寫入者在寫入者保持可用時，為相容的遲訂使用者保留樣本。這適用於對映、校正狀態或鎖存設定。如果版本控制和生命週期語意較弱，程式重啟後也能傳遞過時資訊。
測試釋出者優先訂閱者和訂閱者優先排序、寫入重啟、讀者重啟和設定替換。將版本、時間戳和有效性域附加到保留狀態。當需要跨主機故障恢復時，不要用永續性代替持久的真實源。
時序策略會暴露不同的故障
截止時間描述了樣品之間的預期間隔，並在錯過合約時可能引發事件。生命週期限制樣品有資格交付的時間。活躍度跟蹤釋出者在所選租賃和宣告模型下是否被視為存活。無任何一個自動定義安全的機器人反應。
每個事件與應用邏輯和可觀測性相連線。錯過截止日期可能會要求降級操作，而命令過期則可能強制停止。活程式可能會發布無效資料，因此在需要時將中介軟體事件與範圍檢查、時間戳和應用心跳結合起來。
僅在確認語意後進行調諧傳輸
DDS 實現會暴露影響行為的傳輸、發現、套接字和記憶體設定。 ROS 2 DDS 調優指南 涵蓋了平台相關因素，但廠商旋鈕無法修復不相容的設定檔或超過釋出期限的回呼。
首先確定端點相容性和應用年齡限制。然後在同一時間線上記錄丟包、重傳、佇列佔用、回呼排程和 CPU 負載。一次只更換一層，並在測試記錄中保留精確的 RMW、 DDS 廠商和設定。
錄音和回放需要自己的 QoS 計劃
記錄器本身也是一個訂閱端，必須與釋出者相容。播放則成為另一個釋出者，其設定檔必須與讀者匹配。一個 rosbag 資料包可能包含訊息，但無法重現瞬態、截止日期或原始播放時的準確傳遞模式。
檢查錄製的後設資料，覆蓋有正當理由的設定檔，並測試目標回放拓撲。部署分支應閱讀 rosbag2 原始碼和檔案。記錄源時間戳和設定，以避免離線評估將重放時間與物理時間混淆。
透過受控失效注入驗證
測試名義負載、丟包、延遲、重排、頻寬壓力、緩慢訂閱、阻塞致動器、釋出者重啟、訂閱者重啟及終端消失。測量接收序列、樣本年齡、佇列深度、截止日期事件、活躍度事件和機器人反應。
在介面定義旁邊釋出主題契約。這樣可以讓部署變得可重複，並防止未來的節點無聲地改變通訊行為。
評估“感測器資料和機器人指令 ROS 2 QoS”時，還應儲存模型版本、機器人設定、校正檔案、測試日期和全部試驗記錄。
- 檔案率、年齡限制和損失容忍度。
- 記錄有效的釋出者和訂閱策略。
- 測量樣本年齡，而非僅測量交付數量。
- 測試網路、致動器和重啟失敗。
- 版本 QoS 包含主題的應用語意。
常見問題
每個感測器主題都應該使用盡力而為嗎？
不。正確的策略取決於取樣率、替換行為、容錯度以及缺失資料的結果。
可靠能保證命令會執行嗎？
不是。它涉及中介軟體交付。應用需要接受、有效性、看門狗和完成語意。
不同的可靠性設定會總是阻止連線嗎？
不。相容性是方向性的：一個可靠的報價可以滿足盡力而為的請求，但盡力而為的報價無法滿足可靠的請求。
更高的佇列深度能防止資料丟失嗎？
它可能保留更多采樣，但當使用者速度較慢時，也可能增加延遲並消耗資源。
為什麼一個主題即使 QoS 相容，也會晚交？
傳輸擁堵、回呼排程、鎖、 CPU 負載、序列化和深度佇列都可能延遲相容性後的資料消耗。
QoS 行為與安全界限
QoS 行為取決於 ROS 分發、 RMW 實現、 DDS 廠商、作業系統、網路和致動器設計。驗證整個應用程式；僅靠中介軟體設定本身不是安全功能。