你可能觉得，把AI模型“装”到无人机上就三步：在电脑上训练好模型，导出一个文件，然后拷到机载电脑上跑起来。我当初也是这么想的。直到我把第一个目标检测模型搬上实验机，才发现机载AI部署是一个从模型层到工程层全部重新来过的过程。这一讲是《从零开发一架会AI的无人机》的第十四讲，前面十三讲我们搞定了机身结构、动力系统、飞控调参和地面站通信，这一讲聊最核心的一件事：机载AI部署——把训练好的模型装到无人机上，让它在飞行中实时处理画面、实时决策，而不是把视频传回地面再等结果。

在动手之前我想先把话放在前面：这条路没有服务器端那么舒服。你不能简单地把GPU服务器上的那套推理代码拷贝过来，因为无人机背着你的模型在天上飞，每一克重量、每一瓦功耗、每一毫秒延迟都在跟你对着干。这一讲我会尽量按我实际踩坑的顺序来讲，从权衡、选型、轻量化、部署到实机验证，每一环都给出可复现的做法，而不是只讲概念。

1. 为什么必须机载推理：带宽、延迟和断连这三笔账

很多刚接触无人机AI的人都会问同一个问题：地面站配一台好电脑，把图像传回去跑模型，不是更省事吗？我的回答是：省事，但不实用。机载推理的“必须”，不是技术偏好，而是由带宽、延迟和可靠性这三笔账决定的。

1.1 带宽账：视频回传喂不饱实时检测

机载摄像头输出1080p 30fps的原始画面，即使按H.264硬编码压缩到8Mbps，在常见的5.8GHz数字图传链路里也占掉一大半信道。地面端收到码流要解码、缩放、丢帧，再送给检测模型，整个处理链里每一环都是延迟和损耗。更关键的是，编码是为“人眼观看”设计的，运动目标周围的块效应和细节丢失，恰恰是目标检测最反感的输入。我用一组实测数据说明问题：地面端跑同一个YOLOv8s模型，从目标出现在摄像头视野到检测结果输出，平均延迟在300ms以上；机载端本地推理，同样模型端到端只有45ms左右。对于慢速巡检，300ms也许能忍；但要做避障和动态目标跟随，这个数字是致命的。

1.2 延迟账：1秒的画面里飞机已经飞出去好几米

我习惯用一个直观数字说明问题：自组机在GPS模式下平飞速度通常7m/s，比赛模式更高。假设AI检测延迟100ms，在这个延迟内飞机会前进0.7米；如果是300ms，那就是2.1米。动态障碍物不会在原地等你，你看到它的时候它可能正向你飞来。这时候推理必须尽量压缩到几十毫秒，否则地面站画面看得再清晰，决策链路也跟不上飞机本身的速度。本地推理的真正价值，是把“画面采集-推理-决策”完全放在同一块板子上，不受通信链路抖动影响，延迟稳定可控。这一点在自动避障、动态目标跟随场景里是刚需，不是可选项。

1.3 断连账：链路断开的那个瞬间，AI不能跟着断

在山区、桥底、楼宇间飞行时，图传和遥控链路随时可能被遮挡。如果AI只在远端跑，链路一断，飞机就变成纯“盲飞”状态。机载AI的核心意义之一，是在遥控和图传失效时仍然能依靠自身视觉完成应急动作：悬停、缓降、回到上一可靠点。我曾在山区洪涝灾害的应急模拟演练里做过一次测试，遥控信号被山体遮挡后，地面站完全看不到画面，飞机依靠机载视觉识别并自动返回了出发点。这个场景说明，机载推理不是“炫技”，而是可靠性的底线。把障碍物检测这类关键功能全放在地面端，意味着你的决策系统天然有一个单点故障，这正是无人机AI系统最不能接受的。

2. 机载计算平台选型：我把候选平台挨个飞了一遍

