3. 关键消息类型（上）：HEARTBEAT、STATUSTEXT、SYS_STATUS，解读飞控健康状态

拿到日志文件，别急着翻到最后看错误码。我个人的习惯是，先看飞控的“心电图”——也就是 HEARTBEAT 消息。它就像人的脉搏，有没有在跳、跳得规不规律，直接告诉你飞控是不是还活着。

这一章，咱们就聚焦三个最基础、也最关键的消息类型。你把这三种消息看懂了，飞控的“生老病死”基本就能摸个七七八八。

3.1 HEARTBEAT：飞控的“心跳”信号

HEARTBEAT 是 MAVLink 协议里最基础的消息，没有之一。飞控只要上电正常运行，就会以固定频率（通常是 1Hz，也就是每秒一次）往外广播这条消息。

它的核心作用就两个：宣告存在 和 报告状态。

咱们来看看它的关键字段：

字段名	含义	常见值（解锁失败场景）
`type`	飞控类型	MAV_TYPE_QUADROTOR (2) 或 MAV_TYPE_HELICOPTER (3)
`autopilot`	飞控固件类型	MAV_AUTOPILOT_ARDUPILOTMEGA (3) 或 PX4 (12)
`system_status`	飞控系统状态	MAV_STATE_STANDBY (3) 或 MAV_STATE_ACTIVE (4)
`mavlink_version`	协议版本	2

这里最值得你盯住的，就是 system_status 字段。

解锁失败的关键线索：

如果日志里飞控一直在广播 MAV_STATE_STANDBY (3)，而不是你期望的 MAV_STATE_ACTIVE (4)，那基本可以断定——飞控根本没进入解锁后的“活跃”状态。

说白了，它还在待机，等着你解决某个前置条件。

我记得有一次排查一个客户的日志，HEARTBEAT 里的 system_status 一直在 STANDBY 和 CALIBRATING 之间来回跳。我当时就纳闷，这飞控怎么在反复校准？后来一查，原来是加速度计 Z 轴数据飘得离谱，飞控每次自检都过不去，又退回到校准状态。你看，一个 HEARTBEAT 就能把问题范围缩小很多。

3.2 STATUSTEXT：飞控的“自言自语”

HEARTBEAT 告诉你飞控“活着”，但没告诉你它“在想什么”。这时候就需要 STATUSTEXT 消息登场了。

STATUSTEXT 就是飞控的日志输出。它把内部运行时的关键信息、警告、错误，以文本形式发出来。你想想看，这就像飞控在跟你说话：“GPS 搜星中”、“磁罗盘干扰过大”、“EKF 定位精度不足”……

它的结构很简单：

字段名	含义	说明
`severity`	严重等级	EMERGENCY (0) 到 DEBUG (7)，数字越小越严重
`text`	文本内容	最长 50 个字符的字符串

在解锁失败的分析中，STATUSTEXT 是绝对的“破案主力”。

我的分析习惯：

拿到日志后，我会先用工具过滤出所有 severity 小于等于 3（WARNING）的 STATUSTEXT 消息。然后按时间顺序排列，看看在解锁指令发出前后，飞控到底抱怨了什么。

这比漫无目的地翻看几百 MB 的日志高效得多。

举个例子，你可能会看到这样的文本：

Pre-arm: Compass not healthy
Pre-arm: AHRS not ready
Pre-arm: GPS 3D fix required
EKF check: variance too high
Baro calibration required

这些信息几乎直接告诉了你解锁失败的原因。我曾经遇到过一个案例，日志里反复出现 Pre-arm: Check FS_THR_VALUE。客户百思不得其解，油门值明明设对了。我仔细一看，原来是他在参数列表里把 FS_THR_VALUE

注意：

STATUSTEXT 的文本内容是固件开发者写的，不同固件（ArduPilot、PX4）的提示语可能不一样。比如 ArduPilot 喜欢用 Pre-arm: 开头，而 PX4 可能直接写 Arming denied: ...。你需要熟悉你所用固件的“说话方式”。

3.3 SYS_STATUS：飞控的“体检报告”

如果说 HEARTBEAT 是心跳，STATUSTEXT 是抱怨，那 SYS_STATUS 就是一份全面的体检报告。它把飞控各个子系统的健康状况用数字量化出来。

这个消息里有两个位掩码字段，非常关键：

字段名	含义	如何解读
`onboard_control_sensors_present`	飞控上安装了哪些传感器	每个 bit 代表一种传感器，1 表示存在
`onboard_control_sensors_enabled`	哪些传感器被启用	每个 bit 代表一种传感器，1 表示启用
`onboard_control_sensors_health`	哪些传感器健康	每个 bit 代表一种传感器，1 表示健康

你想想看，这三个字段一组合，就能回答三个问题：

装了啥？（present）
开了啥？（enabled）
啥是好的？（health）

在解锁失败时，我通常会重点关注 onboard_control_sensors_health 这个字段。如果某个传感器的 health bit 是 0，那它很可能就是“罪魁祸首”。

常见的传感器 bit 定义如下：

Bit 位置	传感器	解锁失败常见原因
0	陀螺仪	校准数据丢失、硬件故障
1	加速度计	校准数据丢失、数值超出范围
2	磁罗盘	干扰过大、未校准
3	气压计	数据异常、未校准
4	GPS	未搜到星、3D 定位失败
5	光流	硬件故障、数据无效
10	GPS 罗盘	GPS 航向未收敛

嗯，这里要注意，不同固件对 health 的判断逻辑略有差异。比如 ArduPilot 在 GPS 未锁定前，会把 GPS 的 health bit 置 0，这是正常的。但 PX4 可能会在 EKF 初始化完成前，把多个传感器的 health 都置 0。你需要结合 STATUSTEXT 一起看，才能准确判断。

3.4 三剑客联动：一个完整的分析案例

光讲理论没意思。咱们来模拟一个真实的排查过程。

假设你收到一份日志，解锁失败。你会怎么做？

先看 HEARTBEAT： 确认飞控在跑，system_status 是 STANDBY。嗯，没死机，但也没解锁。
再看 STATUSTEXT： 过滤出 WARNING 级别以上的消息。你看到一条：Pre-arm: Compass health poor。好，问题指向磁罗盘。
最后查 SYS_STATUS： 找到对应时间点的 onboard_control_sensors_health 字段。你发现 bit 2（磁罗盘）是 0。确认了，就是磁罗盘不健康。

整个过程不到 5 分钟。你不需要看任何曲线，不需要复杂的数学计算。三个消息一联动，问题就锁定了。

下面这张图，就是这三个消息在分析流程中的关系：

你看，整个流程非常清晰。从 HEARTBEAT 确认状态，到 STATUSTEXT 定位方向，再到 SYS_STATUS 验证细节。这三板斧下去，大部分解锁失败问题都能找到头绪。

我个人建议，你在分析日志时，把这三种消息的窗口固定在你的分析工具里。它们是你和飞控沟通的“第一语言”。