做航拍人体检测的活儿最头疼的往往不是模型结构而是数据集本身。最近我把一套针对校园操场场景的航拍人体检测数据集完整整理了一遍用YOLO系列训练到部署验证跑通了一轮踩了不少坑也沉淀了不少值得记录的经验。这套东西解决的问题很具体俯视视角下行人目标小、密度高、相互遮挡严重这些恰恰是COCO、CrowdHuman这类通用人体数据集很难覆盖的。如果你正在做航拍视频的人流统计、操场跑操人数监测、体育课密度分析或者单纯缺一套能直接喂给YOLO训练的“场景专精”数据这篇内容应该能帮你省下好几周的弯路时间。1. 航拍校园操场人体检测为什么通用模型在这里会失灵1.1 平视数据训练的模型到了俯视视角表现断崖很多人一开始会想人体检测不是成熟任务吗YOLO在COCO上mAP都五十多了直接拿预训练权重推理不就行了。我第一次也是这么干的结果无人机升到80米往操场一拍模型表现直接“断崖”——大半个操场的人漏检偶尔框出来几个置信度也才0.3左右。问题不在YOLO而在训练数据和推理数据之间的分布差异。COCO里的人物标注绝大多数是平视或近俯视视角拍的行人占画面比例大、轮廓清晰、四肢可辨。而航拍校园操场是什么视角正俯视或者大角度俯视人从“直立形状”变成“头顶圆点加肩膀轮廓”身体各部分的比例关系和平视完全不一样。模型在COCO里学到的那些“人形特征”在俯视图上大多数对不上号。CrowdHuman这类密集人群数据集虽然行人很多但同样以街景平视为主直接迁移过来做航拍场景效果也一般。所以航拍人体检测的第一原则是场景换了数据就得跟着换。预训练权重可以要但只作为初始化必须在目标场景的数据上重新训练。目标域数据的质量直接决定最终模型的上限。1.2 操场场景的三座大山小目标、密集遮挡和纹理伪装把操场航拍图放大看你会立刻理解这个任务的难度在哪。我总结为三座大山做数据集的时候每一个都得针对性处理。第一是小目标。四公里分辨率的无人机相机飞到100米高度一个成年人也就占到二三十个像素。YOLO的下采样倍率是32倍输入640分辨率时特征图只有20x20小目标的特征经过几层下采样后几乎被“磨”没了。所以数据集中必须有意识地采集不同飞行高度、不同分辨率的样本训练时配合切图和 mosaic 增强否则模型对小目标基本是“睁眼瞎”。第二是密集遮挡。跑操、课间操、集体活动的时候几十上百号人挤在一起从头顶看下去就是一堆高度相似的“圆点”互相叠着。这里标注的时候最考验耐心——被遮挡的行人到底标不标我的经验是可见面积超过30%就标完全被挡住的不标遮挡严重时允许框与框之间有较大的IoU重叠不要为了“干净”强行去掉被遮目标否则模型学不会拥挤场景。第三是纹理伪装。操场的跑道线、篮球场边线、草坪上的白色标记在俯视图里和人的轮廓非常像。模型很容易把一段弧形白线当成几个人。这属于典型的背景误检解决思路是数据集中加入大量“无人物”的纯背景帧作为负样本这一点很多自制数据集都会忽略后面章节我专门展开讲。2. 数据采集与标注把原始航拍素材变成YOLO能吃的格式2.1 飞行高度、相机参数和拍摄时段怎么选数据采集这事看着简单实际决定模型上限。拍得不行后面标注训练全是白费功夫。分享一下我的采集配置基于常见实践总结供参考。飞行平台我用的是大疆御系列相机4K 30帧。高度方面我测试过30米、60米、80米、100米四档最终建议主采集高度放在60到80米之间。这个高度下单个人大约占30到50像素既保留了可标注的细节又接近实际部署时的俯视尺度。只拍一个高度会导致模型尺度适配单一所以建议每次飞行至少覆盖两个高度段。拍摄时段我推荐上午9到11点和下午3到5点这两个时段太阳高度角合适人影比较短不会拉出长阴影干扰标注。正午顶光虽然人影最短但对比度过强浅色衣服和白色跑道容易过曝糊成一片傍晚长阴影会把人和影子连在一起标注时极容易把影子框进去。还有个关键参数是云台角度。人体检测不要纯90度正俯视稍微带15到25度的倾斜角效果反而好。原因很简单完全正俯视时人的特征只剩头顶和肩膀倾斜视角能保留一些侧面的身体轮廓模型区分人和其他物体的难度低很多。我在数据集中按大约7:2:1的比例混合了三种云台角度70度为主、45度辅助、90度少量训练出来的模型泛化性明显更好。2.2 标注规范与YOLO txt格式转换标注工具我试过LabelImg、X-AnyLabeling和Roboflow。LabelImg太老对4K大图操作卡顿明显Roboflow在线标注方便但数据要上传如果你项目数据敏感就别用综合下来我推荐X-AnyLabeling开源、支持交互式分割辅助标注、大图缩放流畅通过SAM辅助能省掉不少体力活。标注规范方面我最想强调的一点是不要用“肉眼贴紧”的方式画框。俯视视角下人的边缘很模糊标得太紧会导致框内只包含头顶那一小圈训练时正样本特征太少。我建议标注框比目标外轮廓往外扩2到3个像素让框内包含一些背景纹理作为上下文信息实测AP能提升一到两个点。对于遮挡目标仍然按可见部分画框不要试图脑补被挡住的完整身体。标注完导出的是Pascal VOC的XML格式YOLO训练需要的是txt格式格式是每行一个目标类别ID 中心点x归一化 中心点y归一化 框宽归一化 框高归一化。转换脚本很简单我贴一个通用版本import os import xml.etree.ElementTree as ET def xml_to_yolo(xml_path, out_dir, classes): tree ET.parse(xml_path) root tree.getroot() img_w int(root.find(size).find(width).text) img_h int(root.find(size).find(height).text) lines [] for obj in root.iter(object): name obj.find(name).text if name not in classes: continue cls_id classes.index(name) box obj.find(bndbox) x1, y1 int(box.find(xmin).text), int(box.find(ymin).text) x2, y2 int(box.find(xmax).text), int(box.find(ymax).text) x_center (x1 x2) / 2 / img_w y_center (y1 y2) / 2 / img_h w (x2 - x1) / img_w h (y2 - y1) / img_h lines.append(f{cls_id} {x_center:.6f} {y_center:.6f} {w:.6f} {h:.6f}) out_path os.path.join(out_dir, os.path.splitext(os.path.basename(xml_path))[0] .txt) with open(out_path, w) as f: f.write(\n.join(lines))一个细节如果你的数据集是做“人群计数”而不是“单人体检测”类别就只设一个person但如果你想顺带做行人跟踪或者区分“跑动/静止”建议额外加类别比如student_moving和student_standing。这会让标注工作量明显增加所以项目初期先想清楚下游任务。2.3 标注质量检查那10%的错误框比漏标更致命标注完成不等于数据能用。我自查过上千张图发现问题集中在三类一是小目标漏标一张图里几十上百人时眼睛看花漏掉几个很正常二是框位偏移俯视图里头顶区域颜色和跑道接近标注时AI辅助预测的框会吸到纹理边缘三是误将阴影、球、锥桶标成人。我的检查方法是“可视化和统计双管齐下”。可视化方面把标注框直接画在图上过一遍重点看小目标区域统计方面计算所有标注框的宽高比分布和人脸面积分布——如果出现大量宽高比接近1:1的超小框或者面积小于15x15像素的框异常多大概率是标注跑偏了。另外如果你用的是X-AnyLabeling的SAM辅助一定要警惕AI自动生成的边界框它有时会把两个人合并框成一个有时框在两个人的“中间区域”。我的原则是标注完成后专门抽10%的图片二次复核宁可多花两天也不要拿脏数据去污染模型。3. 训练前的数据准备增强、切图和数据集划分3.1 适合航拍小目标的增强组合数据增强不是越多越好得针对场景选。YOLOv8内置的增强管线里Mosaic和MixUp对航拍小目标帮助最大。Mosaic把四张图拼成一张相当于变相增大了batch内的目标数量也破坏了大目标在画面中的稳定出现防止模型只记住“大目标长什么样”。MixUp则是对两张图做透明度混合对密集人群场景有不错的正则化效果。但有两个增强在航拍场景里要慎用。一个是大幅度的随机旋转YOLO的标注框是轴对齐矩形旋转45度以上会导致框的面积膨胀尤其是旋转90度时宽高互换如果数据管线没处理好等于给模型喂错误标注。另一个是RandomPerspective的大尺度透视变换航拍图本身的透视变化来自无人机高度和云台角度训练时再乱拉透视图反而破坏场景一致性。我的推荐配置是Mosaic开启、MixUp开0.5概率、HSV色域增强开重点加饱和度扰动因为操场草地和跑道的颜色在不同光照下差异很大、随机翻转只做水平翻转垂直翻转后人的形状在俯视图里虽然对称但操场纹理不对称容易学歪、关闭大角度旋转。这组配置跑下来mAP50比默认配置高出3个点左右。3.2 切图策略直接缩放还是滑窗切片航拍4K原图直接缩到640x640训练分辨率损失太严重原图里30像素的“小人”缩放后只剩不到10像素等于把小目标全部毁掉。我测试过两种方案第一种是滑窗切片。把4K图切成若干1024x1024或1280x1280的块每块之间留50%重叠然后训练时把1280再缩到640。这种方式能保留更多目标细节但产出的样本数量膨胀训练时间增加而且需要处理“目标跨越切片边界”的问题——我采用的办法是目标中心落在哪个切片内就归哪个切片被切断的部分靠相邻切片重叠兜住。第二种是Tiling-SAE那种两阶段思路先用全局图检测密集区域再对密集区域局部放大检测。这个更复杂适合做推理端优化训练阶段没必要搞这么重。训练阶段我推荐折中方案主训练用1280输入YOLOv8支持加少量Mosaic增强部署阶段再切图推理。1280输入对小目标的提升非常明显代价是训练显存占用翻倍如果你的卡是24G以下建议batch降到4到6。如果显存实在不够就用640输入加滑窗切片两者最终效果差距在5%以内但1280方案省事很多。3.3 数据集划分怎么做才不“漏题”很多人划分训练集验证集就是随机split这在航拍数据上是个大坑。无人机拍摄同一块操场连续帧之间高度相关如果同一段视频的帧被同时分到训练集和验证集验证集相当于“开卷考试”mAP虚高得离谱一到换场地实测就露馅。我的划分原则是按“飞行架次”分不按“图片”分。每次飞行的素材是一个独立单元要么全部进训练集要么全部进验证集。这样验证集看到的是模型完全没见过的光照条件、拍摄角度和人群分布指标可信度高很多。我最终按大约8:1:1的比例分训练、验证、测试其中测试集来自完全不同的两个拍摄时段和场地专门用来模拟真实部署场景。另外提醒一句航拍视频帧之间冗余极大10分钟视频抽帧2000张相邻帧差异很小。我按每秒抽1帧的频率从视频里抽关键帧避免连续帧堆积造成的数据冗余。抽帧之后再人工筛一遍去掉过于模糊、无人机转弯时剧烈运动模糊、画面被遮挡的帧。4. YOLO训练实战超参、损失函数与踩坑记录4.1 模型选型YOLOv8s还是更轻的nano版本航拍人体检测这种任务目标小、数量多模型容量不能太小。我对比过YOLOv8n、YOLOv8s和YOLOv8m三档。nano在640输入下参数量小、推理快但对30像素级别的小目标召回率明显不足验证集mAP50在0.78左右s版本能到0.87m和s差距只有1个点但推理速度慢了近一倍。最终我选了YOLOv8s理由是“性价比”精度够用速度也不拖后腿。YOLO系列版本迭代很快社区里流传的各种新结构图从v8到v11甚至更新的变体核心组件其实大同小异——CSP结构加Anchor-Free检测头加多尺度输出。实战中不用过分追新关键是稳定复现和部署方便。如果你是在Jetson这类边缘设备上跑可以考虑nano加TensorRT精度损失用切图策略找回来服务器部署就s起步。有个容易被忽略的点是预训练权重。YOLOv8s的COCO预训练权重里已经学到过“人”的通用特征虽然俯视场景分布不同但底层的纹理、边缘特征仍然有效。我训练时加载预训练权重冻结前10层只训练后面检测头先跑30个epoch再解冻全部层微调20个epoch收敛速度和最终精度都比从头训练好不少。4.2 训练参数、损失函数怎么看懂YOLOv8训练日志里那几项损失值很多人只看个热闹。我建议至少弄清三件事box_loss是边界框回归损失用的CIoU加DFLDistribution Focal Losscls_loss是分类损失用的是BCEdfl_loss是DFL的辅助损失负责让框的分布预测更锐利。训练过程中box_loss持续下降说明定位学得稳cls_loss震荡是正常的重点看它的大趋势有没有下降。我用的关键超参如下epochs100、batch8、imgsz1280、optimizerSGD、lr00.01、lrf0.01、warmup_epochs3。优化器选SGD而不是Adam原因是YOLOv8在目标检测任务上SGD加余弦退火的收敛稳定性和泛化性通常优于Adam尤其在小数据集上不易过拟合。学习率我踩过一次坑——默认0.01在1280输入加小batch的组合下偏大loss在epoch 10附近开始震荡后来降到0.005才稳下来。小数据集上学习率宁小勿大。评估指标重点看两个mAP50和mAP50-95。航拍人体检测场景里mAP50比mAP50-95更重要——因为部署时我们关心的是“有没有检出来”而不是“框和真值框重叠得多精确”。实测中我的模型mAP50到了0.87mAP50-95只有0.52这个差距在小目标任务里很正常不用焦虑。4.3 训练翻车现场BN崩溃与标签混乱训练过程中最容易遇到的诡异问题就是BN崩溃。表现是loss突然变成NaN或者某几轮mAP降成0然后永远回不来。原因通常是batch size太小小于8加学习率太大导致BatchNorm层的running mean和running variance被极端值污染。我的解决套路是先降学习率到原来的1/10再把batch调大到8以上。如果BN已经崩了不能接着训练得删掉weights重来因为BN统计量已经脏了。另一个我在自制数据集上遇到的坑是标签文件出错。YOLO的txt标签要求坐标归一化到0到1之间一旦某张图的标注框超出边界比如切图时边界框没裁干净坐标会大于1或小于0训练时轻则警告重则直接报错。我在跑训练前写了个脚本统一检查标签坐标值必须在0到1之间、宽高必须为正、类别ID必须在配置范围内。这个检查脚本强烈建议每个人都写上能节省大量排错时间。还有一个经常被忽略的细节类别ID从0开始和数据集配置里的names列表顺序必须一一对应。如果names是[person]所有标签的第一列只能是0写成1就变成了空类别。这类错误概率不高但一旦发生排查起来非常费时。5. 部署实测TensorRT加速与操场现场效果5.1 导出ONNX再转TensorRT的完整流程模型训练完直接用PyTorch推理在真实项目里基本不可行我习惯转成TensorRT。流程是YOLO权重导出ONNX再用trtexec转TensorRT engine。关键命令记录一下。导出ONNX时要注意opset版本不能太高TensorRT对过新的opset支持可能滞后。我用opset11Python的ONNX导出脚本如下from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) model.export(formatonnx, opset11, dynamicFalse)然后转TensorRTFP16精度能提升吞吐同时把精度损失控制在可接受范围trtexec --onnxbest.onnx --saveEnginebest_fp16.engine --fp16 --workspace2048转换时--workspace要大于模型实际需要的显存不然会报错--fp16开启半精度。个人实测FP16下mAP基本不掉速度提升明显。如果是边缘设备还可以开INT8量化但需要校准数据集我一般只在FP16不够用的时候才上INT8。5.2 T4上能扛多少路1080p25帧一个实用估算热词里有个问题挺多人问T4上用TensorRT跑YOLO 640分辨率检测1080p 25帧的视频流能撑多少路我基于实测给你算笔账。单卡T4在FP16、batch size为1时YOLOv8s 640x640单帧推理实测大约3到4毫秒单路25帧每秒意味着每40毫秒要处理一帧串行跑单路绰绰有余但多路并发时GPU会出现空转和排队。能不能并发TensorRT支持多路stream批处理把多路视频帧拼成一个batch推理吞吐会显著提高。实测batch size为4时T4单帧耗时约5到6毫秒等效单帧1.25到1.5毫秒此时单卡每秒能处理200帧以上。按25帧每秒一路算纯推理端可以支撑8到10路。注意这没算视频解码、缩放、归一化这些前后处理开销——如果这些也在GPU上做路数再打七折如果解码用CPU、预处理跑异步就接近纯推理的水平。所以我的结论是T4单卡稳妥起见按8路设计把输入分辨率压到640、开启FP16、用batch推理预留30%算力余量应对画面复杂度波动。如果你要做更多路优先上L4或者Orin这类新卡T4的算力天花板在那里不是调参能突破的。5.3 外场误检漏检的处理手段部署到真实操场上单靠YOLO裸模型通常不能直接用外场环境比训练集复杂太多。我最常遇到的误检来源有三个操场白色标线、观众席座椅纹理、球场和树影的边界。解决手段按优先级排列第一给模型加负样本。把没有人的纯操场图、只有标线和座椅的图、阴影强烈的图标注成空图片加进训练集这是治本的方法。第二部署时提高置信度阈值从0.25提到0.45能过滤掉大量低置信度误检代价是漏检略微增加。第三加一个ROI区域过滤只在预先划定的操场范围内部做检测外部检测结果直接丢弃——这个做法在固定机位的操场监测场景里极其有效相当于告诉模型“你不用管操场外面的世界”。漏检问题则集中在密集跑操场景。一堆穿相同校服的学生挤在一起模型容易把几个人合并成一个人。我的处理是推理时把输入切成左右两半分别检测再合并结果——因为跑操队列通常是横向排开的切成两半后每半边的人群密度降低检测效果立刻改善。另外配合ByteTrack做跨帧跟踪把单帧漏检通过前后帧关联补回来实际漏检率能再降3到5个百分点。最后说一个很容易被忽略的参数输入分辨率部署时不一定要固定640。我用TensorRT搭了动态shape在系统空闲时用960或1280输入推理高峰期切回640这样可以在精度和速度之间动态平衡。实测1280输入在密集场景的召回率高10%如果你的GPU算力有余量值得一试。做完整套流程我自己最大的感受是航拍场景的数据集设计才是决定项目成败的环节模型结构反而是次要因素。同样一个YOLOv8s用随便收集的数据训练和用经过严格采集、标注、划分的数据训练mAP能差出15个点。所以如果你想复现这个项目我建议先把30%的精力放在想清楚“我到底要检测什么场景、什么尺度、什么密度”再把50%的精力投到数据采集和标注质量上剩下20%给训练和部署这个配比基本不会亏。