機器人 RTOS 核心架構：排程、中斷與硬體控制

機器人需要正確的指令，而且指令必須在還來得及發揮作用時送達。**即時作業系統（RTOS）**負責協調感測到致動之間的工作。本文以一次關節修正為例，追蹤感測器輸入如何通過 RTOS 架構，最後成為硬體輸出。

1. 處理器很快，為什麼機器人還是反應太慢？

四足機器人偵測到不平整階梯，算出正確的修正量

一台四足機器人踩上破損的鋪路石。編碼器回報關節角度改變，慣性量測單元（IMU）偵測到機身旋轉。控制器算出修正量，但指令傳往關節的途中，機器人仍持續移動。

算得正確，只是其中一部分。根據先前姿態產生的指令，可能在姿態已經改變後才送達。

修正指令送到關節時，已經錯過需要它的時刻

假設這個範例要求致動器指令在感測器取樣後的 1 ms 內生效。即使用 0.2 ms 算出答案，也不能證明完整回應過程都在時限內。

平均回應時間很短，仍可能掩蓋偶爾發生的更新延遲。即時控制要求整條路徑的耗時有足夠嚴格的上限，並維持穩定。ROS 2 即時背景說明 詳細解釋了這項差異。

2. 控制器如何協調每個步驟

CPU、記憶體與驅動程式如何將感測值變成關節指令

在以微控制器為基礎的嵌入式系統中，CPU 讀取量測值、計算目標值，再呼叫驅動程式。驅動程式設定周邊裝置，由周邊裝置將訊號送到致動器介面。

機器人硬體指南 說明馬達、傳動機構、感測器與關節負載如何共同決定致動器介面。

PWM 驅動程式可以寫入計時器的比較暫存器，接著由計時器產生脈衝，不必讓 CPU 逐一切換訊號邊緣。匯流排驅動程式則準備資料傳輸，有時也會借助 DMA。寫入暫存器、完成傳輸、套用指令，是三個不同的時刻。

從指令層級來看，記憶體映射暫存器是由周邊匯流排解碼的位址。CPU 的儲存指令改變的是硬體狀態，而非一般 RAM 變數。計時器可能直到下一個更新邊界，才鎖存新的比較值；ST 計時器應用指南 說明了這種預載機制。CAN 傳輸也必須等待匯流排存取權，之後再由驅動器決定套用指令的時機。這些等待並不是選好任務就能解決的。

典型MCU控制器的內部不同位址，不同職責

儲存快閃記憶體指令與常數

工作儲存RAM取樣資料、堆疊與緩衝區

控制I/O暫存器周邊裝置狀態與設定

暫存器寫入轉化為實體訊號

1. 01CPU儲存指令
2. 02計時器比較暫存器
3. 03PWM波形
4. 04馬達驅動器

控制接腳傳遞訊號，馬達驅動器供應運轉所需的電力，也可能自行執行更快的電流迴路。支撐實體 AI 的電子系統 介紹了周邊電路與供電路徑。

每個任務都需要 RAM 來存放執行堆疊與 TCB。堆疊保存函式呼叫狀態及已儲存的暫存器；TCB 告訴核心，這些上下文位於何處。即使任務處於阻塞（Blocked）狀態，堆疊空間仍會保留。

在上游 FreeRTOS 中，xTaskCreate() 透過設定的配置器取得堆疊與 TCB，xTaskCreateStatic() 則接收應用程式提供的儲存空間。兩種方式都使用 RAM；靜態建立只是省去這些物件的堆積配置。上游 FreeRTOS 以 StackType_t 元素數量表示堆疊深度，ESP-IDF 的任務建立 API 則使用位元組。直接沿用堆疊大小之前，應核對任務 API 與 IDF 移植版本的差異 。

記憶體預算有助於理解平台分工。小型 FreeRTOS 核心與 Linux 系統提供的服務不同。用這些數據選擇晶片之前，應先比較每個數字實際包含什麼。

