简介面向轨道交通信号系统学习者的一份实验资料包围绕车载系统与控制模式实验展开同时关联目标检测在列车识别与运行监控中的背景应用。压缩包内为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-CNNResNet50骨干。它们分别代表轻量一阶段、增强一阶段、端到端Transformer、经典两阶段四条路线。模型推理速度精度上限显存占用报告友好度YOLOv8n快中低高跑通最快YOLOv8s中中高低高性能均衡RT-DETR-l快高中中需要解释注意力机制Faster R-CNN慢高高中工程化繁琐选型逻辑是这样的第一次跑实验、目标是流程走通用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 datadata.yaml modelyolov8n.pt \ epochs50 batch16 imgsz640 device0这条命令的含义用data.yaml指定的数据集以YOLOv8n预训练权重为起点训练50个epoch每个batch放16张图输入分辨率640乘640用0号显卡device0。第一次训练建议把这几个参数保持默认先把流程跑通后面再逐个调。训练结束后runs/detect/train/目录下会生成权重文件best.pt和last.pt以及各种训练曲线图。3.2 数据组织与data.yaml一个坑位都不能错YOLO训练要求数据按固定目录组织我用树形结构展示一下dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yamlimages里放图片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_objectpath是数据集根目录的绝对路径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( datadata.yaml, epochs80, imgsz960, batch16, lr00.01, mosaic1.0, close_mosaic10, patience15, seed42, device0, )这段代码里每个参数都有明确作用按轨道场景我给几个调整建议。imgsz960是最关键的一个轨道目标普遍偏小640输入会让裂缝和扣件在特征图上只占几个像素提高到960后小目标的AP通常能涨3到5个点。epochs80是折中值数据量小几百张时训练50个epoch就收敛数据量大时100个epoch更稳。mosaic1.0默认开启close_mosaic10表示最后10个epoch关闭马赛克增强让模型回到真实分布上微调。patience15表示验证集指标连续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 modelruns/detect/train/weights/best.pt datadata.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固定用IoU0.5判断匹配宽松。mAP50-95是把0.5到0.95每隔0.05取一个阈值计算AP再平均严格也更接近真实定位精度。轨道检测实验里裂缝和扣件这类小目标定位框差一两个像素很正常所以mAP50-95会比mAP50低不少这是正常现象报告里不要对这两个数字的差距大惊小怪。报告里写mAP必须同时交代三件事用了多少张验证图、IoU阈值是多少、置信度阈值是多少。只写“mAP0.83”等于没写因为0.83可能是在IoU0.5、conf0.001下算出来的另一个实验在IoU0.5、conf0.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_mosaic10让最后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 报告数据对不上指标口径不一致的核查清单现象自己写脚本评估得到mAP0.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输出目录里所有图过一遍再决定结论怎么写。这个习惯帮我挡掉过好多次报告数据前后矛盾的事故。实验报告不是把训练跑完就结束而是把从数据到结论的每一步都变成别人能复现的证据。希望帮到你。本文还有配套的精品资源点击获取