第二章：日志文件结构
日志文件，说白了就是飞控的「黑匣子」。每次飞行，它都在默默记录一切。我刚开始接触PX4日志时，打开一个.bin文件直接懵了——满屏的二进制数据，完全不知道从哪下手。
后来我才明白，理解日志结构，就像学会看地图。你不需要记住每条街道，但得知道图例怎么读。今天我就带你拆解一下，日志文件到底长什么样。
2.1 头部信息：日志的身份证
每个日志文件的开头，都有一段固定格式的头部信息。它告诉你：这是谁家的日志、什么版本、什么时候录的。
关键字段一览：
- 文件标识符：通常是固定魔数（Magic Number），比如PX4日志以
ULog开头 - 版本号：日志格式版本，不同版本解析方式可能不同
- 时间戳：日志创建时间，通常是Unix时间戳（微秒级）
- 固件版本：记录飞行器固件的版本号，方便追溯问题
我记得有一次，客户反馈说日志打不开。我一看，原来是固件升级后日志格式变了，但解析工具还是老版本。嗯，版本对齐这事，真不能马虎。
2.2 消息类型定义：日志的「语言」
日志里记录的不是杂乱的数据，而是有组织的消息。每个消息都有明确的类型定义。说白了，就像聊天软件里的不同消息类型——文字、图片、文件，各有各的格式。
常见的消息类型包括：
| 消息类型 | 标识符 | 说明 |
|---|---|---|
| 格式定义 | FMT | 定义后续数据的字段结构 |
| 数据消息 | DATA | 实际的传感器、状态数据 |
| 信息消息 | INFO | 文本信息，如参数值、状态提示 |
| 多日志消息 | MLOG | 多日志会话的关联信息 |
你想想看，如果没有FMT消息，你拿到一堆二进制数据根本不知道哪个字节代表什么。FMT就是解码的「字典」。我习惯在解析日志时，先把所有FMT消息提取出来，构建一个消息类型表，后面解析就顺了。
2.3 数据单元结构：数据到底怎么存的
每个数据消息，都遵循FMT定义的结构。举个例子，一个IMU数据消息可能长这样：
FMT, 128, IMU, 16, Qffff, Timestamp,GyrX,GyrY,GyrZ,AccX,AccY,AccZ
这行定义的意思是：
- 消息ID：128
- 消息名：IMU
- 数据长度：16字节
- 字段类型：Q（uint64_t）、f（float）、f、f、f、f、f、f
- 字段名：Timestamp, GyrX, GyrY, GyrZ, AccX, AccY, AccZ
实际的数据消息就是按这个顺序，一个字节不多，一个字节不少。我在项目中遇到过一个问题：解析出来的陀螺仪数据全是乱的。后来发现，是固件升级后IMU消息的字段顺序变了，但FMT定义没更新。这种坑，踩过一次就记住了。
小技巧：解析时永远不要硬编码字段偏移量。先读FMT，再根据FMT动态解析。这样即使消息结构变了，代码也能自适应。
2.4 时间戳机制：时间的「锚点」
时间戳是日志分析中最关键的部分。没有准确的时间，你根本没法把不同传感器的数据对齐起来。
PX4日志使用微秒级时间戳，通常以系统上电时刻为起点。每个数据消息都带有一个时间戳字段，表示该数据采集的时刻。
时间戳有几个特点：
- 单调递增：时间戳只会增加，不会倒退。如果发现时间戳回退，说明系统时钟可能出了问题
- 非均匀间隔：传感器数据不是严格等间隔采集的。受调度延迟、中断响应影响，时间戳会有微小抖动
- 多源同步：不同传感器（IMU、GPS、气压计）的时间戳基准是同一个时钟源，但采集时刻不同
我曾经调试一个无人机悬停不稳的问题。看日志发现，IMU和GPS的时间戳差了将近50毫秒。说白了，就是时间不同步导致融合算法用了过期的GPS数据。后来在代码里加了时间戳对齐逻辑，问题就解决了。
注意：有些日志工具会显示「相对时间」和「绝对时间」。相对时间是从日志开始算的，绝对时间是UTC时间。分析时一定要搞清楚你用的是哪个，不然时间轴对不上就麻烦了。
2.5 知识体系总览
下面这张图，把日志文件的结构关系梳理了一下。你看完应该能有个整体印象。
看到这张图，你应该能明白：头部信息是「门牌」，消息类型定义是「字典」，数据单元结构是「正文」，时间戳机制是「页码」。四者缺一不可。
我个人习惯，拿到一个新日志文件，第一步就是检查头部信息是否完整，第二步提取所有FMT消息建立类型表。这两步走完，后面的解析基本不会出大问题。
核心要点回顾：
- 头部信息：验证文件合法性，获取版本和固件信息
- 消息类型：FMT是解码的关键，必须先读
- 数据单元：严格按FMT定义解析，不要硬编码
- 时间戳：分析的时间基准，注意对齐和精度