2. 实时系统基础

在机器人控制中，“实时”并不是“跑得快”的同义词，而是指系统能够在确定的时间约束内完成计算并输出控制量。一个 1 kHz 的伺服控制周期只有 1 ms，如果某次计算偶尔拖到 3 ms，即使平均耗时只有 0.4 ms，也可能造成关节抖动、轨迹偏差甚至碰撞。因此，理解硬实时与软实时的边界，是使用 PREEMPT_RT 的前提。

一、硬实时与软实时的本质区别

硬实时（Hard Real-Time）要求任务必须在截止时间（Deadline）前完成，超时即视为系统失败，且失败后果不可接受。软实时（Soft Real-Time）同样关注截止时间，但偶尔超时只会导致服务质量下降，不会造成灾难性后果。二者的关键差异不在“速度快慢”，而在对最坏情况执行时间（WCET）的约束强度。

在机器人系统中，这种区别非常具体：

• 硬实时任务：电流环/力矩环控制、关节伺服更新、安全急停链路、EtherCAT 周期通信。一次超时可能导致电机失步、机械臂失控或安全功能失效。
• 软实时任务：视觉目标检测、路径重规划、状态估计中的非关键滤波、日志上传、人机界面刷新。偶尔延迟只影响响应流畅度或识别帧率。

二、实时性核心指标：延迟、抖动与确定性

评价一个实时系统，通常看三个指标：

• 延迟（Latency）：从事件发生到系统产生响应的时间。例如编码器采样到 PWM 更新之间的时间。
• 抖动（Jitter）：同一任务多次执行时，响应时间或周期长度的波动范围。抖动越小，控制越平滑。
• 确定性（Determinism）：系统在最坏情况下仍能满足时间约束的可预测程度。确定性不是“平均很快”，而是“最坏也可控”。

三者关系可以用一个简单公式理解：可用时间余量 = 截止时间 − 最坏情况延迟 − 抖动。如果余量为负，硬实时就无法保证。PREEMPT_RT 的核心价值，正是把 Linux 从“平均延迟低但最坏延迟不可控”改造成“最坏延迟可测量、可约束”的实时内核。

三、抖动与延迟在机器人中的实际意义

机器人控制对抖动的敏感度远高于对平均延迟的敏感度。以典型的串联机械臂为例：

可以看到，硬实时任务对抖动的要求往往比延迟本身更苛刻。一个平均延迟 200 μs、抖动 ±300 μs 的系统，其最坏延迟可能达到 500 μs，已经接近 1 ms 周期的极限；而一个平均延迟 400 μs、抖动仅 ±20 μs 的系统反而更安全。这正是 PREEMPT_RT 要解决的核心问题：把不可预测的长尾延迟压下去。

四、案例：一次抖动引发的轨迹偏差

某六轴协作机器人在 1 kHz 控制周期下运行，使用标准 Linux 内核。测试中发现：平均周期 0.98 ms，但每约 2 秒出现一次 2.3 ms 的周期。对应现象是末端轨迹在特定位置出现约 0.5 mm 的周期性偏差，力控模式下甚至出现轻微振荡。

排查后确认，长尾延迟来自内核网络协议栈处理与 USB 中断的不可抢占区段。切换到 PREEMPT_RT 后，通过以下配置将最坏周期抖动从 1.3 ms 降至 80 μs 以内：

# 查看当前内核是否启用 PREEMPT_RT
uname -a
# 输出示例：Linux robot 6.6.30-rt28 #1 SMP PREEMPT_RT ...

# 使用 cyclictest 测量最坏延迟与抖动
cyclictest -m -p 80 -n -i 1000 -l 100000 -h 400

# 典型输出关注 Max 值
# T: 0 ... Max:      78  (单位 μs)
# 若 Max 超过 200 μs，需检查中断线程化与 CPU 隔离

五、确定性：从“快”到“可预测”

确定性是实时系统最容易被忽视、却最关键的属性。它意味着：无论系统负载如何变化，关键任务的执行时间上界是已知且可验证的。在机器人中，确定性带来的直接收益包括：

• 控制器增益可以按最坏延迟整定，而不必为偶发长延迟留过大余量；
• 多轴同步误差可预测，轨迹精度更稳定；
• 安全功能响应时间可认证，满足功能安全要求；
• 系统集成时，各任务的时间预算可以静态分配，减少现场调试不确定性。

因此，学习 PREEMPT_RT 的第一步，不是急着改代码，而是建立正确的实时观：硬实时关注最坏情况，软实时关注平均体验；延迟决定响应快慢，抖动决定控制品质，确定性决定系统能否被信任。只有把这三者分开度量、分别约束，才能在机器人系统中合理划分任务优先级与时间预算。