RTOS 核心內部：任務、中斷與排程如何協作

RTOS 是一種作業系統類別。 FreeRTOS 與 Zephyr 是提供排程及同步機制的具體實作。開發者設定這些機制，並實作自己的應用任務。

為了說明 FreeRTOS 任務排程，本文採用搶先式單核心設定。控制任務等待新資料時，感測與遙測各自擁有執行上下文。

核心將任務狀態保存在**任務控制區塊（TCB）**中。pxTopOfStack 指向已儲存的上下文，uxPriority 決定優先順序，串列項目則將任務連到狀態串列與事件串列。RTOS 上下文切換會從儲存的執行位置恢復任務。

允許切換時，排程器會選擇符合條件且優先順序最高的就緒（Ready）任務。若高優先順序任務從不阻塞，低優先順序工作就可能一直沒有執行機會。可參閱 FreeRTOS 任務實作 。

在單核心模型中，就緒串列依優先順序索引。任務因等待佇列而阻塞時，會從就緒集合移除，並登記為等待者；有限逾時也需要管理延遲串列。事件或逾時發生後，任務才重新具備執行資格。核心會保護這些串列更新，避免中斷看到只改到一半的排程結構。部分設定使用針對移植版本最佳化的位元圖查找優先順序，但不是所有晶片都採用同一種演算法。

現在讓感測器觸發資料就緒中斷。下圖呈現完整的交接過程：就緒（Ready）還不等於執行中（Running）。

在 Cortex-M4F 移植版本上，切換要求可以將低優先順序例外 PendSV 設為待處理。硬體先儲存例外框架，再由移植版本保存其餘任務上下文、選擇另一個 TCB，並還原該任務。行程堆疊指標（PSP）指向任務堆疊，處理常式程式碼則使用主堆疊指標（MSP）。

選擇下一個任務時，移植版本會提高 BASEPRI，遮罩可能存取核心資料的中斷優先順序。更緊急的中斷可以維持啟用，但不得呼叫相關 FreeRTOS API。PendSV 處於待處理狀態，並不代表它能強行打斷執行中的更高優先順序處理常式來切換任務。這裡專指 Cortex-M4F 移植版本 ，並非 ESP32 的 Xtensa 或 RISC-V 組合語言實作。

搶先式排程可以在兩個節拍之間回應事件。時間片輪替則在節拍到來時，讓相同優先順序的就緒任務輪流執行。兩者使用獨立的 FreeRTOS 設定開關 。

佇列、號誌與互斥鎖如何協調任務和共享資源

這裡的 RTOS 任務同步有兩項工作：傳遞感測器取樣資料，以及喚醒等待中的控制任務。應依照跨越任務邊界的內容，選擇適合的核心物件。

取樣資料可用後，等待接收的任務可以從阻塞（Blocked）轉為就緒（Ready），接著才是取得 CPU 執行權。號誌傳遞的是可用狀態，而非取樣資料本身；互斥鎖還包含所有權與基本的優先順序繼承。

FreeRTOS 的佇列由環形資料緩衝區、元素計數，以及等待傳送或接收的任務串列組成。傳送時會複製指定元素大小的位元組，並可能喚醒等待中的接收任務。號誌使用大小為零的資料元素，重複使用佇列機制；關鍵是計數與等待串列，而非資料緩衝區。互斥鎖還會追蹤持有者，讓核心能暫時提高該任務的優先順序。佇列實作 具體呈現了這些關係。

3. 為什麼關鍵修正仍可能延遲

已就緒的控制任務，為什麼不一定能立即執行

高優先順序任務可能已具備執行資格，卻仍無法接手 CPU；也可能還在等待某項相依條件。只提高任務優先順序，無法自動消除這兩種等待。

