1. 课程导入

PX4无人机AI交付，并非简单地将一个AI模型文件拷贝到机载计算机中运行。它是一条从数据采集、模型训练、参数调优、代码集成、硬件适配，到日志分析、测试验证与最终交付的完整工程链路。在实际项目中，我们经常看到团队在仿真环境中模型精度很高，但上机后却出现控制抖动、推理延迟过高、日志记录不完整等问题，根源往往在于缺乏一套系统化的交付方法论。本章作为整个课程的开篇，将为你勾勒出PX4无人机AI交付的全景地图，明确学习目标、课程框架与适用人群，帮助你在后续30章的学习中建立清晰的全局观。

上图展示了PX4无人机AI交付的七个关键阶段以及贯穿其中的四大核心交付物（代码、模型、参数、日志与测试报告）。从图中可以看出，交付并非线性结束于“测试验证”，而是通过“日志分析”反馈到“模型开发”或“代码集成”，形成一个持续迭代的闭环。接下来，我们将深入拆解每个模块的具体内涵。

1.1 核心原理：为什么AI交付需要系统化工程方法

PX4无人机AI交付的本质，是将一个在数据集中表现良好的AI模型，安全、稳定、高效地部署到物理无人机系统中，并使其在真实环境中完成预定任务。这涉及两个截然不同的技术栈的融合：AI/ML技术栈（Python、PyTorch/TensorFlow、CUDA、模型量化）与实时嵌入式系统技术栈（C++、PX4固件、RTOS、MAVLink协议）。

这种融合带来了三个核心挑战：

• 资源约束：机载计算机（如NVIDIA Jetson Orin Nano、树莓派）的算力、内存和功耗远低于训练服务器。模型必须经过量化、剪枝等压缩处理，且推理延迟必须满足控制回路的实时性要求（通常为10-50ms）。
• 环境差异：训练数据多为理想光照、清晰视角，而实际飞行会遇到光照变化、运动模糊、震动、低对比度等噪声。模型在仿真中精度高，不代表在实飞中同样鲁棒。
• 系统耦合：AI输出（如目标检测框、避障指令）需要与PX4的姿态控制、位置估计、任务规划等模块深度耦合。一个不稳定的AI输出可能导致控制震荡甚至坠机。

因此，系统化工程方法的核心在于可复现性与可追溯性。每一次交付，都必须能够回答：使用了哪个版本的代码？哪个版本的模型？哪些参数？基于哪些日志和测试报告得出的结论？这正是本课程要解决的核心问题。

1.2 判断方法与操作流程：如何评估一个AI交付项目的成熟度

在开始学习具体技术之前，我们需要掌握一套评估AI交付项目成熟度的判断框架。这有助于我们识别项目中的薄弱环节，并合理分配学习精力。以下是一个四维度评估模型：

评估维度	初级（L1）	中级（L2）	高级（L3）	专家级（L4）
代码管理	脚本散落，无版本控制	有Git仓库，但无CI/CD	自动化构建与测试	完整的DevOps流水线，支持回滚
模型管理	模型文件手动拷贝	有模型版本记录	模型注册中心，元数据完整	模型自动评估与准入机制
参数管理	参数在代码中硬编码	使用配置文件，但无校验	参数与代码分离，有默认值	参数动态加载，支持热更新
日志与测试	无日志或仅print输出	有ULog记录，但无分析工具	自动化日志分析，生成报告	基于日志的智能归因与预测

在实际操作中，你可以按照以下流程对项目进行快速体检：

1. 检查代码仓库：查看是否有README、依赖锁定文件（如requirements.txt、package.xml）、以及Dockerfile或构建脚本。
2. 检查模型目录：确认模型文件是否附带SHA256校验和、训练参数记录、评估指标报告。
3. 检查参数文件：确认PX4参数（如MC_PID_RATE_P）是否通过配置文件或MAVLink参数协议动态设置，而非硬编码。
4. 检查日志目录：确认是否定期导出ULog文件，是否有对应的Flight Review或PlotJuggler分析脚本。

