ROS 2 即時性能優化實務：PREEMPT_RT 核心與 DDS 中介軟體設定解析

作者：默思編輯部　發布：2026-05-14

為什麼機器人控制需要「即時」而不只是「快」

一般軟體開發追求的是「平均而言夠快」，但機器人控制系統要求的是可預測的反應時間（deterministic latency）——例如機械手臂的關節控制迴圈，如果某一次運算延遲了 50 毫秒，可能就直接導致機器人動作失準甚至損壞。這種「即時性」（real-time）要求，跟一般應用程式「平均反應快」是完全不同層次的工程問題,標準 Linux 核心的排程機制,原生並不保證這種等級的可預測性。

PREEMPT_RT：讓 Linux 核心具備即時特性

ROS 2 在 2026 年持續深化與 PREEMPT_RT 核心修補（一種讓標準 Linux 核心具備可搶佔式即時排程能力的修補程式）的整合——透過套用 PREEMPT_RT 修補的 Linux 核心，搭配官方的基準測試框架（ros2_realtime_benchmarks），開發者能實際量測系統的延遲抖動（latency jitter），確認控制迴圈是否真的落在可接受的即時範圍內。2026 年 2 月發表的一項研究，更打造了一套 Docker 化的即時測試框架，整合 RT-PREEMPT 修補核心、容器化的多版本 ROS 2 環境，讓開發者能在異質（heterogeneous）部署場景下，做到可控制、可重複的效能評估。

DDS 中介軟體的設定重點

ROS 2 底層通訊仰賴 DDS（Data Distribution Service）協定，即時效能設定的常見實務做法，是使用 Fast DDS 搭配「發現伺服器」（discovery server）架構,確保節點探索過程的一致性,並採用 RTPS/UDP 傳輸層,同時停用共享記憶體傳輸——這些設定的邏輯在於：即時系統要的是「可預測」，而某些預設最佳化選項（如自動探索機制、共享記憶體傳輸）雖然平均效能更好，卻可能引入難以預測的延遲波動，因此在即時場景下反而需要主動關閉。

即時性的關鍵前提：中介軟體要跟上

值得強調的是，ROS 2 本身的即時通訊能力，高度依賴底層 DDS 中介軟體的實作品質——如果採用一套具備即時通訊特性的 DDS 實作，ROS 2 應用層也會相應繼承這些即時特性；反過來說，如果中介軟體本身沒有這樣的保證，光靠應用層的努力也難以彌補。

對機器人開發者的實務意義

對於用 ROS 2 開發機器人控制系統的工程師而言，「即時性」不是預設就有的特性，而是需要從作業系統核心、DDS 中介軟體設定、到應用層程式碼，一路認真調校才能達到的目標——尤其是牽涉到安全關鍵（safety-critical）的控制迴圈，理解並實測這整條鏈路的延遲表現，是正式部署前不可省略的一步。