臨界區、中斷遮罩、排程器暫停與 ISR 執行，都可能延後任務的排程執行，FreeRTOS 也不例外。受保護操作並沒有特殊的「最高任務優先順序」，而是暫時限制可以切換任務的時機。

假設未啟用 PREEMPT_RT 的 Linux 中，某個驅動程式持有 spinlock_t。已啟用的中斷可以喚醒更高優先順序的控制執行緒，並提出重新排程要求。但中斷返回後，CPU 仍可能必須先完成驅動程式的受保護區間，才能切換。控制執行緒雖已就緒，剩餘的受保護操作仍需計入它的回應時間預算。

FreeRTOS 的 vTaskSuspendAll() 與中斷遮罩不同：ISR 仍可執行，但任務切換必須等排程器恢復，並處理延後的工作。Cortex-M 臨界區則使用移植版本特有的中斷遮罩。提高任務優先順序，無法取消其中任何一種機制。Linux 鎖定規則 說明了相關自旋鎖與 IRQ 的差異。

對於支援優先順序繼承的互斥鎖，持有者會暫時繼承等待它的高優先順序任務之優先順序，幫助它完成工作並釋放資源。但這不會消除臨界操作、解決死結，也無法替永遠不回應的裝置設定有效的等待上限。

FreeRTOS 與桌面 Linux 有何不同，PREEMPT_RT 又改變了什麼

比較 RTOS 與 Linux 時，必須考量完整回應路徑。兩種核心都會管理任務狀態、優先順序、搶先式排程與中斷；差異在於設定後的系統如何控制整條路徑中的干擾。

PREEMPT_RT 是 Linux 的一種設定，不是 FreeRTOS 功能。 它透過執行緒化中斷，以及支援優先順序繼承的可睡眠鎖，將更多核心工作納入排程器控制。

典型的執行緒化 IRQ 路徑保留一小段硬中斷入口處理，確認或遮罩中斷來源後，再喚醒 IRQ 執行緒。該執行緒依排程策略與優先順序競爭執行機會。PREEMPT_RT 將一般 spinlock_t 改成以 RT 互斥鎖為基礎的實作：競爭者可以睡眠，優先順序繼承則協助持有者繼續執行。raw_spinlock_t、底層入口路徑與其他明確保護的區間，仍無法被搶先。詳見 RT 核心的差異 。

在設定合宜的 PC 上，即時 Linux 可以執行機器人控制。不能直接假設一般 Ubuntu 符合嚴格時限，也不能對未經驗證的 FreeRTOS 系統做出相同假設。開源授權與這項時序問題無關。

即使排程已允許執行，記憶體仍可能增加延遲。使用虛擬記憶體時，指令可能因頁面需要配置、寫入時複製，或讀取檔案／交換區而觸發分頁錯誤；只有部分分頁錯誤會涉及儲存裝置。典型的 MCU FreeRTOS 系統使用常駐記憶體，不採用隨需分頁，但配置、快閃記憶體／快取存取、匯流排與裝置仍可能造成停頓。

Linux 控制執行緒應在迴圈開始前，準備關鍵緩衝區與堆疊頁面，預先存取所需映射以觸發必要的分頁處理，並在檢查錯誤與限制的前提下使用適當的記憶體鎖定。mlockall() 不會讓未來的配置或寫入時複製變得毫無影響。PREEMPT_RT 本身也不會消除分頁錯誤；記憶體鎖定手冊 說明了這些限制。

現在為整個修正過程設定同一份時間預算，分別對感測、干擾、計算、傳輸與輸出生效設定上限，並納入打斷計算的高優先順序工作。

等待 120 µs 時，範例總耗時為 600 µs，距離 1,000 µs 截止時間還有 400 µs。等待 800 µs 時，固定工作相同，但總耗時變為 1,280 µs，也就是逾時 280 µs。這些是教學範例數值，不是板卡實測結果。

