4. 控制延迟分析：传感器采样延迟、计算延迟、执行器延迟对俯仰控制带宽的限制

做飞控这么多年，我踩过最大的坑，就是「延迟」。

你想想看，PID 调得再好，参数再漂亮，只要系统里藏着几毫秒的延迟，整个控制带宽就会被死死压住。俯仰通道尤其敏感——飞机抬头低头，延迟一多，要么震荡，要么响应慢得像老牛拉车。

这一节，咱们就把延迟这件事掰开揉碎。说白了，延迟就是「从物理量变化，到执行器真正动作」之间的时间差。它分三段：传感器采样延迟、计算延迟、执行器延迟。每一段都有它的脾气。

4.1 传感器采样延迟

传感器采样延迟，是第一个拦路虎。

IMU 里的陀螺仪和加速度计，不是一测到角速度就立刻输出的。它们内部有滤波、有模数转换、有 SPI/I2C 通信。以我常用的 BMI088 为例，陀螺仪内部有一个低通滤波器，默认开启，会引入大约 2-3ms 的群延迟。如果你把滤波器带宽设得很低（比如 20Hz），延迟能到 8ms 以上。

嗯，这里要注意：采样延迟不是采样周期。采样周期是 1ms 一次，但传感器从物理量变化到数据就绪，可能已经过了 3ms。这 3ms 就是纯纯的延迟。

我在项目中遇到过一件事：某次调试一架小翼展飞翼，俯仰通道总是有 5Hz 左右的轻微抖动。PID 怎么调都压不住。后来用示波器抓了 IMU 的原始数据，发现陀螺仪内部滤波器设成了 30Hz，延迟接近 10ms。换成 100Hz 滤波器后，抖动立刻消失。你看，问题往往不在算法，而在你没想到的地方。

4.2 计算延迟

计算延迟，就是飞控从拿到传感器数据，到算出控制输出，这中间花的时间。

这部分延迟取决于几个因素：

• MCU 主频： 100MHz 和 400MHz 的芯片，算同样的姿态解算，时间差好几倍。
• 算法复杂度： 用互补滤波还是卡尔曼滤波？卡尔曼滤波的矩阵运算，在低端 MCU 上可能吃掉 2-3ms。
• 任务调度： 实时操作系统里，如果高优先级任务抢占了控制任务，计算延迟会抖动。

我个人习惯，把控制任务放在最高优先级的中断里跑，而不是靠 RTOS 的任务调度。中断里只做最核心的计算——姿态解算 + 控制律，其他一切（日志、通信、地面站）统统扔到后台。这样计算延迟基本稳定在 0.5ms 以内。

4.3 执行器延迟

执行器延迟，往往是最容易被忽略的，但也是影响最大的。

舵机或者电机，收到 PWM 信号后，不会立刻转到目标角度。舵机内部有电机、齿轮、电位计反馈，从 PWM 信号变化到舵面实际偏转，通常有 10-30ms 的延迟。便宜的塑料舵机，延迟能到 50ms。

为什么会这样？因为舵机内部有一个死区控制，PWM 脉宽变化小于某个阈值时，舵机不动作。另外，舵机的电机转速有限，大角度偏转需要时间。

执行器类型	典型延迟范围	对俯仰带宽的影响
微型塑料舵机（9g）	20-50ms	严重限制带宽，< 5Hz
金属齿轮舵机（标准）	10-20ms	中等限制，5-10Hz
无刷电机 + 高速电调	5-10ms	影响较小，> 10Hz
力矩电机直驱	1-5ms	几乎无限制

我曾经用过一个廉价舵机做俯仰控制，结果飞机在高速飞行时，舵面反应总是慢半拍。后来换成高速金属舵机，延迟从 35ms 降到 12ms，控制品质明显提升。说白了，舵机省下来的钱，最后都花在调试时间上了。

4.4 延迟对俯仰控制带宽的定量影响

延迟和带宽的关系，可以用一个简单公式估算：

带宽 ≈ 1 / (2 * π * 总延迟)

总延迟 = 传感器延迟 + 计算延迟 + 执行器延迟。

举个例子：

• 传感器延迟：3ms（BMI088 默认滤波）
• 计算延迟：1ms（STM32F4 跑互补滤波 + PID）
• 执行器延迟：15ms（标准金属舵机）
• 总延迟：19ms

那么俯仰控制带宽 ≈ 1 / (2 * 3.14 * 0.019) ≈ 8.4Hz。

这意味着，如果你想抑制 8Hz 以上的俯仰扰动，基本没戏。飞机遇到 10Hz 的阵风，舵面根本跟不上。

4.5 如何测量和优化延迟

我建议你在调试阶段，至少做一次完整的延迟测量。方法很简单：

1. 在飞控代码里，传感器数据就绪时，拉高一个 GPIO。
2. 在 PWM 输出更新时，拉低这个 GPIO。
3. 用示波器看这个 GPIO 的高电平宽度，就是总延迟。

优化方向：

• 传感器： 关闭内部滤波器，或者用外部硬件滤波代替。如果必须用，选截止频率最高的档位。
• 计算： 用定点数代替浮点数，减少三角函数调用。姿态解算用互补滤波，别用卡尔曼——除非你的 MCU 很强。
• 执行器： 换高速舵机，或者用无刷电机直驱。如果预算有限，至少保证舵机的 PWM 频率在 400Hz 以上。

好了，这一节的内容就到这里。延迟分析是俯仰控制的基础，搞懂了它，后面的带宽设计和滤波器选型才能有的放矢。