在城市交通管理越来越智能化的今天，违章识别已经从“人工盯监控”逐步转向“算法自动巡检”。我这里说的这个项目，就是基于YOLOv5、YOLOv8和YOLOv10去实现违停、压线、逆行这三类典型交通违章行为的全自动检测。它不是学术Demo，而是一套可以直接对接摄像头视频流、在无人值守环境中跑起来的实战方案，适合正在做智慧交通、停车场管理、园区安防的开发者参考。

这三类违章场景看起来简单，但实际落地时坑很多。违停可能发生在夜间光线不足的路边，压线可能是跨实线的瞬间动作，逆行则有方向性判断的问题。单纯靠目标检测框没办法直接判断“是否违章”，需要把检测框和规则逻辑结合起来。这也是这个项目的核心价值：不只是跑通模型，而是把模型输出变成真正可用的业务判断。

整个方案我个人实测下来，从数据准备到最终部署，大概需要两到四周时间，主要取决于你的数据集质量和硬件条件。下面我会把选型依据、数据构建、训练调参、部署推理、以及我踩过的问题一个一个拆开讲，尽量做到拿着就能用。

1. 项目核心思路与方案选型

1.1 违章识别的场景剖析

先明确一下这个项目要解决的三个问题：

• 违停检测：车辆在禁停区域停留超过一定时间，或者停在非划线区域。核心是“车辆坐标”+“停留时长”。
• 压线检测：车辆跨越实线或黄线行驶。核心是“车辆轨迹”+“线与框的交集逻辑”。
• 逆行检测：车辆行驶方向与规定方向相反。核心是“车辆轨迹”+“方向向量计算”。

这三种行为都不是单帧图像能搞定的，至少需要视频流或连续多帧数据。比如违停，你在一帧里看到一辆车停在路边并不能判定它违章，可能只是在等红灯或临时上下客。要判断为违停，必须让检测框在同一个位置稳定存在超过设定阈值，比如30秒或60秒。这就需要检测模块保持高帧率运行，并且有稳定的目标关联算法。

对于压线检测，传统的做法是提前在画面里设定虚拟线或者区域，然后判断车辆中心点或边缘是否越过这条线。这个方案的优点是计算量小，但需要人工配置点位，适合固定摄像头。但对于道路复杂的场景，你可以改用语义分割模型识别车道线，然后和车辆框做几何计算。这个项目为了控制成本，我用的是虚拟线方案，效果很稳定。

逆行检测则更依赖跟踪。你需要知道车辆从哪边进入画面，往哪个方向移动。如果车辆在特定车道的移动方向统计量异常，比如大量车辆从左到右，而某辆车从右到左，就判定为逆行。判断标准不止是和车道方向相反，还要设置置信度阈值，避免因车辆横向移动造成误判。

所以你在设计项目时，一定要把“目标检测”和“规则引擎”拆成两个模块。目标检测只负责输出“车辆类别、置信度、边界框”，规则引擎再去消费这些数据，结合帧序号和时间戳，得出最终违章结论。这个思路能让你在不同场景下快速更换检测模型或调整规则，而不会互相干扰。

1.2 YOLOv5/8/10版本对比与选型逻辑

很多朋友问我为什么不直接用最新版YOLOv10，还要提YOLOv5和v8。原因很简单：项目不是跑一次排行榜，而是要适配不同的硬件环境和业务预算。

YOLOv5在很多边缘设备上优化得非常到位，尤其是有TensorRT版本的预编译模型，可以在英伟达Jetson系列上跑得很流畅。如果你的现场设备是几年前的IPC摄像头搭配小型服务器，那YOLOv5s或YOLOv5m是稳妥选择。它不追求最先进的结构，但胜在稳定。

YOLOv8则是在架构层面做了不少调整，比如使用C2f模块增强特征提取，检测头的解耦设计让分类和回归更独立。如果你需要同时检测车辆类型和违章行为，且硬件相对充裕，用YOLOv8m或YOLOv8l能带来更高的mAP。这个版本对小目标的检测能力比YOLOv5好不少，比如远处的小车或者部分遮挡的车辆。

YOLOv10最大的变化是采用了无NMS的训练和推理策略，从设计上消除了NMS这一后处理耗时。我实测在相同硬件上，YOLOv10的推理速度比YOLOv8快大约20%-30%。但在实际违章识别场景中，精度和速度的平衡点要自己找。如果你的视频源超过8路，而且每一路都要求实时分析，那YOLOv10是更合适的。

我的建议是：先以YOLOv5跑通整个完整流程，包括跟踪和规则判定，不要一上来就用最复杂的结构。等业务逻辑稳定后，再对照v8和v10的精度、速度表现做替换。模型升级只需要改检测模块的接口，规则引擎不需要动。

