3. 实时操作系统选型与运动控制适配
运动控制回路对操作系统的要求，本质上不是“快”，而是“可预测”。一个 1 kHz 的位置环每 1 ms 必须完成一次采样、计算与输出，若某次抖动到 1.5 ms，即使平均耗时只有 300 μs，也会造成速度前馈失配、电流环相位滞后，进而在机械上表现为异响、振纹或过流报警。因此选型时真正要比较的是三个量：中断延迟（从硬件中断到 ISR 第一条指令）、调度粒度与抖动（任务被唤醒到实际运行的时间偏差）、内存锁定能力（关键代码与数据是否可能被换页或缓存抖动拖慢）。
下面这张图把四类主流方案放在同一条“从硬件中断到运动输出”的信号链上对比，重点看延迟来源与可控边界。
从图中可以看出，延迟并非只由内核决定，而是“中断控制器 → ISR → 调度器 → 任务 → 输出”整条链路的叠加。RTOS 与 VxWorks 把这条链压到微秒级，代价是算力与生态；PREEMPT_RT 与 Xenomai 在通用 Linux 上重建实时性，代价是调优复杂度。选型时不能只看标称延迟，还要看最坏情况执行时间（WCET）是否稳定。
中断延迟与调度粒度的实际影响
以 1 kHz 电流环为例，周期 1 ms。若中断延迟抖动为 20 μs，占周期 2%，对电流环影响有限；但若抖动达到 200 μs，占 20%，则 PWM 占空比更新时刻漂移，等效于引入相位误差。对 4 kHz 电流环（周期 250 μs），20 μs 抖动已占 8%，必须把中断延迟控制在 10 μs 以内。这就是为什么高带宽伺服往往选择 RTOS 或 VxWorks，而不是通用 Linux。
调度粒度同样关键。PREEMPT_RT 下若把控制任务设为 SCHED_FIFO 优先级 80，并配合 sched_setscheduler 与 CPU 亲和性绑定，实测抖动可压到 30–80 μs；但若任务中调用了未加锁的 printf、动态内存分配或文件 IO，抖动会瞬间放大到毫秒级。因此调度粒度不是内核单方面给的，而是“内核能力 × 任务编写规范”的乘积。
内存锁定：最容易被忽视的抖动源
Linux 默认按需分页，控制任务第一次访问某段代码或数据时可能触发缺页异常，耗时可达数百微秒。必须在任务启动前调用：
mlockall(MCL_CURRENT | MCL_FUTURE);
// 预分配并锁定控制缓冲区
double *buf = (double*)malloc(4096 * sizeof(double));
mlock(buf, 4096 * sizeof(double));
// 关闭透明大页，避免合并导致的延迟尖峰
echo never > /sys/kernel/mm/transparent_hugepage/enabled此外，应避免在实时任务中使用 malloc/free，改用启动时预分配的对象池；栈空间也要用 mlockall 覆盖。Xenomai 的实时域任务天然运行在锁定内存中，但仍需注意 Linux 域与实时域之间的数据拷贝不能阻塞实时域。
选型依据与决策表
选型应围绕四个问题：控制环频率、轴数、是否需要视觉/上位机融合、认证与成本约束。下面给出一个可直接对照的决策表，参数为示例性工程经验值，实际需以目标硬件实测为准。
| 场景 | 推荐方案 | 中断延迟目标 | 调度抖动目标 | 内存策略 |
|---|---|---|---|---|
| 单轴 1–4 kHz 电流环，MCU 级 | RTOS（FreeRTOS/RT-Thread） | ≤ 5 μs | ≤ 10 μs | 静态分配，无 MMU |
| 多轴 EtherCAT 主站 + 视觉 | Linux PREEMPT_RT | ≤ 30 μs | ≤ 80 μs | mlockall + 预分配 |
| 高动态多轴 + 非实时 HMI | Xenomai（Cobalt） | ≤ 15 μs | ≤ 40 μs | 实时域锁定 |
| 航空航天/高端数控，需认证 | VxWorks | ≤ 3 μs | ≤ 10 μs | 静态/受控分配 |
cyclictest（Linux）或内核自带延迟跟踪工具测量最坏延迟，而不是只看平均值。建议连续运行 24 小时，记录最大抖动值，再决定是否满足控制环要求。
综合来看，RTOS 适合资源受限、确定性要求极高的嵌入式伺服；PREEMPT_RT 适合需要 Linux 生态与视觉融合的中高端控制器；Xenomai 适合既要求硬实时又要保留 Linux 用户态的中高动态场景；VxWorks 适合认证与可靠性优先、成本不敏感的高端装备。选型的核心不是追求最低延迟数字，而是让整条信号链的最坏抖动小于控制环允许的相位误差预算。