简介这份资源面向计算机视觉方向的毕业设计、课程设计学生及深度学习入门者提供一套基于YOLO的交通流量统计与违章行为检测完整工程。系统通过交通摄像头视频流进行目标检测识别车辆、行人等对象并统计流量同时支持压线、逆行、非法停车等违章行为的判定与证据留存适合作为智慧城市交通管理场景的实战参考。压缩包共119个文件约64.38MB以46个py源码与53个pyc编译文件为主体辅以3个pt权重、2个cfg与names配置、3个ui界面文件、4个sh与3个bat启动脚本以及sql建表脚本和说明文档工程结构完整、可直接运行调试。目前已有112人学习下载。读者可从中获得从模型加载、视频帧处理到流量统计与违章判定的完整实现思路并借助现成权重与配置快速复现检测效果为二次开发或论文撰写提供扎实基础。1. 从一段路口监控说起YOLO 做交通流量统计和违章检测到底靠不靠谱早高峰的十字路口摄像头架在信号灯杆上画面里同时有四十多辆车、十几辆电动车和一堆行人。你要从这段视频里数清楚每个方向过了多少车、哪辆车压了实线、哪辆闯了红灯——这就是「基于 YOLO 的交通流量统计、违章行为检测」要解决的事。它不是一个模型能搞定的而是「检测 跟踪 逻辑判定」三件事串起来的流水线。YOLO 负责每帧把车、人、车牌框出来跟踪算法负责给每个目标一个稳定 ID业务逻辑再根据轨迹和车道线判断有没有违章。适合谁做有 Python 基础、能跑通 YOLO 推理、手头有路口视频或 RTSP 流的同学。新手照着步骤能跑通最小闭环熟手能在这套框架上换模型、调参数、接自己的业务规则。下面把我实际落地时踩过的路讲清楚。2. 拆解这条流水线检测、跟踪、判定各干什么2.1 为什么不能只靠 YOLO 一帧一帧检测很多人第一反应是YOLO 每帧检测出车数一数不就行了实际跑起来立刻翻车。同一辆车在连续帧里会被反复检测到你按帧计数一辆车能给你数出几百次。而且 YOLO 只告诉你「这一帧这里有个车」它不知道这辆车上一帧在哪、下一帧去哪更不知道它有没有越过停止线。所以流量统计的核心不是检测是「去重」和「跨帧关联」这就是跟踪算法要干的事。常见做法是 YOLO 检测 ByteTrack 或 BoT-SORT 跟踪。ByteTrack 的思路很直接把检测框按置信度分成高分和低分两组先用高分框和已有轨迹匹配剩下的低分框再去匹配没配上对的轨迹。这样即使某帧车被遮挡、置信度掉到 0.3只要它还在轨迹就不会断。我一般用 Ultralytics 的 YOLOv8 或 YOLO11它内置了 ByteTrack 和 BoT-SORT一行配置就能开跟踪省得自己搭。违章判定则完全是业务逻辑层的事。闯红灯需要知道信号灯相位 车辆轨迹是否越过停止线压线需要车道线坐标 车辆底部中心点是否跨线逆行需要方向向量和车道规定方向比对。这些都不是 YOLO 能直接输出的必须自己写规则。所以整条流水线的分工是YOLO 管「看到什么」跟踪管「谁是谁」规则管「违不违规」。2.2 最小可跑通的代码骨架先装环境。Ultralytics 把检测和跟踪都封装好了一条命令搞定pip install ultralytics opencv-python numpy然后是最小推理 跟踪的脚本from ultralytics import YOLO import cv2 # 加载模型n 版最轻量适合先跑通 model YOLO(yolov8n.pt) # 打开视频源可以是文件也可以是 RTSP 地址 cap cv2.VideoCapture(intersection.mp4) # 用 ByteTrack 做跟踪persistTrue 保证帧间轨迹连续 while cap.isOpened(): ret, frame cap.read() if not ret: break # classes[2,3,5,7] 只检测 car/motorcycle/bus/truck过滤行人干扰 results model.track(frame, persistTrue, trackerbytetrack.yaml, classes[2, 3, 5, 7], conf0.4, iou0.5) annotated results[0].plot() cv2.imshow(traffic, annotated) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()这段代码的逻辑说明model.track()是 Ultralytics 封装的检测 跟踪一体接口persistTrue是关键参数它让跟踪器在帧与帧之间保持状态不加这个每帧都会重新初始化轨迹全断。classes参数用 COCO 的类别索引过滤2 是 car、3 是 motorcycle、5 是 bus、7 是 truck这样行人、交通灯这些类别不会进来干扰计数。conf0.4是置信度阈值路口场景车多遮挡多设太高会漏检设太低误检多0.4 是我在几个路口视频上试出来比较平衡的值。iou0.5控制 NMS 的合并力度车挨得近的时候这个值影响很大。跑通之后你会看到每个车被框住并且带一个 ID这个 ID 就是后续统计和判定的基础。2.3 流量统计的计数逻辑怎么写有了稳定 ID计数就简单了给每条车道画一条虚拟检测线当某个 ID 的轨迹从线的一侧移动到另一侧时计数加一同时记录这个 ID 已经计过数避免来回抖动重复计。counted_ids set() line_y 400 # 虚拟线在画面中的 y 坐标 lane_counts {up: 0, down: 0} def check_cross(track_id, prev_cy, curr_cy): if track_id in counted_ids: return # 从下往上穿线 if prev_cy line_y curr_cy: lane_counts[up] 1 counted_ids.add(track_id) # 从上往下穿线 elif prev_cy line_y curr_cy: lane_counts[down] 1 counted_ids.add(track_id)参数说明line_y要根据你的摄像头视角标定一般选在画面中段、车辆行驶最稳定的位置太靠上或靠下都会因为透视变形导致计数偏差。counted_ids这个集合是防重复计数的后悔药没有它一辆车压线来回晃能给你计好几次。方向判断用前后帧的中心点 y 坐标比较简单但有效。如果要分车道统计就把画面按 x 坐标切成几个区域每个区域一条独立的线和计数器。3. 违章行为检测规则引擎怎么搭3.1 闯红灯判定的三个必要条件闯红灯不是「车在红灯时动了」这么简单。我实际做的时候判定条件必须同时满足三条第一当前信号灯相位是红灯第二车辆轨迹越过了停止线第三越过停止线的那一刻是红灯。缺一个都会误判。信号灯相位怎么拿两种方式如果路口信号机有开放接口直接读相位最准没有的话就用 YOLO 检测信号灯颜色但这条路玄学成分大晚上、逆光、灯被遮挡都会翻车。我一般建议能接信号机就接实在不行再上视觉方案而且要加多帧投票连续五帧里至少四帧判定为红才认。停止线就是画面里的一条线段和流量统计的虚拟线类似但位置在停止线实际位置。判定逻辑是跟踪某个 ID记录它上一帧和当前帧的中心点如果两帧之间跨过了停止线且此时相位是红灯就标记为闯红灯候选再连续跟踪几帧确认车辆确实继续前行而不是压线后停下。def check_red_light(track_id, prev_point, curr_point, stop_line, signal_state): if signal_state ! red: return False if track_id in red_light_confirmed: return False # 线段相交判断轨迹线段是否跨过停止线 if segments_intersect(prev_point, curr_point, stop_line): red_light_confirmed.add(track_id) return True return Falsesegments_intersect是标准的线段相交判断用向量叉积实现。red_light_confirmed同样是防重复。注意这里用的是车辆底部中心点而不是框中心因为框中心会随车辆大小变化底部中心更贴近车辆实际位置。3.2 压线、逆行、违停的判定差异压线判定和闯红灯类似区别在于参照线变成了车道线而且车道线往往是斜的需要标定每条线的两个端点坐标。逆行判定不看线看方向给每条车道定义一个允许行驶方向向量车辆连续多帧的位移方向如果和允许方向夹角超过 90 度就判逆行。违停更简单某个 ID 在指定区域内连续 N 秒位移小于阈值就判违停N 一般设 10 到 30 秒看路段规定。这几种违章的共同点是都需要先标定区域或线再基于轨迹做逻辑判断。标定这件事没有捷径每个摄像头视角不同必须手动标或者做一个简单的标定工具。我一般用 OpenCV 的鼠标回调写个几十行的小工具点几下把线和区域存成 JSON后面加载直接用。3.3 参数怎么调一份实际用的配置表参数作用建议值调整方向conf检测置信度阈值0.4漏检多就降到 0.3误检多就升到 0.5iouNMS 合并阈值0.5车密集时降到 0.45稀疏时升到 0.6track_high_thresh跟踪高分阈值0.5轨迹断得多就降到 0.4track_buffer轨迹保留帧数30遮挡严重就加到 50line_y计数线位置画面中段根据透视调整避免车头车尾跨线抖动confirm_frames违章确认帧数5误报多就加到 8漏报多就降到 3这张表是我在几个路口视频上反复试出来的起点值不是万能公式。每个场景光照、角度、车流密度都不一样必须拿实际视频跑一遍看效果再微调。调参这件事没有银弹就是看输出、找问题、改一个参数、再看输出。4. 避坑与排查那些让我加班到凌晨的问题4.1 同一辆车被分配了多个 ID现象计数结果比实际车流量多出两三成看可视化发现同一辆车在画面里 ID 跳变。原因通常是遮挡导致轨迹中断跟踪器重新分配了新 ID。解决办法把track_buffer从默认 30 加到 50 甚至 70让轨迹在遮挡期间保留更久同时把track_high_thresh适当降低让低置信度检测也能参与匹配。如果还不行就在业务层做 ID 合并两个 ID 的轨迹在时空上连续且距离很近就合并成一个。4.2 夜间和逆光场景检测大面积漏检现象白天跑得好好的一到晚上或者下午逆光车都检测不到。原因YOLO 在 COCO 上训练夜间样本少加上逆光时车辆轮廓和背景对比度低。解决办法短期用 CLAHE 做图像增强再送进模型能救回一部分中期收集自己场景的夜间数据做微调哪怕只标几百张效果提升也很明显长期考虑换用对低照度更友好的模型或者加红外补光。4.3 计数线附近车辆抖动导致重复计数现象一辆车在计数线附近走走停停被计了三四次。原因车辆中心点在线的两侧来回跳。解决办法加一个滞回区间比如中心点越过线下方 10 像素才算穿线回到线上方 10 像素才重置状态同时counted_ids集合要保留足够长时间别过早清理。4.4 RTSP 流延迟累积导致实时性越来越差现象跑着跑着画面延迟从 1 秒变成十几秒。原因推理速度跟不上视频帧率帧在缓冲区里堆积。解决办法用多线程把拉流和推理分开拉流线程只保留最新帧旧帧直接丢或者用cv2.CAP_PROP_BUFFERSIZE把缓冲区设成 1。如果还跟不上就降分辨率或者降帧率别硬扛。4.5 违章判定误报太多被业务方投诉现象明明没闯红灯的车被判闯红灯。原因信号灯相位读取有延迟或者视觉识别出错导致红灯时刻判断错误。解决办法信号灯相位加多帧投票和延迟补偿违章判定加二次确认候选违章后继续跟踪几帧看车辆行为是否符合违章特征所有违章记录保存前后各几秒的视频片段方便人工复核和申诉。5. 进阶把单路方案推到多路和边缘设备单路跑通之后下一步通常是多路。这里有个热词值得聊T4 1080p25 帧每秒用 TensorRT YOLO 640 分辨率检测能支持多少路。我实际测过的数据是T4 上用 TensorRT 加速 YOLOv8n 在 640 分辨率下单帧推理大概 3 到 5 毫秒理论上算下来能跑几十路但实际瓶颈不在推理在解码和跟踪。1080p25 的流解码一路就要占不少 CPU跟踪算法也是 CPU 大户。所以真实能跑的路数往往是推理能力的零头我一般按 8 到 12 路来规划留足余量。优化路径有几条一是导出 ONNX 再用 TensorRT 加速Ultralytics 支持直接model.export(formatengine)但要注意导出时的动态 batch 和分辨率设置二是把跟踪也放到 GPU 上用 GPU 版的 ByteTrack 实现三是多路共享一个模型实例batch 推理但 batch 太大会增加延迟要权衡。边缘设备上则相反算力有限得用 YOLOv8n 甚至更小的模型分辨率降到 416 或 320帧率抽到 10 帧先保证能跑再谈精度。验证方法上我习惯用一段标注好的视频做回归测试跑完统计结果和人工计数比对误差控制在 5% 以内算合格违章检测则看召回和误报宁可漏报也别误报因为误报的代价是人工复核成本。每次改参数或换模型都拿同一段视频跑一遍看指标有没有退化。这个习惯帮我省了很多次上线后才发现问题的尴尬。最后说个我自己的教训一开始我总想一步到位把精度调到最高结果模型越换越大速度越来越慢业务方等不及直接换了方案。后来才明白交通场景里稳定和实时比极致精度重要得多先用小模型跑通闭环再根据实际 badcase 逐步优化才是能落地的节奏。希望帮到你。本文还有配套的精品资源点击获取