2. 数据集构建与预处理

2.1 数据采集要点

违章识别的数据不像通用目标检测那样随便抓，三个场景各有难点。

违停数据要覆盖多个时间段。晴朗白天的样本和夜景补光的样本差距极大，算法如果只见过白天，夜间的漏检率会直线上升。我自己采集的时候，专门在早中晚各时段采集了同一批道路的视频，再剪辑成帧。注意不要从公开数据集直接拿完全一样的数据，那样泛化能力会很差，最好能混合约三分之一的公开数据加三分之二的现场数据。

压线数据的关键在于“负样本”。不少车辆会骑跨在线上但并没有越线，或者轮胎轻微压到虚线但立刻回正，这些不算违章。标注时要明确区分“压线”和“正常行驶”，否则模型会混淆。另外压线检测往往需要清晰的车道线，如果你用虚拟线方案，数据标注只需要框出车辆本身即可，但如果是端到端的车道线识别，就要额外标注线。

逆行数据最难。你在马路上正常拍，很难拍到大量逆行样本，但算法不能只见过正行样本。一个可行的办法是在仿真环境或可控场地中采集转向车流。或者从交通事故视频中剪辑出逆行片段。这类样本哪怕数量少，只要形态差异大，比如轿车、SUV、货车，就比大量相似的轿车样本更有价值。

收集完视频后，要按帧率抽帧。我通常用OpenCV读视频，每5帧保存一帧作为待标注图片，这样能保持图像多样性又不会让标注量爆炸。标注图片尺寸建议保持在640x640左右，YOLO系列对此分辨率优化最好。尺寸过大或过小都不利于特征提取。

2.2 标注规范与工具

标注工具我用的是开源的LabelImg或X-AnyLabeling，前者更轻量，后者支持半自动辅助。考虑到违章识别场景中车辆目标比较大，标注的效率其实很高，平均一张图1到2分钟。

标注时注意统一类别名称。我设定的类别有：

• vehicle_car
• vehicle_bus
• vehicle_truck
• vehicle_motorcycle

为什么要区分车型？因为违停和压线规则对不同车型的处罚逻辑不同，比如摩托车违停和汽车违停的判定阈值就不一样。但注意不要设太细，比如单独分“白色轿车”、“黑色SUV”，这没有意义，反而会降低模型精度。

标注框一定要紧贴车辆外轮廓，不要留太多背景。特别是压线检测，框的位置直接影响后续虚拟线交集计算的准确度。如果框太松，车辆还没完全上线就会被判定压线，制造大量误报。

标注完成后，按数据集构建标准划分训练集、验证集、测试集，比例我习惯用7:2:1，并且确保每个类别在各个集合中的分布比例一致。YOLO格式中，每张图片对应一个txt文件，每一行是“class x_center y_center width height”，坐标全部归一化到0-1。

2.3 数据增强策略

交通场景中，天气、光照、遮挡是最大的变量，数据增强能显著提升模型的鲁棒性。我用albumentations库做在线增强，常用的有：

• 水平翻转
• 随机亮度对比度调整
• 高斯噪声
• 随机旋转（不要超过15度，否则目标变成斜着停的车辆，会误导模型）
• 模棒遮挡模拟摄像头被树枝或雨滴遮挡

针对夜间样本不够的情况，我还额外采取了策略：降低图像亮度到80%-60%作为增强效果，并混合少量色偏样本，模拟傍晚路灯下的橙色光晕。这些操作在测试时一定要关闭，增强只用于训练过程。

还有就是针对小目标检测，我会用Mosaic增强。YOLOv5和YOLOv8都内置了Mosaic，它把四张图片裁剪拼接成一张，让模型在训练时看到不同尺度的目标，对小尺寸车辆的识别效果提升非常明显。但Mosaic也有副作用，就是可能让模型对目标真实大小产生错觉，所以训练后期我会逐步降低Mosaic的概率，让模型在正常尺度上微调。

最终我的数据集大约包含8000张标注图片，其中违停3500张、压线3000张、逆行1500张，最后合并为一个项目统一训练。这样模型能在一次推理中同时检测所有目标，不用为每个行为单独训练一个模型，极大地节省了部署资源。

3. 模型训练与性能调优

3.1 训练环境配置

训练阶段我用的是单张消费级显卡，配置是某实验室的Tesla T4，显存16GB。如果你本地没有大显存卡也没关系，YOLOv5s在8GB显存下同样能训练，只是batch size要调小。这类项目对训练集群没有硬性要求，重点是环境的一致性。

