1. 实时性概述：姿态控制系统的实时性要求

各位同学，咱们今天聊聊实时性。说实话，做姿态控制这些年，我见过太多「看起来能跑，一上天就炸」的案例。问题出在哪？多半是实时性没搞明白。

先问大家一个问题：你的飞控从传感器读到数据，到输出舵机指令，这中间到底花了多少时间？ 如果你答不上来，那这堂课你可得认真听了。

1.1 姿态控制系统的实时性要求

姿态控制，说白了就是让飞行器保持我们想要的姿态。你想想看，四旋翼在空中，每秒要调整几百次姿态。任何一个环节慢了，飞机就可能翻跟头。

我个人的习惯是，先把实时性要求分成三个层次：

• 传感器采样周期：IMU数据多久读一次？一般1-10ms
• 控制律计算周期：从读到数据到算出控制量，通常1-5ms
• 执行器响应周期：PWM信号更新频率，常见50-400Hz

我在项目中遇到过一件事：某款无人机，传感器采样是1kHz，但控制律计算被一个日志打印任务阻塞了。结果呢？飞起来就抖，越抖越厉害。查了两天才发现，是printf惹的祸。

1.2 硬实时与软实时的区别

很多教材喜欢把实时性分成「硬实时」和「软实时」。我换个说法：超时了会怎样？

类型	超时后果	典型场景
硬实时	系统崩溃或灾难	飞控、发动机控制
软实时	性能下降，但能接受	视频传输、日志记录
固实时	介于两者之间	工业机器人

嗯，这里要注意：姿态控制属于硬实时。为什么？因为控制律计算超时1ms，可能就意味着飞机偏了0.5度。累积几帧，飞机就失控了。

我曾经在一个项目中，把姿态控制任务优先级设低了。结果地面站通信任务占用了CPU，控制任务被延迟。飞机起飞后直接侧翻，还好是在测试架上。从那以后，我再也不敢把控制任务的优先级排在后面。

1.3 实时性三大指标：延迟、抖动、吞吐量

做实时系统，我们关注三个数字。我习惯叫它们「三剑客」：

1.3.1 延迟（Latency）

从事件发生到系统响应的时间。在姿态控制里，就是传感器数据产生到舵机动作的时间。

举个例子：

// 典型的姿态控制延迟分解
传感器读取延迟: 0.5ms (SPI读取)
姿态解算延迟: 0.8ms (四元数更新)
控制律计算延迟: 0.3ms (PID计算)
PWM输出延迟: 0.1ms (定时器更新)
--------------------------------
总延迟: 1.7ms

我建议你把每个环节的延迟都测出来。别问为什么，问就是吃过亏。

1.3.2 抖动（Jitter）

延迟的变化量。说白了，就是每次执行时间的差异。

你想想看：如果每次控制周期都是1ms，那很好。但如果有时候0.5ms，有时候2ms，那问题就大了。抖动会导致控制品质下降，甚至引发振荡。

1.3.3 吞吐量（Throughput）

单位时间内能处理的任务数量。在姿态控制里，就是控制频率。

常见的控制频率：

• 四旋翼：200-400Hz
• 固定翼：50-100Hz
• 火箭：500-1000Hz

这里有个权衡：频率越高，控制效果越好，但CPU负担也越大。我个人的经验是，先保证延迟和抖动达标，再考虑提高吞吐量。

1.4 三个指标的关系

这三个指标不是孤立的。我画个简单的图帮你理解：

吞吐量 = 1 / (延迟 + 抖动)
// 注意：这是理想情况
// 实际中还要考虑任务切换开销

举个例子：如果你把控制频率从200Hz提高到400Hz，每个周期的时间就从5ms降到了2.5ms。这时候如果延迟还是2ms，那留给其他任务的时间就只剩0.5ms了。很容易出问题。

1.5 本章小结

好了，咱们总结一下：

• 姿态控制是硬实时系统，超时就是灾难
• 关注三个指标：延迟、抖动、吞吐量
• 先保证延迟和抖动，再追求高吞吐量
• 每个环节都要测量，别靠猜

下一章，我会带大家深入RTOS的任务调度，看看怎么用优先级和抢占机制来保证实时性。到时候我会分享一个我踩过的坑——关于优先级反转的，保证让你印象深刻。

记住：实时性不是优化出来的，是设计出来的。