简介一份系统梳理计算机视觉与轨道交通交叉应用的docx技术文档面向人工智能、智慧交通领域的工程师、科研人员及高校学生契合当前人工智能与大模型技术加速落地背景适合作为技术综述与选题调研参考。资源包仅1个Word文档大小约170KB排版清晰、目录完整可直接阅读或按章节查阅。正文先介绍计算机视觉技术概况、图像处理原理、深度学习算法与目标检测识别方法以及软硬件系统构成随后分三类场景展开信号系统部分涵盖信号灯状态自动识别、列车位置检测与闭塞状态监测线路维护部分涉及轨距与轨道变形、轨道表面缺陷、道岔关键部件缺陷、桥梁变形与隧道裂缝检测运营管理部分包含客流量实时监测等。各模块均配有研究背景、国内外现状与安全性能评估思路章节结构层层递进既能帮助从零入门也可为实际项目方案提供索引。已有31人学习下载值得从事轨道交通智能化改造或视觉算法应用的相关人员收藏。1. 计算机视觉技术在轨道交通应用里的位置与门槛地铁站台门和列车门之间那道三十多厘米的缝隙每天都在上演人与时间赛跑。屏蔽门防夹靠的是红外和激光雷达但雨伞、裙摆、盲杖这类细长物体经常让传统传感器漏判轨道巡检工每天走十几公里看钢轨和扣件人眼疲劳后的漏检率并不低。把计算机视觉技术放进轨道交通解决的正是这类“看得见但来不及反应”的问题用摄像头和算法替代一部分人工目视让异常检测从人眼疲劳的随机抽查变成每帧都在执行的确定性检查。这件事的难点不在模型精度而在于轨道交通对“稳定”的要求远高于对“聪明”的要求。地铁环境光照剧烈变化、震动、灰尘、遮挡任何一项都是通用视觉算法在现场崩掉的常见原因。这篇文按“任务与选型 → 数据与训练 → 边缘部署 → 参数调优”的顺序讲一套可落地的做法覆盖从模型选型到现场调参的完整路径。适合做轨交智能化项目的算法工程师、集成商技术负责人以及想评估视觉方案可行性的运维管理者。2. 轨道交通视觉任务的任务定型与训练数据管线2.1 轨道交通视觉任务不是通用目标检测的简化版把通用目标检测模型直接搬到站台和隧道里最大的坑就是“任务定型错了”。通用检测的目标是“把物体框出来”但轨道交通里的视觉任务绝大多数不是目标检测而是异常事件检测和状态识别。以屏蔽门防夹为例要判断的不是“门缝里有什么”而是“门关到哪个位置了、夹缝里有没有异物”。前者是检测问题后者是语义分割加时序判断的问题。两者用到的模型、标签方式和判定逻辑都完全不同。另一个常见误区是照搬自动驾驶的方案。轨道交通线路固定、运行图固定摄像头位置固定这决定了视觉系统可以用更强的先验场景背景几乎不变物体运动轨迹有明确的物理约束。这意味着可以大量使用背景建模、轨道区域掩膜、速度预测这类方法大幅降低误报率。通用检测模型在这里反而会因为“过于通用”而产生大量无意义的候选框。先把任务按四个维度分类定型和选型任务类型典型场景建议模型方向输出形式目标检测轨行区人员入侵、遗留物检测YOLO系v8/v11边界框类别实例分割屏蔽门夹缝异物、车底异物Mask R-CNN、YOLO-seg像素级掩膜语义分割道床裂缝、钢轨表面缺陷U-Net、DeepLabV3像素级分类异常检测接触网异物、烟雾PatchCore、视频异常检测分数局部定位这里没有把姿态估计列进去因为轨道交通里对“人的动作”识别需求较少站台门区域的判断更依赖轮廓而非骨骼点。选型时优先用检测或分割实在需要判断“是否摔倒”再引入姿态模型减少一层推理就少一层失败概率。2.2 样本不是从网上爬的是从现场录的再抽的通用模型可以用公开数据集起步轨道交通不行。站台门形状、隧道光照、列车外观都具有强烈的场景特异性公开数据训练出来的模型在现场基本不可用。我做轨交项目样本来源就一个现场安装的摄像头原始录像。原始录像不能直接拿来训练需要先做抽帧和清洗。最常见的做法是按时间间隔抽帧再用CLIP或感知哈希去掉重复帧最后人工标注。抽帧这一步看似简单但间隔设错了会直接影响模型效果地铁进站约30秒如果你每秒抽1帧能拿到约30帧而列车门关闭过程只有3到5秒有效帧可能就10帧出头。抽帧间隔设成5秒甚至10秒关门瞬间大概率被跳过模型永远学不到“夹物”的视觉特征。import os import cv2 from pathlib import Path video_path Path(raw/station_cam_01.mp4) out_dir Path(frames/20240511) out_dir.mkdir(parentsTrue, exist_okTrue) cap cv2.VideoCapture(str(video_path)) fps cap.get(cv2.CAP_PROP_FPS) # 大多数现场摄像头为25fps interval int(fps * 1.0) # 每1秒取1帧进站事件可不遗漏 frame_id 0 saved 0 while True: ret, frame cap.read() if not ret: break if frame_id % interval 0: # 保存前先压缩减少标注平台加载压力 cv2.imwrite(str(out_dir / f{video_path.stem}_{saved:06d}.jpg), frame, [cv2.IMWRITE_JPEG_QUALITY, 90]) saved 1 frame_id 1 cap.release() print(fsaved {saved} frames from {fps:.2f} fps video)这段代码的关键参数是interval int(fps * 1.0)即按1秒1帧抽。如果做隧道裂缝检测车行速度快抽帧间隔要缩短到0.2秒以下否则裂缝目标在相邻帧之间位移过大标注时难以确认同一裂缝的不同形态。压缩质量设为90也是刻意的现场录像原盘体积大训练对画质不敏感但太低的压缩率会在裂缝这类细纹理任务上产生伪影模型学到的是压缩噪声。标注阶段建议用矩形框加多边形混合屏蔽门异物标注用多边形物体形状不规则轨道入侵人与遗留物用矩形框目标相对完整。标注类别要克制类别越少越好两三个类别足够时不要扩到五六个。轨道交通场景样本密度低类别多了每类的样本量都不够模型容易在类别间混淆。2.3 数据平衡正样本太多负样本不够训练数据里“没有异物的正常画面”约占九成这会导致模型把“什么都不做”学得很好把真正的异常事件当成噪声忽略。解决思路不是删正常帧而是引入“难负样本”在正常场景里手动放入可能引起误判的物体比如报纸、塑料袋、反光的水渍。这些样本让模型学会区分“看着像异物但实际无害”的情况比单纯堆异常样本更能压误报。另一个有效做法是时间维度上的连续帧标签。轨道交通异常往往是一个过程比如人翻越屏蔽门有跨坐、跳下、落地三个瞬间单帧标注只能让模型识别静态特征而带上前后帧可以让模型学到动作的连贯性。实践中我会把抽帧后的连续5帧打包成一个样本单元标注时只标关键帧但在训练时把前后帧作为上下文输入模型对“正在发生的异常”的判断明显更稳。3. 边缘端推理部署从ONNX导出到国产化工控平台3.1 算力边界决定了模型不能只图准轨道交通的摄像头点位分散在车站、隧道、车辆段不可能把每路视频都传到机房做GPU推理。常见做法是轨旁机柜放一台边缘计算盒子单台设备接入2到8路摄像头在设备上完成推理只把结果和关键帧上传。这就引出一个硬约束模型必须跑在边缘设备的算力范围内。以常见的边缘盒子为例配置从几十TOPS的NPU到低功耗x86工控机都有。如果你的推理后端是英伟达系列模型导出TensorRT是通用路径如果你面对的是龙芯、飞腾这类国产平台就得走ONNX Runtime或OpenVINO兼容层。把PyTorch模型转成ONNX是第一步这一步谁都要做。import torch import torch.onnx model torch.load(best.pt, map_locationcpu)[model].float() model.eval() # 固定输入尺寸避免动态尺寸带来的导出警告和推理抖动 dummy_input torch.randn(1, 3, 640, 640) torch.onnx.export( model, dummy_input, best.onnx, opset_version17, input_names[images], output_names[output0], dynamic_axes{images: {0: batch}} # 推理时按batch1跑动态维只留batch ) print(ONNX exported)注意这里把输入分辨率固定为640x640这是轨道交通现场部署最常见的做法。不要用动态分辨率边缘设备的显存或内存有限推理框架在动态分辨率下容易因为输入尺寸变化触发重新分配内存导致推理耗时抖动。dynamic_axes只留下batch维度保证一张图和四张图走同一个模型图又不会因为分辨率变化拖慢速度。导出后要立刻用ONNX Runtime验证输出是否与PyTorch一致。差值的容忍度取决于任务检测任务允许坐标有几像素偏差但分割任务要求像素级一致否则现场轮廓判断会出问题。3.2 TensorRT与OpenVINO的转换参数选择如果边缘盒子带N卡TensorRT是首选推理后端如果面对的是国产CPU加集显方案OpenVINO是更稳的选择。两者的转换命令并不复杂难在参数搭配。用TensorRT做INT8量化时校准数据集必须来自现场不能用COCO或城市道路数据。轨道交通场景的色彩分布和交通场景差异极大隧道里整体偏暗偏黄站台区高亮偏白校准数据代表不了现场INT8量化后的精度损失可能超过3%这个损失在异物检测里就是漏报。# TensorRT通过trtexec转换核心是--calib和--fp16/int8 trtexec --onnxbest.onnx \ --saveEnginebest_fp16.engine \ --fp16 \ --workspace2048 # OpenVINO通过mo转换--scale控制输入归一化 mo --input_modelbest.onnx \ --input_shape[1,3,640,640] \ --scale255 \ --mean_values[0,0,0] \ --output_dirir_model--fp16在这里是推荐默认值。很多工程师一上来就追求INT8但INT8在轨交这类小目标多、对比度低的场景里精度掉得比预期快。我一般建议先用FP16跑通全流程再回过来测INT8如果精度掉点小于1%再切。OpenVINO侧--scale255对应训练时的归一化策略如果训练代码用的是/255.0这里就是255如果用了ImageNet的mean和std就要换成对应的三组值。这步错位是模型在转IR后精度骤降的最常见原因而且报错信息不会提示只能通过对比推理结果才能发现。3.3 国产化工控平台上的部署形态热词里提到的龙芯2K3000赋能AFC系统其实代表了轨道交通行业的一个明确趋势核心设备和工控平台逐步国产化。AFC是自动售检票系统表面上是闸机、二维码扫描、票卡读写和计算机视觉没有直接关系但闸机通道里的人体检测、尾随判定、行李识别已经在往视觉方案迁移。也就是说视觉算法要跑的不只是轨旁机柜还包括闸机内置的国产化工控模块。这类平台的共性是CPU基于MIPS或ARM架构没有独立GPU内存带宽有限。在这种硬件上跑视觉模型三个做法比较实际一是模型轻量化换用YOLO-nano或MobileNetV3作为backbone二是用OpenVINO的CPU推理路径并开启多线程三是把预处理缩放、归一化放到推理框架里避免Python层的逐帧拷贝。真上项目时还需要确认编译器版本和指令集支持。龙芯平台对OpenVINO的兼容性不如x86成熟需要先用CPU推理跑通基准再决定是否启用自研向量指令优化。这里建议在项目启动的第一周就做一次目标平台的推理实测不要等模型训完再移植否则优化时间不够项目排期会被这个“最后一公里”吃掉大半。4. 现场误报控制的3个必调参数与两类难样本4.1 置信度阈值看场景不看模型模型训练完第一个要调的参数就是置信度阈值。轨道交通场景对此极其敏感屏蔽门防夹漏报一次就可能造成安全事故阈值要压低宁可多报几次让站务员确认但遗留物检测如果阈值太低站台每趟车到站都会报警站务员很快就会对报警麻木反而把真报警忽略了。阈值不是模型参数是运营策略参数。我的做法是按“每路摄像头每小时可接受报警数”反过来定阈值。站台门区域每小时3次以内误报可以接受那就先设0.3跑一整天的历史录像统计误报次数高了上调到0.4低了再降。这个过程必须用历史录像回放做不能在现场边运营边调否则每一次误报都是在消耗站务员的信任。4.2 NMS参数和跟踪缓冲的配合目标检测后处理经常被忽略但NMS参数直接决定了“同一目标是否被重复报警”。轨道交通场景里摄像头固定行人目标小如果NMS的IoU阈值设得过高同一行人可能被输出成两个相邻框触发两次报警。常用经验值如下参数默认值轨交场景建议值说明confidence_threshold0.250.30~0.45按运营阈值策略调整NMS IoU threshold0.450.50小目标密集场景适当调高报警帧连续数1帧连续5~10帧过滤瞬时闪烁报警冷却时间无30~60秒避免同一事件重复报警连续帧判断是降误报最有效的手段。现场摄像头25fps一个行人走过站台至少停留几秒目标不会只出现一帧。要求目标连续出现N帧才触发报警可以过滤掉飞鸟、落叶、光影变化这类单帧噪声。但N不能太大屏蔽门关门只有3秒如果要求连续10帧确认等确认完门已经关上了。给这个场景的建议值是5帧约0.2秒人眼还没反应过来算法已经完成确认。import collections frame_buffer collections.deque(maxlen5) def on_track_result(frame_id, detections): # detections: [(class_id, conf, x1,y1,x2,y2)] frame_buffer.append((frame_id, detections)) # 检查连续5帧内同一位置是否都有检出 if len(frame_buffer) 5: return None base_frame, base_dets frame_buffer[0] current_frame, current_dets frame_buffer[-1] if current_frame - base_frame 10: frame_buffer.popleft() return None # 这里简化处理判断当前帧的目标是否与第一帧重合 for det in current_dets: for ref in base_dets: iou compute_iou(det[2:], ref[2:]) if iou 0.5: return det # 连续5帧都有触发报警 return None这段代码是报警缓冲的骨架。maxlen5规定了必须连续5帧都检测到同一位置目标才放行同时用current_frame - base_frame 10限定了总时间跨度超过10帧则重新累积。关键点在于IOU比较的是第一帧和当前帧而不是相邻帧。如果比较相邻帧目标缓慢移动时会因为每一帧都有重叠而触发但目标其实已经走了很远比较首尾帧可以约束“目标必须一直停留在报警区域内”。4.3 两类难样本雨雾干扰与遮挡截断轨道交通现场最难处理的不是“目标太小”而是“环境让目标变得不像目标”。雨天玻璃反光、隧道内车灯过曝、站台门半透明反光都是误报源。反光导致的前景区域没有纹理特征模型容易产生高置信度的错误候选框。对于雨雾可以用图像增强做预处理但不要用深度学习增强网络那种方法在边缘设备上跑不动。OpenCV的直方图均衡化或带色彩恢复的多尺度Retinex就够用代价是每帧多2到3毫秒在边缘设备上可以接受。遮挡问题更麻烦行人被立柱挡住一半检测框只有半个模型往往会因为训练集里完整样本太多而把半个目标判为低置信度。解决办法在训练层面标注的时候就要把“截断目标”也标出来比如人被柱子挡住一半依然标记完整框让模型学会“只看到一半也能判断是个人”。5. 用历史录像回放验证模型的实战技巧回放验证是整个项目交付前最重要的环节但很多人做得太随意拉一段当天录像跑一遍看几个报警然后写报告。正确的做法是建立一个固定的测试集和回放脚本让每次模型更新后都能在同样的数据上对比。# 用ffmpeg把指定时间段的录像切出来作为回放测试集 ffmpeg -ss 06:30:00 -i station_cam_01.mp4 -t 1800 -c copy test_set/20240511_morning.mp4 # 批量回放测试跑推理并把结果存成JSON方便对比 python replay_test.py --video test_set/20240511_morning.mp4 \ --model best.engine \ --output result/20240511_morning.json \ --confidence 0.35回放脚本会逐帧跑推理输出每帧的检测框和置信度。重点是把每次更新模型后的推理结果保存下来做帧级对比。对比时关注三个指标检出率人工标注过的异常帧有多少被检出、误报率正常帧有多少被误报、报警时间差异常发生到系统报警延迟几秒。时间差是轨道交通里常被忽视的指标异物检测要求2秒内报警回放测试时用暂停键人工计时测试标准就是异常出现到画面出现报警框之间不超过2秒。测试集里要专门放一批“阴雨天、夜间、强光”的样本这些是现场最容易出问题的时段。如果阴雨天数据不足可以等一个雨天专门录制不要用图像增强去模拟雨天模拟出来的效果和真实雨雾差异太大验证结果没有参考价值。还有一个实用技巧把误报的画面按周汇总做成台账。这个台账比任何测试报告都有用。画面里反复出现某一类误报说明某个现场条件没有被训练集覆盖要么补样本要么加规则过滤。比如某个站台在午后特定时间会有大面积光影移动视觉上很像行人这种情况与其硬调模型不如在时间策略上做限制。轨道交通的视觉项目最终交付的不只是一个模型而是一套“模型规则运营策略”的组合回放验证就是把这套组合逐步调到现场可用的过程。本文还有配套的精品资源点击获取