轨道目标检测实验全流程：从YOLOv8训练到报告避坑指南

简介：面向轨道交通信号系统学习者的一份实验资料包，围绕车载系统与控制模式实验展开，同时关联目标检测在列车识别与运行监控中的背景应用。压缩包内为1份doc格式实验报告，体积约27.52MB，报告完整呈现实验目的、器材、操作步骤、过程截图与数据分析，重点演示了CBTC条件下区域控制器CBTCZC与车载软件的协同流程：从列车加车、ATC钥匙接通与初始化，到RM/CM/AM模式切换、ATS计划下发、运行曲线接收，再到到站开关门、提前发车和跳停设置等关键操作，并对线路设置、任务下发、驾驶台操作等影响因素进行了剖析总结。该报告既可用于课程实验报告的撰写参考，也能帮助理解目标检测在列车位置与速度感知中的工程意义。目前已有135人学习下载，适合高校轨道交通类专业学生、目标检测初学者及相关实验人员。

1. 轨道实验里的目标检测：为什么这项内容最容易让报告翻车

轨道实验内容是个大集合，测量、控制、通信都有，但目标检测是其中最容易被看出来水的部分。很多同学把训练跑通就以为实验做完了，结果报告交上去被批“没有说服力”，问题不出在代码，出在整条证据链是断的：为什么选这个模型、数据怎么准备的、指标怎么算、漏检怎么分析，一个都没交代。我在某公司做轨旁巡检方案验证时带过几个工程师，也踩过同样的坑——模型训练完，报告里贴一张loss下降图就算交差，评估用的IoU阈值自己都说不清。

这套内容适合两类人：正在做轨道实验课程、需要提交目标检测实验报告的学生，以及想在轨道交通视觉方向快速做技术验证的工程师。下文按我从数据、训练、评估到报告的顺序来拆，代码和参数可以直接照做，遇到翻车点也给了排查路径。

2. 轨道场景的样本与模型选型：为什么YOLO系是默认起点

2.1 传统视觉方法在轨道场景的三个死穴

轨道场景的视觉检测，传统做法一般是三件套：边缘检测找轮廓、模板匹配找扣件、阈值分割找异物。单看原理都没问题，用在真轨道上就处处碰壁。

第一道坎是光照和反光。钢轨表面在晴天是强反光面，隧道口又有剧烈的亮度跳变，固定阈值在这种场景下基本失效。Canny边缘检测会把水渍、锈迹、轮轨接触斑都当成边缘输出。我见过一个用传统方法做的扣件缺失检测方案，白天效果好，傍晚太阳一歪，误检率直接翻倍。

第二道坎是目标尺寸。一个扣件在1080P画面里可能只有三四十个像素宽，模板匹配对尺度变化极其敏感，稍微旋转或遮挡就匹配不上。钢轨裂缝更麻烦，对比度低、宽度只有几个像素，边缘检测找到的线段断成一截一截，后处理很难连接成完整缺陷。

第三道坎是类间相似。焊缝和裂缝在灰度上高度相似，道床碎石和侵入异物也长得差不多。传统方法靠手工设计特征，在“看起来像但其实是两类”的问题上很难拉开区分度。阈值调一调就变成玄学，换个场景全部失效。

所以现在的轨道检测实验基本都转向深度学习目标检测，不是因为时髦，而是特征从数据里学出来，对光照、姿态变化有更强的鲁棒性。你要做的不是从头训练一个网络，而是在预训练模型上做迁移学习微调，用轨道数据把模型带回正轨。

2.2 轨道数据集怎么建：拍摄、标注与类别定义

数据是所有实验报告的地基。轨道检测实验最常见的数据来源有三种：轨检车或巡检机器人拍摄的真实图像、安装在车站或隧道入口的固定相机抓拍图、公开的轨道缺陷数据集。无论数据从哪来，第一步是统一格式。

我一般习惯用LabelImg标注，输出PascalVOC格式的XML，再转成YOLO需要的txt；如果团队喜欢LabelMe，输出的是JSON，转换思路一样。数据集目录按images和labels分开，训练和验证再各拆一份，具体目录在第3章给出。

类别定义直接影响报告质量。以典型的轨旁视觉检测为例，我通常定义四类：「正常扣件」「缺失扣件」「钢轨裂缝」「轨道异物」。

