PX4-Autopilot/docs/project/PX4_ULog日志分析实用指南.md

PX4 ULog 日志分析实用指南

1. 这份文档解决什么问题

本文针对当前工程环境编写：

• PX4：v1.17.0
• 飞控：CUAV 7-Nano V2
• 机型：Generic VTOL Tailsitter
• SYS_AUTOSTART=13200
• 固件目标：cuav_7-nano_minimal_vtol
• 本机已经安装：pyulog 1.2.3

本文说明：

1. .ulg 文件是什么。
2. 如何从飞控中取得日志。
3. 有哪些现成的日志分析工具。
4. 如何系统地分析一次飞行故障。
5. 如何重点分析 EKF2、振动、控制器和尾座式 VTOL 转换。
6. 把日志交给他人分析时还需要提供什么信息。

---

2. .ulg 文件是什么

.ulg 是 PX4 的 ULog 二进制日志文件。它不是普通文本日志，而是按时间记录大量 uORB 主题数据，例如：

• 飞行模式和解锁状态。
• 飞机姿态、位置、速度和高度。
• 姿态、角速度、位置和速度目标值。
• IMU、GNSS、磁力计、气压计和空速计数据。
• EKF2融合状态、创新量和故障标志。
• 遥控器输入。
• 电机和舵机输出。
• 电池电压、电流和剩余电量。
• VTOL状态和前后转换过程。
• PX4事件、警告和错误消息。
• 飞行时使用的参数值以及固件版本信息。

它的核心价值是：把同一时刻的“输入、状态估计、控制目标、控制输出和故障事件”放在一条时间线上进行比较。

传感器输入
    │
    ▼
EKF状态估计
    │
    ▼
控制目标与实际响应
    │
    ▼
电机/舵机输出
    │
    ▼
飞机运动结果和故障事件

仅看 QGroundControl 当时显示的一句错误，通常只能知道“系统发现了什么”；ULog 才能进一步判断“错误发生前后各数据如何变化”。

---

3. 日志如何产生

PX4默认通常在解锁时开始记录，在上锁后停止记录。每次完整的解锁飞行一般都会生成一个新的 .ulg 文件。

在 MAVLink 控制台中可以检查记录器：

logger status

查看完整命令帮助：

logger help

手动开始和停止记录：

logger on
logger off

3.1 建议的基本参数

首次调试建议保持：

SDLOG_BACKEND：启用 SD 卡日志
SDLOG_MODE=0：解锁时开始、上锁时停止
SDLOG_PROFILE=1：默认通用分析主题

SDLOG_PROFILE 是位掩码，不是单选编号。当前 v1.17 的常见位如下：

位	数值	用途
0	1	默认通用分析主题
1	2	EKF2完整回放主题
2	4	温度校准
3	8	系统辨识
4	16	高速机动、控制器和执行器高频记录
5	32	自定义调试主题
6	64	多传感器对比
7	128	视觉与避障
8	256	陀螺仪原始 FIFO 高频数据
9	512	加速度计原始 FIFO 高频数据
10	1024	MAVLink tunnel 消息
11	2048	高频传感器主题

多个配置需要把数值相加。例如：

默认主题 + 高频控制主题 = 1 + 16 = 17

不要为了“记录得更全”直接设置为 4095。高频原始 IMU 会显著增加写入带宽和文件大小，SD卡写入不及时反而会造成日志丢帧。

3.2 针对当前尾座式的建议

• 日常飞行和第一次排查：SDLOG_PROFILE=1。
• 角速度跟踪、PID或快速转换细节：短时间测试可用 SDLOG_PROFILE=17。
• EKF深度回放不是普通故障排查的必需项，不要一开始就启用全部高频配置。
• 改变 SDLOG_PROFILE 后需要重启飞控。

3.3 确认日志没有严重丢帧

日志质量也要检查。可以用：

ulog_info flight.ulg

输出中会显示：

Dropouts: count, total duration, max, mean

少量很短的 dropout 未必影响分析，但故障发生的关键时间段存在长时间丢帧，会使因果链不完整。

