2. 实时系统基础

在机器人控制器中，“实时”并不是“跑得快”的同义词，而是指系统能够在确定的时间边界内对外部事件作出响应。一个控制周期为 1 ms 的伺服环路，如果偶尔因为调度延迟变成 3 ms，即使平均 CPU 占用率很低，也可能导致关节抖动、力控失稳甚至安全风险。因此，理解实时系统的关键术语，是设计机器人实时 Linux 控制器的第一块基石。

一、实时性的核心定义

实时系统是指：系统的正确性不仅取决于计算结果的逻辑正确，还取决于结果产生的时间正确性。也就是说，一个结果“太晚”就等于“错误”。在机器人控制中，这种时间正确性通常体现为：

• 截止时间（Deadline）：任务必须完成的最晚时刻。例如控制周期 1 ms，则每个周期的计算必须在下一个周期开始前完成。
• 响应时间（Response Time）：从事件发生到系统产生响应的时间间隔。
• 延迟（Latency）：信号从采集、传输、计算到执行所经历的总时间，通常包含传感器延迟、总线延迟、调度延迟和执行器延迟。
• 抖动（Jitter）：同一周期任务实际执行时刻与理想时刻之间的偏差波动。抖动越小，控制越平滑。
• 确定性（Determinism）：系统在最坏情况下仍能保证可预测的时间行为，而不是“平均很快”。

二、硬实时与软实时的区别

根据错过截止时间的后果，实时任务通常分为硬实时、软实时和固实时。硬实时任务一旦错过截止时间，后果不可接受，甚至造成设备损坏或人身伤害；软实时任务偶尔超时只会降低体验或控制品质；固实时介于两者之间，偶尔超时可以容忍，但结果价值会迅速下降。

在同一个机器人系统中，这三类任务往往共存。例如，EtherCAT 主站循环和电流环属于硬实时；轨迹规划属于固实时；而 Web 监控界面属于软实时。实时 Linux 控制器的关键设计目标，就是通过 CPU 隔离、优先级调度和中断线程化，让硬实时任务不被软实时任务干扰。

三、截止时间、抖动与延迟的关系

假设一个控制周期为 T = 1 ms 的伺服任务，理想情况下它每隔 1 ms 准时执行一次。但实际系统中，任务可能因为中断、锁竞争或调度延迟而出现偏移。下图展示了理想周期、实际执行时刻、抖动和截止时间之间的关系。

从图中可以看出，抖动描述的是“实际执行时刻围绕理想时刻的波动”，而延迟描述的是“从事件到响应之间的绝对时间”。截止时间则是一条不可逾越的红线。对于硬实时任务，最坏情况下的响应时间必须小于截止时间，即：

WCET + 调度延迟 + 中断延迟 + 阻塞时间 < Deadline

其中：
WCET：最坏执行时间（Worst-Case Execution Time）
调度延迟：任务就绪到真正获得 CPU 的时间
中断延迟：硬件中断发生到 ISR 开始执行的时间
阻塞时间：等待锁、资源或低优先级任务释放的时间

四、机器人控制对实时性的具体需求

不同类型的机器人控制任务，对周期、抖动和延迟的要求差异很大。下表给出常见参考值，实际工程中需结合机械刚度、控制带宽和安全等级调整。

五、常见误区与工程复盘

误区一：平均延迟低就是实时性好。 实时系统关注最坏情况。一个平均延迟 100 μs、但偶尔飙到 5 ms 的系统，对硬实时控制是不可接受的。

误区二：CPU 占用率低就不会超时。 即使 CPU 空闲，若中断被屏蔽、优先级反转或内存缺页，任务仍可能错过截止时间。

误区三：软实时任务可以随意运行。 软实时任务如果长时间占用 CPU 或持有锁，会间接推高硬实时任务的阻塞时间，破坏确定性。

误区四：只优化算法，不优化时间路径。 在实时 Linux 中，调度策略、CPU 亲和性、中断线程化、内存锁定和优先级继承，往往比算法本身更决定截止时间能否满足。

总结来说，实时性定义的核心是时间正确性；硬实时与软实时的区别在于错过截止时间的后果；截止时间、抖动、延迟和确定性共同构成了机器人控制的时间约束体系。理解这些术语，并在 Linux 控制器中通过调度、隔离和测量手段加以保障，才能让机器人运动既精准又安全。