标注有两条实操原则。一是小目标不要为了看得清楚而放大框，贴着真实边界标，否则会把背景学进特征；二是模糊图像要么删掉，要么单开一个模糊类，不要和清晰目标混在一起，混了会让模型在推理时对模糊目标举棋不定。另外至少安排第二个人抽检20%的标注，框偏移超过5个像素就要返工。很多报告的数据问题不是数量不足，而是标注质量拉低了模型上限。

数据增强要按物理场景来设计。隧道内需要模拟低照度、雨雾天需要模拟雾化、夜间需要压低亮度，增强策略应该和真实部署场景对齐，不是把所有手段无脑叠加。亮度扰动、对比度扰动、±15°以内的小角度旋转是安全的。水平翻转要谨慎，因为扣件有方向性，翻转会把左扣件变成右扣件。mosaic增强对小目标利用率有帮助，但也会带来翻车点，留在第5章细讲。

2.3 模型选型对比：报告里必须有的论证逻辑

模型选型这部分，报告里不能只写“我用了YOLOv8”，需要做对比论证，哪怕只做一组小实验作为证据。我通常拿四类方案对比：YOLOv8n、YOLOv8s、RT-DETR-l、Faster R-CNN（ResNet50骨干）。它们分别代表轻量一阶段、增强一阶段、端到端Transformer、经典两阶段四条路线。

选型逻辑是这样的：第一次跑实验、目标是流程走通，用YOLOv8n，训练时间短、显存要求低、出错好排查。拿到baseline之后再升级到YOLOv8s，或者RT-DETR看精度收益。如果硬件够强，再用Faster R-CNN做对照实验，补一组“两阶段方法精度更高但速度更慢”的数据，报告的说服力会明显不一样。

我默认选YOLO系还有一层原因：一阶段检测的逻辑很好文字化——图片被分成网格，每个网格预测边界框和类别置信度，再做NMS去重。这个逻辑在答辩时两三句话能讲明白。RT-DETR的注意力机制解释成本高，Faster R-CNN的RPN提案网络也要额外篇幅，对课程实验而言，YOLO是把精力留给数据分析和结论的最短路径。

3. 用YOLOv8在本地跑通轨道检测训练：最小命令与关键参数

3.1 环境准备与最小训练命令

轨道检测实验不需要一开始就上服务器，本地一张消费级显卡就够出baseline。环境准备我一般用虚拟环境隔离，避免和系统Python互相污染。

python -m venv track_env source track_env/bin/activate pip install ultralytics torch torchvision

这三行命令的作用是：创建独立Python环境、激活环境、安装目标检测框架和深度学习核心库。如果你机器上有NVIDIA显卡，torch会自动装CUDA版本；如果没有，CPU版本也能跑通验证流程，只是训练会慢很多。建议先用CPU版本把数据管道跑通，再换到有显卡的机器训练，这样定位问题更快。

装好之后，准备一份至少几百张的轨道图像和对应标注，就能跑最小训练命令：

yolo detect train data=data.yaml model=yolov8n.pt \ epochs=50 batch=16 imgsz=640 device=0

这条命令的含义：用data.yaml指定的数据集，以YOLOv8n预训练权重为起点，训练50个epoch，每个batch放16张图，输入分辨率640乘640，用0号显卡（device=0）。第一次训练建议把这几个参数保持默认，先把流程跑通，后面再逐个调。训练结束后，runs/detect/train/目录下会生成权重文件best.pt和last.pt，以及各种训练曲线图。

3.2 数据组织与data.yaml：一个坑位都不能错

YOLO训练要求数据按固定目录组织，我用树形结构展示一下：

dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yaml

images里放图片，labels里放同名txt标注文件。每个txt的每一行是一个目标，格式为：class_id x_center y_center width height，四个坐标都归一化到0到1之间。类别编号从0开始，和data.yaml里的names顺序必须一一对应。

data.yaml是数据集的唯一配置文件：

path: /abs/path/to/dataset train: images/train val: images/val nc: 4 names: 0: normal_clip 1: missing_clip 2: rail_crack 3: foreign_object

path是数据集根目录的绝对路径；train和val填写相对于path的子目录；nc是类别总数；names是类别名列表。最容易翻车的点有两个：一是names顺序和标注txt里的编号对不上，训练出来的模型会把裂缝识别成扣件；二是path写成相对路径且运行目录不对，训练直接报Dataset not found。建议path一律写绝对路径，或把data.yaml放在dataset根目录下。