选平台第一件事不是挑芯片，而是看无人机的载重余量。这个系列前面讲电机选型时提过，每个电机需要留20%~30%推力余量。以我自己那台四轴为例，总起飞重量约2.3kg，用6英寸桨和2216电机，悬停油门约48%，加上云台和图传之后还能剩约600g有效载荷。机载AI板卡加相机、散热片、线材、减震板之后，必须压在这600g以内。

2.1 从负载能力反推平台上限

很多人在这上面翻车：先定了高大上的算力板卡，结果加完外壳和散热片之后超重几十克，只能拆掉其它传感器。我的建议是，先给AI分系统画一张重量预算表：板卡、金属外壳、散热片、风扇、相机模组、减震板、线束各占多少，加起来再乘以1.2的安全系数，够用才下单。以Jetson Orin NX为例，板卡约220g，带载板和散热后接近350g，再加相机和线束，单人很难控制在400g以内。如果你用的还是2212级别的小电机，这个重量基本送不上去。

2.2 我飞过的四类平台的真实感受

我先后在机载AI这个位置试过树莓派5、Jetson Nano、Jetson Orin Nano和RK3588方案，简单用表格说下感受，方便大家按自己需求快速对比：

表里的AI算力数字看看就好，实际帧率受散热和功耗策略影响很大。树莓派5加Hailo-8的组合名字很诱人，但Hailo的部署工具链资料少，我踩了不少坑，后来放弃了。RK3588性价比很高，尤其国产化项目里常用，跑YOLOv8s的NPU算力够用，就是RKNN的算子支持偶尔会给你“惊喜”。最后我长期用的是Jetson Orin Nano 8GB：虽然比别的贵，功耗也更高，但生态最省心，JetPack自带TensorRT，出问题的概率明显小。

2.3 散热和供电：这是“装进去”最容易出事的两处

板子装进机身之后，最大的敌人是散热和供电。Nano时代我图省事只贴了个被动散热片，结果夏天中午飞，10分钟就从60℃升到82℃触发降频，YOLOv8n从12fps掉到6fps，画面一拖一拖。后来改成翅片散热片加5V涡轮风扇，并把风扇接到飞控的电池监测通道上，起飞后自动全速，降落前减速，才把温度稳定在70℃以内。

供电方面，我强烈建议给机载电脑单独用一路BEC或小型DC-DC降压模块，不要跟飞控、舵机串在同一路电源上。舵机堵转或电机大电流会造成瞬间电压跌落，AI板卡容易重启。实测我用飞控5V输出给Jetson供电，一打舵电压从5.0V掉到4.4V，板卡直接进入不可用状态。后来改成独立5V5A降压模块，供电接口换成XT30保险插头，这个问题再没出现过。

3. 模型轻量化三件套：剪枝、量化、蒸馏不是可选项

装到无人机上的模型，大概率不是高精度大模型，而是满足任务需求的最小可行模型。我做机载AI的第一个任务是杆塔巡检里的绝缘子检测，最开始在PC上用的是YOLOv8m，mAP50有88%，很漂亮，但搬到Orin Nano上只有9fps。后来把任务拆开想：我需要的是在7m/s飞行速度下，看清几十米外的目标并给出大致位置，并不需要把每一处细小裂纹都标出来。于是换成YOLOv8s，mAP50降到84%，但帧率翻倍。很多时候不是模型越准越好，而是“在目标平台上的可用帧率”决定模型上限。

3.1 先把任务拆清楚再选模型

也有用Transformer结构（比如RT-DETR）的情况，检测精度确实高，但端侧直接跑很吃力，尤其动态shape和处理器支持不到位时延迟波动明显。我现在的习惯是：大模型只用来做离线分析和蒸馏，端侧实际部署的尽量是CNN检测头加轻量骨干，比如YOLOv8n/s、RTMDet的小版本。这样做的原因很简单：端侧处理器的硬件算子对CNN的支持成熟，未知的坑少，延迟也可预测。机载AI本质是工程问题，不是因为模型结构新就一定好。

3.2 结构化剪枝比你想的更省时间

