1. 课程导入

无人机AI项目的交付并非简单地将训练好的模型文件拷贝给客户，而是一个涉及算法工程、嵌入式系统、飞行安全与质量保障的系统工程。一个完整的交付物集合通常包含四个核心部分：模型文件（Model）、固件（Firmware）、飞行日志（Flight Log）和测试报告（Test Report）。这四者相互关联、互为印证，共同构成了项目验收与后续运维的技术基线。本章将围绕这四个关键交付物，梳理其在项目生命周期中的定位、价值与内在逻辑，帮助学员建立无人机AI项目交付的整体框架。

上图展示了四个核心交付物在项目不同阶段的流转关系。模型文件经过转换与量化后嵌入固件，固件在实飞中产生飞行日志，日志经过分析形成测试报告，而报告又反向验证模型与固件的质量。这种闭环关系构成了无人机AI项目交付的工程基线。下面我们将逐一拆解每个交付物的具体内涵、技术要点与常见误区。

1.1 模型文件：AI能力的核心载体

核心原理：模型文件是无人机AI功能的“大脑”，它封装了从输入数据（如图像、点云、IMU序列）到输出决策（如目标检测框、避障指令、语义分割掩码）的映射关系。在交付场景中，模型文件不仅仅是训练好的权重，还包含网络结构定义、预处理/后处理参数、类别标签映射、输入尺寸约束等元信息。常见的交付格式包括PyTorch的.pt、ONNX的.onnx以及针对嵌入式平台优化的TensorRT引擎文件.engine或RKNN格式。

判断方法与操作流程：在交付模型时，需要重点验证三个维度：精度（Accuracy）、时延（Latency）和体积（Footprint）。精度指标需在目标数据集上重新评测，不能直接引用训练集结果；时延需在目标硬件（如Jetson Orin、RK3588或STM32+NPU）上实测，而非GPU服务器上的推理时间；体积则直接影响固件分区大小和启动加载时间。交付前应完成以下操作：

1. 导出标准化格式（如ONNX），并固定输入张量形状（如1x3x640x640）。
2. 使用模型量化工具（如TensorRT PTQ或QAT）将FP32转为FP16或INT8，记录精度损失。
3. 编写模型说明文档（Model Card），包含训练数据分布、已知失效场景、版本变更记录。

1.2 固件：模型与硬件的桥梁

核心原理：固件是将模型文件、AI推理引擎、飞控调度逻辑、传感器驱动和通信协议打包而成的可烧录二进制文件。它运行在无人机的主控MCU或高性能计算单元上，负责协调实时控制（如PWM输出、姿态解算）与非实时AI推理（如目标检测）。固件交付的关键在于版本一致性——即固件中嵌入的模型哈希值必须与单独交付的模型文件哈希值一致，否则会出现“固件跑的是旧模型”的严重事故。

操作流程与案例拆解：以某农业植保无人机的“果树识别与变量喷洒”项目为例。初始交付时，团队将YOLOv5s模型转换为TensorRT引擎并集成进固件，但现场测试发现喷洒延迟高达180ms，导致药液漂移。通过分析飞行日志发现，AI推理线程与飞控控制线程共享CPU核心，推理任务抢占导致控制周期抖动。最终解决方案是：

• 将AI推理任务绑定到独立CPU核心（如Jetson的Denver核心），并设置实时优先级。
• 在固件中增加“推理超时看门狗”，若单帧推理超过80ms则自动降级为“均匀喷洒”模式。
• 重新编译固件后，实测延迟降至65ms，控制周期抖动小于0.5ms。

这个案例说明，固件交付不仅是代码编译，更是资源调度与安全兜底的设计。交付固件时，必须附带编译环境的完整说明（交叉编译器版本、依赖库哈希、内核补丁），确保客户能够复现构建过程。

1.3 飞行日志：飞行过程的“黑匣子”

核心原理：飞行日志是无人机在飞行过程中记录的时序数据流，通常包含IMU原始数据（加速度、角速度）、姿态估计结果、电机PWM指令、GPS位置、AI推理输入帧（缩略图或特征图）以及推理输出结果。日志的价值在于可追溯性——当交付后出现“偶发误识别”或“飞行抖动”时，日志是唯一能还原现场的技术证据。常见的日志格式有PX4的.ulog、MAVLink的.tlog以及自定义的CSV/JSON流。