从其他格式转YOLO txt时，我习惯写一个一次性脚本，核心逻辑是读XML或JSON里的坐标，换算成归一化中心点坐标：

import os import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, out_dir, class_map): tree = ET.parse(xml_path) root = tree.getroot() img_w = int(root.find("size/width").text) img_h = int(root.find("size/height").text) lines = [] for obj in root.findall("object"): name = obj.find("name").text box = obj.find("bndbox") x1 = float(box.find("xmin").text) y1 = float(box.find("ymin").text) x2 = float(box.find("xmax").text) y2 = float(box.find("ymax").text) cx = (x1 + x2) / 2 / img_w cy = (y1 + y2) / 2 / img_h w = (x2 - x1) / img_w h = (y2 - y1) / img_h lines.append(f"{class_map[name]} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}") out_path = os.path.join(out_dir, os.path.basename(xml_path).replace(".xml", ".txt")) with open(out_path, "w") as f: f.write("\n".join(lines))

转换脚本的参数说明：class_map是把类别名映射成编号的字典，必须和data.yaml的names顺序一致。归一化坐标使用图片宽高做分母，如果图片被resize过，需要先用resize后的尺寸再算一次。转完一定要抽查几个txt，用可视化工具把框画回图片上确认，这一步能拦住大部分标注转换错误。

3.3 训练脚本：四个必调参数与训练曲线怎么看

CLI命令适合快速验证，正式实验我会写成Python脚本，方便复现和记录参数：

from ultralytics import YOLO model = YOLO("yolov8n.pt") results = model.train( data="data.yaml", epochs=80, imgsz=960, batch=16, lr0=0.01, mosaic=1.0, close_mosaic=10, patience=15, seed=42, device=0, )

这段代码里每个参数都有明确作用，按轨道场景我给几个调整建议。imgsz=960是最关键的一个，轨道目标普遍偏小，640输入会让裂缝和扣件在特征图上只占几个像素，提高到960后小目标的AP通常能涨3到5个点。epochs=80是折中值，数据量小（几百张）时训练50个epoch就收敛，数据量大时100个epoch更稳。mosaic=1.0默认开启，close_mosaic=10表示最后10个epoch关闭马赛克增强，让模型回到真实分布上微调。patience=15表示验证集指标连续15个epoch不提升就早停。

训练过程中每隔几十秒看一次终端输出的loss值。比较重要的是val精度曲线：跑完会在runs/detect/train/目录生成results.png，包含box_loss、cls_loss、mAP50、mAP50-95四条曲线。如果mAP曲线还在上升就停了，说明epochs不够或patience设小了。如果loss下降但mAP不动，先检查标注文件是否有空txt或者类别编号错乱。

训练收敛后，用验证命令复现报告数据：

yolo detect val model=runs/detect/train/weights/best.pt data=data.yaml

验证命令不传imgsz时，默认用训练时的分辨率。它在runs/detect/val/目录下输出混淆矩阵confusion_matrix.png、PR曲线PR_curve.png以及逐类别的AP统计表，这些就是实验报告里最核心的证据材料。

4. 报告里必须有的评估指标：从mAP到漏检率误检率

4.1 mAP50与mAP50-95：先把口径讲清楚再写数字

mAP是目标检测报告里最常出现的指标，也是口径最容易出问题的指标。它的计算链路是：模型输出预测框和置信度，通过IoU判断预测框和真实框是否匹配，IoU大于阈值记为TP，否则记为FP；没被匹配到的真实框记为FN。然后按置信度从高到低排序，累计计算每一档的precision和recall，画成PR曲线，曲线下面积就是AP，所有类别AP的平均值就是mAP。

mAP50和mAP50-95的差别只在IoU阈值。mAP50固定用IoU=0.5判断匹配，宽松。mAP50-95是把0.5到0.95每隔0.05取一个阈值计算AP再平均，严格，也更接近真实定位精度。轨道检测实验里，裂缝和扣件这类小目标定位框差一两个像素很正常，所以mAP50-95会比mAP50低不少，这是正常现象，报告里不要对这两个数字的差距大惊小怪。

报告里写mAP，必须同时交代三件事：用了多少张验证图、IoU阈值是多少、置信度阈值是多少。只写“mAP=0.83”等于没写，因为0.83可能是在IoU=0.5、conf=0.001下算出来的，另一个实验在IoU=0.5、conf=0.5下算出来0.71，两者不具备可比性。翻了车才懂，这个口径说明是报告的命根子。