轻量化的第一步不是量化，而是剪枝。通道剪枝可以在不改变模型结构文件的前提下，把不重要的卷积通道去掉。我用的方式是在训练阶段加稀疏化约束，让BN层的gamma值趋向于0，训练完根据gamma分布把低于阈值的通道裁掉，然后fine-tune几轮恢复精度。一套操作下来，YOLOv8s的理论计算量能降25%~35%，精度只掉1~2个mAP。注意别做非结构化剪枝（权重置零），那种剪枝在GPU上速度快但模型文件并不会变小，对部署没有实质帮助。结构化剪枝之后，模型文件和后续生成的engine文件都会同步变小，这才是机载场景真正需要的。

3.3 INT8量化：校准集不能随手拿

剪枝完成后做量化。FP16相对简单，大部分模型直接转换就能用，精度几乎不变；真正敏感的是INT8。INT8量化的关键是校准集，需要用有代表性的真实图像，最好从机载相机实际拍摄的素材里抽1000张左右，覆盖不同光照、不同角度、不同目标尺寸。我试过只拿500张通用数据集图片给消防场景模型做校准，结果mAP掉了6个点，换回实拍素材后只掉1.5个点。素材的代表性比数量更能决定量化质量。如果INT8之后精度崩得太狠，还有一招是混合精度：保持前几层或最后几层用FP16，中间层用INT8，精度掉得少一些，代价是推理速度略慢。在Orin Nano上，YOLOv8s的INT8比FP16快大约1.4倍，我通常优先考虑INT8。

3.4 知识蒸馏：把大模型的“判断经验”传给小模型

蒸馏对无人机机载AI是个非常划算的操作。用一个训练好的YOLOv8m（Teacher）去指导YOLOv8n（Student），不只是让Student学习真值框，还让它拟合Teacher在难样本上的概率输出和特征图。我做过一次雨天场景的检测对比：直接训练YOLOv8n的mAP50是74%，蒸馏后再微调能到79%，等于在不增加任何端侧算力的情况下白捡了5个点。蒸馏时的关键是Teacher的预测质量要够高，最好挑一批困难样本和模糊样本一起参与蒸馏，而不是随机抽样。机载环境的光照变化、运动模糊正是小模型最容易丢分的地方，拿这些样本定向“补课”，效果比盲目堆数据更明显。

4. TensorRT部署全流程：从PyTorch到engine文件

Jetson平台部署TensorRT，第一件事是版本对齐。JetPack版本的CUDA、cuDNN、TensorRT是打包好的，自己手动在Ubuntu上装很容易出现onnx解析器版本不匹配的问题。我强烈建议直接烧录对应JetPack的SDK镜像，并用apt方式更新到固定版本。比如JetPack 5.1.2自带CUDA 11.4和TensorRT 8.5，我的所有容器和onnx导出都按这个版本来，避免“本地能跑、板卡上Cannot parse”的经典尴尬。

4.1 版本对齐：JetPack是省心之选

我在容器化时也吃过亏：一开始图省事在宿主机上直接装Python包，后来发现JetPack自带的系统Python被改坏了，连nvcc都找不齐。重刷镜像之后，我把训练、导出、转换全部放进Docker容器，宿主机只保留JetPack原装环境。这样做的另一个好处是，换一台新的Jetson板卡时，容器一导入就能跑，不用重新排查环境。容器镜像里只需要装PyTorch CPU版、onnx、onnx-simplifier和trtexec依赖，推理代码用C++或Python都行，但建议至少把后处理部分用C扩展编译，避免Python GIL在推理循环里搅局。

4.2 从PyTorch导出ONNX再转engine

导出建议直接用官方export脚本，关键参数是opset和动态维度。下面是我用的命令：

python export.py --weights yolov8n.pt --include onnx --opset 12 --simplify

拿到onnx后用trtexec转换，FP16版本：

trtexec --onnx=yolov8n.onnx --saveEngine=yolov8n_fp16.engine --fp16 --workspace=1024

INT8版本需要先准备校准缓存，简单方式是写一个Calibrator类处理一批校准图，生成calibration.cache，再执行：

trtexec --onnx=yolov8n.onnx --saveEngine=yolov8n_int8.engine --int8 --calib=calibration.cache --fp16

