一、飞控实时性概述
大家好，我是老张。干了十几年飞控系统开发，今天咱们来聊聊实时性这个话题。
说实话，我刚入行那会儿，对「实时性」的理解特别肤浅。觉得不就是跑得快嘛？后来被现实狠狠教育了几次，才明白这里面门道深着呢。
什么是实时系统？
先问大家一个问题：你手机上的操作系统，是实时系统吗？
答案是否定的。你刷抖音卡了，顶多骂一句「破手机」，然后等它缓过来。但飞控系统不行——它卡了，飞机可能就掉下来了。
实时系统，说白了就是「必须在规定时间内完成规定任务」的系统。时间一到，不管任务做没做完，都得有个结果。我习惯把它比作「倒计时炸弹」——你必须在倒计时结束前剪断正确的线，晚一秒都不行。
实时系统分两种：
- 硬实时系统：错过截止时间 = 灾难
- 软实时系统：错过截止时间 = 体验变差
飞控系统，属于典型的硬实时系统。嗯，这一点要刻在骨子里。
飞控系统的实时性要求
飞控系统到底有多「实时」？我给大家列几个典型数据：
| 任务类型 | 典型周期 | 容忍最大抖动 |
|---|---|---|
| 姿态解算（IMU读取） | 1ms - 4ms | ±0.1ms |
| 控制律计算 | 1ms - 10ms | ±0.5ms |
| GPS数据解析 | 10ms - 100ms | ±5ms |
| 遥控器信号接收 | 10ms - 20ms | ±1ms |
| 日志记录 | 100ms - 1000ms | ±50ms |
看到没？姿态解算的周期只有1-4毫秒，抖动不能超过0.1毫秒。这是什么概念？你眨一下眼大概300毫秒，够飞控跑完300次姿态解算了。
核心要点：飞控系统的实时性不是「快」，而是「可预测」。哪怕你跑得慢一点，只要每次都在规定时间内完成，也比「有时快有时慢」强一百倍。
硬实时 vs 软实时
我经常被问到：「硬实时和软实时到底有啥区别？不都是要快吗？」
区别大了去了。我举个例子：
- 软实时：你看视频，偶尔卡顿一下，画面停半秒，你忍忍就过去了。
- 硬实时：飞控在控制电机，该在1ms内输出的PWM信号，晚了0.5ms才输出。飞机可能已经偏了5度，然后控制律开始疯狂修正，最终——炸机。
我在项目中遇到过一件事，印象特别深。有一次调试四旋翼，发现飞机总是在悬停时突然抖一下。查了三天，最后发现是一个中断服务函数里不小心加了个printf打印。就这一个打印，把姿态解算的周期从1ms拖到了1.3ms。嗯，0.3ms的延迟，飞机就抖给你看。
避坑指南：我曾经在中断里做过浮点运算，结果导致中断响应时间从2μs飙升到50μs。从此以后，我定了个规矩：中断里只做最必要的事，复杂计算全部扔到任务里去。
实时性三大指标
评价一个飞控系统的实时性好不好，主要看三个指标：
1. 延迟（Latency）
从事件发生到系统响应的时间。比如传感器采集到数据，到控制律算出结果，这个时间差就是延迟。
我习惯把延迟分成两部分：
- 中断延迟：硬件触发中断 → CPU开始执行中断服务函数
- 任务调度延迟：任务就绪 → 任务开始执行
2. 抖动（Jitter）
这个指标很多人会忽略。抖动指的是「每次执行时间的波动范围」。
举个例子：
- 系统A：每次姿态解算耗时 0.9ms - 1.1ms（抖动±0.1ms）
- 系统B：每次姿态解算耗时 0.5ms - 1.5ms（抖动±0.5ms）
虽然系统B平均更快，但系统A更稳定。在飞控里，我宁愿要稳定的1ms，也不要忽快忽慢的0.5ms。为什么？因为控制律设计时都是基于固定周期的，周期一抖，控制参数全乱了。
3. 吞吐量（Throughput）
单位时间内能处理的任务数量。说白了就是「干活能力」。
但要注意：吞吐量和实时性有时候是矛盾的。你让系统同时处理太多任务，每个任务分到的时间就少了，延迟和抖动都会变差。
个人经验：我一般先保证延迟和抖动达标，再考虑提升吞吐量。就像开车，先保证不撞车，再考虑开多快。
知识体系总览
下面这张图，是我自己梳理的飞控实时性知识框架。建议大家先看个大概，后面每个点我们都会展开讲。
这张图把飞控实时性的核心内容串起来了。你会发现，所有问题最后都归结到三个指标上：延迟、抖动、吞吐量。后面的课程，我们会围绕这三个指标，一步步教你如何优化。
好了，第一章就到这里。记住一句话：飞控实时性，不是比谁跑得快，而是比谁跑得稳。
公众号:蓝海资料掘金营，微信deep3321