如果日志经常丢帧，可检查：

• SD卡质量和格式。
• 是否启用了过多高频记录主题。
• 日志文件是否过大。
• SD卡写入是否出现长时间阻塞。

飞控控制台可以测试 SD 卡：

sd_bench -r 100

---

4. 如何从飞控下载 .ulg

4.1 使用 QGroundControl

最方便的方式是：

1. 连接飞控。
2. 打开 QGroundControl 的 Analyze/分析页面。
3. 进入 Log Download/日志下载。
4. 刷新日志列表。
5. 根据日期、时间和大小选择对应日志。
6. 下载为 .ulg 文件。

下载时建议记录：

• 飞行日期和大致时间。
• 哪一次解锁对应哪个文件。
• 故障大约发生在起飞后多少秒。

4.2 直接读取 SD 卡

也可以断电后取出 SD 卡，在日志目录中复制 .ulg 文件。操作前应正常上锁并断电，避免日志尚未写完或文件系统损坏。

4.3 日志突然在空中结束

如果 .ulg 在空中突然中止，应同时检查 SD 卡根目录是否存在类似文件：

fault_YYYY_MM_DD_HH_MM_SS.log

日志突然结束的常见原因包括：

• 飞控掉电或供电瞬断。
• PX4/NuttX发生硬故障。
• SD卡被移除或写入失败。

仅凭 .ulg 结束无法区分掉电和系统硬故障，fault_*.log、飞行视频和供电记录都很重要。

---

5. 有哪些现成的分析工具

工具	类型	适合用途	注意事项
PX4 Flight Review	在线网页	第一次快速全面检查	日志会上传到公网服务，敏感数据需谨慎
PlotJuggler	本地 GUI	自由选择全部 uORB 字段、同步多图分析	需要安装，初次使用要建立布局
pyulog	本地命令行/Python	查看主题、参数、事件、转CSV和自动化分析	需要理解主题字段
PX4 EKF分析脚本	本地 Python	自动生成 EKF健康结果、CSV和PDF	只针对 EKF，不等于整机故障诊断
FlightPlot	本地 GUI	常规曲线查看	功能和维护状态需按实际版本确认

建议采用这样的组合：

Flight Review快速总览
          │
          ▼
找出异常发生的准确时间
          │
          ▼
PlotJuggler检查相关原始主题
          │
          ▼
pyulog或Python做精确提取和批量分析

如果日志包含敏感航迹、经纬度、设备编号或任务信息，不应上传公共 Flight Review；可以只使用本地工具，或者自建私有 Flight Review。

---

6. 工具一：PX4 Flight Review

地址：https://logs.px4.io/

使用方式：

1. 打开网页。
2. 上传 .ulg。
3. 等待生成报告。
4. 查看报告中的事件、模式、姿态、振动、GPS、EKF和执行器曲线。
5. 保存分析页面链接，方便多人查看同一份报告。

6.1 Flight Review适合检查什么

• 固件、机型和关键参数。
• 解锁、起飞、模式切换、转换和上锁时间。
• PX4产生的 warning、error 和 failsafe 事件。
• 姿态或角速度目标跟踪。
• 位置和高度目标跟踪。
• IMU振动、剪切和FFT。
• GNSS质量和位置跳变。
• EKF创新量及估计器异常。
• 电池电压、电流和压降。
• 电机或舵机输出饱和。
• VTOL模式背景：MC、FW和转换阶段。

Flight Review 中常见背景颜色会表示飞行模式；VTOL还会标记多旋翼、固定翼和转换区段。因此先确定故障发生在哪个模式，再看对应控制器。

6.2 Flight Review的局限

• 它展示的是预设图表，不会把日志中的所有字段全部显示出来。
• 自动告警是线索，不一定是根因。
• 某个曲线异常可能是前一个问题的结果。
• 日志上传到公共服务会涉及数据隐私。

例如“EKF高度创新异常”可能由气压计气流干扰、强振动、GNSS高度跳变或实际快速下沉引起，不能只看这一条自动结论。

---

7. 工具二：PlotJuggler

