带无人机出去外场跑一整天回来还要对着FPV录屏一帧帧翻就为了找画面里一闪而过的那辆车或者那个人——这类经历做过无人机视觉项目的人应该都不陌生。目标检测这个方向本身已经非常成熟但把一个目标检测模块真正装到无人机上让它稳定地在空中自主找到目标这中间隔着一大堆论文和项目文档里不会写的坑。这个Module 16要聊的不是单纯调一个YOLO模型而是覆盖整条链路的实战过程从无人机视角下的感知约束、算力与传感器选型到数据集准备、模型训练调优、机载部署推理再到把检测结果通过MAVLink交给飞控完成避障和跟踪。适合的人群是已经有一定无人机飞行基础、想入门无人机视觉感知的飞手或开发者。这一篇读完之后你应该能独立搭出一套“摄像头画面进来检测结果出去飞控做出反应”的完整系统。1. 无人机视角下的目标检测先搞清楚边界再动手1.1 无人机“看到”的世界和普通安防摄像头完全不是一回事很多人第一次做无人机目标检测会习惯性地拿公开的目标检测数据集比如COCO训练的模型直接搬到机载设备上跑。结果一到外场就翻车地面目标在画面里小得可怜目标稍一移动就糊成一片逆光时整个画面过曝。这个时候才意识到无人机视角的视觉感知有它自己的特殊性。第一个特殊性是尺度变化极其剧烈。普通监控摄像头安装高度相对固定目标的像素尺寸在一个范围内波动但无人机从10米爬到120米同一辆车的像素尺寸可能缩小到原来的十分之一以下。在500米高度看一辆普通轿车它的实际尺寸大约只有十几个像素而YOLO系模型默认训练时输入图片里的目标通常占据较大比例。这就是为什么在无人机场景里小目标检测永远是个绕不开的话题。第二个特殊性是运动带来的图像退化。无人机本身在飞云台在转地面目标在动三重运动叠加在一起很容易出现运动模糊。我自己实测过在傍晚光线一般的情况下快门速度只要低于1/500秒画面里运动目标的检出率就会明显下降。这不是算法能完全弥补的必须从传感器和参数层面提前解决。第三个特殊性是光照变化的剧烈程度。从阴影区飞到阳光直射区曝光参数还没来得及自适应画面就已经过曝了。正面迎光时目标可能完全处于逆光剪影状态纹理信息全部丢失。这些都不是靠换一个更“聪明”的网络结构就能解决的需要从整个传感链路去设计。1.2 一条完整的感知-决策-控制链路长什么样把目标检测放到整架无人机里看它其实是“机载视觉感知”这个大模块里的一个环节。完整链条大致是这样的摄像头采集图像图像进入检测模型输出目标类别和位置跟踪模块对连续帧的检测结果做关联和稳定状态估计模块结合飞控的位姿数据把像素坐标估算成地面目标的地理坐标或者相对位置最后决策模块决定是悬停观察、自动跟随还是绕行避障。这个链路里每一环都可能出问题。检测模型漏检了跟踪模块可以靠预测延续一段时间的轨迹跟踪失效了飞控可以按最后已知位置做保守动作。我在实际项目里最深的体会是不要把检测模型的准确率当成整个系统的准确率系统的鲁棒性要靠上下游模块一起扛。一条非常实用的经验是在搭建完整链路之前先用一套离线录制好的机载视频做模块级联调。把实飞时的视频导入电脑让检测、跟踪、坐标转换的代码在同一份数据上跑逐帧对结果做可视化。链路里的bug在现场是很难调试的但在离线数据上可以快速定位。1.3 明确边界检测模型能输出什么不能输出什么做这个模块之前一定要先想清楚目标检测系统的边界。它能告诉你的是画面里有没有目标、目标在哪个像素位置、属于哪个类别、置信度多高。它不能直接告诉你的是目标距离无人机多远、目标朝哪个方向运动、目标是不是当前任务真正需要跟踪的那个目标。距离信息需要额外的传感器或者几何假设才能算出来。比如已知目标真实物理尺寸、当前飞行高度、相机内参可以通过小孔成像模型估算距离但那是有误差的还不小。目标运动的朝向需要连续多帧的跟踪结果才能估算单帧检测是无能为力的。另外一个常见误区是把置信度当成任务成功的概率。模型输出的0.9置信度只能说明“这个框和训练数据里的目标很像”不能说明“这就是任务目标”。在搜救、巡检这类落地场景里我会对检测结果加一层任务层校验比如颜色属性、区域约束、目标出现频率等避免模型被相似物体误导。2. 算力与传感器选型先做减法和功耗预算2.1 机载算力怎么选预算、功耗、散热三个一起看目标检测是要吃算力的而无人机恰恰在载重、功耗、散热三个维度上都非常敏感。我见过一个典型翻车案例有团队在六轴无人机上装了一块桌面级显卡算法倒是跑得飞快但整机续航从35分钟掉到12分钟电机电流明显增大飞完一块电池电机烫得不能碰。机载算力选型本质上是个平衡问题。常见的机载AI算力平台大概可以分成几个档次入门级是树莓派4B/5加推理棒适合跑轻量模型做原型验证功耗低但算力有限实测YOLOv8n在树莓派4B上用ONNXRuntime CPU推理大概只有2到3 FPS主流级是NVIDIA Jetson系列从Orin Nano到Xavier NX自带GPU和TensorRT加速能跑到10到30 FPS是目前无人机视觉项目最常用的选择工业级则是一些带NPU的国产平台或者小型化x86不同项目差异比较大。我自己用过的一块Jetson Orin Nano 8GB在TensorRT FP16精度下跑YOLOv8s640输入分辨率实测稳定16 FPS功耗在7到10瓦之间配合一块机载电池或者从飞控的BEC取电可以长时间运行。如果是树莓派5加Hailo-8L推理棒性价比也不错但底层适配需要自己做适合愿意折腾的人。选型时还要注意一个容易被忽略的细节散热。SBC在机载这种密闭或者半密闭环境里没有主动风道GPU满载时温度很容易到80度以上触发降频后FPS掉得厉害。我习惯在机身侧面开一个通风口或者直接绑一个5V的小风扇对着散热片吹效果立竿见影。2.2 相机选型和安装直接决定检测上限算法再强拍不清楚就全白搭。相机选型上几个关键参数是传感器尺寸、帧率、全局快门还是卷帘快门、镜头焦距、是否有自动曝光控制。无人机目标检测强烈建议优先考虑全局快门相机。卷帘快门在高速运动或振动环境下会产生果冻效应目标会变形检测框跟着抖动跟踪稳定性也会变差。全局快门相机虽然贵一些但这个钱值得花。帧率至少30 FPS起步60 FPS更好因为检测模型输入帧率通常是10到20 FPS相机帧率留出余量才能保证每次推理拿到的都是新鲜帧。焦距选择取决于任务距离。视角越窄看得越远但视野范围小目标容易跑出画面视角越宽视野大但远处目标变得太小。拍摄10到50米距离上的地面目标我一般推荐6到12mm焦距的镜头水平视场角在40到60度之间比较舒服。相机安装位置和固定方式也很有讲究。建议用减震球或者橡胶垫把相机和机身结构隔开减少高频振动传递。固定螺丝一定要打螺丝胶无人机振动环境下相机的锁紧螺丝松脱是特别常见又特别隐蔽的问题。我有一架测试机就是飞着飞着画面慢慢歪了降落一看镜头固定的三颗螺丝松了两颗。2.3 内外参标定不是可做可不做的事检测模型要输出目标在像素坐标系下的位置但飞控要的是机体坐标系或者地理坐标系下的位置这中间必须靠相机内外参做换算。内参标定解决镜头畸变和焦距问题外参标定解决相机相对于机体的安装姿态问题。内参标定用棋盘格加OpenCV的calibrateCamera就能做二十分钟能搞定。外参标定相对麻烦一些需要知道相机安装的俯仰角和偏航角相对于机头方向的关系。简单做法是测量安装支架的机械角度精度够用要更准可以用PNP算法对着已知尺寸的标定板解算。常被忽略的是半固态或者纯电子防抖相机会自动裁切画面导致有效焦距和视场角变化内外参也跟着变。如果是这类相机建议关闭电子防抖用机械云台来稳定画面否则标定参数会漂。3. 数据集准备公开数据只是起点自采数据才是真正的瓶颈3.1 哪些公开数据集适合无人机视角目标检测领域公开数据集不少但直接适配无人机视角的没有想象中那么多。COCO和VOC是通用目标检测的基准量大、类别丰富但绝大多数图像是平视或者俯视角度拍摄的目标尺度和无人机俯瞰场景差异很大直接用效果不会太好。针对航拍场景VisDrone是绕不开的数据集全部由无人机拍摄覆盖了汽车、行人、自行车、公共汽车等多个类别包含大量小目标样本是训练无人机检测模型的起始选择。UAVDT和DOTA也是常用的航拍数据集尤其DOTA还带旋转框标注适合进阶做定向目标检测。如果你的任务关注的是特定目标比如鸟、车辆、船只或某个工程结构那么特定类别的公开数据集会更实用。我个人的建议是用通用数据集做预训练用航拍数据集做迁移学习的中间站最后用自采数据做最终微调。三层数据叠加比任何单一数据源效果都好。3.2 自采数据与标注流程比想象中花时间自采数据是决定项目上限的关键。公开数据最多让你验证流程能跑通真正到实飞环境里光照、角度、背景这些因素全部变了只有自采数据才能让模型贴合真实任务。采集数据时要注意覆盖度同一目标要拍不同高度、不同角度、不同光照、不同季节背景目标本身最好也有多种状态比如车辆要拍车头、侧面、正上方的视角。最简单的办法是用无人机手动飞对目标区域做多次航线拍摄视频转抽帧后得到图片集。标注是另一个费时费力的环节。一个小型任务2000张图、每张平均3到5个目标用LabelImg或者X-AnyLabeling标注大约要一到两个人干三到四天。X-AnyLabeling支持半自动标注能先用已有模型打预标注框人再去修效率能提升不少。标注完成之后别忘了做数据划分训练集/验证集/测试集建议按7:2:1划分且划分前先确认同一目标不出现在跨集合的图片里否则会有数据泄漏问题。3.3 小目标检测问题为什么无人机上的目标总是小得可怜在无人机视角里小目标检测几乎是必然要面对的课题。究其原因就是上一章提到的像素尺寸问题。大部分检测模型为了压在机载算力里跑输入分辨率只能做到640甚至更低一个高空视角下的目标映射到输入图像上可能只有10个像素左右别说检测了人眼都不一定看得清。应对小目标问题我试过几种方案并做了对比增大输入分辨率好处是效果提升最直接但计算量成平方增长机载推理帧率会掉得厉害在原有大图上切块检测把图像分成多个区域分别推理然后合并结果能保留小目标细节但会带来重复检测和计算量倍增增加针对小目标的增强策略比如在训练时对目标做随机缩放、复制粘贴、拼接小目标样本效果提升明显代价几乎为零换用高分辨率特征融合更强的模型结构例如带P2检测头的模型对小目标更友好但需要更多算力支持。在没有办法换更强算力平台的前提下我最常用的组合是输入分辨率从640稍微提升到800加上训练时的小目标增强策略模型权重从YOLOv8s换成同系列的m版本。代价是帧率略有下降但小目标检出率能提高差不多一倍。注意小目标检测的提升是一个系统性问题不要指望单一的模型结构升级能解决所有问题训练数据里小目标的分布比例和输入分辨率往往比网络结构影响更大。4. YOLO训练流程与调参关键控制点不只在模型结构4.1 标准训练流程从数据配置到跑通一次完整训练YOLO目标检测流程现在非常标准化了使用Ultralytics的开源工具链从数据准备到训练命令半天就能跑通一次完整流程。# 数据目录结构datasets/mydataset/ # images/train, images/val, labels/train, labels/val # data.yaml内容 # train: datasets/mydataset/images/train # val: datasets/mydataset/images/val # nc: 1 # names: [car] yolo detect train datadata.yaml modelyolov8s.pt imgsz640 epochs100 batch16 device0训练启动之后重点关注三个指标训练损失曲线是否平稳下降、验证集上mAP50和mAP50-95的变化、各个类别和各个尺度区间上的单独表现。很多新手只看整体mAP但无人机场景里更应该关注的是小尺度目标的AP值因为总体mAP可能被大目标的高分掩盖了。4.2 影响检测精度的几个关键调节点模型结构、训练数据、超参数三者共同决定最终效果。在超参数里最常调也最容易出效果的有这几个学习率是整个训练里最重要的超参数。Ultralytics默认的lr0在0.01左右小数据集可以适当降到0.005防止过拟合。如果训练损失震荡严重先降学习率。批量大小受机载显存限制如果只能调到8甚至4就要同步把学习率调低一点否则相当于步子迈太大很容易震荡。Mosaic数据增强是YOLO系列的经典增强方式把四张图拼在一起训练能显著提升模型泛化能力。但在无人机小目标场景里拼接导致目标变得更小对检测反而不利训练后期会把mosaic概率关掉只对最后10到20个epoch用普通增强。锚框对YOLOv8之后版本的自动锚框设计影响减弱但如果你用的是YOLOv5或者自己在改结构锚框聚类还是要做的。自定义数据集上的目标尺度和COCO差异极大自动聚类出的锚框可能和实际分布完全不匹配检测框收敛会很慢。4.3 模型规模怎么选不是越大越好YOLO家族按规模和精度排nano、small、medium、large、xlarge参数量和计算量依次递增。机载平台算力有限模型规模的选择要结合部署平台的推理能力倒推。以Jetson Orin Nano为例做一个简单测算TensorRT FP16下YOLOv8s跑640输入大约是16 FPSYOLOv8m大约是9 FPSYOLOv8l就基本跑不动了。如果任务是识别空中目标需要帧率不低于15 FPS那就只能选s甚至n如果任务是静态区域的低空巡检帧率要求不高可以上m。我通常的做法是先用small规模模型打通整条链路保证端到端系统能用再去实验medium或者large模型看精度提升和帧率下降之间的性价比。优先保证系统的稳定性不要一上来就追求最强模型。5. 部署到机载平台模型转换、推理优化与后处理5.1 模型转换链路上的坑比训练还多训练出的PyTorch权重不能直接用在机载平台上一般流程是先导出ONNX再根据部署后端转成TensorRT引擎或者直接用ONNXRuntime跑。导出常用命令yolo export modelruns/train/exp/weights/best.pt formatonnx dynamicFalse imgsz640导出时有两个容易踩的坑一个是dynamicFalse的问题如果开了动态输入尺寸某些推理后端的算图过程会变慢而且显存碎片化实测帧率反而下降。另一个是opset版本兼容问题导出ONNX时用的opset版本太新在老版本ONNXRuntime上会直接报不支持的算子部署端和导出端的版本需要保持一致。TensorRT部署在Jetson上是性能最好的方案但TensorRT引擎是跟具体GPU型号和TensorRT版本强绑定的换一块板子就得重新构建引擎很多新手在这一步反复踩坑。构建引擎的时间通常得好几分钟对于反复调试的迭代来说非常痛苦。生产环境里有个实用技巧先把构建好的引擎序列化保存到硬盘每次启动时直接反序列化加载能大幅减少启动时间。5.2 推理优化的三板斧输入尺寸、精度、流水线部署优化最直接的手段是降低输入分辨率从640降到480或者416推理时间能减少一半但小目标精度必然受影响。其次是推理精度TensorRT支持FP16和INT8两种低精度模式FP16基本无感精度损失约0.5%以内INT8进一步减少计算量但需要校准集做量化不小心会掉几个点的mAP。我在机载项目里通常只用FP16INT8留给有经验的团队做。另一个常被忽略的优化方向是流水线。如果检测是单线程串行执行“采集一帧→预处理→推理→后处理”这个流程帧率必然受限于最慢的推理环节。改成三线程流水线采集线程不停抓帧预处理线程对最新帧做变换推理线程只处理预处理完的最新帧能有效把整体吞吐提上去。代价是会有两三帧的延迟但无人机视觉任务对延迟没有极端要求完全可接受。实测里还有一个无解的问题CPU预处理瓶颈。缩放和归一化虽然简单但高分辨率图像在高清视频流下非常吃CPU。如果CPU被预处理占满就会拖累整个系统的调度。解决方法是尽量用GPU或者NPU上的预处理算子把缩放和归一化直接合并到推理图里减少CPU负担。5.3 检测结果的后处理质量差距从这里拉开模型输出的原始结果不能直接用后处理阶段能显著影响最终表现。第一步是NMS非极大值抑制过滤重叠框航拍场景目标密集时NMS的IOU阈值设置很关键设太高会漏检重叠目标设太低误捡一堆重复框一般0.45到0.5看起来比较合适。第二步是针对时序的平滑和稳定性处理。单帧检测会有抖动直接把这个结果输出给飞控飞控会疯掉的。最简单的办法是加一个滑动窗口滤波取最近5帧的同类检测框坐标做均值或者用带权重的指数移动平均。更正规的方案是接入跟踪算法比如ByteTrack或者DeepSORT用目标ID把跨帧轨迹串起来不但框更稳还能输出运动方向。第三步是置信度阈值设置。机载场景我一般设置两类阈值检出阈值0.25跟踪确认阈值0.5。第一类用于生成候选框第二类用于跟踪起始。这个双阈值设计能有效过滤掉那些闪烁出现的误检框。6. 检测结果怎么交给飞控避障、跟踪与MAVLink通信6.1 先理解飞控和数据链路的关系机载视觉模块和飞控之间的连接方式取决于飞控的硬件接口和通信协议。主流的PX4和ArduPilot飞控都支持MAVLink协议视觉模块可以通过串口或者USB连接到飞控的TELEM接口以MAVLink消息的形式发送检测结果。MAVLink是一套非常庞大但设计良好的通信协议消息类型非常多。对视觉模块来说经常用到的有OBSTACLE_DISTANCE把检测到的障碍物距离填入距离数组发给飞控用于避障DISTANCE_SENSOR上报单个测距传感器的数据LANDING_TARGET用于降落目标引导还有GLOBAL_POSITION_INT这类定位数据用于坐标同步。实际项目里视觉模块和飞控的MAVLink通信通常还需要一台运行QGroundControl或者Mission Planner的地面站做中间可视化。外场调试时地面站的作用不只是显示还可以直接改飞控参数、看日志回放是排查问题的重要工具。6.2 避障实现OBSTACLE_DISTANCE消息的实用写法让无人机避开检测到的目标比很多人想象的要简单。PX4已经内置了基于距离传感器的避障模块视觉模块要做的只是把“哪个方向有障碍物、距离多远”告诉飞控。无人机避障算法的大致逻辑是机载视觉模块持续检测画面把障碍物投影到以机体为中心的极坐标系里生成一个扇形距离数组然后通过OBSTACLE_DISTANCE消息发给飞控。飞控内部会把这些距离数据纳入局部规划器一旦某个方向上的距离低于设定安全阈值就会自动调整航向绕开。通信频率上避障消息一般要求不低于10Hz我习惯用15到20Hz飞控响应会更平滑。消息里的时间戳必须用飞控能够同步的时间基准常见做法是填收到该图像时的MAVLink时间戳。还有一个容易忽略的细节OBSTACLE_DISTANCE的angle_offset和increment必须和相机安装方向严格匹配否则飞控会把左边的障碍物当成右边的障碍物后果很危险。注意PX4的避障模块默认关闭需要在参数里打开同时还需要把航点模式切换成带避障的规划器模式。第一次测试避障建议先在仿真环境里验证再上真机并且遥控器随时准备接管。6.3 目标跟踪实现从像素坐标到云台联动跟踪是比避障更复杂的应用场景目标不仅仅是“不能撞上”还要一直保持在画面中心附近。完整流程是检测模块输出目标框跟踪模块负责持续锁定并预测目标运动云台控制模块根据目标框相对画面中心的偏移量调整相机朝向飞控再根据目标的相对位置做悬停或者跟随。最简单的云台追目标控制逻辑计算目标框中心与画面中心的像素偏差经过一个比例控制器输出云台俯仰和偏航角速度指令。控制频率不需要太高10Hz足够云台机械响应本身就慢。P值设太大会震荡设太小会跟丢目标需要现场调。如果想让无人机自主跟随目标移动还需要把目标框的位置转换到机体坐标系。假设目标在地面可以通过高度和相机俯仰角估算水平距离配合云台偏航角得到目标在机体坐标系下的方位再把这个方位期望发给飞控的位置控制器。这套逻辑在OpenCV和MAVLink的标准接口上都能实现代码量比想象中少困难的是参数调节。我在这个环节的习惯是先在PX4的软件在环仿真SITL里把整套逻辑跑通用仿真环境里的小车模型代替真实目标调好PID参数再上真机。仿真环境里跑通至少能解决80%的逻辑问题剩下20%是传感器噪声和环境干扰只能现场调。7. 实飞中的环境之坑外场测试的三类典型失败7.1 逆光和自动曝光的斗争外场环境里逆光导致的检测失效几乎每个人都会遇到。问题通常出在相机的自动曝光被天空的强光带偏整个地面区域变成暗部目标纹理全部丢失。解决办法有两个层面底层是相机的曝光设置。支持手动模式的相机把曝光锁定在地面目标的平均亮度上不要等自动曝光慢慢恢复。支持AE Lock的相机可以掉头锁定曝光值再飞回目标区域作业。上层是任务规划尽量避开上午10点到下午3点这段太阳高度最高、光照最强的时段。这两个办法配合逆光问题能解决大半。实在要对抗强逆光可以考虑加偏振镜。偏振镜能滤掉一部分地面反光对植被、水面等场景有奇效代价是整体进光量下降对光线本来就差的环境不友好。7.2 运动模糊与帧率预算的两难无人机飞行速度快、振动强运动模糊问题在傍晚光线不足时被进一步放大。提高快门速度是解决运动模糊最直接的办法但快门提高了进光量减少画面整体变暗噪声变大检测精度又掉下来。这种两难情况我的解法是联动调节白天光线好的时候快门固定在1/1000秒以上ISO压到最低傍晚光线差的时候快门降到1/500秒ISO允许升到1600左右同时把检测模型输入分辨率从640降到480用更大目标的相对像素弥补画面噪声带来的干扰。帧率预算上实飞时经常出现“感知帧率够但整机响应跟不上”的情况。原因可能在链路别处图像采集线程丢帧、MAVLink消息在某个环节排队、飞控内部位置环和速度环周期不匹配。排查思路是从末端往前逐级看先看飞控有没有收到消息再看视觉模块发送频率是否稳定最后看采集到送检的延迟。用带时间戳的日志逐级定位比瞎猜高效得多。7.3 真机测试的场地与安全策略视觉算法的不确定性比普通飞控逻辑更大试飞时的安全策略需要做得更保守。我第一次做真机目标跟踪试验时选了一个周五下午的空旷足球场周围没有行人没有车备了两块满电电池和一个飞行围栏飞行高度控制在20米以下遥控器始终握在手里随时准备切回手动。试飞流程也有固定套路先做短距离定点悬停验证检测模块在真实环境下的稳定输出再做缓慢推杆测试验证检测结果不随姿态变化剧烈跳变最后才做全自动跟踪和避障验证。每跨一步都要看日志确认每个模块的反馈正常。这里也提醒一下无人机视觉相关的外场试验一定提前了解当地空域管理规定遵守飞行高度限制和禁飞区要求尽量不要在人群密集区域做自动飞行测试。视觉算法本身不危险但失控的无人机带着高速旋转的桨叶是有真实风险的宁可多花时间是走流程也不要冒着风险硬飞。最后分享一个我的习惯每次外场测试必带一块备用电池和一台手动控制端。算法在当前架次表现异常时第一时间切回手动接管先保证飞行安全再回来分析数据。视觉模块从来不是无人机的全部但当它在几十米高空、复杂光照下稳定输出那个目标框的时候你会觉得之前调模型、啃协议、熬夜标数据的那些日子都是值得的。