依赖安装方面，我建议严格按照各版本的官方requirements文件执行。YOLOv5要求Python3.8以上，PyTorch1.8以上；YOLOv8和v10则要PyTorch1.8+且建议使用最新的CUDA版本。装完依赖后先跑一个官方预训练模型做前向推理，确认环境没问题再启动训练。

训练脚本的核心命令（以YOLOv5为例）：

python train.py --data traffic.yaml --weights yolov5s.pt --img 640 --batch 16 --epochs 100 --device 0

这里traffic.yaml要配置训练集路径、验证集路径和类别名。如果从零训练，weights参数可以设为--weights '' --cfg yolov5s.yaml。但基于预训练权重做迁移学习会快很多，收敛也更稳定。我默认从预训练模型开始。

3.2 关键参数调整

YOLO系列虽然自带一套默认的超参数，但实际训练中一定要根据你的数据分布做调整。

首先是anchor。虽然YOLOv8和v10有自动学习anchor的能力，但YOLOv5需要手动检查。你可以运行python train.py --data traffic.yaml，自动计算适合你的数据集的anchor尺寸。特别是车辆目标的长宽比通常接近2:1，和COCO数据集的分布差别很大，自动生成一次anchor能有效减少定位误差。

然后是学习率。我习惯把初始学习率设为0.01，配合余弦衰减曲线。任务难度中等，训练100轮左右。如果发现loss在某个阶段不再下降，不要盲目加大学习率，而是尝试用1/10的lr再跑20轮微调。

batch size的选择直接影响梯度稳定性。模型越大，batch size应该越小。我实测在16GB显存下，YOLOv8m的batch size设为32比较合适。如果显存不够，调低到16或者使用梯度累积，但效果会有轻微下降。

还有一个容易被忽略的参数是anchor_t和cls_pw。cls_pw代表正负样本的比例权重，在交通场景中背景占比大，负样本很多，适当调高背景的权重能减少误检测。我一般把cls_pw从默认1.0调到1.2或1.5。

3.3 模型评估与迭代

训练过程中我最关心的指标不只是mAP，而是三个行为场景各自的precision和recall。在测试集上，我单独统计了以下数据：

如果你发现某类指标明显偏低，先别急着调模型，回到数据层面排查。比如压线低，可能是因为压线样本中车辆姿态多样，标注框边界不稳定。我后来把标注规范加强了，要求边界框必须覆盖到轮胎与地面接触点，压线的mAP提升了5个百分点。

模型评估完，要导出推理结果做可视化。直接用检测框可视化看不到违章时间信息，我习惯写一个自定义Draw函数，在图像上叠加时间戳、车辆ID和状态标签。这样能直观暴露问题，比如目标ID频繁跳变可能导致逆行方向判断错误。可视化工具这一步不能省，它比任何指标都更能反映实际效果。

4. 实战部署与推理优化

4.1 视频流接入与帧处理

部署的第一步是把摄像头视频流变成可供算法的连续图像。我常用两个协议：RTSP和RTMP。RTSP适合局域网监控，延迟低，但容易受网络波动影响；RTMP更适合公网流媒体。接入时要注意丢包引发的花屏问题，一般用FFmpeg做解码缓冲，掉帧时自动重连。

帧处理的流程分成三步：解码、缩放、预处理。我直接用OpenCV读取，但不要直接resize到640就送入网络，因为车辆识别对细节敏感。推荐先做LetterBox填充，保留宽高比，再把图像归一化到0-1之间。这个细节如果处理不对，推理精度会明显下降。

实际视频流往往包含25fps或30fps，但模型推理不一定能扛住这个帧率。我的策略是跳帧处理：每隔3到5帧跑一次检测，检测中间帧直接用跟踪算法基于上一帧结果预测。这样既保证了实时性，又保留了完整的轨迹信息。

4.2 违章逻辑判定

这一部分是把原始检测框变成违章事件的“业务层”，也是整个项目最容易出bug的地方。

违停判断逻辑：

• 设定一个静止区域，比如画面中固定的禁停区多边形。
• 检测框的中心点落在该区域内，并持续N秒没有移动。
• 车辆移动可以通过连续帧的检测框中心坐标差值判断，差值小于阈值则认为静止。
• 一旦超过时间阈值，生成一条违停记录。

注意摄像头抖动会造成静止判断失效，所以要加一个小的抖动容忍阈值，我设为5个像素。

压线判断逻辑：

• 提前在画面中设定两条虚拟线，即路线或停车线的边界。
• 当检测框左下角和右下角的坐标跨越虚拟线，即认为是压线行为。
• 需要区分轮胎是否真的与线相交，所以不仅看中心点，还要看框底边与线的距离。