PlotJuggler 是适合深入分析 ULog 的桌面工具。它能列出日志中实际存在的全部 uORB 主题和字段，并将多个曲线放在同步时间轴上。

基本使用方式：

1. 安装并启动 PlotJuggler。
2. 打开 .ulg 文件。
3. 在左侧搜索主题或字段。
4. 将字段拖到绘图区。
5. 横向缩放到故障时间段。
6. 分割多个面板，对比输入、目标、状态和输出。
7. 保存 Layout，下次分析同类日志直接复用。

7.1 建议建立的四层布局

第一层：模式、状态和事件
第二层：目标值与实际状态
第三层：传感器和 EKF 创新量
第四层：电机、舵机、电池和执行器饱和

PlotJuggler还可以：

• 用四元数计算 roll、pitch 和 yaw。
• 做字段间加减、缩放和滤波。
• 用 X/Y 字段显示二维航迹。
• 保存尾座式专用分析模板。

7.2 为什么需要多图同步

假设飞机转换时突然掉高，单看高度只能知道“发生了掉高”。同步查看以下数据才能判断原因：

VTOL状态
俯仰目标与实际俯仰
空速和地速
高度与垂直速度
推力目标
最终电机输出
电池电压
EKF垂直创新量

如果俯仰没有跟上目标且电机已经饱和，重点检查推重比、控制参数和重心；如果姿态正常但空速增长不足，重点检查推力、阻力和空速计；如果物理状态正常而估计高度突然跳变，则重点检查 EKF 和高度传感器。

---

8. 工具三：pyulog

当前电脑已经安装：

pyulog 1.2.3
ulog_info：/home/jiagu/.local/bin/ulog_info
ulog2csv：/home/jiagu/.local/bin/ulog2csv

如果终端能找到用户级命令，可直接运行；如果提示找不到命令，可以使用完整路径，或把 $HOME/.local/bin 加入用户的 PATH。

8.1 查看日志概况和主题

ulog_info flight.ulg

详细显示：

ulog_info -v flight.ulg

重点检查：

• 日志开始时间和持续时间。
• 是否存在 dropout。
• 硬件和固件版本。
• 日志包含哪些 uORB 主题。
• 每个主题的数据点数量。

如果想分析某个问题，却发现关键主题没有记录，事后无法从该日志恢复这些数据，只能调整日志配置后重新测试。

8.2 把指定主题导出为 CSV

不要默认把全部主题导出成几百个 CSV。应按问题选择主题：

mkdir -p csv_out
ulog2csv -m vehicle_status,vtol_vehicle_status,vehicle_attitude,vehicle_local_position,airspeed_validated -o csv_out flight.ulg

仅导出特定时间段：

ulog2csv -ts 30 -te 55 -m vehicle_attitude,vehicle_attitude_setpoint,airspeed_validated -o csv_out flight.ulg

-ts 和 -te 使用日志开始后的秒数，适合只提取故障附近的窗口。

查看帮助：

ulog_info -h
ulog2csv -h

8.3 Python读取示例

from pyulog import ULog

ulog = ULog("flight.ulg")

print("Start timestamp:", ulog.start_timestamp)
print("Last timestamp:", ulog.last_timestamp)

for dataset in ulog.data_list:
    print(dataset.name, dataset.multi_id, len(dataset.data["timestamp"]))

vtol = ulog.get_dataset("vtol_vehicle_status").data
print(vtol.keys())

使用前先通过 ulog_info 或 data.keys() 确认字段名。不同 PX4 版本的主题和字段可能变化，不应把其他版本脚本中的字段名直接套用。

---

9. 工具四：PX4自带 EKF2 分析脚本

当前源码仓库包含：

Tools/ecl_ekf/process_logdata_ekf.py
Tools/ecl_ekf/analyse_logdata_ekf.py
Tools/ecl_ekf/batch_process_logdata_ekf.py

在 PX4 源码目录中执行：

cd /home/jiagu/seeker_debug_tool1/simulation_ws/deps/PX4-Autopilot
python3 Tools/ecl_ekf/process_logdata_ekf.py /完整路径/flight.ulg