注意，--workspace是构建期的临时工作空间大小，不是最终显存占用；给太大不会提升性能，只会让构建期吃满内存。我的经验是设1024~2048MB足够，engine生成之后就不再依赖workspace。

4.3 固定输入尺寸和预处理对齐

很多教程喜欢让TensorRT支持动态分辨率，但无人机场景我劝你固定输入尺寸。比如YOLOv8n固定640×640，batch固定1。动态shape在每次推理时都会触发显存分配和优化重排，延迟抖动急剧增大，这对避障任务非常不友好。预处理对齐有个常见翻车点：训练时用的归一化是(x/255 - mean)/std，而部署代码里只用x/255，结果精度掉好几个点。我的做法是把归一化参数写进一个预处理结构体，训练和部署共用同一份配置。此外，摄像头输出的颜色顺序记得跟训练数据保持一致。我用GStreamer取RTSP流时默认是BGR，而训练用的是RGB，忘记转通道会让目标颜色特征完全错乱，错得还特别隐蔽。

4.4 推理循环：把CPU和GPU的活分开

部署时最容易出现“模型本身挺快，端到端却卡得要死”，问题往往出在推理循环写得糙。我的推荐结构是双缓冲队列：相机线程把新帧拷入pinned memory，推理线程只负责GPU侧执行，后处理线程做NMS和结果发布。帧率上限不由模型单帧时间决定，而是由整条流水线最慢的一环决定。NMS别在Python里用普通循环写，一张640×640图像有很多检测框时，纯Python NMS可能吃掉8ms以上。可以换成TensorRT的EfficientNMS插件让NMS直接在GPU完成并输出筛选后的结果，或者用C++实现一个轻量NMS。实测下来，EfficientNMS插件能把后处理从8ms压到2ms左右，真机里检测结果不再一卡一卡地出。

5. 实机测试踩坑实录：过热降频、框抖动和IMU采样率

设备装好那天，我兴冲冲抬头机做静态推理测试，帧率35fps，很完美。结果一装上桨叶起飞，帧率立刻掉到15fps。排查对象不是模型不是板卡，而是振动。电机高速旋转带来的高频振动通过机架传递到相机固定件上，画面出现滚纹和边缘抖动，检测框跟着乱跳。这个教训让我明白：机载AI部署不只是软件问题，机械减震做不好，模型精度再高也白搭。

5.1 第一次整机联调的崩溃现场

解决振动问题分两步：一是相机安装位置加硅胶减震球，并尽量把相机远离飞控IMU，避免互相干扰；二是在软件层面对检测结果做滤波。硬件减震是根，软件滤波是补充，两者缺一不可。有人会用3D打印的硬连接件固定相机，我试过效果很差，桨叶振动直接传导到感光元件，图像行间都出现微小的错位。后来改用四点悬挂的硅胶减震球，并给相机底座增加配重，实测悬停状态下画面边缘的跳动幅度降低了70%以上。

5.2 框抖动：滑动窗口滤波模型的正确用法

检测框在视频流里来回跳，是机载视觉的常规问题。无人机悬停时会微抖，目标又被桨叶气流吹起尘土，YOLO的框中心每帧可能左右跳动十几个像素。直接拿原始框去控制云台或进行避障，效果就是一顿一顿的。我给检测框坐标加了一个滑动窗口滤波模型：保留最近5帧的框中心坐标，取中位数或均值作为输出。遇到目标快速移动时，我会把窗口缩短到3帧，否则框会显得“黏”住目标跟不上。经验是：低速悬停窗口可设5，高速跟随窗口设3。滑窗滤波虽然简单，但比单纯提高模型帧率更关键，因为它改变了输出的“稳定感”。

5.3 IMU采样率达不到200Hz会造成什么影响