4.2 轨道场景更要盯漏检率与误检率：两个业务的硬指标

mAP是学术指标，但轨道检测实验如果只写mAP，和工程落地是脱节的。轨道交通的安全要求决定了：缺陷漏检的代价远大于正常目标误检。漏检一个裂缝可能引发安全事故，多报一个异物最多让人工复核一次。所以实验报告除了mAP，必须给出漏检率和误检率。

漏检率的计算方式就是1减去recall，等于FN除以TP加FN；误检率等于FP除以TP加FP。在Python里就是几行换算：

# 从验证输出统计出三要素后换算业务指标 TP = 120 # 正确检出的目标数 FP = 18 # 检错的目标数，包括背景误检和类别错检 FN = 10 # 漏掉的目标数 recall = TP / (TP + FN) # 召回率，越高漏检越少 precision = TP / (TP + FP) # 精确率，越高误检越少 miss_rate = FN / (TP + FN) # 漏检率，业务上最关心 false_alarm = FP / (TP + FP) # 误检率 f1 = 2 * precision * recall / (precision + recall) print(f"漏检率: {miss_rate:.2%} 误检率: {false_alarm:.2%}")

TP、FP、FN这三个数从哪来？最可靠的方式是用yolo detect val输出的统计表，或者从混淆矩阵里读：对角线是各类别TP，某一行非对角线元素是该类被错认成别的类的数量，合计算进FP。报告的结论部分不要写“效果不错”，要写“漏检率从初始模型的15%下降到6%，代价是误检率上升2个百分点”，这才叫把实验做成可决策的结论。

4.3 用PR曲线和混淆矩阵给报告做证据

PR曲线回答的是一个部署问题：把置信度阈值设成多少，才能在漏检和误检之间取平衡。训练完在runs/detect/val/目录下生成的PR_curve.png，横轴是recall，纵轴是precision，不同颜色的曲线对应不同类别。曲线越往右上角凸，模型越好。报告里建议在曲线上标出一个实际选用的阈值点，配合文字说明“当置信度阈值取0.25时，裂缝类的precision是0.81、recall是0.92，低于0.1会导致背景误检陡增”。

混淆矩阵confusion_matrix.png解决的是“错在哪里”的问题。矩阵第i行第j列表示真实类别i被预测成类别j的样本数，对角线自然是正确预测。轨道场景里最常见的错位有两处：背景被误判为扣件，以及裂缝被误判为焊缝（如果类别里没有焊缝，就表现为裂缝漏检）。把这两个错位在报告里单独拎出来分析，比一句“模型存在误检”有说服力得多。

分析误检的根因时，我建议把误检案例图批量导出，按类别分组。通常翻来覆去就几种原因：标注漏标导致模型学到有缺陷的扣件；反光区域纹理复杂导致背景误判；小目标在特征图上响应太弱导致漏检。每类挑两三张典型图贴进报告，配上原因分析，报告的案例分析部分就成立了。

5. 轨道目标检测实验的避坑指南：现象、原因与解决

5.1 小目标漏检严重：loss正常但裂缝AP接近0

现象：训练loss平稳下降，正常扣件AP到了0.9，裂缝类AP只有0.02甚至没有检出记录。排查时先在验证集上逐张看图，发现几十像素宽的裂缝全部没框出来，偶尔检出的还把背景反光当成裂缝。

原因有两个。一是imgsz太小，640的输入分辨率下，几个像素宽的裂缝在特征图里只剩一个点，难以产生有效响应。二是mosaic增强全程开启，把多张图拼在一起后，原本就小的目标被缩得更小，模型在训练时几乎看不到清晰的小目标特征。

解决：把imgsz从640提到960或1280，小目标AP通常立竿见影。训练参数里加close_mosaic=10，让最后10个epoch脱离马赛克增强。如果显存有限，batch减半换分辨率。还有一种兜底方案：推理阶段对原图做滑窗裁剪，把大图切成1280乘1280块分别检测再合并结果，适合部署阶段而不是训练阶段。

5.2 训练集mAP很高、真实场景崩盘：增强策略做出了域偏移