脚本正常完成后会生成类似文件：

flight.ulg-0.mdat.csv
flight.ulg-0.pdf

• .mdat.csv：EKF各项指标和 Pass/Warning/Fail 结果。
• .pdf：EKF关键曲线报告。
• -0：第0个 EKF 实例；启用多 EKF 时可能有多个实例。

只运行检测、不生成图：

python3 Tools/ecl_ekf/process_logdata_ekf.py /完整路径/flight.ulg --no-plots

该脚本至少需要日志中包含：

• estimator_states
• estimator_status
• estimator_status_flags
• estimator_innovations
• 能够判断起飞和着陆的数据

如果日志没有检测到有效飞行段，或者缺少必要主题，脚本会报告前置条件不满足。

9.1 自动 EKF 报告的正确用法

自动报告适合：

• 快速检查 GNSS、磁力计、高度、速度和空速创新。
• 批量比较多次试飞。
• 找出异常时间段和异常指标。

它不负责：

• 判断舵面安装反向。
• 判断电机编号映射错误。
• 分析全部 VTOL 转换逻辑。
• 代替对飞行视频、机体结构和供电系统的检查。

因此 EKF报告为 Pass，不代表整架飞机所有系统都正常；报告为 Fail，也要继续判断是什么外部因素导致 EKF观测异常。

---

10. 通用日志分析方法

分析日志不要一上来查看所有曲线。建议固定采用以下流程。

第一步：明确问题和时间点

先用一句话描述现象，例如：

解锁后起飞正常，前转换约3秒后飞机快速掉高并自动退回MC。

同时记录：

• 故障发生在起飞后多少秒。
• 当时飞行模式。
• 遥控器执行了什么动作。
• 飞机实际表现。
• QGC显示了什么消息。

第二步：检查日志是否完整

检查：

• 日志是否覆盖故障前后。
• 是否在空中突然结束。
• dropout 是否严重。
• 关键主题是否存在。
• 固件版本和参数是否与预期一致。

第三步：建立事件时间线

优先查找：

• 解锁。
• 起飞。
• 模式变化。
• VTOL转换请求和状态变化。
• PX4 warning/error/failsafe事件。
• Quadchute。
• 上锁、坠机或日志中断。

第四步：比较目标与实际状态

控制问题最重要的判断原则：

目标是否合理？
实际状态是否跟上目标？
控制输出是否还有余量？

典型比较包括：

• 期望姿态 vs 实际姿态。
• 期望角速度 vs 实际角速度。
• 期望高度 vs 实际高度。
• 期望速度 vs 实际速度。
• 期望推力/力矩 vs 最终执行器输出。

第五步：判断是估计问题还是物理响应问题

传感器变化合理，但EKF输出异常 → 重点查融合和参数
传感器本身跳变             → 重点查传感器、安装、供电和干扰
EKF状态正常，实际未跟目标   → 重点查控制器、执行器、重心和动力
控制目标本身异常           → 重点查模式、任务、设定值和上游逻辑

第六步：寻找最早异常，不要只看最后告警

坠机前往往会连续出现很多错误。最后出现的“姿态失控”“EKF异常”可能只是结果。应向前回溯，找出第一条偏离正常状态的数据。

第七步：用其他证据交叉验证

日志不能直接看到：

• 螺旋桨是否断裂或脱落。
• 舵面连杆是否松脱。
• 机架是否开裂。
• 外部风况和碰撞过程。
• 电源接头是否瞬间接触不良。

因此最好同时保留：

• 飞行视频。
• QGC画面或截图。
• 机体照片和损伤情况。
• 参数文件。
• 电机、螺旋桨、舵面和电源配置。

---

11. EKF2问题重点看什么

推荐主题：

estimator_status
estimator_status_flags
estimator_innovations
estimator_states
vehicle_attitude
vehicle_local_position
vehicle_global_position
sensor_gps / vehicle_gps_position（以日志实际主题为准）
sensor_mag
vehicle_air_data
airspeed_validated

11.1 检查融合状态

estimator_status_flags 用于确认在异常时刻：