这一讲虽然重点在AI，但绕不开一个重要前提：机载AI系统要和飞控的姿态估计共享时钟。我在调试视觉惯性融合时专门对比过IMU采样率的影响。飞控的IMU采样率如果只有100Hz，姿态更新和视觉特征点的时间戳对齐颗粒度会变粗；在快速横滚、俯仰时，融合轨迹的平滑度明显变差，动态目标检测结果在云台坐标系里存在可感知的滞后。换成200Hz采样率后，姿态估计更新周期从10ms缩短到5ms，融合误差明显下降。如果你们用的飞控支持IMU采样率配置，建议至少设到200Hz，并检查驱动日志有没有丢包。IMU数据和视觉帧的时间戳不对齐，AI输出的目标坐标一旦换算到地面系，会有系统性偏差，这个偏差没法靠模型参数修回来。

5.4 时间戳同步：光有检测框还不够

机载AI的最终输出往往要给到飞控：目标在画面里，要换算成偏航角偏差多少、距离多远。这里的关键是把相机帧的时间戳和IMU/飞控的姿态时间戳对齐。我用的是GMSL相机，支持trigger同步；如果是普通USB摄像头，至少要在驱动里打上系统时钟时间戳，并在飞控侧开启时间同步。实测中，时间戳偏差超过30ms时，目标方位角的解算值会静默偏移，偏移量随飞机姿态角速度加大，这种软故障比显式错误更难发现，排查时很容易误判成模型不准或云台标定问题。

6. 性能评估与后续优化：算力紧张时的几个土办法

机载AI落地前，我习惯用四维指标做验收：帧率、端到端延迟、整机AI系统功耗、检测精度。帧率和延迟用计时器打点，功耗直接读tegrastats里的GPU/CPU功率加总，检测精度则是把机载端的结果通过图传回传，在地面用同批次的真值做对比。这一套下来能回答“这套AI能不能上真机”——如果帧率低于任务要求但不影响安全，可以接受；如果端到端延迟超过100ms，基本不适合做避障类任务。

6.1 部署完成后怎么量化“够不够用”

我的验收方式比较朴素：在地面先跑30分钟静置推理，记录温度曲线和帧率曲线；再上真机飞10分钟，对比地面和空中的帧率差异。如果空中帧率比地面低超过20%，基本可以判断振动或散热出了问题，需要从机械层面解决，而不是继续优化模型。这个过程听起来麻烦，但能在真实任务前暴露大部分隐患，我自己靠这招在演练前避免过两次“整个任务中途掉线”的尴尬情况。

6.2 低显存运行模型的几个土办法

很多Jetson入门者一上来就担心显存不够。我的经验是按顺序优化：先用INT8把精度和显存一起降下来；然后固定batch=1、固定输入尺寸；如果还超显存，减少TensorRT的workspace，而不是硬扣中间张量。YOLOv8s INT8在8GB Orin Nano上batch=1实测显存约2.1GB，剩余空间足够跑一路摄像头解码再加一路RTSP推流。如果手头只有4GB的板子，可以把模型换成YOLOv8n并关掉多余的线程池，也能跑起来。还有一个更“土”的思路：目标检测不需要每帧都做，可以结合飞控的运动指令做触发式推理。我在自动巡检任务里，直飞段只开目标跟踪，转弯后或到达航点时才开完整检测，整体算力需求瞬间降了一半。这个思路比继续压显存更有效。

6.3 下一步：从目标检测到自主降落

机载AI部署完成之后，自然要往上走。我现在在做的是把检测结果和飞控联动，实现自动起降平台上的自主对准降落。具体来说，目标检测给出平台在图像里的像素坐标，结合云台角度、高度和机体姿态，通过相机内参反投影算出相对位置，再交给路径规划和降落控制。这一套链路里，部署好的模型只是第一步，后面的坐标解算、时间同步、控制接口才是真正拉开差距的地方。我在实际使用中还有一个体会：机载AI工程不是一锤子买卖，模型会换、任务会加，所以从第一天起就要把部署流程做成可复用的脚本，包括导出、量化、构建engine、性能回归。这样每次换模型，半小时内就能重新出数和试飞，而不是又花一个晚上手工调参。这一讲的内容基本都是我从“能跑”到“能飞”之间踩出来的，希望大家能少走点弯路。