简介：MineCarWithPeople-yolo-data数据集面向矿业自动化与计算机视觉开发者，聚焦轨道上矿车及人员检测任务，采用YOLO格式组织，适合用于训练和评估实时目标检测模型。压缩包共2000个文件，包含1045张jpg现场图像、954个txt标注文件以及1个yaml类别配置文件，整体体积约206.69MB，目录结构符合YOLO训练常规要求，可直接划分train/valid使用。数据集采集自实际矿业轨道环境，标注分为Normal与With People两个类别，对应矿车正常运行和有人干扰两种关键场景，类别数适中，便于模型集中学习两类目标的特征。目前已有118人浏览学习，适合需要开展矿车安全监测算法实验的研究人员、学生或工程开发者。借助这批数据，用户可快速完成数据准备、模型微调与效果验证，减少自行采集和标注成本，为矿区人员安全预警系统提供实用的训练基础。
1. MineCarWithPeople：矿井轨道运输场景下的人员与矿车检测数据集
做矿井视频分析的人，十有八九会卡在同一个地方：现场没有公开可用的数据。井下轨道运输场景里，昏暗光照、粉尘、矿车与人员交错出现，通用数据集（比如 COCO、VOC）训练的模型拿过去基本失灵。MineCarWithPeople 这个数据集，命名直白——矿山轨道场景下的矿车和人员检测，YOLO 格式已经整理好。它解决的核心问题不是"能不能检测人"，而是"在这种特定工业场景下，模型能不能稳定检测矿车和人员，并且能直接拿来训练 YOLO 系列模型"。适合要做矿井人员违章检测、机车防撞预警、井下巡检自动化的算法工程师和项目集成方。拿到这份 zip 后，你要做的不是直接训练，而是先做三件事：核对标注格式、统计类别分布、重新划分训练集。
2. 先把 zip 拆开：目录结构与 YOLO 标注格式解析
2.1 数据集目录的常规组织方式与命名规则
MineCarWithPeople 这类 YOLO 格式数据集，命名里已经带出关键信息：MineCar（矿车）+ WithPeople（含人员）+ yolo（标注格式）+ data（数据），这种命名习惯说明作者已经把数据从 VOC 或 COCO 转成了 YOLO 的 txt 标注格式。常见做法是 zip 里直接是一个根目录，根目录下面按images与labels分好，再往下按train/val或train/val/test划分。
我一般拿到 zip 后，第一件事不是解压完就训练，而是先记录目录树的原始结构。因为很多数据集作者自己划分过 train 和 val，但划分逻辑未必适合你的场景。比如有的按文件名前缀切分，导致同一段视频的相邻帧同时出现在训练集和验证集里——这就是典型的数据泄漏。先摸清结构，后面划分时才不会被原作者的划分带偏。
2.2 用 Python 核对 images 和 labels 文件是否一一对应
YOLO 格式的核心是：每张图片对应一个同名的 txt 文件，txt 里每行是「类别id、归一化中心x、归一化中心y、归一化宽、归一化高」。最常见的翻车点是图片和标注文件数量对不上，或者某个 txt 是空的。这里给一个直接能跑的核对脚本：
import os from pathlib import Path def check_dataset(root_dir): root = Path(root_dir) images_dir = root / 'images' labels_dir = root / 'labels' img_files = list(images_dir.rglob('*.jpg')) + list(images_dir.rglob('*.png')) lab_files = list(labels_dir.rglob('*.txt')) img_names = {f.stem for f in img_files} lab_names = {f.stem for f in lab_files} # 图片有标注缺失的 missing_labels = img_names - lab_names # 标注没有对应图片的（孤儿标注） orphan_labels = lab_names - img_names print(f'图片总数: {len(img_files)}') print(f'标注总数: {len(lab_files)}') print(f'缺标注的图片数: {len(missing_labels)}') print(f'孤儿标注数: {len(orphan_labels)}') # 检查每个标注文件的非空行数 empty_boxes = 0 for f in labels_dir.rglob('*.txt'): if f.stat().st_size == 0: empty_boxes += 1 print(f'空标注文件: {f}') return missing_labels, orphan_labels, empty_boxes if __name__ == '__main__': check_dataset('./MineCarWithPeople')这个脚本的核心逻辑是把images和labels两个目录的文件名（不含后缀）分别取集合，做差集就能立刻发现哪些图没有标注、哪些标注没有图。空标注文件也要单独统计，YOLO 训练时空 txt 会被视为背景图，如果背景图占比过高，模型会倾向于把所有目标都预测成背景。
2.3 标注坐标系与归一化规则：YOLO 格式的基本约束
YOLO 标注的四个数值有两个硬性约束：一是坐标必须归一化到 0~1 之间，二是宽高必须为正数。转换公式是x_center = (x_min + x_max) / 2 / img_width，y_center = (y_min + y_max) / 2 / img_height，w = (x_max - x_min) / img_width，h = (y_max - y_min) / img_height。如果原作者从 VOC 的 xml 转过来时忘了归一化，或者把x_min / img_width当成了中心点，坐标就全错了。
一条合理的验证方式是写一个「回读坐标」的小脚本：把 txt 里的归一化坐标乘回图片宽高，画框回图片上，人眼抽查 20 到 50 张。这个步骤虽然笨，但能发现两个自动检查发现不了的问题——框偏移半张图、框把整个矿车框了一半。坐标系的玄学在于：问题往往不是整体错，而是某个子目录的图片转换脚本用错了宽高基准。
import cv2 import random from pathlib import Path def visualize_labels(images_dir, labels_dir, sample_num=10): img_files = list(Path(images_dir).rglob('*.jpg')) samples = random.sample(img_files, min(sample_num, len(img_files))) colors = [(0, 0, 255), (0, 255, 0)] # class 0 红色, class 1 绿色 for img_path in samples: img = cv2.imread(str(img_path)) h, w = img.shape[:2] label_path = Path(labels_dir) / (img_path.stem + '.txt') if not label_path.exists(): continue with open(label_path, 'r') as f: for line in f.readlines(): parts = line.strip().split() if len(parts) < 5: continue cls_id = int(parts[0]) x_center = float(parts[1]) * w y_center = float(parts[2]) * h box_w = float(parts[3]) * w box_h = float(parts[4]) * h x1 = int(x_center - box_w / 2) y1 = int(y_center - box_h / 2) x2 = int(x_center + box_w / 2) y2 = int(y_center + box_h / 2) cv2.rectangle(img, (x1, y1), (x2, y2), colors[cls_id % 2], 2) cv2.imwrite(f'./check_{img_path.stem}.jpg', img) visualize_labels('./MineCarWithPeople/images', './MineCarWithPeople/labels')visualize_labels的核心价值是验证「数据从离散文件到可视化框」这一整条链路。如果图上框的位置明显偏移，大概率是标注坐标系出了问题；如果框比目标大一圈且偏在一侧，常见原因是标注时把矿车自带的遮罩或阴影也算进去了。抽样检查建议覆盖不同光照段——矿井数据里暗光图片最容易出问题，因为标注员在暗图上容易把矿车边缘勾歪。
3. 类别与标签体系：mining 场景下最容易忽视的类别不平衡
3.1 类别定义与常见标注习惯：person、mine_car 与背景
MineCarWithPeople 的类名从标题就能推断，至少包含「人」和「矿车」两类。但实际训练前必须打开data.yaml或classes.txt看一眼类别 id 的定义。YOLO 的类别 id 从 0 开始，txt 标注文件里的第一列数字必须严格对应 yaml 里类别列表的索引。很多数据集作者在 README 里写的是 person = 0, mine_car = 1，但实际代码里用了 person = 1，矿车 = 2，这种错位在训练时不报错，只在推理时表现为类别名完全对不上。
类别定义这件事还有个隐性坑：矿车在不同矿山长得不一样，有翻斗式、有梭式、有侧卸式。如果数据集里的矿车图片全部是同一型号，训练出来的模型放到另一个矿山就会识别率暴跌。处理办法是先看图片里矿车的形态多样性，如果图片量足够但形态单一，收集自己现场的数据做微调是绕不开的。
import yaml from collections import Counter from pathlib import Path def analyze_classes(labels_dir, yaml_path): # 读取 yaml 里的类别映射 with open(yaml_path, 'r') as f: cfg = yaml.safe_load(f) class_names = cfg['names'] # 例如 ['person', 'mine_car'] print(f'类别映射: {class_names}') cls_counter = Counter() total_boxes = 0 for label_file in Path(labels_dir).rglob('*.txt'): with open(label_file, 'r') as f: for line in f: if line.strip(): cls = int(line.strip().split()[0]) cls_counter[cls] += 1 total_boxes += 1 print(f'总标注框数: {total_boxes}') for cls_id in sorted(cls_counter.keys()): name = class_names[cls_id] if cls_id < len(class_names) else f'unknown_{cls_id}' ratio = cls_counter[cls_id] / total_boxes * 100 print(f'类别 {cls_id} ({name}): {cls_counter[cls_id]} 框, 占比 {ratio:.2f}%') analyze_classes('./MineCarWithPeople/labels', './MineCarWithPeople/data.yaml')这个统计脚本的结果直接决定要不要做类别均衡。如果 person 有 5000 框而 mine_car 只有 800 框，训练时模型会倾向于把矿车误检成人，或者对矿车的召回率极低。YOLO 的损失函数里类别损失是独立计算的，但样本量差距太大时，数据增强对少样本类别的作用非常有限——这属于数据层面的问题，不是调参能解决的。
3.2 类别不平衡的三个处理路径：过采样、复制粘贴、剔除冗余
面对类别不平衡，我一般按顺序尝试三种方案。第一种是简单的过采样：把少类别样本多的图片在训练列表里复制多份，让每个 epoch 里少类别图片出现的频率提高。第二种是复制粘贴增强：把图片里的矿车抠出来，粘贴到只有人的背景图上，生成新的标注。第三种是我在矿井项目里常用但容易被人忽略的——检查有没有大量「人坐在矿车里」的标注重叠，如果有，这种样本对模型是强干扰。
真实项目里还有一类特殊的类别不平衡值得注意：同一张图片里同时出现多个人和一辆矿车，与单张图片里只有一个人或只有一辆矿车，这两种样本的分布如果是偏的，模型学到的上下文关系会过于单一。验证方式是检查每张图片的标注框数量分布：
from collections import Counter def check_boxes_per_image(labels_dir): dist = Counter() for label_file in Path(labels_dir).rglob('*.txt'): with open(label_file, 'r') as f: cnt = sum(1 for line in f if line.strip()) dist[cnt] += 1 print('每张图片的框数分布:') for cnt, num in sorted(dist.items()): print(f' {cnt} 个框的图片: {num} 张')这个分布的价值在于发现数据集是否过度集中于「单人单矿车」这种简单场景。如果 80% 的图片都只有一两个目标，训练出来的模型在处理多人多车交错场景时会不稳定。矿山现场的真实难点恰恰是人车交错——矿车旁边站着两三个人，互相遮挡，这时检测框会剧烈抖动。数据分布偏简单，模型的上限就偏简单，这不是调 anchor 或调 IoU 阈值可以救回来的。
4. 数据划分与训练集构建：文件名的坑与数据集清洗
4.1 按时间序列或场景划分：避免数据泄漏的划分策略
许多工业数据集是从监控录像抽帧生成的，文件名里会带上时间戳或帧号，比如20240315_143210_000123.jpg。如果划分时直接按文件名 hash 切分，同一次录像里的相邻帧会同时出现在训练集和验证集里，验证指标虚高。部署到线上后，面对的是完全没见过的新时段录像，性能立刻打回原形。正确做法是按录像文件或时间区间来划分，保证同一段视频的帧只落在一个集合里。
假设原文件名带日期_时间_帧号结构，可以按日期作为粗粒度分组，整个日期目录只进训练集或验证集之一：
import random from pathlib import Path import shutil def split_by_date(images_dir, labels_dir, output_dir, val_days=2): # 按文件名前 8 位（日期）分组 day_to_imgs = {} for img_path in Path(images_dir).rglob('*.jpg'): # 假设文件名形如 20240315_143210_000123.jpg day = img_path.stem[:8] day_to_imgs.setdefault(day, []).append(img_path) all_days = sorted(day_to_imgs.keys()) random.seed(42) random.shuffle(all_days) val_days_set = set(all_days[:val_days]) for split, day_set in [('train', all_days[val_days:]), ('val', val_days_set)]: out_img_dir = Path(output_dir) / split / 'images' out_lab_dir = Path(output_dir) / split / 'labels' out_img_dir.mkdir(parents=True, exist_ok=True) out_lab_dir.mkdir(parents=True, exist_ok=True) for day in day_set: for img_path in day_to_imgs[day]: label_path = Path(labels_dir) / (img_path.stem + '.txt') if not label_path.exists(): continue shutil.copy2(img_path, out_img_dir / img_path.name) shutil.copy2(label_path, out_lab_dir / (img_path.stem + '.txt'))脚本核心是按日期前缀聚合图片，再把日期列表随机分到训练集和验证集。val_days=2表示拿两个日期的所有图片当验证集，而不是随机抽 20% 的图片。这样验证集里没有与训练集同一天拍摄的帧，指标更接近真实场景。
4.2 数据清洗：模糊帧、过度曝光帧与标注异常帧的处理
矿井数据清洗是纯体力活，但收益很大。常见需要剔除的帧有三类：运动模糊帧（矿车行进中抽帧经常出现拖影）、过度曝光帧（井下补光灯直射镜头时画面全白）、小目标密集帧（距离远导致人只有十几个像素的标注框，学习价值低但干扰大）。剔除方法有两种思路，一是人工扫一遍图片，二是用图像质量指标自动过滤。我一般先自动过滤，再人工抽检。
import cv2 import numpy as np from pathlib import Path def filter_blurry_images(images_dir, labels_dir, output_dir, blur_thresh=80): img_files = list(Path(images_dir).rglob('*.jpg')) removed = 0 for img_path in img_files: img = cv2.imread(str(img_path), cv2.IMREAD_GRAYSCALE) if img is None: continue # Laplacian 方差: 值越小越模糊 laplacian_var = cv2.Laplacian(img, cv2.CV_64F).var() if laplacian_var < blur_thresh: removed += 1 print(f'剔除模糊帧: {img_path.name} (方差={laplacian_var:.1f})') print(f'共剔除 {removed} 帧，剩余 {len(img_files) - removed} 帧')Laplacian 方差是检测模糊帧的经典方法，原理是计算图像二阶导数的响应，模糊图的边缘响应弱，方差自然小。阈值blur_thresh需要根据现场图片试探，井下暗光图片本身方差就偏低，一般我会先取 80 统计一批被剔除的图片，如果误杀太多就下调到 60 或 50。剔除后的数据集需要同步删掉对应的 txt 文件，否则图片少了但标注还在，训练时会报找不到图片的错误。
4.3 生成 data.yaml 并确认类别 id 与标注文件对应
YOLO 训练前需要一份data.yaml，里面指定train、val的路径和类别名列表。写这个文件有个细节：路径最好写绝对路径或相对 yaml 的路径，不能写相对当前工作目录的路径。很多人在这上面翻车，训练时报AssertionError: train: No such file or directory，原因就是路径写错。
# data.yaml 示例 train: ./MineCarWithPeople/train/images val: ./MineCarWithPeople/val/images nc: 2 names: ['person', 'mine_car']这里names的顺序就是标注 txt 里类别 id 的映射。如果原始数据集的classes.txt是[mine_car, person]，而这里写成['person', 'mine_car']，训练不会报错但推理时类别全反了。确认方法是随机抽几张图，把标注里的 id 打印出来，对照 yaml names 的顺序人工核对一遍。这一步花不了五分钟，但能省下后面所有调参时间。
5. 训练与验证中的避坑排查：mAP 上不去的原因和解决办法
5.1 现象：loss 降但 mAP 不动——标注质量与背景占比问题
训练到中期，loss 曲线稳定下降，但验证集的 mAP 一直卡在 0.3 左右。大多数人第一反应是调学习率或换模型，但矿井数据训练的排查顺序完全不同。先看标注质量——拉出几十张验证集图片，把预测框和标注框同时画出来，如果预测框总是比标注框大一圈或偏在一边，说明标注框本身不规范。这个数据集如果是从 VOC 手工转的，转换脚本对x_max - x_min的边界处理容易出问题。
其次是背景占比。如果图片里矿车占画面的比例很小，比如只有 5% 的区域有目标，模型容易把大量背景学成负样本特征。YOLO 的损失设计里，背景样本对损失函数的贡献占比很高，如果背景过于复杂（井下有皮带、管道、电缆），模型会把注意力放在排除背景上，对目标的响应变弱。解决思路是提高输入分辨率，或裁剪大图只保留有效检测区域再训练。
5.2 现象：矿车漏检率高、人员误检多——anchor 设置与尺度问题
矿井场景的矿车有显著的长宽比特征，尤其侧面和斜侧视角下，宽高比可能达到 3:1 甚至 4:1。如果训练时用的是 YOLOv8 默认的 anchor 或自适应 anchor，对长条形目标的适配会偏弱。处理办法有两个：一是用model.tune跑一轮 anchor 自适应，二是检查数据里矿车标注框的宽高比分布，如果过于集中在特定范围，可以手动调整 anchor 数量。
人员误检多的问题，常见原因是数据集里的人大多是穿着工装、戴安全帽的完整人形，但现场会出现只露出半个身子或远处的小人目标。如果验证集里没有这类样本，模型会在部署时才暴露出严重的误检。应对办法是往训练集里加入部分「截断人形」样本，哪怕是从原始视频里额外抽帧标注，也比纯粹调后处理有效。
5.3 现象：训练时 loss 剧烈震荡——batch size 与学习率不匹配
MineCarWithPeople 这类数据集的图片尺寸如果较大（比如 1920×1080），直接训练时 GPU 显存吃紧，被迫把 batch size 调到 4 或 8。这时如果学习率还用默认的 0.01，loss 会出现典型的周期性震荡。原因很简单：batch size 越小，梯度噪声越大，大学习率会放大噪声。
# 常见做法: 小 batch 配小学习率 python train.py --data data.yaml --batch 8 --lr 0.005 --imgsz 640 --epochs 100batch size 和初始学习率的经验公式是lr = 0.01 * batch_size / 64。batch size 从 16 降到 8，学习率应从 0.01 降到 0.005 附近。另外--imgsz的选择也直接影响显存占用。640 是性价比最高的默认值，但如果矿车尺度普遍较大，试一次 960 输入不一定变慢很多——因为矿车检测不需要对小目标过度敏感，大输入尺寸反而能让模型看清矿车的轮廓特征。
5.4 现象：训练没报错，推理全空白——图片解码与模型导出问题
这类问题最容易在 Windows 平台出现。训练时用的图片路径是E:\data\MineCarWithPeople\train\images\xxx.jpg，复制到另一台 Linux 机器上后，data.yaml 里的绝对路径没改，模型加载后推理时读不到图片，输出全空。另一个常见原因是 OpenCV 版本对 exr、tiff 格式的图片支持不完整，但数据集如果只有 jpg 和 png，通常不会踩到。
推理全空还要检查一个隐蔽环节：模型导出的格式。PyTorch 权重转 ONNX 再转 TensorRT 时，如果输入输出张量名对不上，推理结果可能是空白框或直接崩溃。遇到这种情况，我一般先用原始 PyTorch 权重跑一遍验证集，确认模型本身没问题，再去排查导出链路的参数设置。不要一上来就怀疑模型训练效果。
6. 验证与进阶：把 mAP 之外的指标补齐，才能判断数据集值不值得
6.1 按类别拆分 PR 曲线和混淆矩阵
训练结束后，多数人只看总体 mAP@0.5，但工业场景里「误检」比「漏检」更致命。矿井里把矿车误检成人，会触发本不该有的报警；把人漏检成背景，是更严重的安全隐患。所以除了总体 mAP，必须看每个类别单独的表现。
YOLOv8 训练结束后会自动生成results.png，里面包含 PR 曲线和混淆矩阵。我习惯额外跑一遍按类别的指标统计：
from ultralytics import YOLO model = YOLO('./runs/train/exp/weights/best.pt') metrics = model.val(data='./MineCarWithPeople/data.yaml', split='val') # 按类别输出指标 for i, name in enumerate(metrics.names.values()): cls_map = metrics.box.map[i] # 该类别的 mAP@0.5:0.95 cls_precision = metrics.box.p[i] cls_recall = metrics.box.r[i] print(f'{name}: mAP={cls_map:.3f}, precision={cls_precision:.3f}, recall={cls_recall:.3f}')输出结果后重点看 recall。如果 mine_car 的 recall 远低于 person，说明矿车类别存在系统性漏检，需要回到数据处理层面找原因，而不是继续调训练参数。PR 曲线的形状也有信息量：如果曲线在召回率 0.8 附近垂直下跌，说明高置信度预测集中在简单样本上，复杂样本的置信度分布跟简单样本严重重叠。
6.2 用测试视频验证时间序列上的检测稳定性
验证集上的 mAP 只能说明静态帧的检测准确性，部署时还要验证时间序列上的稳定性。矿井视频流里，矿车从远处驶近，尺度从小到大变化，如果模型对尺度变化敏感，会出现「近处检测到、远处丢失、下一帧又检测到」的抖动。这种问题验证集指标完全看不出来。
我一般会从数据集外面找两段连续监控视频，一段是矿车匀速驶过的画面，一段是人员在轨道旁行走的画面，跑一遍全量推理，输出每帧的检测框位置。然后用相邻两帧的检测框 IoU 跳变幅度来判断稳定性。如果同一目标的检测框中心在相邻帧之间跳动超过 20 个像素，说明模型对目标的定位不够稳健，这时可以考虑在模型层面加一点帧间平滑的推理逻辑。
6.3 数据集扩展与迁移学习：结合自身矿山的图像做二次标注
MineCarWithPeople 的定位是「基础数据集」，直接部署到现场之前基本都要做增量训练。原因很简单：每个矿山的矿车外观、涂装、巷道光照条件差异很大，基础数据集里的图片不可能覆盖。常见的做法是保留这个数据集的全部图片，然后从自己的监控系统里抽 500 到 1000 帧，用训练好的模型做预标注，再人工修正，合并进训练集。
增量训练的时候要注意格式对齐——自己标注的数据如果用了 CVAT 或 LabelMe，导出格式是 JSON 或 XML，必须转成 YOLO txt。转格式的脚本网上很多，但核心就一句话：把多边形或矩形框的顶点坐标转成归一化中心点加宽高。转换后跑一遍前面第 2 章的校验脚本，确保格式对齐再训练。这一步我吃过亏，当年直接把 LabelMe 导出的 JSON 丢进 YOLO 训练，结果所有框的坐标都错位了——训练过程不报错，但模型完全没法用。
另一个值得做的方向是尝试用带注意力机制的检测头替代原始检测头。这类改进对矿山场景的收益在于：矿车和人员在画面里经常是靠近轨道的小目标，加强局部特征提取能改善难样本的检测效果。
文本格式的项目里，最怕的不是模型不够强，而是数据底子没打好。MineCarWithPeople 作为轨道运输场景的专用数据集，是少见的贴合实际工况的原料。拿到手先做格式核对、类别统计、时间维度划分，再用自己的现场数据增量训练，这套流程走完，至少能为矿井安全监控系统提供一个真正能用的检测模型。整个过程里，最容易被忽视的永远是数据划分和类名对应，这两处卡住，后续全部白费。希望帮到你。
本文还有配套的精品资源，点击获取