• GNSS位置是否正在融合。
• GNSS速度是否正在融合。
• 磁力计或其他航向源是否正在融合。
• 气压、GNSS、测距或视觉高度源是否启用。
• 空速是否参与相关融合。
• 是否进入惯性推算或失去位置辅助。

11.2 检查创新量和检验比

创新量是观测与预测的差：

innovation = measurement - prediction

需要关注：

• 异常是否短暂还是持续。
• 哪一类观测首先出现异常。
• 是否和模式切换、油门增加、振动或供电变化同时发生。
• 检验比是否越过拒绝门限。

不能只凭创新量大就认定 EKF算法错误。强振动、气压口受螺旋桨气流影响、磁场干扰、GNSS遮挡和空速管安装错误都可能造成创新异常。

11.3 尾座式姿态变化的特殊性

尾座式前转换会产生约90度的姿态变化和明显加速，以下现象需要一起观察：

• 实际俯仰是否平滑跟随转换目标。
• 加速度变化是否与推力和姿态变化相符。
• 气压高度是否受气流干扰。
• GNSS垂直速度与气压高度是否一致。
• 空速增长是否合理。
• 转换过程中是否发生磁力计或GNSS融合切换。

---

12. 振动问题重点看什么

推荐主题和图表：

• 原始或滤波后的加速度计数据。
• sensor_accel。
• sensor_gyro。
• vehicle_angular_velocity。
• 加速度功率谱。
• Actuator Controls FFT。
• IMU clipping/剪切计数。

常见特征：

• 悬停时加速度曲线很粗、三个轴互相覆盖。
• 某个固定频率出现强峰值。
• 提高油门后振动突然明显增加。
• IMU clipping持续增长。
• 振动出现后紧接着发生EKF创新异常。

振动可能来自：

• 螺旋桨不平衡或损伤。
• 电机轴弯曲、轴承问题。
• 电机或机臂松动。
• 飞控减振安装不当。
• 机架、起落架或线束共振。
• 高频控制参数不合适。

日志能证明振动存在并确定频率和发生时间，但不一定能单独指出是哪一个物理零件，需要结合实机检查。

---

13. 控制器和执行器问题重点看什么

推荐主题：

vehicle_attitude
vehicle_attitude_setpoint
vehicle_angular_velocity
vehicle_rates_setpoint
vehicle_torque_setpoint
vehicle_thrust_setpoint
actuator_motors
actuator_servos
actuator_outputs
battery_status

不同版本和驱动配置记录的最终执行器主题可能不同，应以 ulog_info 实际输出为准。

13.1 目标跟踪差

如果目标变化正常，但实际姿态或角速度跟不上：

• 检查输出是否饱和。
• 检查电机和舵面方向。
• 检查控制参数是否过低或过高。
• 检查重心、惯量和执行器能力。
• 检查电池压降和推重比。

13.2 输出长期饱和

某些电机或舵机长期达到上下限，通常表示控制器没有足够余量。可能原因包括：

• 飞机过重或推力不足。
• 重心偏移。
• 舵面行程不足。
• 电机、螺旋桨或舵机异常。
• 错误的执行器几何或控制分配。
• 过于激进的目标和控制参数。

短时间满油门并不必然是故障，必须结合飞行阶段和目标判断。

---

14. 当前尾座式 VTOL 转换如何分析

推荐至少记录和查看：

vehicle_status
vtol_vehicle_status
vehicle_attitude
vehicle_attitude_setpoint
vehicle_angular_velocity
vehicle_rates_setpoint
vehicle_local_position
airspeed_validated
vehicle_torque_setpoint_virtual_mc
vehicle_torque_setpoint_virtual_fw
vehicle_thrust_setpoint_virtual_mc
vehicle_thrust_setpoint_virtual_fw
vehicle_torque_setpoint
vehicle_thrust_setpoint
actuator_motors / actuator_servos / actuator_outputs
battery_status
estimator_status
estimator_status_flags
estimator_innovations

默认日志中大部分主题已经存在；部分虚拟控制输出是 optional，必须先用 ulog_info 确认实际日志是否记录。