應量測實際輸出生效的邊界。只看排程延遲，無法知道驅動器何時套用指令；單次執行觀察到的最大延遲，也不能證明最壞情況的上限。

4. 從本機控制到完整機器人

建立控制韌體，並透過自訂 SDK 對外提供功能

選擇 FreeRTOS 或 Linux，應從負責感測與動作的硬體出發。RAM、CPU 架構、周邊驅動程式與時序需求，共同決定哪些軟體能勝任。以下針對支援的目標平台，各列出兩個選項範例。

為感測與回授控制指定明確的喚醒條件、優先順序、執行時間上限，並提供足夠的堆疊。不要讓解析、網路通訊、日誌與儲存工作持續占用關鍵迴圈需要的資源。

核心提供排程與同步，韌體提供控制行為和驅動程式，自訂 SDK 則對外提供指令與實測狀態。

前面的中斷交接過程，可以用以下簡短的 FreeRTOS 模式表示。單一元素佇列保留最新的完整取樣資料。應先建立佇列與任務，再啟用中斷，並透過耗時有上限的硬體路徑取得取樣。

void sample_isr(void) {
  BaseType_t wake = pdFALSE;
  Sample s = read_ready_sample();
  xQueueOverwriteFromISR(
    sample_q, &s, &wake);
  portYIELD_FROM_ISR(wake);
}

void control_task(void *arg) {
  Sample s;
  for (;;) {
    xQueueReceive(sample_q, &s,
                  portMAX_DELAY);
    Target t = target_snapshot();
    Command u =
      control_step(s, t);
    actuator_write(u);
  }
}

ISR 複製一筆已完成的取樣資料，並在需要時提出切換要求。任務等待時不耗用 CPU，接著讀取一致的目標快照、計算下一次輸出，再呼叫驅動程式。多欄位目標值應透過訊息傳遞，或耗時有上限的任務層級鎖，複製成一致的版本；不要在緩慢的 I/O 期間一直持有這把鎖。

週期迴圈應使用適當的計時器或 xTaskDelayUntil()，避免反覆使用相對延遲，讓工作耗時不斷累積。節拍解析度必須符合週期；短於一個節拍的需求，需要合適的硬體計時來源。

在既有核心設定中，指定 configUSE_PREEMPTION、優先順序範圍、配置選項與堆疊大小，再實作任務及其同步。通常是設定與移植排程器，而非自行撰寫就緒串列的選擇邏輯。在支援的雙核心 ESP-IDF 設定中執行 ESP32 上的 FreeRTOS 時，排程器還會考量核心親和性。把任務固定到某個核心，無法隔離共享記憶體或匯流排；本機中斷遮罩也不會停止另一個核心。共享資料需要使用目標平台支援的跨核心同步機制。

定義單位、接受範圍、時間戳記、序號、確認回應、新鮮度與逾時行為。收到指令，並不等於已執行物理動作。

在通訊邊界上，應明確定義序列化方式，包括欄位寬度、位元組順序、訊框格式及必要的完整性檢查。不要直接傳送原始 C 結構，因為主機端的填補布局可能不同。控制器驗證封包、發布完整目標值，並回報實際套用的序號。逾時後可選擇適合機構的預定義保持、漸降或故障回應。SDK 應呈現這個狀態，不能把接收成功當成動作成功。

開發客製化機器人時，應將這些介面與感測、致動器整合一併界定範圍。VoicePing 的客製化機器人開發 從任務及其運作環境出發。

核心如何成為產品平台。 客製化可以在核心移植版本、應用韌體或外部 SDK 邊界進行。企業不必重寫排程器，也能打造自己的控制器。

Espressif 公開說明了針對其硬體的 FreeRTOS 實作與整合。Bitcraze 的 Crazyflie 展現另一種常見做法：使用 FreeRTOS 任務，再加上感測器 → 估測器 → 控制器 → 馬達的處理流程。穩定控制文件 與韌體原始碼 呈現了這個應用層。