我用线段和矩形的相交测试来判定，精确到每条轮胎。还有一个技巧是，压线不是瞬时动作，要连续3帧以上都检测到跨线才触发告警，避免一帧噪声造成误报。

逆行判断逻辑：

• 用跟踪算法（如DeepSORT或ByteTrack）维护每个车辆ID的历史轨迹。
• 在画面中定义行驶方向参考向量，例如从左到右为正方向。
• 统计车辆位置序列的位移方向，与参考方向比较。
• 连续多帧反向移动且速度超过阈值，判定为逆行。

这里我最常犯的错误是直接用检测框中心点变化作为位移，这样车急转弯时容易被误判。你至少要结合车道线方向做修正，或者限制在一个车道范围内判断。

4.3 性能优化与模型导出

模型导出这一步对实际部署影响非常大。我推荐先把PyTorch模型导出为ONNX，再用TensorRT转成engine文件。ONNX是通用格式，方便各种设备使用；TensorRT则能最大化利用英伟达GPU的推理能力。

以YOLOv5为例，导出TensorRT的流程：

python export.py --weights best.pt --include engine --device 0 --half

--half开启FP16精度，推理速度会比FP32快一倍以上，同时精度损失很小。在Jetson设备上，这可能就是决定能不能跑实时的关键。

除了模型本身，还有几个系统级优化点：

• 多线程解码，让GPU不用等待IO。
• 视频帧同时复制到CPU和GPU，减少数据传输等待。
• 检测和跟踪放流水线中，检测完成一帧立即送入跟踪线程，不阻塞采集流程。

我在4路1080P视频流下做了压测，使用YOLOv8m + TensorRT，总体延迟约120ms，单路视频稳定实时。如果只使用CPU推理，多路视频会迅速卡顿，所以有条件尽量上GPU。

5. 常见问题与避坑指南

5.1 误检和漏检问题排查

误检和漏检是开发中最常见的烦恼。我遇到的几种典型情况，以及对应的解决思路如下：

如果是漏检，最直接的办法是回放测试视频，找到漏检的那一帧，看目标大小、亮度和遮挡情况。不要只凭想象调网络结构，数据层面的问题占据七八成。

5.2 实时性卡顿与延迟排查

项目部署后最常被甲方吐槽的就是“画面卡住”。我排查时习惯优先检查CPU占用率和GPU利用率。如果CPU核数不够，FFmpeg解码就会成为瓶颈，可以改用硬解码（NVDEC）。

如果GPU利用率高但推理延迟大，说明模型太大或输入尺寸太大。我有时会把YOLOv8l换回YOLOv8m，把输入分辨率从1280降到960，延迟立刻降到可接受范围。违章识别不需要极致的小目标精度，平衡点和别的场景不一样。

此外，缓存队列不要设置太长。我曾把帧队列放到30帧，结果实际延迟远超感觉上的“实时”，画面看起来流畅但动作响应慢半拍。经验是把队列长度控制在5帧以内。

5.3 违章判定逻辑的边界情况

判定逻辑里的边界情况比想象中多。

违停方面，应急车辆停在禁停区应该豁免，但算法无法识别是否在作业。目前常见的做法是接入一个白名单模块，通过车牌识别排除特种车辆。这是规则层的事，模型本身管不到。

压线方面，压线变道和持续压线行驶所触发的规则应该不同，但很多同学没有区分。你在判定时应该记录压线的持续时间，超过3秒的判为长时间压线，小于1秒的则忽略，这样能大幅减少正常变道的误报。

逆行方面，非机动车和行人有时也会出现在画面里，如果模型把它们也识别为车辆，逆行判定就会错得非常离谱。所以类别中一定要有过滤条件，只对vehicle开头的类别启动逆行逻辑。

最后还要加一个“置信度门槛”。即使检测框本身置信度很高，如果错误地关联到一个ID，也可能触发误报警。我在业务层统一设置全局置信度阈值，比如检测框置信度低于0.4时直接丢弃，跟踪阶段低于0.6时不放行进入规则引擎。这个值可以根据你的现场误报情况微调，我一度调试到0.75，虽然让召回率略微下降，但换来的是极高的业务可用性。

在这个项目里，真正让违章识别从“实验室指标好看”到“生产环境靠谱”，靠的其实是规则层的快速迭代。根据我的实测，把精力平均分配到数据、模型和规则三层，比盲目加模型参数学到的经验要多得多。比如压线检测的优化瓶颈往往不在模型精度，而在虚拟线的几何精度；逆行检测的核心也不在车辆识别，而在跟踪轨迹的平滑度。希望这篇实战记录能帮大家少走一些弯路，尤其是那些准备把YOLO模型真正接进摄像头、跑通业务系统的朋友。