1. 飞机起落架检测数据集的项目背景与核心价值1.1 为什么起落架检测是个值得单独做数据集的方向飞机起落架这个目标乍一看好像只是飞机的一个部件但真正做过航空器视觉检测的人都知道它跟“检测一整架飞机”完全是两码事。整机检测里飞机在画面中往往占据较大像素面积轮廓清晰、背景相对干净模型很容易学到“大块金属机翼形状”这种粗粒度特征。但起落架不一样它的目标尺度小、结构细碎、遮挡频繁而且在不同拍摄角度下形态差异极大——正面看是几根支柱加轮组侧面看是收放机构的剪影仰视又变成一堆液压杆和舱门的组合。我最初接触这个方向是因为一个机场地面保障的课题。当时想用通用目标检测模型直接识别起落架区域结果发现公开数据集里几乎没有专门标注起落架的。COCO里飞机是一个大类起落架被淹没在整机框里ImageNet的检测子集也没有细到部件级别。于是只能自己从零构建这个过程踩了不少坑也积累了一些经验。这个1144张、单类别、VOCYOLO双格式的数据集就是在这个背景下整理出来的。它的核心价值在于把“起落架”作为一个独立目标类别固定下来让模型专门去学这个部件的视觉特征而不是被整机的大轮廓带偏。对于做机场地面监控、飞机维修辅助检查、滑行道异物排查这类场景的人来说一个干净的起落架检测数据集比一个庞大的整机数据集更实用。1.2 数据集的基本规格与适用人群这个数据集的规格很明确1144张图像1个类别起落架同时提供VOC格式和YOLO格式的标注文件。VOC格式是XML结构每个目标用bndbox记录左上角和右下角坐标YOLO格式是TXT文本每行是类别索引 中心x 中心y 宽 高坐标都归一化到0到1之间。两种格式覆盖了绝大多数主流检测框架的输入需求Pascal VOC系的框架直接读XMLYOLO系和大部分现代检测器读TXT。适合谁来用我梳理了一下大概三类人最需要做航空地面视觉检测的算法工程师需要快速验证起落架检测的可行性不想从零标注。高校里做目标检测课程设计或毕业设计的学生需要一个真实场景、单类别、规模适中的数据集来跑通训练流程。做机场智能监控产品原型的团队需要一个小规模但标注质量可控的数据集来做POC验证。1144张这个量级说大不大说小也不小。对于单类别检测任务来说如果标注质量过关、场景多样性够训练一个可用的基线模型是足够的。但如果你指望它直接产出工业级精度的模型那需要在此基础上做增量标注和hard negative mining。1.3 VOC与YOLO双格式并存的现实意义很多人会问为什么不在VOC和YOLO之间选一个非要两个都提供这个问题我在实际项目里被问过很多次。答案其实很直接不同框架对标注格式的偏好不同而且转换过程中容易出问题。VOC格式的XML文件可读性强包含图像尺寸、目标类别、遮挡程度、截断标志等元信息适合做数据分析和可视化。YOLO格式的TXT文件简洁直接对应训练时的标签加载逻辑省去了框架内部的解析开销。但如果你只有VOC格式想用YOLOv8训练就得写转换脚本如果你只有YOLO格式想用MMDetection里的某些VOC系配置又得反向转换。更关键的是转换过程中坐标归一化、类别索引映射、图像尺寸读取这些环节稍不注意就会引入静默错误。比如VOC的坐标是绝对像素值YOLO是归一化值如果转换时用错了图像宽高标注框就会整体偏移。我见过有人直接把VOC的xmin除以图像宽度却忘了YOLO的中心点坐标需要先算(xminxmax)/2再归一化结果训练出来的模型框全部偏左。所以这个数据集直接提供双格式省去了使用者自己转换的麻烦也降低了出错概率。2. 数据集构建过程中的关键决策与技术细节2.1 图像采集与筛选的取舍逻辑构建这个数据集时图像来源主要有几个渠道公开的航空摄影图片、机场地面监控视频抽帧、以及部分飞行模拟器渲染图。这里有一个很重要的取舍真实监控画面和模拟器渲染图要不要混在一起我的做法是混合但控制比例。真实监控画面占大约七成模拟器渲染图占三成。原因在于真实画面里的光照变化、运动模糊、压缩噪声是模拟器很难完全复现的这些恰恰是模型在实际部署时最常遇到的干扰。但模拟器图可以提供一些真实场景中难以采集的角度比如极端仰视、近距离特写、夜间红外模拟等对提升模型的视角泛化能力有帮助。筛选阶段我定了几个硬性标准分辨率下限短边不低于480像素。起落架目标本身就不大如果原图分辨率太低标注框可能只有几十个像素训练时经过下采样后特征几乎消失。目标可见性起落架被遮挡面积超过70%的图直接剔除。这种样本标注出来也是噪声模型学不到有效特征。场景重复度控制同一架飞机、同一角度、连续帧的图片最多保留3张。否则数据集会被少数场景主导模型过拟合到特定机型和涂装。这里有个经验连续视频抽帧时如果间隔太小相邻帧几乎一样标注工作量翻倍但信息增量几乎为零。我一般按每秒1到2帧抽再人工筛掉重复度高的。2.2 标注规范与边界框的确定原则标注这件事说起来简单做起来全是细节。起落架的边界框到底怎么画是只框轮子还是把支柱和舱门都包进去我的标注规范是以起落架主体结构的外接矩形为准包含支柱、轮组和收放机构可见部分但不包含机腹和机翼的延伸区域。这个规范的依据是模型需要学的是“起落架这个部件”的整体特征如果只框轮子那模型学到的就是“圆形物体”容易和地面车辆轮子混淆如果框得太大把机腹也包进来那模型又会退化成整机检测。实际操作中有几个边界情况需要统一当起落架部分被机身遮挡时边界框只覆盖可见部分不脑补被遮挡的区域。当多个起落架如前起落架和主起落架同时出现在画面中且距离较近时分别独立标注不合并成一个大框。当起落架在画面边缘被截断时如果可见面积不足30%不标注超过30%则按可见部分标注并在VOC的truncated标签里标记为1。这些规则看起来琐碎但如果不提前定好不同标注人员画出来的框风格不一致模型训练时就会困惑。我试过用不同标注风格的数据混在一起训练结果模型的框回归损失震荡得很厉害收敛速度明显变慢。2.3 VOC与YOLO格式转换中的参数计算虽然数据集直接提供了双格式但理解转换过程对排查问题很有帮助。这里把关键计算拆开说。VOC的XML里一个目标框记录为bndbox xmin320/xmin ymin180/ymin xmax460/xmax ymax310/ymax /bndbox假设图像宽度为1920高度为1080。转换成YOLO格式时中心点x (320 460) / 2 390中心点y (180 310) / 2 245宽度 460 - 320 140高度 310 - 180 130归一化后x_center 390 / 1920 ≈ 0.2031y_center 245 / 1080 ≈ 0.2269width 140 / 1920 ≈ 0.0729height 130 / 1080 ≈ 0.1204最终YOLO行0 0.2031 0.2269 0.0729 0.1204注意YOLO格式的类别索引从0开始如果只有一个类别索引就是0。有些转换脚本会写成1导致训练时类别数对不上报“label index out of range”的错。还有一个容易忽略的点VOC的坐标是1-based还是0-basedPascal VOC官方标注是1-based但很多工具读出来直接当0-based用。如果转换时差1个像素对检测精度影响微乎其微但如果图像尺寸读取错误比如把宽度和高度搞反那标注框就会完全错位。我建议转换后随机抽10张图做可视化用OpenCV把框画出来看一眼比任何检查脚本都直观。3. 基于该数据集的YOLO训练实操流程3.1 环境准备与数据目录组织训练之前先把目录结构理清楚。YOLO系框架对目录组织有约定俗成的规范我一般这样安排landing_gear_dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ └── data.yaml图像和标签文件名必须一一对应比如images/train/001.jpg对应labels/train/001.txt。如果标签缺失训练时框架会报错或者跳过但不同框架行为不一致最好提前检查。data.yaml的内容path: /path/to/landing_gear_dataset train: images/train val: images/val test: images/test nc: 1 names: [landing_gear]划分比例我一般按7:2:1分train/val/test。1144张的话train约800张val约230张test约114张。如果数据量更小可以适当增大val比例但test集建议至少保留100张否则评估结果的置信区间太宽没有参考意义。环境方面YOLOv8需要Python 3.8以上PyTorch 1.8以上。如果用的是较新的YOLOv8或YOLOv10建议直接装ultralytics包pip install ultralyticsGPU方面起落架检测这个任务单类别、1144张图用一张8GB显存的卡就够。batch size可以设16输入尺寸640训练100到150个epoch。如果显存更小把batch降到8同时把学习率按比例调小。3.2 训练参数的选择与调整依据YOLO的默认参数对大多数任务都能跑但起落架检测有几个特殊性需要针对性调整。输入尺寸默认640。起落架目标在原图中占比不大如果缩放到640后目标小于32像素检测效果会明显下降。我试过用1280输入mAP能提升3到5个点但训练时间翻倍。折中方案是用640训练推理时用1280测试或者直接用960训练。学习率默认0.01对单类别任务偏大容易在初期震荡。我一般从0.001开始配合余弦退火。如果发现loss前几个epoch就爆了检查一下标注有没有越界坐标超过1或者小于0。数据增强起落架检测对旋转和尺度变化比较敏感建议开启degrees10、scale0.5、translate0.1。但mosaic增强要慎用因为mosaic会把四张图拼在一起起落架目标可能被切到边缘导致标注框不完整。我一般在前80%的epoch开mosaic后20%关掉让模型在接近真实分布的图像上微调。锚框如果用YOLOv5系需要根据数据集重新聚类锚框。起落架的长宽比分布比较集中大部分在1:1到2:1之间。用k-means跑一下标注框的宽高把结果替换到配置文件里比默认锚框的召回率高。3.3 训练过程监控与关键指标解读训练启动后重点盯几个指标box_loss框回归损失。正常应该在前10个epoch快速下降然后缓慢收敛。如果一直震荡不降检查标注框是否有大量越界或宽高为0的情况。cls_loss分类损失。单类别任务这个值应该很快降到接近0。如果居高不下可能是类别索引映射错了。mAP0.5IoU阈值为0.5时的平均精度。起落架检测这个指标一般能到0.85以上算不错0.9以上算很好。mAP0.5:0.95更严格的指标对框的定位精度要求更高。这个值通常会比mAP0.5低10到20个点。我习惯每10个epoch存一次权重同时用验证集跑一次推理把预测框和真实框画在一起看。有时候指标看着不错但可视化一看模型把起落架旁边的液压管也框进去了这种“过检”在指标上体现不明显但实际部署时就是误报。实操心得训练到中期如果mAP卡住不涨先别急着调参。把验证集里mAP最低的10张图挑出来看看是标注问题还是模型确实学不会。我遇到过几次发现是某些图的起落架标注框画得太紧只框了轮子模型学出来的框也偏小跟其他图的标注风格不一致。统一标注风格后mAP直接涨了4个点。4. 常见问题排查与实战避坑指南4.1 标注格式相关的典型报错与修复问题一训练时报“Label class X is not in the dataset”这个通常是YOLO的TXT里类别索引超过了nc定义的范围。单类别任务TXT里只应该有0如果出现1、2就是转换时类别映射错了。检查VOC的XML里是不是混入了其他类别的标注或者转换脚本里类别名到索引的字典写错了。问题二图像和标签数量不匹配YOLO训练时如果某个图像没有对应的TXT框架会跳过或者报错。用这个命令快速检查for f in images/train/*.jpg; do labellabels/train/$(basename ${f%.jpg}).txt if [ ! -f $label ]; then echo Missing: $label fi done反过来如果有多余的TXT没有对应图像也要清理掉否则某些框架会报“image not found”。问题三VOC转YOLO后框全部偏移九成是图像尺寸读取错误。VOC的XML里size标签记录了width和height但有些标注工具写反了。转换时不要盲信XML里的尺寸用OpenCV实际读一下图像以实际尺寸为准。如果XML尺寸和实际尺寸不一致以实际尺寸做归一化。4.2 训练不收敛与过拟合的应对策略不收敛的常见原因学习率太大loss在初期就发散。把学习率降到0.0001试试。标注框有大量越界坐标小于0或大于1。YOLO对越界坐标的处理是截断但如果大量框被截断模型学到的就是错误的位置信息。数据增强太激进比如mosaic加旋转加剪切全开导致图像失真严重。先关掉所有增强用原始图训练确认能收敛后再逐步加。过拟合的判断与处理训练集mAP到0.95以上验证集mAP只有0.7左右就是典型过拟合。1144张图对单类别任务来说不算多过拟合风险确实存在。应对方法加数据增强特别是随机裁剪和色彩抖动。加权重衰减从默认的0.0005提到0.001。用预训练权重。YOLO在COCO上预训练的权重对起落架检测有迁移价值虽然COCO没有起落架类别但底层边缘和纹理特征是可复用的。如果还不行考虑冻结主干网络的前几层只训练检测头。4.3 推理部署时的性能优化技巧训练完的模型要部署到实际场景推理速度是个硬指标。起落架检测如果用在实时监控上至少要到15 FPS才能跟上视频流。优化手段模型剪枝YOLOv8n本身已经很小但如果用YOLOv8m或l可以考虑剪掉一些冗余通道。剪枝后mAP可能掉1到2个点但速度能提升30%以上。量化FP16量化对精度影响很小速度能提升近一倍。INT8量化需要校准集精度损失稍大但速度更快。输入尺寸调整如果实际场景中起落架目标较大可以把推理尺寸从640降到416速度提升明显mAP损失可控。批处理如果服务端推理把多帧图像拼成一个batchGPU利用率更高。但要注意延迟和吞吐的权衡。踩过的坑有一次把训练好的模型直接部署到边缘设备上发现推理速度只有3 FPS。排查后发现是模型输入尺寸设成了1280而边缘设备的NPU只支持到640。改成640后速度到18 FPSmAP只掉了2个点。所以部署前一定要确认目标硬件的输入尺寸限制。4.4 数据集扩展与持续迭代的建议1144张图训练一个基线模型够用但如果要提升到工业级精度需要持续迭代。我的建议是主动学习用当前模型在未标注的监控视频上跑推理把置信度在0.3到0.7之间的样本挑出来人工复核。这些是模型“拿不准”的样本标注后加入训练集对mAP的提升最明显。困难样本挖掘把验证集里漏检和误检的图单独整理分析是光照问题、遮挡问题还是尺度问题有针对性地补充类似场景的数据。类别细化如果后续需要区分前起落架和主起落架可以在现有标注基础上增加子类别但要注意类别不平衡问题。前起落架通常比主起落架小样本也更少。这个数据集后续还可以往多模态方向扩展比如加入红外图像或深度图做RGB-D的起落架检测。但那是另一个课题了先把单模态的基线做扎实更重要。5. 数据集使用中的合规与安全注意事项5.1 图像来源的合规性审查航空器相关的图像数据来源合规是第一条红线。公开渠道获取的图片要确认授权协议允许用于算法训练自己采集的监控画面要确保不涉及敏感区域和隐私信息。如果图像里包含可识别的机场标识、航班号、人员面部在入库前要做脱敏处理。我一般会在数据集里附一个SOURCE.md记录每批图像的来源、采集时间、授权方式。这不是形式主义而是当数据集被多人使用时能追溯每一张图的来龙去脉。如果后续有合规审查这个记录就是证据。5.2 标注过程中的质量控制标注质量直接决定模型上限。我的做法是双人标注交叉复核同一批图由两个人独立标注然后对比差异。差异超过5%的图由第三人仲裁。定期抽检每完成200张随机抽20张做可视化检查看框的位置和大小是否符合规范。版本管理标注文件用Git管理每次修改都有记录。如果发现某次修改引入了系统性错误可以快速回滚。一个容易被忽略的细节标注工具的显示缩放比例。如果标注时图像被缩小显示标注人员画的框在原始分辨率下可能偏小。我要求标注工具必须100%显示或者至少保证缩放比例一致。5.3 模型部署后的持续监控模型上线不是终点。起落架检测模型在实际运行中会遇到训练集里没有的场景极端天气、新型号飞机、临时遮挡物。需要建立监控机制记录每次推理的置信度分布如果大量样本置信度集中在0.5附近说明模型对当前场景不确定需要补充标注。定期回传误报和漏报的样本人工复核后加入训练集。如果机场引入了新机型起落架外观差异较大需要针对性补充该机型的样本。这个迭代过程是持续的没有一劳永逸的模型。但有了这个1144张的基础数据集后续的增量标注和迭代就有了起点不用每次从零开始。我个人在实际操作中的体会是数据集的质量比数量重要得多。1144张标注精准、场景多样的图训练出来的模型往往比3000张标注粗糙、场景单一的图效果更好。起落架检测这个任务难点不在模型结构而在数据本身。把标注规范定好、把场景覆盖全、把格式转换的细节抠清楚模型训练就是水到渠成的事。