3、数据采集架构：传感器数据流（IMU/GPS/磁力计/气压计）、执行器反馈、状态估计数据、外部控制指令
好，咱们进入第三讲。这一章，我打算聊聊飞控系统里最核心的骨架——数据采集架构。
说白了，飞控系统就是个“数据吃货”。它得不停地吃进各种传感器的数据，然后消化成控制指令。如果吃进来的数据有问题，或者吃得太慢，那飞控算法再牛也白搭。我个人习惯把数据采集架构比作人体的神经系统——传感器是末梢神经，执行器是肌肉，而中间件就是脊髓和大脑之间的高速通道。
3.1 传感器数据流：飞控的“五感”
飞控系统通常依赖四大类传感器：IMU、GPS、磁力计、气压计。它们各自扮演不同角色，缺一不可。
| 传感器 | 测量内容 | 典型频率 | 关键特性 |
|---|---|---|---|
| IMU（惯性测量单元） | 加速度、角速度 | 100-1000 Hz | 高频、短时精度高，但会漂移 |
| GPS | 位置、速度、时间 | 5-20 Hz | 低频、无漂移，但易受遮挡 |
| 磁力计 | 磁场强度（航向） | 10-100 Hz | 提供绝对航向，但易受干扰 |
| 气压计 | 气压（高度） | 25-100 Hz | 提供绝对高度，但受气流影响 |
嗯，这里要注意一个关键点：数据频率不匹配。IMU跑得飞快，GPS却慢吞吞。怎么让它们和谐共处？这就是中间件要做的事。
核心原则：高频传感器提供“短时精确”的增量信息，低频传感器提供“长时稳定”的绝对参考。两者通过数据融合算法（如扩展卡尔曼滤波）互补。
3.2 执行器反馈：你说的话，它听进去了吗？
光有传感器数据还不够。你给电机发了个PWM信号，它真的转到了那个转速吗？我曾经在项目中遇到过，电机堵转导致无人机直接翻了个跟头——就是因为执行器反馈没做。
执行器反馈通常包括：
- PWM/油门实际值：电机是否按指令输出
- 舵机位置：舵面是否到达目标角度
- 电流/电压：执行器是否过载
- 转速（RPM）：电机实际转速
我建议，所有执行器反馈数据都要打上时间戳，并且与传感器数据流同步。否则你根本分不清是“指令没到”还是“执行器没动”。
3.3 状态估计数据：飞控的“大脑”在想什么
状态估计是飞控的“黑盒”部分。它把传感器原始数据吃进去，吐出一个“最优估计”的状态——位置、速度、姿态、角速度偏差等等。
常见的状态估计数据包括：
- 姿态四元数/欧拉角：滚转、俯仰、偏航
- 位置（NED坐标系）：北、东、地
- 速度（机体/地面坐标系）
- 加速度计/陀螺仪零偏：用于校准
- 协方差矩阵：告诉你估计值有多可信
个人经验：记录状态估计的协方差数据非常有用。有一次飞机莫名其妙地飘，我查了半天日志，发现是GPS协方差突然变大——原来是卫星信号被树挡住了。如果没有协方差数据，你根本不知道“飞控自己也在怀疑自己的位置”。
3.4 外部控制指令：谁在发号施令？
外部控制指令是飞控的“输入源”。它可能来自：
- 遥控器（RC）：手动控制
- 地面站（GCS）：航线指令、模式切换
- 机载计算机：视觉导航、路径规划
- MAVLink/自定义协议：指令载体
为什么要采集这些指令？说白了，是为了“复盘”。飞机坠了，你得知道是飞控自己抽风，还是遥控器发了错误指令。我曾经排查过一个案例，日志显示飞控一切正常，但飞机就是往地上栽。最后发现是地面站发了一个“降落”指令，而操作员完全没意识到——因为指令被误触发了。
3.5 数据采集架构总览
好了，我们把上面这些串起来。下面这张图是我自己画的架构图，你看一眼就能明白整个数据流怎么走。
这张图你看懂了吗？从上到下，数据流是单向的，但中间件层做了关键的“时间同步”和“频率对齐”。
3.6 数据采集的避坑指南
最后，我分享几个实战中踩过的坑：
坑1：时间戳不同步
我曾经调试一架无人机，发现IMU和GPS的数据时间戳差了整整200毫秒。结果状态估计出来的位置一直在震荡。后来发现是中间件用了两个不同的时钟源。记住：所有传感器数据必须使用同一个时间基准，最好是飞控主控的硬件定时器。
坑2：数据丢帧不标记
有一次我分析坠机日志，发现IMU数据有一段“空白”。但日志里没有任何丢帧标记，导致我以为数据是连续的。实际上，中间件在采集时丢了几帧，却没有记录。我建议：每条数据都带一个序列号，丢帧时显式标记。
坑3：执行器反馈频率太低
我见过一个设计，执行器反馈只有10Hz，而控制循环是400Hz。结果控制算法以为执行器没响应，疯狂加大油门——电机直接烧了。执行器反馈频率至少要是控制频率的1/10，我建议做到1/4以上。
好了，这一章的内容就到这里。数据采集架构是飞控系统的地基，地基不稳，上层算法再漂亮也是空中楼阁。下一章我们会深入数据融合，看看这些数据是怎么变成“最优估计”的。