14.1 建立转换时间线

按顺序标记：

收到固定翼转换请求
        │
        ▼
进入 TRANSITION_TO_FW
        │
        ▼
俯仰目标开始向固定翼方向变化
        │
        ▼
实际俯仰跟随、飞机加速、空速上升
        │
        ├── 条件满足 → 进入 FW
        │
        └── 条件失败/保护触发 → Quadchute回MC

14.2 前转换逐项检查

1. vtol_vehicle_status 是否确实进入前转换。
2. 姿态目标是否平滑向前俯转。
3. 实际俯仰是否跟随目标，有没有明显滞后或振荡。
4. 多旋翼虚拟力矩和推力是否正常输出。
5. 电机最终输出是否饱和或明显不对称。
6. 电池电压是否在加速时大幅下降。
7. 空速是否连续、合理地增长。
8. 地速和空速是否符合当时风况。
9. 高度和垂直速度是否发生不可接受的下降。
10. 是否进入固定翼状态，或者出现 Quadchute 事件。

14.3 常见异常模式

日志现象	优先怀疑方向
姿态目标正常，实际俯仰跟不上，电机已饱和	推重比、重心、控制参数、电机能力
姿态跟踪正常，但空速增长很慢	推力不足、阻力过大、逆风、空速计或安装问题
空速突然跳变，而地速和姿态无对应变化	空速计、皮托管、气路或校准问题
转换时高度估计跳变，GNSS垂直运动不支持该变化	气压气流干扰或EKF高度源问题
电机输出正常，但某一轴姿态突然失控	电机/舵面机械问题、控制分配、振动或传感器异常
转换达到固定翼后立即退回MC	查看Quadchute原因、空速、角度、掉高和超时条件
日志在高功率阶段突然结束	供电、飞控重启、硬故障或SD卡问题

14.4 后转换逐项检查

1. 状态是否从 FW 进入 TRANSITION_TO_MC。
2. 姿态目标是否回到接近竖直悬停方向。
3. 实际俯仰是否平滑跟随。
4. 固定翼推力向多旋翼推力的连接是否连续。
5. 空速下降过程中舵面控制能力是否减弱。
6. 多旋翼电机力矩是否及时恢复。
7. 是否出现掉高、振荡或输出饱和。
8. 是否最终进入 MC 状态。

---

15. 电池和供电问题重点看什么

推荐主题：

battery_status
system_power
vehicle_status
actuator_motors
cpuload

检查：

• 大油门时电压是否严重下跌。
• 电流是否达到电池、线材或电源模块极限。
• 电压下降是否和姿态失控、重启或日志终止同时发生。
• 剩余电量估计是否突然变化。
• 是否出现电池相关 failsafe。

ULog可能在彻底掉电前来不及记录最后一个瞬间，因此“日志内没有看到电压为0”不能排除供电瞬断。

---

16. QGC消息和事件如何分析

ULog会记录 PX4事件、warning 和 error。Flight Review会根据日志中的事件元数据将其翻译成人类可读内容。

分析事件时应记录：

• 事件准确时间。
• 事件严重级别。
• 事件发生前5至10秒的传感器和控制数据。
• 事件之后系统采取了什么动作。

例如 QGC显示“Transition timeout”，真正需要查的是超时前：

• 是否收到转换请求。
• 姿态是否达到要求。
• 空速是否增长。
• 电机是否饱和。
• 是否掉高。
• 空速是否有效。

事件说明 PX4在哪个保护条件上作出了判断，但根因可能更早发生。

---

17. 把日志交给我分析时需要提供什么

可以直接提供原始 .ulg 文件。不要先只转成截图或只给 CSV，因为原始文件包含更完整的主题、参数、事件和时间关系。

同时建议提供以下信息：

1. 问题发生在哪一次飞行。
2. 大约发生在起飞后多少秒。
3. 当时飞行模式，以及是否正在前/后转换。
4. 遥控器或QGC当时发出了什么命令。
5. 肉眼看到的飞机动作。
6. QGC显示的原始报错文字或截图。
7. 是否有同步视频。
8. 是否改过参数、固件或执行器分配。
9. 电机、舵面、GPS、空速计和电池配置。
10. 是否发生碰撞、断桨、掉电或飞控重启。