现象：验证集上mAP有0.87，模型放到夜间隧道或雨雾天气实拍数据上，漏检率飙升到40%。很多人第一反应是“模型过拟合了”，其实不是，是增强策略和部署域不一致。

原因：训练时用的增强是随机高斯噪声、随机亮度扰动，生成的是抽象变体，和真实雨雾的物理成像模型差很远。模型在合成噪声上鲁棒，遇到真实水雾反而失效，这是典型的域偏移。

解决：先把真实目标场景的图片各收集几十张做独立测试集，再按场景设计增强——夜间场景做gamma压暗和局部提亮，雨雾场景用雾化模拟。最稳妥是A/B测试：同一份数据，一组只用基础增强（翻转、轻微亮度扰动），另一组加场景增强，对比它们在真实测试集上的漏检率，用数据决定要不要那个增强项。

5.3 缺陷类别训练不动：样本极度不均衡的三种解法

现象：正常扣件几千张，缺失扣件只有几十张，训练几十个epoch后正常扣件AP很高，缺失扣件AP纹丝不动。这种情况不是参数没调好，是数据分布问题。

原因：类别不均衡让模型把绝大多数学习容量消耗在多数类上，少数类在损失函数里的贡献太低。

解决按投入从低到高排序。第一，复制粘贴增强，把少数类目标从原图裁剪出来，随机粘贴到没有该类目标的背景图上，成本最低，注意不要破坏真实遮挡关系。第二，在损失函数里给少数类更高的类别权重，框架支持在训练时对每个类别设置权重，把缺失扣件权重调到正常扣件的3到5倍。第三，伪标签半监督：用当前模型在大量无标注轨道图上推理，挑出高置信度（conf大于0.7）的少数类检测结果自动生成标注，加入训练集迭代。风险是伪标签会放大模型原有错误，需要人工抽检。

5.4 报告数据对不上：指标口径不一致的核查清单

现象：自己写脚本评估得到mAP=0.75，训练日志最后一行却是0.81。或者同事复现你的实验得到完全不同的数字，互相质疑数据造假。

原因：对不上通常出在三个地方。一是IoU匹配口径不同，有的脚本用预测框和真实框的中心点距离小于阈值算匹配，有的用IoU，结果自然不同。二是验证集不一致，训练时验证集和最后写报告时的验证集不是同一份文件。三是置信度阈值不同，有的脚本默认过滤conf低于0.25的框，有的从0.001开始全量计算。

解决：报告数据一律以yolo detect val的输出为准，自定义脚本只做辅助分析。如果确实要自定义评估，必须在报告附录写明三要素：验证集文件列表、IoU阈值、置信度阈值。这个习惯帮我挡下了好几次答辩现场被人质疑数据的尴尬。评估代码能复用就复用，别自己造轮子。

6. 把实验结果变成一份能交付的实验报告：证据链与可视化

报告的结构建议按这个顺序组织：问题定义、数据说明、模型与方法、实验设计、量化结果、典型案例分析、结论与局限。前面是铺垫，中间是证据，最后是判断。轨道实验内容里的目标检测部分，最出彩的往往不是模型本身，而是数据怎么准备的、失败案例怎么分析的这两块。

三个可视化技巧值得留意。第一，PR曲线不要原样贴一张大图，把置信度阈值0.1、0.25、0.5对应的点标在曲线上，旁边注上三点各自的漏检率和误检率，读者一眼能看到取舍关系。第二，漏检案例拼图用GT框（绿色）和预测框（红色）叠加显示，每张图下方写一句失败原因，比几段文字描述直观得多。第三，训练曲线只保留box_loss和mAP50两张图，其他杂图不放，报告不是日志转储。

结论的写法有一条底线：不写“模型效果很好”这种无法验证的句子。用数字说话，写“在300张夜间隧道验证图上，mAP50从0.73提升到0.85，漏检率从18%降到9%，代价是单帧推理时间从8ms增加到15ms”。这个写法让任何读到的人都能判断这套方案值不值得用。局限部分如实写，裂缝小目标的误检还受反光影响，这反而是报告里最真实的部分。

我现在的习惯是跑完最后一组实验，先把val输出目录里所有图过一遍，再决定结论怎么写。这个习惯帮我挡掉过好多次报告数据前后矛盾的事故。实验报告不是把训练跑完就结束，而是把从数据到结论的每一步都变成别人能复现的证据。希望帮到你。

本文还有配套的精品资源，点击获取