判断方法与实战场景：在交付验收时，客户通常会要求提供至少3次完整任务的日志，覆盖白天/夜晚、晴天/弱光等典型场景。作为交付方，需要从日志中提取关键指标并生成摘要：

# 日志分析伪代码示例
import ulog
log = ulog.open("flight_20250321_1430.ulg")
# 提取AI推理频率
ai_freq = log.get("ai/inference_freq")
# 提取控制延迟
ctrl_delay = log.get("ctrl/loop_time")
# 检查异常事件
failsafe = log.get("events/failsafe_triggered")
print(f"AI推理平均频率: {ai_freq.mean():.1f} Hz")
print(f"控制环最大延迟: {ctrl_delay.max():.2f} ms")
print(f"触发保护事件次数: {failsafe.sum()}")

一个典型的排障案例：某城市巡检项目中，无人机在飞行至第8分钟时突然丢失目标。通过回放日志发现，AI推理输入图像的时间戳与IMU时间戳偏差达到120ms，导致目标位置预测错误。进一步分析发现，相机驱动在长时间运行后缓冲区溢出，丢帧后未正确重置时间戳基准。修复驱动并增加时间戳同步校验后，问题解决。这个案例表明，日志不仅是“记录”，更是跨模块时间同步分析的关键工具。

1.4 测试报告：质量与合规的证明文件

核心原理：测试报告是项目交付的“最终答卷”，它系统性地汇总了模型精度、固件稳定性、飞行安全性和任务完成率的量化证据。一份合格的测试报告应包含：测试环境描述（硬件版本、固件版本、气象条件）、测试用例清单（悬停、航线飞行、故障注入）、性能指标汇总（识别准确率、控制超调量、续航时间）、以及已知限制与免责声明。报告的价值在于降低信任成本——让客户无需重复全部测试即可建立对系统的信心。

操作流程与结构建议：测试报告应遵循“可复现”原则，即任何第三方按照报告中的步骤，应能获得相近的结果。建议采用以下结构：

1. 版本记录表：列出模型、固件、测试工具的精确版本号与哈希值。
2. 测试环境说明：包括测试场地的GPS坐标、风速、光照强度、地面站软件版本。
3. 功能测试矩阵：以表格形式列出每个功能点（如“识别高度5米处的行人”）的通过/失败状态、实测值、误差范围。
4. 可靠性测试：连续飞行10个架次，记录故障间隔时间（MTBF）或故障次数。
5. 安全测试：模拟GPS丢失、电机堵转、AI推理超时等场景，验证保护逻辑。

以某物流无人机“投递包裹识别”项目为例，测试报告中的关键数据如下：

*注：弱光环境未达标，已在报告中明确说明限制条件，并建议客户在夜间任务中开启辅助照明。该限制被客户接受并签署确认。

这个案例展示了测试报告的另一重要功能：风险透明化。主动披露已知限制，比隐瞒后在现场暴露问题更有利于长期合作。

1.5 常见误区与总结复盘

在无人机AI项目交付中，团队常陷入以下误区，需要特别警惕：

• 误区一：重模型轻固件。认为模型精度高就万事大吉，忽视嵌入式部署中的内存碎片、算子不支持、动态形状等问题。实际上，模型转换和固件集成往往占据项目40%以上的工作量。
• 误区二：日志记录不完整。只记录正常飞行数据，不记录故障注入或边界条件数据，导致后期排障时缺乏对照样本。建议每次测试都保留原始日志，并建立日志索引数据库。
• 误区三：测试报告“报喜不报忧”。隐藏失败用例或弱化性能波动，一旦客户在验收中复现问题，将严重损害技术信任度。正确的做法是如实呈现数据，并给出改进路线图。
• 误区四：交付物之间版本脱节。模型文件更新了，但固件中的模型未同步更新；或者测试报告基于旧固件编写。必须建立版本管理矩阵，确保四类交付物一一对应。

总结复盘：无人机AI项目交付的本质是工程化信任的建立。模型文件证明了“算法可行”，固件证明了“工程可用”，飞行日志证明了“过程可控”，测试报告证明了“结果可信”。四者缺一不可，且必须保持严格的一致性。在实际项目中，建议在项目启动初期就定义好交付物模板和版本管理规范，而非在项目末期匆忙整理。同时，培养团队“日志先行”的思维——每次飞行前明确要记录哪些关键数据，飞行后立即分析，而不是等到问题爆发才去翻找日志。