1.3 案例拆解：一个失败的AI避障交付项目复盘

为了更直观地理解系统化交付的重要性，我们来看一个典型的失败案例。某团队开发了一个基于视觉的避障系统，目标是在PX4四旋翼上实现前方障碍物检测与绕飞。

项目背景与约束：团队由3名算法工程师和1名飞控工程师组成，开发周期为3个月。机载计算机为Jetson Nano，运行TensorRT加速的YOLOv5s模型。飞控为Pixhawk 6C，通信方式为UART连接。

初始现象：在仿真环境（AirSim + PX4 SITL）中，模型检测精度达到85% mAP，避障成功率100%。但实飞测试时，无人机在遇到白色墙壁时直接撞上，且日志显示检测框严重滞后。

关键数据与日志分析：

• 推理延迟：仿真中平均推理延迟为15ms，实飞中由于Jetson Nano温升降频，延迟飙升至45ms。
• 图像质量：实飞摄像头为卷帘快门，在快速旋转时产生果冻效应，导致目标框偏移。
• 控制耦合：避障指令通过MAVLink的SET_POSITION_TARGET_LOCAL_NED发送，但未考虑PX4的offboard模式切换延迟，导致指令执行滞后。

分析判断过程：团队最初怀疑是模型过拟合，但通过对比ULog中的图像时间戳与推理输出时间戳，发现主要瓶颈在推理延迟和通信链路。进一步检查发现，Jetson Nano的散热片安装不当，导致CPU/GPU温度超过85℃，触发了降频保护。

实际操作步骤：

1. 更换为全局快门摄像头，消除果冻效应。
2. 优化TensorRT引擎，启用FP16精度，并将输入尺寸从640x640降至512x512，延迟降至22ms。
3. 在PX4参数中调整COM_DISARM_LAND（设置更长的超时时间），并增加MAVLink通信速率。
4. 在代码中增加推理结果置信度阈值（0.6），低于阈值时忽略检测框，避免误触发。

结果对比：优化后，实飞避障成功率从0%提升至80%。剩余20%的失败案例均发生在逆光场景，最终通过增加图像增强预处理（直方图均衡化）解决。

风险与代价：该问题导致项目延期2周，额外花费约5000元用于更换摄像头和散热模组。复盘发现，如果团队在项目初期就建立硬件在环（HIL）测试环境，并制定详细的日志分析流程，这些问题可以提前暴露。

1.4 常见误区与总结复盘

在PX4无人机AI交付的入门阶段，学习者容易陷入以下几个误区：

• 误区一：重模型轻系统。认为只要模型精度高，部署就水到渠成。实际上，模型部署后的推理延迟、内存占用、数值稳定性往往比离线精度更重要。
• 误区二：忽视参数管理。将PX4参数与AI参数混为一谈，或者直接在代码中修改参数，导致无法复现实验结果。
• 误区三：日志记录不完整。只记录AI输出，不记录飞控状态（如姿态、速度、模式切换），导致问题无法关联分析。
• 误区四：测试覆盖不足。只在晴天、无风环境下测试，未覆盖低光照、小雨、强风等边界条件。

总结来看，本课程的核心目标是帮助你建立一套完整的AI交付知识体系。你将学习到：如何编写结构清晰、可维护的PX4 ROS2代码；如何将PyTorch模型转换为ONNX并进一步优化为TensorRT引擎；如何通过PX4参数动态调整控制行为；如何利用ULog和Flight Review进行深度日志分析；以及如何编写一份专业的测试报告。

在后续章节中，我们将按照“代码 → 模型 → 参数 → 日志 → 测试报告”的顺序，逐一深入每个交付物的具体实现细节。每一章都会包含实战案例、代码示例和常见陷阱提醒。建议你在学习过程中，结合自己的实际项目或开源的PX4仿真环境（如Gazebo + QGroundControl）进行动手实践。