Unitree 則是公開介面層的例子。SDK2 Go2 範例 發布低階馬達指令並訂閱狀態，Python SDK 文件說明了 Cyclone DDS 的使用 。這能證明機器人介面可擴充，卻不能證明內部未公開的關節控制器使用 FreeRTOS。應區分有文件依據的 SDK 行為，以及對內部韌體的推測。

在四足機器人與無人機中，連接本機 RTOS 控制與 ROS 2

現在把控制器放進整台機器人的架構。主機規劃運動，本機控制器閉合回授迴路，關節驅動器則調節電流。每個迴圈都應配置在能驗證其時序的位置。

一種四足機器人架構將各個迴圈放在能滿足其時序要求的位置

目標值 →← 實測回授

主機Linux + ROS 2運動規劃

控制器本機 RTOS執行回授迴圈

關節驅動器驅動器韌體調節電流與功率

ROS 2 是中介軟體，RTOS 是作業系統核心或平台。 兩者職責不同，也經常搭配使用。選定的迴圈同樣可以在適當的 Linux/PREEMPT_RT 主機上執行；ROS 2 即時設計討論 說明了應用層的限制。

Linux 提供行程、攝影機／網路驅動程式、機器人函式庫與部署工具，因此適合擔任主機。PREEMPT_RT 保留這個平台，同時改善核心回應能力。ROS 2 回呼仍需要合適的執行器／執行緒策略、耗時有上限的工作，以及預先準備的記憶體；RT 核心不會自動讓每個回呼都具備即時性。FreeRTOS 則為本機韌體提供較小的執行環境，無法直接接手主機整套 Linux 軟體堆疊。

先決定時序需求，再選核心。 視覺或建圖主機可能需要吞吐量與廣泛的驅動程式支援，快速迴路則交給獨立 MCU。若 Linux 主機直接負責嚴格的控制時限，就需要適當的即時設定及端到端驗證。PC 可以執行 PREEMPT_RT，但一般桌面工作負載往往不需要那麼嚴格的延遲目標。

這些成本取決於工作負載。IRQ 執行緒與優先順序繼承鎖會增加管理工作，CPU 分配及驅動程式的假設也需要檢查。停用深度睡眠或頻率變動，可能以能源效率換取較短的回應時間；這是調校選擇，不是 PREEMPT_RT 自動帶來的效果。Canonical 延遲指南 介紹了這些實務取捨。即使使用非 RT 核心，持續占用 CPU 的即時執行緒也可能使其他工作陷入飢餓。

這種並存也出現在開發者調查中。下方兩個類別涵蓋不同的硬體角色，兩者都不是基準測試，也不是對特定 MCU 的推薦。

「資源受限」應相對於應用可用的 RAM、快閃記憶體、CPU、電力與 I/O 預算來理解。ESP32 等級的控制器與 Linux 邊緣電腦，可能面臨不同限制。調查中廣泛的 Linux 使用結果，不能證明桌面 Linux 適合 ESP32。仍需針對實際板卡，核對記憶體容量、MMU 支援、驅動程式及實測迴圈時序。

相同模式也支援無人機姿態穩定。在支援的飛控板上，PX4 通常使用 NuttX；ArduPilot 則在許多 STM32 目標上使用 ChibiOS。可參閱 PX4 飛行軟體堆疊概述 、系統架構 與 ArduPilot 移植指南 。

回到四足機器人

現在，我們能一路追蹤不平整階梯引發的修正，直到指令抵達關節。核心組織執行，而完整的感測、控制與致動路徑，決定修正是否來得及。

設計下一款控制器時，請追蹤一個感測器事件，直到產生物理輸出。明確訂出截止時間，計入每段等待，並在硬體上驗證輸出生效的邊界。

若要將控制器用於實際應用，可以了解 VoicePing 的機器人工程方法 ，共同定義硬體、控制介面與驗收標準。