简介面向YOLO系列旋翼无人机目标检测任务的专用数据集包适合计算机视觉方向的研究者、算法工程师及无人机巡检相关项目开发者使用。第一部分包含5000多张已标注图像标注格式同时提供VOC和YOLO两种可直接用于YOLOv5、YOLOv8等主流模型的训练与验证免去自行标注与格式转换的额外工作。整个压缩包约672.99MB共19264个文件主要由6421张jpg图像、6421个xml标注文件、6422个txt标注文件构成清晰对应图像、VOC格式标注及YOLO格式标注三部分目录组织规整便于按需取用。由于数据总量较大作者将整体划分为两部分发布本部分为part1已在CSDN平台累计获得1154人次浏览学习适合需要扩充旋翼无人机检测样本、快速开展模型迭代实验的读者。下载即可获得一套可复用的高质量标注数据能够显著减少数据准备时间提升目标检测模型在无人机场景下的训练效率。1. 先厘清一个认知YOLO系列算法旋翼无人机目标检测难的不是网络是“尺度”反无人机、低空安防、无人机巡检路径跟踪这些场景都在等同一个能力在一路1080p视频流里把远处那个只有十几个像素的旋翼无人机认出来而不是把飞鸟、塑料袋、云影一起报进来。YOLO系列算法旋翼无人机目标检测这个方向网络本身已经很成熟了真正难的是“运动小目标”这件事——旋翼无人机速度快、尺寸小、背景乱常规检测参数直接套上去十有八九在实拍里翻车。这篇笔记就围绕一件事展开拿到一份像 drone-part1.zip 这样的无人机检测数据集怎么从格式整理、模型选型、训练调参一路做到部署实测中间哪些参数是决定成败的哪些坑是必须绕开的。适合正在做低空目标识别、无人机反制或者航拍任务的检测工程师也适合刚入门 YOLO、想用真实数据集跑通全流程的新手。2. 选型与数据构成为什么旋翼无人机检测要用 YOLOdrone-part1.zip 里到底是什么2.1 旋翼无人机检测的三个硬约束小目标、高机动、强穿透旋翼无人机和普通行人、车辆检测最大的区别在于它几乎没有“大尺度”出现的时刻。悬停时它是个静止小点加速时它是运动模糊的残影贴近了拍又会因为旋翼转动出现局部形变。用 COCO 的阈值看大多数实战画面里无人机的像素尺寸落在 20×20 到 60×60 之间属于典型的“小目标”区间。YOLO 系列针对小目标有天然的结构优势多层特征金字塔让浅层特征保留更多空间细节anchor-free 的回归方式让目标框不再受预设长宽比限制——旋翼无人机的俯视、侧视、斜视形状差异很大这点比依赖锚框的旧版检测器省心。第二个约束是高机动。多旋翼无人机可以瞬间改变航向帧间位移能达到几十个像素。这意味着检测器不能单纯依赖时序信息去“猜”每一帧都要有独立的检测能力。单阶段检测器在这方面比两阶段检测器更合适没有候选区域提取阶段端到端回归单帧延迟低适合把检测结果直接送给跟踪模块做航迹关联。第三个约束是背景穿透天空、建筑外墙、树林、水面各种纹理都可能与无人机纹理相似尤其飞鸟和无人机在远距离上几乎是同一个轮廓。这不是换个网络结构能解决的问题而是数据集分布的问题——训练集里必须覆盖足够多的近远距离样本、不同天光背景和姿态角这也是 drone 这类专项数据集比通用 COCO 数据集更有效的原因。2.2 YOLO 系列怎么选从 YOLOv8 到 YOLOv11 的档位逻辑先回答一个高频问题做旋翼无人机检测到底选 YOLOv5、YOLOv8 还是 YOLOv11我的选型逻辑不看版本号新旧只看两件事部署环境的算力预算以及标注格式的兼容成本。目前 ultralytics 库已经把 YOLOv8 之后的主线统一了YOLOv8 和 YOLOv11 共享同一套训练流程、同一套数据组织方式和同一种权重文件格式换版本的迁移成本极低。档位模型规模适用场景无人机检测表现倾向n最小速度快边缘盒子、实时视频流近距离大目标尚可远距离小目标容易漏s轻量Jetson、嵌入式设备平衡之选配合切图策略可用m中等服务器、GPU 工作站小目标召回率明显提升训练资源可控l / x大模型离线分析、高精度任务精度上限最高但速度和大图推理都是压力对旋翼无人机这类移动小目标我一般建议从 s 或 m 起步而不是一上来就上 x。原因很直接m 档的参数量约是 s 档的三倍小目标检测精度提升明显但推理时间也会从个位数毫秒涨到十几毫秒而 x 档想用好的前提是推理分辨率足够高否则参数量再大小目标的特征已经在下采样中丢了属于白烧显存。等模型结构验证通过、确认数据集没问题再考虑大模型做精度上限测试。2.3 先拆 drone-part1.zip认清标注格式再决定预处理方案很多人在拿到数据集的第一步就翻车不看标注格式直接套用通用脚本结果训练出一批置信度全为 0 的废模型。drone-part1.zip 这类数据集zip 名字里的 “part1” 说明它可能只是整个数据集的第一卷后续可能还有 part2、part3。拿到压缩包后第一件事不是写训练代码而是解压、列目录、打开一张标注文件看结构。unzip drone-part1.zip find . -maxdepth 3 -type f | head -50解压后重点看两件事图片后缀是 jpg 还是 png标注文件是 xml、txt 还是 json。如果是 Pascal VOC 格式标注文件是 XML里面每个object节点有name和bndbox四个坐标值如果是 YOLO 格式标注是 txt每一行是“类别ID 中心x 中心y 宽度 高度”坐标都是 0 到 1 的归一化浮点数。这两种格式的预处理逻辑完全不同所以先花五分钟跑一遍find命令比后面返工两小时值得多。我的经验是无人机检测数据集因为来源多样常用格式恰恰是 VOC XML——很多是用 LabelImg 标注的所以后面章节会重点讲 XML 转 YOLO 的脚本逻辑。3. 把 drone 数据集整理成 YOLO 能吃的结构目录布局与格式转换3.1 先定标准目录images/labels train/val避免后面返工ultralytics 的训练脚本对数据集目录结构有约定写法正确做法是根目录下放 images 和 labels 两个文件夹各自再分 train 和 val 两个子集。这个结构定下来之后所有后续的转换、划分、训练脚本都可以按同一个路径前缀去拼字符串省去改配置的麻烦。dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yaml注意主目录名不要包含中文和空格YOLO 内部读取路径时会把空格当成路径分隔符解析导致“找不到图片”这种幽灵报错。我习惯把数据集根目录放在和训练脚本同级的一个datasets/目录下这样 data.yaml 里可以用相对路径后续迁移到别的机器也不会因为绝对路径失效而重新配一遍。还有一个小建议不要直接把标注文件覆盖回源目录而是先复制到一个raw_annotations备份目录转换过程中出了问题还有后悔药用。3.2 VOC 标注转 YOLO 格式一个不依赖第三方库的转换脚本如果解压后看到的是 Pascal VOC 的 XML下面这个脚本可以直接用。它只依赖 Python 标准库在一个新环境里不需要安装任何额外依赖也能跑。转换的核心逻辑是解析每个 XML 文件取出每个目标的类别名和边界框坐标把左上右下坐标转换成归一化的中心点坐标和宽高再写入同名 txt 文件。import os import xml.etree.ElementTree as ET def convert_annotation(xml_path, output_dir, class_names): tree ET.parse(xml_path) root tree.getroot() filename root.findtext(filename).strip() size root.find(size) width int(size.findtext(width)) height int(size.findtext(height)) # 同名标注文件.xml 换 .txt txt_name os.path.splitext(os.path.basename(xml_path))[0] .txt txt_path os.path.join(output_dir, txt_name) lines [] for obj in root.iter(object): name obj.findtext(name).strip() if name not in class_names: continue # 过滤不需要的类别 cls_id class_names.index(name) bndbox obj.find(bndbox) x1, y1 float(bndbox.findtext(xmin)), float(bndbox.findtext(ymin)) x2, y2 float(bndbox.findtext(xmax)), float(bndbox.findtext(ymax)) # 转为归一化中心点 宽高 cx (x1 x2) / 2.0 / width cy (y1 y2) / 2.0 / height w (x2 - x1) / width h (y2 - y1) / height lines.append(f{cls_id} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}) with open(txt_path, w) as f: f.write(\n.join(lines)) # 示例调用转换 raw/xml 目录里所有 xml 到 labels/train xml_dir raw_annotations label_dir datasets/drone/labels/train os.makedirs(label_dir, exist_okTrue) class_names [drone] # 按数据集实际类别写 for xml_file in os.listdir(xml_dir): if xml_file.endswith(.xml): convert_annotation(os.path.join(xml_dir, xml_file), label_dir, class_names)这个脚本有几个关键点在部分开源代码里被一带而过其实最容易翻车的地方是坐标归一化。我见过不少转换脚本直接用图片左上角的绝对坐标除以原图宽高这个逻辑本身没错但如果 XML 里的size节点和实际图片分辨率对不上生成的所有框都会偏移。所以脚本里写的是从 XML 读取宽高而不是从图片文件读保证坐标系数和标注时使用的基准一致。另外class_names.index(name)这个写法要求类别名严格一致如果 XML 里首字母大写、txt 里小写找到的结果会是ValueError跑之前先打印一份类别清单确认。3.3 数据集划分与类别校验先跑通再放大转换完成之后要把图片和对应的 txt 按比例切分为 train 和 val。这里有一个常见的错误操作直接按文件名前缀去分类图片结果某个前缀下图片和标签数量不一致训练时 YOLO 标注文件缺失会静默跳过这一张图导致数据量莫名其妙缩水。稳妥的做法是先只处理“同时存在图片和标注”的样本把有效样本的列表作为数据源再做随机划分。import os import random import shutil random.seed(42) # 固定随机种子保证划分可复现 image_dir images label_dir labels val_ratio 0.2 image_files [f for f in os.listdir(image_dir) if f.endswith(.jpg)] valid [] for img in image_files: label os.path.splitext(img)[0] .txt if os.path.exists(os.path.join(label_dir, label)): valid.append(img) random.shuffle(valid) val_count int(len(valid) * val_ratio) for split, files in [(val, valid[:val_count]), (train, valid[val_count:])]: os.makedirs(fimages/{split}, exist_okTrue) os.makedirs(flabels/{split}, exist_okTrue) for img in files: shutil.copy(f{image_dir}/{img}, fimages/{split}/{img}) label os.path.splitext(img)[0] .txt shutil.copy(f{label_dir}/{label}, flabels/{split}/{label}) print(ftrain: {len(valid) - val_count}, val: {val_count})random.seed(42)这行值得单独说不固定种子每次跑出来的训练/验证划分都不同模型效果差一点倒是其次最麻烦的是你在 A 机器上调好的训练配置跑到 B 机器上验证集不同指标对不上问题无从查起。无人机数据集规模通常不大如果总量只有小几千张我建议 val 占比给到 20% 而不是更小因为旋翼无人机姿态和背景的多样性高验证集太小会导致 mAP 浮动剧烈单次验证结果没有参考价值。另外复制而不是移动文件是为了保留原始图片目录后面做可视化对比或者补充训练时不必重新解压。3.4 训练前必须做的可视化检查转换完成之后直接训练是一个危险动作。格式对不代表坐标正确坐标正确不代表框贴合目标。训练前花五分钟把标注画回图上用肉眼确认框的位置、大小、类别是否合理。这一步能拦下大部分数据问题避免训练几个小时后才发现 loss 不收敛是因为标签本身就是错的。from PIL import Image, ImageDraw def show_labels(image_path, label_path, class_names(drone,)): img Image.open(image_path) draw ImageDraw.Draw(img) with open(label_path) as f: for line in f: parts line.strip().split() cls, cx, cy, w, h int(parts[0]), float(parts[1]), float(parts[2]), float(parts[3]), float(parts[4]) W, H img.size x1 (cx - w / 2) * W y1 (cy - h / 2) * H x2 (cx w / 2) * W y2 (cy h / 2) * H draw.rectangle([x1, y1, x2, y2], outlinered, width3) draw.text((x1, y1 - 10), class_names[cls], fillred) img.show()检查时重点看三类样本离得远的、背景杂乱的、无人机处于画面边角的。前两类考验箱子回归精度最后一类能看出标注人员的手滑习惯。如果发现框整体偏左或偏上基本可以断定是转换时没有做归一化回到上一个脚本查width、height的取值如果发现某些样本的框明显比目标大了一圈说明原始标注就是粗标框这种数据留在训练集里会影响回归精度考虑删除而不是保留——它们会在训练时持续干扰损失收敛而且占比不大时删除对样本多样性影响很小。4. 用 Ultralytics 跑通训练环境配置、data.yaml 和参数设置4.1 环境配置与版本坑0基础也能跟着装训练环节我以 ultralytics 库为主它对新手友好命令行统一也方便导出 onnx 和 TensorRT。安装前先建独立环境避免和机器上已有的 PyTorch 版本互相污染。这里有一个很现实的坑ultralytics库版本之间的 API 有小幅变动有些文章写的参数在新版本里已经改名安装时尽量装更新的版本但不要频繁升级。conda create -n drone python3.10 -y conda activate drone pip install ultralytics torch torchvision装完之后跑一句yolo predict modelyolo11n.pt sourcebus.jpg能输出检测结果图就说明环境通了。单独提一句如果机器上没有 GPU也可以 CPU 训练小型模型但无人机检测数据集即使只有几千张图片CPU 训练也要按天计算现实项目里基本都会准备一张 NVIDIA 显卡device0指定第一张卡。显存 8G 以下时优先考虑 s 档模型加混合精度训练而不是换更小的 n 档——n 档的小目标召回率在无人机场景下降太快省出来的显存不划算。4.2 data.yaml 的写法nc、names、path 三件事data.yaml 是训练脚本和数据集之间的契约写在根目录下即可。它的内容很短但每个字段都直接影响训练行为写错了不会报错只会静默训练出废模型。path: ./datasets/drone train: images/train val: images/val nc: 1 names: 0: drone注意nc和names的数量必须一致这是最常见的低级错误。有的人用通用 COCO 数据集预训练权重注释掉了原来 80 类的 names但没有改 nc训练时类别数对不上loss 直接变成 NaN。如果你是单类检测names下的类别名可以自己定但要和转换脚本里的class_names顺序保持一致。还有一个隐藏细节path字段建议用相对路径train 和 val 也保持相对路径写法。这样换机器、换目录时只需要在同一个上级目录下运行命令不需要改 yaml 内容。4.3 训练命令与关键参数imgsz、epochs、batch 怎么定环境就绪后训练命令长这样yolo detect train \ modelyolo11s.pt \ datadata.yaml \ epochs100 \ imgsz640 \ batch16 \ device0 \ patience20 \ ampTrue把参数拆开说modelyolo11s.pt指定起始权重。填预训练权重文件时YOLO 会用 COCO 预训练的参数初始化网络迁移学习对小数据集尤其重要。无人机检测数据集的规模一般不足以从零训练使用预训练权重几乎是必选项。epochs100不是越多越好。数据量小的时候模型在 30 到 50 个 epoch 附近就可能过拟合后面只是记住了训练集的特例验证集的 mAP 反而不涨。imgsz640训练分辨率。这是影响小目标检测最直接的参数。如果显存允许我通常会在无人机数据集上尝试 736 或 832目标在特征图上占据的区域越大浅层特征保留的信息就越多。batch16受显存约束。8G 显存跑 s 档 640 分辨率16 是安全值想加大 batch先确认ampTrue开着。patience20早停参数验证集指标连续 20 个 epoch 无提升就自动停止省时间也防过拟合。ampTrue混合精度训练。显存不够时的第一道保险默认开启老显卡如果训练不稳定再关掉。一个小技巧:对于无人机这类“小目标占比高”的数据集ultralytics 默认开启的 mosaic 增强对小目标不太友好——四张图拼在一起目标被缩小到原始尺寸的一半左右本来就已经小到极限的无人机直接变成 8×8 像素等于把标签糊掉了。发现训练中 mAP 起伏剧烈时把增强相关的参数单独调弱或改用不带 mosaic 的增强策略只靠旋转、缩放、色彩扰动来撑样本多样性。4.4 训练时盯住三个损失box_loss、cls_loss、dfl_loss训练过程中终端会打印一长串指标很多人只盯着 P、R 和 mAP50其实损失的曲线更有诊断价值。YOLO 的损失由三部分组成理解它们各自的含义才能快速判断模型到底在哪个环节出了问题。box_loss边界框回归损失衡量预测框和真实框的位置偏差。无人机是刚体框的形状相对规整如果 box_loss 起起伏伏不下降大概率是数据里存在大量错标框或者学习率设置过高导致梯度震荡。cls_loss分类损失衡量类别预测的对错。单类检测时 cls_loss 不会太高一旦它异常高回头检查标签文件里是否有残留的多余类别名——我遇到过某个 XML 里混入drone和drone末尾带空格导致类别数变成 2。dfl_loss分布焦点损失针对边框坐标的质量分布。它震荡属于正常现象但如果 dfl_loss 长时间不降说明目标框和预测框之间始终存在系统性偏差比如边框的宽高比分布超过了训练数据覆盖的范围。4.5 训练输出的解读weights、results.csv、混淆矩阵、训练图训练结束后输出目录下有weights/文件夹、results.csv、confusion_matrix.png和一批验证集推理图。weights里有两个权重文件last.pt是最后一个 epoch 的权重best.pt是验证集 mAP 最高的权重。绝大多数场景直接用best.pt别纠结 last 和 best 哪个“更有潜力”检测任务没有续训的强制需求直接取指标最好的就行。results.csv是最值得看的文件里面按 epoch 记录了三类损失、精确率、召回率、mAP50 和 mAP50-95。看这张表时有一个习惯不要只看最后一个 epoch 的数字而是观察 mAP50-95 的曲线在全程的变化。如果 mAP50 高但 mAP50-95 低说明检测框和真实框的重合度不够精细——模型把目标认出来了但框得不够准这在后续做跟踪融合时会很吃亏因为跟踪器依赖的是稳定的框中心点。训练结束时再看confusion_matrix.png单类检测关注的是“背景被误判为无人机”的比例如果这块比例超过 10%说明背景误检严重需要补充负样本或调整置信度阈值。5. 无人机检测训练的避坑记录现象、原因、解法5.1 标签错位类别ID从1开始训练直接崩现象训练启动后 loss 为 NaN或者训练能跑但所有检测结果都是同一个类别置信度极高框却出现在画面的固定位置。原因转换脚本里cls_id从 1 开始编号而 YOLO 要求类别 ID 必须从 0 开始。data.yaml 里names索引是 0 对应第一个类如果 txt 文件里写的是 1YOLO 会把它当成第 2 个类处理而nc1的模型根本没有第 2 个类损失函数直接崩掉。解决重写转换脚本令cls_id class_names.index(name)这个函数天然从 0 返回索引。转换后写一个小脚本遍历所有 txt输出所有出现过的类别 ID 集合确认只包含0。在 data.yaml 的names列表和 txt 文件之间做一次对账这是投入产出比最高的一次检查。5.2 转换后的框整体偏移没做归一化或使用了错误的宽高现象训练前可视化检查时发现框的位置和目标物体有系统性偏移——比如框的左上角贴着目标左上角但框整体向右下方偏了半个身位。原因转换脚本中cx、cy计算用的是绝对像素坐标没有除以width、height。另一种常见情况是除以了图片文件的实际尺寸但 XML 里的size节点记录的是标注时的尺寸两者不一致——比如标注软件自动缩小了预览图。解决严格以 XML 的size节点为归一化基准不要在脚本里用 PIL 读图片宽高。如果两种尺寸不一致以 XML 为准因为标注人员画框时看到的画面就是那个分辨率。改完脚本后重新生成标注再次可视化抽查直到框和目标完全贴合。5.3 远距离小型无人机漏检640 分辨率不够考虑切图策略现象训练完的模型在近距离大目标上效果不错验证集 mAP50 能到 90% 以上但放到真实低空安防场景距离 50 米外的小无人机基本漏检。原因旋翼无人机在 1080p 画面里远距离时尺寸常小于 20×20 像素。经过 YOLO 的 8 倍下采样目标在特征图上只剩 2 到 3 个像素点浅层特征仍然不够勾勒轮廓检测器无法同时满足“看得远”和“认得清”。解决最常见的做法是切图推理。把原图按滑动窗口切成 640×640 的块每个块独立送入模型再对重叠区域的检测框做 NMS 合并。由于目标在切块中占比被放大小目标检出率会有明显提升。训练阶段也可以做同样的切图预处理让模型提前适应目标被放大的分布。另一个辅助手段是提升推理分辨率到 960 或 1280对 GPU 压力也同步上升显存不够时优先考虑切图而不是硬拉分辨率。5.4 loss 不降反升从学习率与数据分布查起现象训练前几个 epoch loss 快速下降20 个 epoch 后 loss 开始反弹验证集 mAP 也随之下降。原因最常见的是学习率过高加上数据量不足导致的过拟合震荡。无人机检测数据往往是从不同来源收集的部分来源的图像风格差异极大模型先拟合了样本量大的来源再被迫调整适配小样本来源损失曲线就会出现周期性反弹。解决把初始学习率调低ultralytics 训练时可以通过lr0参数指定默认 0.01 对大型数据集合理对小数据集建议改为 0.005 甚至 0.001。同时配合更高的patience早停阈值让模型在验证指标开始下跌时立刻停止不要等 50 个 epoch 之后损失彻底爆炸。还有一种数据层面的解法检查验证集和训练集的来源分布尽量确保两者分布一致如果验证集里恰好集中了某种极端姿态的样本mAP 波动会特别明显。5.5 显存不够amp、batch、模型档位三连招现象设置 batch32 甚至 64 后训练命令启动即报 OOM显示 CUDA out of memory。原因小目标检测往往伴随着高分辨率输入显存消耗与分辨率平方成正比640 提到 960相同 batch 下显存需求直接翻倍。解决一套固定的处理顺序。先确定ampTrue已开启再把 batch 降到 16 或 8仍不够就换 s 档模型。注意 batch 过小会导致 BatchNorm 统计不稳定batch 降到 4 以下时建议改用 n 档模型而不是继续压 batch。如果机器是共享显存或有人同时训练可以用nvidia-smi先排查占用曾经的踩坑经验是其他进程的显存碎片占用了预留空间换一张空闲卡立竿见影。6. 落地前的最后一步验证指标、实测视频与 TensorRT 部署6.1 用 map50-95 和 PR 曲线判断模型真实水平训练结束不等于项目结束。评估模型能不能用不要只看验证集的 mAP50这个指标在单一类别检测里太容易虚高——背景干净时哪怕框偏移四分之一IoU 也能过 0.5。真正的衡量标准是 mAP50-95它计算从 IoU0.5 到 0.95 十个阈值的平均精度对框的精确度要求严苛得多。无人机检测如果 mAP50-95 能到 60% 以上框的质量已经足够支持后续的跟踪算法如果只有 30% 左右说明位置回归还有明显偏差。同时把val_batch*.jpg里的预测框翻出来看视觉确认模型能否在逆光、低对比度、远距离这三种场景下稳定输出框。6.2 用 best.pt 实测视频确认“能不能用”验证集指标达标后用真实视频做端到端测试。命令很简单yolo detect predict modelruns/detect/train/weights/best.pt sourcetest_video.mp4 conf0.35conf0.35是置信度阈值这个值直接影响误检率和召回率的平衡。安防场景宁可多一些误报也不希望漏检阈值可以降到 0.25无人机反制场景相反误报会导致反制设备无效动作阈值提到 0.5 更合适。拖几个不同时段、不同背景的测试视频进去重点看目标从远到近的过程——如果远端频繁闪烁检测框时有时无说明模型对极小目标不够稳健需要回到数据层面补样本或做切图。6.3 TensorRT 导出与实时路数估算如果项目要求实时处理一路或几路视频流下一步就是把权重导出为 TensorRT 引擎格式。这一步能有效压缩推理耗时让 s 档模型在消费级显卡上跑到几毫秒一帧。导出命令如下yolo export modelbest.pt formatengine device0 imgsz640 halfTrue导出后的.engine文件通过predict modelxxx.engine调用即可。有人会问“T4 上用 TensorRT 跑 YOLO 640 分辨率支持多少路 1080p 25 帧视频”这类问题必须实测因为同一模型在不同输入分辨率、不同 confidence 阈值下的延迟差异很大。只给一个经验性结论单路视频推理耗时在 5 到 15 毫秒的话理论上可以支持多路并行但这个估算没有算入预处理、后处理和跟踪模块的消耗实际部署时必须写一个压力测试脚本逐路递增验证。我的习惯是先跑两路加一路观察显存和帧率变化再逐步往上加直到帧率跌到目标值以下再回调一路。预处理也是常被忽视的瓶颈BGR 转 RGB、resize、归一化都在 CPU 侧完成路数多了 CPU 先成为瓶颈。一个建议是直接把预处理挂到 GPU 上做降低成本另一个建议是减小视频帧流向检测器的分辨率安防场景中 1080p 原图可以先缩放检测小目标再用 ROI 放大检测一次这个两级策略比粗暴拉高输入尺寸高效得多。我现在跑无人机检测项目固定套路是先跑通最小数据集、确认标注和流程无误再上全量数据和调参。这个习惯帮我避免过多次“训了十个小时才发现标签错了一半”的窘境。做检测这行模型选型永远不是最难的部分数据质量才是决定天花板的那只手希望这篇笔记能帮你在无人机目标检测的落地路上少走几段弯路祝顺利。本文还有配套的精品资源点击获取