一个有效的问题描述示例：

文件：2026-08-12-15-30-20.ulg
现象：起飞后约42秒请求前转换，约47秒快速掉高并自动回MC。
操作：遥控器VTOL开关从MC切到FW，没有其他摇杆动作。
QGC消息：Transition timeout，随后提示Quadchute。
机体：双电机双舵面尾座式，空速计已连接CAN并校准。
改动：VT_F_TRANS_DUR从5秒改为4秒，其余转换参数未改。
附件：机载视频和QGC截图。

有了这些上下文，可以先定位时间段，再对照状态机、空速、姿态、EKF和执行器输出，分析效率会高很多。

---

18. 哪些结论不能仅凭 ULog 得出

ULog非常重要，但不是完整的“黑匣子真相”。以下情况通常需要其他证据：

• 某个螺旋桨是否在空中脱落。
• 某个舵机连杆是否滑脱。
• 实际风速、阵风和外部碰撞。
• 线缆或接插件是否发生微秒级瞬断。
• 相机、图传或独立设备内部故障。
• 飞控断电后未能写入日志的最后瞬间。

合理的结论应区分：

• 日志直接证明的事实。
• 多项数据共同支持的高概率原因。
• 当前证据无法排除的可能性。

---

19. 推荐的日常工作流

每次重要试飞建议保留一个独立目录：

flight_2026-08-12_01/
├── flight.ulg
├── params.params
├── qgc_message.png
├── flight_video.mp4
├── airframe_notes.md
└── analysis.md

建议分析步骤：

1. 保存原始 .ulg，不要修改。
2. 用 ulog_info 检查完整性、版本、主题和 dropout。
3. 用 Flight Review 做快速全局检查；敏感日志使用本地工具。
4. 建立异常事件时间线。
5. 用 PlotJuggler同步比较目标、实际、估计和输出。
6. EKF问题运行 PX4自带 EKF脚本。
7. 必要时用 ulog2csv 只导出相关主题和时间窗口。
8. 把结论、证据和下一次只改变的一个变量写入 analysis.md。
9. 下一次试飞后对比两份日志，而不是凭主观感觉判断改善。

---

20. 快速命令清单

# 查看日志主题、时长、固件信息和丢帧
ulog_info flight.ulg

# 查看详细信息
ulog_info -v flight.ulg

# 导出尾座式转换常用主题
mkdir -p csv_out
ulog2csv \
  -m vehicle_status,vtol_vehicle_status,vehicle_attitude,vehicle_attitude_setpoint,vehicle_local_position,airspeed_validated,battery_status \
  -o csv_out \
  flight.ulg

# 只导出日志开始后30至55秒
ulog2csv \
  -ts 30 -te 55 \
  -m vtol_vehicle_status,vehicle_attitude,vehicle_attitude_setpoint,airspeed_validated \
  -o csv_out \
  flight.ulg

# PX4 EKF专项分析
cd /home/jiagu/seeker_debug_tool1/simulation_ws/deps/PX4-Autopilot
python3 Tools/ecl_ekf/process_logdata_ekf.py /完整路径/flight.ulg

# 仅生成EKF检查结果，不生成PDF图表
python3 Tools/ecl_ekf/process_logdata_ekf.py /完整路径/flight.ulg --no-plots

---

21. 最终建议

对于当前尾座式项目，最实用的工具组合是：

1. ulog_info：确认日志是否可用和包含什么。
2. Flight Review：快速发现事件、振动、控制跟踪、EKF和执行器异常。
3. PlotJuggler：围绕转换时间点做多主题同步分析。
4. PX4 EKF脚本：对估计器进行专项健康检查。
5. 原始 .ulg + 视频 + 现象描述：进行最终根因判断。

不要直接根据一张曲线修改大量参数。先找出最早异常，建立因果关系，每次只验证一个主要假设，并保留修改前后的日志用于对比。