带学生做无人机目标识别课题那年我踩过最大的一个坑是把“目标检测”当成一个算法问题来解决。后来才明白Module 16真正要解决的问题不是让模型在图片里画出框而是让一架飞在天上的无人机实时看见目标、确认目标、跟上目标。这篇就把我在这个模块里摸出来的完整思路整理出来从算法选型、数据集、仿真部署到真机踩坑一次性说清楚。如果你是刚接触目标检测的无人机爱好者或者已经跑通了YOLO但不知道下一步怎么上机这篇文章应该能帮你少走不少弯路。先讲清楚一个事实检测算法只是链条上的一环真正的难点在“检测结果怎么变成飞行行为”。1. “自动找到目标”背后是三个完全不同的技术栈在打架1.1 Module 16要解决的真实问题“让无人机自动找到目标”这句话拆开来至少包含三件事感知、决策和控制。感知负责从图像或雷达数据里算出“目标在哪儿”决策负责判断“我该飞过去还是停在原地还是绕过障碍”控制负责把决策变成电机的转速变化。很多人只盯着感知这一层模型在电脑上跑通了就觉得任务完成。但真到了无人机上图像数据要经过摄像头曝光、传输、预处理、模型推理、坐标解算再打包成MAVLink消息发给飞控飞控内部还要串级PID一节一节地响应。任何一个环节卡住目标都“找不到”。这个模块的训练思路应该一开始就建立完整闭环无人机飞到一个高度机载摄像头看到画面检测算法输出目标框程序算出目标相对机身的位置再生成飞行指令飞机调整姿态飞向目标。这中间只要有一个环节用的坐标系不一致结果就会偏得离谱。1.2 无人机上的目标检测和普通图像检测差在哪我在很多地方讲过把桌面端的检测模型直接搬到无人机上就像让一个在平地上开车多年的司机直接去跑拉力赛路况完全不是一回事。下面这几个差异直接影响算法选型和部署方式。维度普通图像检测无人机目标检测视角摄像头平视目标占比大俯视/斜视目标小且密集目标尺度通常几十到几百像素几个像素到几十像素很常见运动状态图像静态为主图像本身持续运动目标也在动算力约束服务器可以堆显卡机载设备受电池和重量限制光照条件相对可控强光、阴影、水面反光随时变化实时要求秒级可以接受必须10Hz以上才有实用价值尤其是“目标小”这一点几乎贯穿了整个模块。同样是检测一辆车车在100米外的路边照片里可能占200像素在300米高的无人机俯视画面里只有20像素甚至更少。模型能不能在小目标上保持稳定往往比在标准评测集上的mAP更重要。2. 算法选型先判断目标类型再谈YOLO还是Transformer2.1 常规可见光目标为什么要先跑通YOLO流程大多数无人机视觉感知入门项目第一次接触的都是YOLO。这个选择没有错。YOLO把目标检测当成单次回归问题输入一张图经过骨干网络提取特征再经过特征金字塔融合多尺度信息最后输出边界框、类别和置信度。整个流程可以简写成输入缩放 → 归一化 → Backbone提取特征 → Neck融合多尺度特征 → Head输出类别和框 → NMS去除重复框。在无人机场景里YOLO的优势不只是速度更重要的是它天然支持多尺度目标。因为航拍画面里同一个目标在不同高度下尺度差异极大YOLO的FPN/PAN结构能同时保留深层语义信息和浅层细节信息小目标不至于完全丢失。我自己常用的组合是YOLOv8n或者YOLOv5s配合TensorRT导出FP16模型在Jetson Orin Nano上能做到30到60FPS这个帧率对大多数跟踪场景都够用。Transformer类检测器比如DETR、RT-DETR也不是不能用它们对全局上下文的理解更好适合目标被遮挡或者背景杂乱的情况。但这类模型结构更重端侧部署成本高机载算力有限时优先考虑YOLO路线。判断标准很简单先看目标尺寸再看目标周围环境复杂度。2.2 红外小目标、低空小目标、点云3D目标怎么选可见光并不是唯一选择。夜间巡检、森林搜救、电力设施测温这类任务里红外成像反而是主流。但红外目标检测有个经典难题目标小、对比度低、没有清晰的纹理信息直接套YOLO很容易出现大量漏检和虚警。红外小目标检测领域有两条路线。一条是传统空域-频域协同处理通过形态学滤波、背景抑制、局部对比度分析把目标从复杂背景里抠出来另一条是训练专门的小目标检测网络通常会在输入层做patch分解或者在特征层加注意力机制让模型更关注局部高亮区域。评估这类系统光看mAP不够还要看信杂比增益、背景抑制因子和虚警率因为很多指标会被“容易检测的大目标”拉高掩盖小目标上的真实能力。如果传感器换成了激光雷达问题又变成三维目标检测。点云数据可以用PointPillars、VoxelNet这类网络处理输出目标的3D包围框、朝向和速度。无人机在树林里做避障、在复杂地形里找可着陆点时3D检测比2D图像检测可靠得多因为它直接给出距离信息不需要再靠单目几何去猜深度。2.3 我的选型判断逻辑会按四个问题来过滤每次接到类似需求我不会一上来就翻论文而是先问四个问题目标是什么传感器下可见的可见光、红外、毫米波雷达还是激光雷达目标在画面里通常占多大是几十像素的“大块头”还是几个像素的“小点”机载算力是什么级别能不能跑深度学习模型还是只能跑轻量传统算法从检测到执行允许多少延迟是发现后慢慢接近还是必须立刻避让根据这四问选型会自然收敛。比如目标是空地背景下的车辆就是YOLOv8n加ByteTrack目标是远距离红外小火点就先做背景抑制再加轻量分类目标是用来避障的树木和电线杆那么深度相机或毫米波雷达的3D信息比2D框更有用。3. 数据集无人机视角下公共数据集往往不够用3.1 公开航拍数据集与实拍场景之间的代沟很多人训练无人机检测模型第一反应是下载VisDrone、UAVDT这类公开无人机数据集。它们确实能帮你把模型跑起来但实机部署时往往要重新面对数据集和真实场景之间的代沟。问题出在视角、高度和天气三个地方。公开数据集里很多画面来自固定翼或者高空气球视角、高度和你手里这台四旋翼的巡航高度不一定匹配。目标大小分布也可能偏离。你把模型训练好拉到真实场地一飞发现画面里的车辆因为高度更高、尺度更小模型基本上认不出来。更麻烦的是天气和光照。公开数据集以晴天白天为主真机巡检会遇到逆光、薄雾、树影遮挡、水面反光。模型在训练集上没见过这些变化部署后置信度会疯狂波动。所以我现在的习惯是公开数据集只用来做预训练最后一定要用目标场景的自采数据微调。3.2 自采数据的一条可行路径自采数据听起来工作量很大实际上有捷径。先把无人机飞到目标任务会使用的典型高度沿规划好的航线录制视频再把视频按间隔抽帧。我一般会做三层抽帧悬停时连续抽、巡航时每秒抽1到2帧、转弯时多抽几帧。标注的时候航拍影像里的目标往往很小很多标注工具默认的框大小都不合适。我建议用多边形标注而不是普通矩形框因为俯视视角下车辆和树木的边缘不规则矩形框会把大量背景包进去训练出的模型会学到错误特征。还有一个很实用的技巧把数据集按距离分层。5米内、20米内、50米外的目标分开统计训练时保证每个距离层都有足够样本。这样模型才不会只在某个高度好用换个高度就失效。3.3 数据增强小目标最怕“增过头”常规目标检测里随机旋转、翻转、裁剪、颜色抖动都是标配。但在无人机航拍小目标场景里增强策略不能照搬。比如随机旋转90度在普通图片里问题不大在航拍画面里会打乱目标的朝向分布。无人机从上往下看车辆朝向和道路方向是有物理约束的你硬把一辆车旋转成倒着开模型被迫学习不可能的样本反而变差。还有大范围的颜色抖动会把红外图像的对比度关系破坏导致模型过度关注颜色而不是形状。对小目标我更推荐的做法是Mosaic增强和Copy-Paste。Mosaic把四张图拼在一起相当于变相提高了目标数量Copy-Paste把目标从一个位置搬到另一个位置可以人为制造更多目标密集的情况。另外把输入分辨率从640提到800或960对小目标的改善非常明显代价只是算力和帧率这个取舍值得在实机上测。4. 从仿真到实机整条链路怎么打通4.1 先在UbuntuPX4仿真环境里把闭环跑通我不建议任何人第一次做视觉无人机就直接上真机调试。最稳的路线是把整个闭环在Ubuntu加PX4的仿真环境里先跑通。具体做法是在Ubuntu里装好PX4-Autopilot配合Gazebo仿真环境运行SITLSoftware In The Loop仿真再通过MAVLink协议和机载计算机上的感知程序通信。仿真环境里你可以给无人机加载机载摄像头模型摄像头画面实时输出给目标检测程序。检测程序把结果转换成飞行指令通过MAVLink的OFFBOARD模式发送给仿真飞控。Gazebo里能模拟不同天气、不同地形还能自由设置目标位置。我最喜欢用它来验证坐标转换逻辑因为真机一旦飞起来任何坐标方向的错误都会表现为无人机疯狂乱飞而在仿真里最多是飞机撞到虚拟地面。需要提醒的是仿真环境里摄像头没有真实的光学畸变和曝光变化模型在仿真里表现好只能证明“逻辑通”不代表“实机稳”。仿真的价值是把整个软件链路的bug提前暴露掉而不是替代真机测试。4.2 机载算力选型和模型导出目标检测跑在哪个设备上直接决定模型大小和推理方式。目前主流选择是NVIDIA Jetson系列Orin Nano、Orin NX用得最多。它们功耗低、算力够能跑TensorRT加速。如果你手里的飞控是STM32配合FreeRTOS那不建议直接在STM32上跑深度学习目标检测它更适合做底层姿态解算和控制感知任务应该交给独立的机载计算机。模型导出这一步我踩过不少次坑。PyTorch训练好的权重不能直接用要先转换成ONNX再通过TensorRT生成engine文件。转换过程中最容易出问题的是自定义算子不兼容所以训练初期就应该避免在模型里加太多花哨的自定义模块。导出后一定要用TensorRT自带的性能测试工具看延迟而不是只看PyTorch里的FPS两者差距可能是一倍以上。4.3 从检测框到飞控指令坐标转换链路目标检测输出的只是图像上的一个矩形框但无人机要找到目标需要知道目标在真实空间里的位置。坐标转换是整个模块里最“劝退”但也最核心的一步。简单说检测框中心点得到像素坐标p通过相机内参矩阵K反推归一化坐标再结合云台和机身的安装角度把目标从相机坐标系转到机体坐标系最后经过姿态旋转转到地面坐标系。公式不复杂核心是弄清楚每个矩阵的先后顺序。我最常看到的问题是欧拉角顺序搞错导致机体在俯仰时目标位置解算出现系统性偏移。实操中如果只需要跟踪不一定非要解算精确的地理坐标。很多项目直接在图像平面上算像素偏差再生成机体的期望角速度指令让云台或飞机把目标“拉”到画面中心。这种方式简单、响应快非常适合目标跟踪落地。真正需要地理坐标的场景通常是规划航线或者投放任务那才需要完整的世界系转换。4.4 串级PID和目标跟踪检测频率与飞控频率的配合检测频率和飞控控制频率不是同一个量级。飞控内部的姿态内环通常跑到200到400赫兹速度外环在50到100赫兹而视觉检测往往只有10到30赫兹。这不是说检测慢而是模型推理、图像采集和预处理都需要时间。串级PID的内外环分工要清楚外环控制位置或速度输出是期望姿态角或角速度内环控制角速度输出是电机油门差值。视觉检测结果进不了内环它只能作为外环的参考输入。如果把目标检测直接接到内环飞控会被低帧率的检测信号带得乱抖。通常我会在检测输出后加一个目标状态估计器比如卡尔曼滤波或者简单的一阶低通把10Hz的检测框平滑成50Hz以上的连续目标位置估计再送进外环控制器。5. 上了真机之后延伸出的系统问题5.1 避障不是“检测到障碍就刹停”目标检测模块一旦跑通很多人马上会想加避障。但我得提醒一句避障不是检测到障碍物就刹车。无人机在空中急停本身就是一种危险操作可能导致姿态失控而且单纯的“检测到障碍就停”在障碍物密集区域会让无人机寸步难行。更合理的设计是把避障放进路径规划层。检测模块输出障碍物的3D位置后本地路径规划算法会生成一条绕行轨迹无人机沿着新轨迹继续飞。只有当绕过不了一定要走另一条路线时才考虑悬停等待。在视觉避障之外毫米波雷达或激光雷达可以提供更可靠的距离信息尤其在光线不足的树丛里纯视觉避障几乎等于瞎飞。5.2 巡检场景里最气人的是小目标漏检电力巡检、桥梁检测、森林搜救这类场景真正要发现的目标往往在画面里只占几个像素。一段几百米长的电线上的一个绝缘子损坏点摄像头稍微远一点就完全看不见。这不能只靠换更大的模型解决因为模型更大推理速度更慢无人机已经飞过去了检测结果才出来根本没有意义。我常用的处理思路是“粗检加细看”。无人机先在一根较高航线上用轻量模型做大范围筛查发现可疑区域后自动降低高度飞近目标再用更精细的模型确认。整个过程由任务规划系统控制目标检测只是其中的触发条件。巡检能不能命中往往取决于你愿不愿意让无人机为了确认一个可疑目标多飞一段路。5.3 编队飞行检测结果可以共享当从单机升级到无人机编队时目标检测的价值会进一步放大。单架无人机受视角和距离限制只能看到目标的局部信息编队里不同位置的无人机同时检测能获得不同角度的目标特征。编队飞行的技术难点首先是相对定位常见做法是RTK GPS或者视觉SLAM做相对位姿估计。有了稳定的相对位置关系之后僚机完全可以把检测结果通过数传链路共享给长机。长机融合多架飞机的目标框和置信度决策更可靠。换句话说检测不只是“眼睛”它还能变成整个编队的“共同视野”。6. 实测中最常踩的五个坑以及我现在的处理方式6.1 曝光突变让检测框满屏乱跳无人机从阴影飞到阳光下曝光会瞬间变化。画面亮度突变时模型的置信度会剧烈波动检测框会出现闪烁甚至整屏误检。我现在解决这个问题有两个办法一是锁定相机曝光参数不依赖自动曝光二是在图像进入模型前做一次归一化增强把亮度变化对模型的影响降到最低。不要小看这个处理曝光问题不解决后面所有算法都白搭。6.2 机载FPS达标延迟却仍然很要命有段时间我调试的目标检测模型在机载设备上能跑到40FPS但飞机实际响应很迟钝。一查才发现40FPS是模型推理的帧率但从摄像头采集到图像进入模型之间经过了很多排队环节整条pipeline的延迟已经达到两三百毫秒。检测“看起来快”和“真正快”是两回事。后来我把pipeline改成“只处理最新帧”的模式不缓存旧图像同时把预处理放到GPU上做延迟立刻降了下来。跑目标检测一定要测端到端延迟而不是只看模型推理的FPS。6.3 离线测试mAP高真机识别率不行训练时mAP高不代表实机好用。最常见的原因是训练数据太“干净”背景单一、目标清晰、光照均匀。到真机上背景变成草地、道路、屋顶混合目标被阴影和树冠遮挡模型自然崩溃。我的建议是训练初期就留出一部分真实飞行素材当验证集不参与训练专门用它来卡模型上线标准。数值上mAP再高也不如真实场景验证集上的表现有说服力。6.4 检测出来和锁得住是两件事目标检测输出的是一个独立的目标框但无人机要跟踪的是“同一个目标”的连续状态。如果每一帧都重新检测而不做目标关联检测框的身份会不停跳变目标稍微交叉一下就彻底跟丢。现在的主流做法是用ByteTrack这类多目标追踪算法把检测框关联成轨迹。追踪层看着简单实际对整个系统的稳定性影响非常大。我甚至建议先不调检测模型只用现成的检测结果加一个强一点的追踪器很多表面上的“检测问题”就会被解决。6.5 仿真环境给不了你的真实干扰有一说一仿真能帮你验证算法逻辑但它模拟不了真实的震动、风扰、电磁干扰和复杂光影。实机调试时机载相机因为电机震动导致的画面模糊、高空气流引起的高度波动都会让检测效果和仿真里完全不同。所以正确的路径是仿真里把大问题清掉真机上小步快跑一次只改一个变量。我现在的习惯是实机第一次飞行只做数据采集不跑任何闭环控制。把真实画面录下来回放给检测模型看先判断算法在真实光照下的表现。这一步过了再加一个简单的目标指示功能最后才做完整的自动跟踪闭环。每一步都验证过再往下一步走虽然慢但胜在可控。这个模块做到最后你会发现真正难的不是某一项技术而是把检测、跟踪、控制、避障、路径规划这些听起来毫不相关的模块拼成一个能在天上稳定工作的系统。拿出耐心一点点来飞机不会辜负你。