一、日志基础：什么是飞行日志、日志的作用、常见的日志格式
各位同事，今天咱们聊聊飞行日志。这东西听起来简单，但我在项目里见过太多因为日志没处理好而翻车的案例。说白了，飞行日志就是飞行器在空中飞的时候，实时记录下来的“黑匣子”数据——只不过这个黑匣子不是物理的，而是一堆文件。
1.1 什么是飞行日志
飞行日志，就是飞行器在运行过程中，由飞控计算机、传感器、执行机构等各个子系统，按照一定频率持续记录下来的状态数据集合。你可以把它理解成飞行器的“体检报告”和“行车记录仪”的结合体。
我个人习惯把飞行日志分成两类：
- 系统日志：记录飞控软件运行时的关键事件，比如启动、自检、异常、模式切换等。这类日志通常以文本形式存在，方便人眼阅读。
- 数据日志：记录传感器原始数据、控制输出、姿态估计等数值型信息。这类日志才是我们做故障分析、性能评估的核心素材。
核心要点：飞行日志不是“有就行”，而是“够全、够准、够快”。我在一次无人机试飞中，就因为日志采样率设得太低，导致振动分析时根本看不出共振频率——白白浪费了一周时间。
1.2 日志的作用
日志到底能干什么？我总结了四个最核心的用途：
- 故障排查：飞行器坠了、飞偏了、抖了，日志是唯一能还原现场的证据。我记得有一次客户说飞机无故掉高，我翻日志发现是气压计被遮挡了——没有日志，这锅就得飞控算法背。
- 性能评估：通过日志里的姿态误差、控制响应、电机转速等指标，可以量化评估飞控调参效果。说白了，调参好不好，日志说了算。
- 安全审计：在适航认证或事故调查中，日志是法律层面的有效证据。你想想看，如果日志格式不规范、时间戳不准，那这数据拿到法庭上就是废纸。
- 算法迭代：开发新功能时，用真实飞行日志回放，比任何仿真都靠谱。我经常跟团队说：“仿真骗人，日志不骗人。”
| 用途 | 典型场景 | 关键数据字段 |
|---|---|---|
| 故障排查 | 坠机分析、异常抖动、GPS丢失 | 时间戳、姿态角、加速度、GPS状态 |
| 性能评估 | 调参前后对比、续航分析 | 电机PWM、电池电压、空速 |
| 安全审计 | 适航取证、事故调查 | 完整时间线、事件标记、冗余数据 |
| 算法迭代 | 新滤波器验证、控制律优化 | 原始传感器数据、中间变量 |
小技巧：我建议在日志中额外记录一个“系统健康状态”字段，比如CPU负载、内存余量、温度等。这些看似不重要的数据，往往能帮你定位一些“玄学”问题——比如飞控过热导致的随机重启。
1.3 常见的日志格式
日志格式这事儿，说实话，行业内没有统一标准。但主流格式就那么几种，我一个个说。
1.3.1 CSV（逗号分隔值）
CSV 是最简单、最通用的格式。每一行是一条记录，字段用逗号隔开。优点是人眼可读、Excel 直接打开、处理方便。缺点嘛——数据量大时文件体积爆炸，而且没有结构信息。
# 典型的CSV飞行日志片段
timestamp,roll,pitch,yaw,altitude,battery_voltage
0.000,0.12,-0.05,1.23,10.5,16.8
0.010,0.13,-0.04,1.24,10.5,16.8
0.020,0.11,-0.06,1.25,10.5,16.7注意：CSV 格式没有数据类型定义。我曾经遇到过一个问题：某传感器输出的“0”被当作字符串处理，导致后续计算全部出错。所以用 CSV 时，一定要在文档里明确每个字段的数据类型和单位。
1.3.2 JSON（JavaScript对象表示法）
JSON 是带结构的文本格式，用键值对表示数据。它的优势在于可读性好、支持嵌套结构、解析方便。缺点嘛，同样的数据量，JSON 文件比 CSV 大 2-3 倍。
{
"flight_id": "F20240315-001",
"timestamp": 0.000,
"attitude": {
"roll": 0.12,
"pitch": -0.05,
"yaw": 1.23
},
"sensors": {
"baro_altitude": 10.5,
"battery": 16.8
}
}我个人习惯在调试阶段用 JSON，因为结构清晰，一眼就能看出数据归属。但到了量产阶段，我会换成更紧凑的格式——毕竟飞行器的存储空间和带宽都有限。
1.3.3 BIN（二进制格式）
BIN 格式是真正的“硬核”日志。数据按字节流存储，没有冗余的逗号、花括号、换行符。它的优点是：体积小、写入快、解析效率高。缺点也很明显——人眼完全不可读，必须用专用工具解析。
# 二进制日志结构示意（非实际字节）
[0xAA][0x55] // 帧头
[0x01] // 消息ID: 姿态数据
[0x00 0x00 0x00 0x00] // 时间戳 (uint32)
[0x3D 0xCC 0xCC 0xCD] // roll (float32)
[0xBD 0x4C 0xCC 0xCD] // pitch (float32)
[0x3F 0x9D 0x70 0xA4] // yaw (float32)
[0x41 0x28 0x00 0x00] // altitude (float32)
[0x41 0x86 0x66 0x66] // battery (float32)
[0x0D 0x0A] // 帧尾经验之谈：BIN 格式虽然高效，但坑也最多。我见过最离谱的案例是：某团队自己定义了一套二进制协议，结果版本迭代后解析工具没同步更新，导致三个月的数据全部作废。所以，用 BIN 格式一定要配套维护好解析库，并且做好版本号标记。
1.4 三种格式对比
| 特性 | CSV | JSON | BIN |
|---|---|---|---|
| 可读性 | 高 | 中 | 低（需工具） |
| 文件大小 | 中 | 大 | 小 |
| 写入速度 | 中 | 慢 | 快 |
| 解析效率 | 中 | 慢 | 快 |
| 结构支持 | 无 | 强 | 需自定义 |
| 适用阶段 | 调试、分析 | 调试、接口 | 量产、嵌入式 |
嗯，这里要注意：没有一种格式是万能的。我自己的做法是——开发阶段用 JSON 或 CSV，方便快速查看；定型后转 BIN，节省空间和带宽。但不管用哪种格式，时间戳的精度和同步性永远是第一位的。没有准确的时间轴，再好的数据也是垃圾。
好了，这就是日志基础的全部内容。记住一句话：日志是你和飞行器之间唯一的“对话”渠道。格式选对了、字段记全了、时间戳对齐了，后面分析起来就事半功倍。否则，你就是在垃圾堆里找金子——累死也找不到。