# 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事件、警告和错误消息。 - 飞行时使用的参数值以及固件版本信息。 它的核心价值是：把同一时刻的“输入、状态估计、控制目标、控制输出和故障事件”放在一条时间线上进行比较。 ```text 传感器输入 │ ▼ EKF状态估计 │ ▼ 控制目标与实际响应 │ ▼ 电机/舵机输出 │ ▼ 飞机运动结果和故障事件 ``` 仅看 QGroundControl 当时显示的一句错误，通常只能知道“系统发现了什么”；ULog 才能进一步判断“错误发生前后各数据如何变化”。 --- ## 3. 日志如何产生 PX4默认通常在解锁时开始记录，在上锁后停止记录。每次完整的解锁飞行一般都会生成一个新的 `.ulg` 文件。 在 MAVLink 控制台中可以检查记录器： ```sh logger status ``` 查看完整命令帮助： ```sh logger help ``` 手动开始和停止记录： ```sh logger on logger off ``` ### 3.1 建议的基本参数 首次调试建议保持： ```text 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 | 高频传感器主题 | 多个配置需要把数值相加。例如： ```text 默认主题 + 高频控制主题 = 1 + 16 = 17 ``` 不要为了“记录得更全”直接设置为 `4095`。高频原始 IMU 会显著增加写入带宽和文件大小，SD卡写入不及时反而会造成日志丢帧。 ### 3.2 针对当前尾座式的建议 - 日常飞行和第一次排查：`SDLOG_PROFILE=1`。 - 角速度跟踪、PID或快速转换细节：短时间测试可用 `SDLOG_PROFILE=17`。 - EKF深度回放不是普通故障排查的必需项，不要一开始就启用全部高频配置。 - 改变 `SDLOG_PROFILE` 后需要重启飞控。 ### 3.3 确认日志没有严重丢帧 日志质量也要检查。可以用： ```sh ulog_info flight.ulg ``` 输出中会显示： ```text Dropouts: count, total duration, max, mean ``` 少量很短的 dropout 未必影响分析，但故障发生的关键时间段存在长时间丢帧，会使因果链不完整。 如果日志经常丢帧，可检查： - SD卡质量和格式。 - 是否启用了过多高频记录主题。 - 日志文件是否过大。 - SD卡写入是否出现长时间阻塞。 飞控控制台可以测试 SD 卡： ```sh 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 卡根目录是否存在类似文件： ```text 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 | 常规曲线查看 | 功能和维护状态需按实际版本确认 | 建议采用这样的组合： ```text Flight Review快速总览 │ ▼ 找出异常发生的准确时间 │ ▼ PlotJuggler检查相关原始主题 │ ▼ pyulog或Python做精确提取和批量分析 ``` 如果日志包含敏感航迹、经纬度、设备编号或任务信息，不应上传公共 Flight Review；可以只使用本地工具，或者自建私有 Flight Review。 --- ## 6. 工具一：PX4 Flight Review 地址： 使用方式： 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 建议建立的四层布局 ```text 第一层：模式、状态和事件 第二层：目标值与实际状态 第三层：传感器和 EKF 创新量 第四层：电机、舵机、电池和执行器饱和 ``` PlotJuggler还可以： - 用四元数计算 roll、pitch 和 yaw。 - 做字段间加减、缩放和滤波。 - 用 X/Y 字段显示二维航迹。 - 保存尾座式专用分析模板。 ### 7.2 为什么需要多图同步 假设飞机转换时突然掉高，单看高度只能知道“发生了掉高”。同步查看以下数据才能判断原因： ```text VTOL状态 俯仰目标与实际俯仰 空速和地速 高度与垂直速度 推力目标 最终电机输出 电池电压 EKF垂直创新量 ``` 如果俯仰没有跟上目标且电机已经饱和，重点检查推重比、控制参数和重心；如果姿态正常但空速增长不足，重点检查推力、阻力和空速计；如果物理状态正常而估计高度突然跳变，则重点检查 EKF 和高度传感器。 --- ## 8. 工具三：pyulog 当前电脑已经安装： ```text pyulog 1.2.3 ulog_info：/home/jiagu/.local/bin/ulog_info ulog2csv：/home/jiagu/.local/bin/ulog2csv ``` 如果终端能找到用户级命令，可直接运行；如果提示找不到命令，可以使用完整路径，或把 `$HOME/.local/bin` 加入用户的 `PATH`。 ### 8.1 查看日志概况和主题 ```sh ulog_info flight.ulg ``` 详细显示： ```sh ulog_info -v flight.ulg ``` 重点检查： - 日志开始时间和持续时间。 - 是否存在 dropout。 - 硬件和固件版本。 - 日志包含哪些 uORB 主题。 - 每个主题的数据点数量。 如果想分析某个问题，却发现关键主题没有记录，事后无法从该日志恢复这些数据，只能调整日志配置后重新测试。 ### 8.2 把指定主题导出为 CSV 不要默认把全部主题导出成几百个 CSV。应按问题选择主题： ```sh mkdir -p csv_out ulog2csv -m vehicle_status,vtol_vehicle_status,vehicle_attitude,vehicle_local_position,airspeed_validated -o csv_out flight.ulg ``` 仅导出特定时间段： ```sh ulog2csv -ts 30 -te 55 -m vehicle_attitude,vehicle_attitude_setpoint,airspeed_validated -o csv_out flight.ulg ``` `-ts` 和 `-te` 使用日志开始后的秒数，适合只提取故障附近的窗口。 查看帮助： ```sh ulog_info -h ulog2csv -h ``` ### 8.3 Python读取示例 ```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 分析脚本 当前源码仓库包含： ```text Tools/ecl_ekf/process_logdata_ekf.py Tools/ecl_ekf/analyse_logdata_ekf.py Tools/ecl_ekf/batch_process_logdata_ekf.py ``` 在 PX4 源码目录中执行： ```sh cd /home/jiagu/seeker_debug_tool1/simulation_ws/deps/PX4-Autopilot python3 Tools/ecl_ekf/process_logdata_ekf.py /完整路径/flight.ulg ``` 脚本正常完成后会生成类似文件： ```text flight.ulg-0.mdat.csv flight.ulg-0.pdf ``` - `.mdat.csv`：EKF各项指标和 Pass/Warning/Fail 结果。 - `.pdf`：EKF关键曲线报告。 - `-0`：第0个 EKF 实例；启用多 EKF 时可能有多个实例。 只运行检测、不生成图： ```sh 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. 通用日志分析方法 分析日志不要一上来查看所有曲线。建议固定采用以下流程。 ### 第一步：明确问题和时间点 先用一句话描述现象，例如： ```text 解锁后起飞正常，前转换约3秒后飞机快速掉高并自动退回MC。 ``` 同时记录： - 故障发生在起飞后多少秒。 - 当时飞行模式。 - 遥控器执行了什么动作。 - 飞机实际表现。 - QGC显示了什么消息。 ### 第二步：检查日志是否完整 检查： - 日志是否覆盖故障前后。 - 是否在空中突然结束。 - dropout 是否严重。 - 关键主题是否存在。 - 固件版本和参数是否与预期一致。 ### 第三步：建立事件时间线 优先查找： - 解锁。 - 起飞。 - 模式变化。 - VTOL转换请求和状态变化。 - PX4 warning/error/failsafe事件。 - Quadchute。 - 上锁、坠机或日志中断。 ### 第四步：比较目标与实际状态 控制问题最重要的判断原则： ```text 目标是否合理？ 实际状态是否跟上目标？ 控制输出是否还有余量？ ``` 典型比较包括： - 期望姿态 vs 实际姿态。 - 期望角速度 vs 实际角速度。 - 期望高度 vs 实际高度。 - 期望速度 vs 实际速度。 - 期望推力/力矩 vs 最终执行器输出。 ### 第五步：判断是估计问题还是物理响应问题 ```text 传感器变化合理，但EKF输出异常 → 重点查融合和参数 传感器本身跳变 → 重点查传感器、安装、供电和干扰 EKF状态正常，实际未跟目标 → 重点查控制器、执行器、重心和动力 控制目标本身异常 → 重点查模式、任务、设定值和上游逻辑 ``` ### 第六步：寻找最早异常，不要只看最后告警 坠机前往往会连续出现很多错误。最后出现的“姿态失控”“EKF异常”可能只是结果。应向前回溯，找出第一条偏离正常状态的数据。 ### 第七步：用其他证据交叉验证 日志不能直接看到： - 螺旋桨是否断裂或脱落。 - 舵面连杆是否松脱。 - 机架是否开裂。 - 外部风况和碰撞过程。 - 电源接头是否瞬间接触不良。 因此最好同时保留： - 飞行视频。 - QGC画面或截图。 - 机体照片和损伤情况。 - 参数文件。 - 电机、螺旋桨、舵面和电源配置。 --- ## 11. EKF2问题重点看什么 推荐主题： ```text 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 检查创新量和检验比 创新量是观测与预测的差： ```text 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. 控制器和执行器问题重点看什么 推荐主题： ```text 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 转换如何分析 推荐至少记录和查看： ```text 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 建立转换时间线 按顺序标记： ```text 收到固定翼转换请求 │ ▼ 进入 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. 电池和供电问题重点看什么 推荐主题： ```text 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，因为原始文件包含更完整的主题、参数、事件和时间关系。 同时建议提供以下信息： ```text 1. 问题发生在哪一次飞行。 2. 大约发生在起飞后多少秒。 3. 当时飞行模式，以及是否正在前/后转换。 4. 遥控器或QGC当时发出了什么命令。 5. 肉眼看到的飞机动作。 6. QGC显示的原始报错文字或截图。 7. 是否有同步视频。 8. 是否改过参数、固件或执行器分配。 9. 电机、舵面、GPS、空速计和电池配置。 10. 是否发生碰撞、断桨、掉电或飞控重启。 ``` 一个有效的问题描述示例： ```text 文件：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. 推荐的日常工作流 每次重要试飞建议保留一个独立目录： ```text 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. 快速命令清单 ```sh # 查看日志主题、时长、固件信息和丢帧 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` + 视频 + 现象描述：进行最终根因判断。 不要直接根据一张曲线修改大量参数。先找出最早异常，建立因果关系，每次只验证一个主要假设，并保留修改前后的日志用于对比。