简介面向智慧城市交通管理场景的Python/OpenCV项目提供一套自动交通红灯违规检测系统的完整实现方案。系统由对象检测器与对象跟踪器协同工作用于实时锁定红灯期间通行车辆并精准标识违章位置输出可准确区分所有违规车辆辅助交通管理部门快速定位适合具备一定计算机视觉基础的开发者参考、复现与二次开发。资源包为ZIP压缩格式整体约76.31MB平台暂未列出文件总数与类型明细但代码、运行说明及优化建议均包含在压缩包内。已有302人学习浏览。项目描述显示掩膜部件运行精度约85%级联模型仍处于测试模式附带的运行代码可为算法调优提供明确起点结合检测与跟踪的联动设计读者可深入理解目标检测、轨迹保持、违章判定及结果输出的完整流程也可借此评估模型瓶颈并展开针对性改进。1. 这个系统到底在解决什么问题检测出车不等于找出违章路口摄像头固定不动同一辆车在画面里走走停停傍晚光线一顿一顿地变化这些干扰都不是“识别出车辆”这个动作能解决的。TrafficviolationDetectionUsingOpenCV 这个方向的实际价值在于把单帧的车辆检测和跨帧的车辆跟踪做成一条流水线让系统能回答“画面里这辆车是不是刚才那辆它有没有在红灯期间越过停车线”。如果你是做智慧城市里的违章留证难点从来不在“抓到一辆车”而在“持续咬住一辆车”。这套方案适合两类人一类是想把课程设计做成完整可演示工程的开发者另一类是给园区、出入口低成本搭取证系统的工程师。下文按组件选型、流水线集成、违章判定、避坑和调参五步展开照做就能跑通。2. 检测器与跟踪器怎么分工OpenCV 红灯违规检测的时间关联基础这个系统把检测器和跟踪器“集成”在一起很多人一开始想不明白检测器既然能框出车为什么还要跟踪器。原因在于检测器是静态的它只回答“这一帧里车在哪”不回答“这一帧的框是上一帧的哪辆车”。违章判断需要的是时间维度上的连续信息这辆车是什么时候出现在停车线前的它有没有在红灯期间持续移动它最终停在了哪个位置。跟踪器补上的正是这段跨帧关联这也是标题里“精确区分违规车辆”这句话的落点。2.1 检测器负责“这一帧车在哪里”空间定位的最小实现OpenCV 里做车辆检测最快能跑通的方案不是深度学习而是背景减除。固定摄像头下背景几乎不动运动的车辆会作为前景突出来。代码只有几行import cv2 cap cv2.VideoCapture(intersection.mp4) back_sub cv2.createBackgroundSubtractorMOG2( history500, varThreshold36, detectShadowsTrue) while cap.isOpened(): ret, frame cap.read() if not ret: break fg back_sub.apply(frame) # MOG2 会把阴影标成灰色 127这里只保留纯前景避免阴影干扰后续判断 _, fg cv2.threshold(fg, 200, 255, cv2.THRESH_BINARY) contours, _ cv2.findContours(fg, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) for c in contours: area cv2.contourArea(c) if area 2500: # 过滤掉行人、树叶晃动等小目标 continue x, y, w, h cv2.boundingRect(c) cv2.rectangle(frame, (x, y), (x w, y h), (0, 255, 0), 2)逻辑说明先做背景建模再把前景掩膜二值化最后用轮廓外接矩形作为车辆框。这套方案在车辆少、背景干净的路口表现不错而且完全依赖 OpenCV 内置功能没有模型文件依赖。如果场景复杂、车流密集把contours这一整段替换成 OpenCV dnn 模块加载你已有的检测模型即可主流程不用动。参数说明history500是背景建模参考的历史帧数值越大越能适应缓慢光照变化但车辆久停后容易被“吸收”进背景varThreshold36是前景判定阈值调大误报少、小目标丢失调小对小轿车更敏感、夜间更容易飘area 2500是轮廓面积下限视频分辨率越高这个值要跟着放大1080p 下我一般取 3000 到 5000。2.2 跟踪器负责“这一辆还是那一辆”时间关联的核心 API检测器给出的是零散的框跟踪器负责把这些框串成轨迹。OpenCV 的目标跟踪 API 使用方式非常固定创建、初始化、逐帧更新三步# 不同 OpenCV 版本 API 位置不同做一层兼容 try: tracker_create cv2.TrackerKCF_create except AttributeError: tracker_create cv2.legacy.TrackerKCF_create trackers {} def create_tracker(frame, box, tid): t tracker_create() t.init(frame, box) trackers[tid] {tracker: t, age: 0} for tid, item in list(trackers.items()): ok, box item[tracker].update(frame) if ok: item[age] 0 # box 是跟踪器预测的新位置直接用于后续判定 else: item[age] 1 # 连续失败多帧后再删除避免短暂遮挡就丢 ID逻辑说明update返回的box是跟踪器根据目标外观和运动模型预测出的新框即使检测器这一帧没有输出跟踪器也能给出一个位置这就是“补位”作用。age字段记录连续丢失帧数常见做法是连续 10 帧失败才删轨迹否则目标只是被短暂遮挡重新出现后还能接上。参数说明这里的核心参数不在跟踪器本身而在删除阈值。age设太小公交车挡一下后面的车就被当成新车设太大已经驶出画面的车留下的轨迹会干扰判定。25fps 视频里我一般把删除阈值放在 10 到 15 帧之间折半秒左右的容忍度。2.3 固定监控场景下选 KCF 还是 CSRT一张表说清楚OpenCV 内置多个跟踪器红灯违章场景真正值得比较的只有三个其余要么太慢、要么太容易漂。固定机位、车辆目标小且运动平滑是最理想的跟踪条件。跟踪器速度精度适合场景MOSSE极快较低目标极小、只需要位置不需要尺度的场景KCF快中等多车道、车辆多的路口首选CSRT较慢高单车道特写、需要稳定长轨迹时我一般会先用 KCF 跑通全流程因为路口车辆数量多CSRT 在每个目标上都跑会明显掉帧。KCF 的代价是尺度估计不准车辆由远及近时框会偏大或偏小但只要底边中心点稳定对停车线判定影响不大。CSRT 只在单车道、摄像机距离近、需要精确留证时换上去。要提醒的是跟踪器内部参数基本不用改真正决定成败的是后面的关联策略和判定状态机。3. 把检测和跟踪集成成流水线从视频帧到停车线越线判断的代码骨架组件选好之后下一步是把它们组装成一条连续处理的流水线。这里的核心设计决策是检测器不需要每帧都跑。固定摄像头视野里车辆运动是平滑的跟踪器有能力在几帧内维持目标位置而检测器每帧全量跑在低算力设备上是浪费。常见做法是检测器每 5 帧跑一次中间帧完全交给跟踪器补位检测结果再用来纠正跟踪框的漂移。3.1 主循环骨架检测器降频、跟踪器补位DETECT_EVERY_K_FRAMES 5 frame_id 0 while cap.isOpened(): ret, frame cap.read() if not ret: break frame_id 1 gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) # 傍晚、树荫场景建议加 CLAHE画面正常时可以注释掉 gray cv2.createCLAHE(clipLimit2.0, tileGridSize(8, 8)).apply(gray) if frame_id % DETECT_EVERY_K_FRAMES 0: dets detect_vehicles(frame, gray) match_detections_to_trackers(frame, dets) else: update_all_trackers(frame) judge_violations(frame, frame_id) cv2.imshow(traffic violation detection, frame)逻辑说明函数名各自对应一块独立逻辑detect_vehicles负责跑检测模型或背景减除match_detections_to_trackers用 IoU 把新检测框和既有轨迹关联起来update_all_trackers在检测间隔帧里纯跑跟踪器judge_violations是把停车线、红灯状态和车辆位置放在一起判定的函数。把判定函数独立出来是因为调试时最常改的就是它不要让判定逻辑散在主循环里。关联阶段有一个必须处理的细节检测框和既有跟踪框的 IoU 超过阈值就认为是同一辆车用检测框去修正跟踪框没有匹配上的检测框才创建新轨迹。iou_thresh我一般取 0.3 到 0.4取太高会导致同一辆车被重复创建取太低会把并排车辆合并。这不是玄学是把误报和轨迹断裂做一次权衡。3.2 停车线标定用鼠标点两个点换一条可靠的参考直线停车线在画面里是一条斜线的概率远大于水平线。摄像机安装在立杆侧面时停车线在图像里是从左上到右下的斜线直接比 y 坐标必然误判。正确做法是在画面上点出停车线的两个端点拟合一条直线以后计算车辆到底边中心点到这条直线的带符号距离。pts [] def on_mouse(event, x, y, flags, param): if event cv2.EVENT_LBUTTONDOWN: pts.append((x, y)) cv2.circle(param, (x, y), 3, (0, 0, 255), -1) cv2.imshow(calibrate, frame) cv2.setMouseCallback(calibrate, on_mouse, frame) # 等待点完两个点后用下面公式构造直线 Ax By C 0 def line_from_two_points(p1, p2): dx p2[0] - p1[0] dy p2[1] - p1[1] # A, B, C 满足 A*x B*y C 0方向由 p1 - p2 决定 return dy, -dx, dx * p1[1] - dy * p1[0] def signed_distance(px, py, A, B, C): return (A * px B * py C) / (A ** 2 B ** 2) ** 0.5逻辑说明line_from_two_points返回直线系数signed_distance算出的距离带正负号这个符号代表车辆在停车线的哪一侧后面状态机要靠它判断“越线前”和“越线后”比单纯算绝对值有用得多。参数说明标定只需要两个点但选点位置尽量靠近车道中间不要点在线的最边缘。标定结果存进配置文件换摄像头或调整角度后必须重新标这是这套系统里最容易忽略的一次性操作。停车线在画面外的情况也要考虑标定时视角里必须能看到停车线否则整个判定无从谈起。3.3 红灯时段怎么判HSV 颜色检测与信号相位配置两种做法判定闯红灯的前提是知道当前信号灯是红灯。最省事的做法是从信号机系统直接读相位数据但很多落地场景拿不到这个接口。退一步的常用做法是检测画面中的红灯区域离线录像也能用。def is_red_light(frame, roi): # roi 是信号灯在画面中的区域提前标定好 hsv cv2.cvtColor(frame[roi], cv2.COLOR_BGR2HSV) # 红色在 HSV 中跨两个区间必须取并集 mask1 cv2.inRange(hsv, (0, 120, 120), (10, 255, 255)) mask2 cv2.inRange(hsv, (170, 120, 120), (180, 255, 255)) red_pixels cv2.countNonZero(mask1 | mask2) return red_pixels 30逻辑说明把信号灯区域裁剪出来转 HSV统计红色像素数量。两个区间是处理红色的关键坑点HSV 色相环里红色跨越 0 度和 180 度边界只查一个范围会漏掉一半红灯状态。参数说明roi建议在标定步骤里用鼠标框出来越小越不容易被车尾灯干扰。red_pixels 30这个阈值跟 ROI 大小相关ROI 越大阈值也要提高否则黄灯和红灯同时亮时会把黄灯误判成红灯。备选做法是把信号灯周期写进配置文件比如 60 秒周期、前 30 秒红灯配合视频时间戳判断但只适用于信号灯固定周期且摄像机时间同步的场景。4. 红灯违章判定状态机越线、持续前进与唯一 ID 三条规则缺一不可检测和跟踪只是感知层真正的核心在判定逻辑。闯红灯抓拍行业里有“三张照片”的标准车前轮压线一张、车辆到达路口中间一张、车辆到达对面路口一张。这个标准背后的思路是不仅要证明车辆越过停车线还要证明车辆在红灯期间持续移动。落到代码里就是一个由越线状态、持续前进帧数、唯一轨迹 ID 组成的状态机。4.1 用带符号距离判断越线为什么不能直接比 y 坐标车辆框的底边中心点最接近车辆与地面的接触位置用它去算和停车线的距离。这里不能直接比较 y 坐标是因为画面里停车线是斜的而且大货车和小轿车的中心点高度差异会导致巨大的透视误差。底边中心点受车型影响最小是固定机位下最稳的参考点。state {} def bottom_center(box): x, y, w, h box return x w / 2, y h def update_cross_state(tid, box, A, B, C): px, py bottom_center(box) d signed_distance(px, py, A, B, C) if tid not in state: state[tid] {phase: free, progress: 0} s state[tid] if s[phase] free and d 0: # 负距离表示底边已越过停车线进入待确认状态 s[phase] crossed s[cross_frame] frame_id s[progress] 0逻辑说明signed_distance算出的d为正时车辆在停车线外侧为负时车辆已越过停车线。状态从free切到crossed只说明“压线了”还不能定罪。进入crossed后记录起始帧号方便后面统计持续移动的帧数。参数说明距离的符号方向由标定时的两个点顺序决定标定时从线的一侧点向另一侧方向反了会把所有判断颠倒。建议在标定后立刻打印一个已知位置车辆的距离值人工核对符号是否正确这一步能省掉后面一小时的排查时间。4.2 持续前进确认用“三张照片”逻辑防误报压线停车和闯红灯在画面里都是“越过停车线”区别在于前者没有持续前进。进入crossed状态后必须连续若干帧观察到车辆继续向前移动才升级为violating。HOLD_FRAMES 5 FORWARD_DIST 30 def confirm_violation(tid, box, A, B, C): s state[tid] if s[phase] ! crossed: return False px, py bottom_center(box) d signed_distance(px, py, A, B, C) if d -FORWARD_DIST: s[progress] 1 else: s[progress] 0 if s[progress] HOLD_FRAMES: s[phase] violating return True return False逻辑说明FORWARD_DIST是越过停车线后至少要前进的像素距离30 像素在 1080p 画面里大约是半个车身宽的量级。HOLD_FRAMES是连续满足前进条件的帧数25fps 下 5 帧约 0.2 秒。这两个条件一起作用压线后原地等待的车辆会被滤掉因为它的progress会不断清零。参数说明FORWARD_DIST设置太小车身晃动就会误判为前进设置太大车速快的车辆可能只被拍到一个模糊框就冲过了判定距离。分辨率越高的画面这个值可以越大。HOLD_FRAMES也需要和检测频率配合如果检测器降频到每 5 帧跑一次中间帧靠跟踪器补位那这里的计数依然每帧都在累加不受影响。4.3 结果输出把违章车辆的位置和轨迹绑到唯一 ID 上确认违章后要做两件事记录车辆的唯一 ID 和轨迹信息保存违章截图。唯一 ID 的价值在于同一辆车在画面里多次出现时系统能区分这是新违章还是重复记录。records [] def record_violation(tid, box, frame, frame_id): x, y, w, h [int(v) for v in box] px, py bottom_center(box) records.append({ track_id: tid, violation_frame: frame_id, position: (px, py), box: (x, y, w, h), snapshot: fviolation_{tid}_{frame_id}.jpg }) cv2.imwrite(records[-1][snapshot], frame)逻辑说明每条记录包含轨迹 ID、违章帧号、底边中心位置和车辆框以及落地保存的截图。track_id是跟踪器维持的轨迹编号用来做去重即使同一辆车在一段视频里被判定多次也只会保留第一次或最近一次的记录。这里有个容易犯的错只保存截图不保存轨迹数据。截图只能证明“有一辆车在画面里”不能证明“这辆车在红灯期间持续前进”。把轨迹点序列一起落盘后续人工复核时有据可查对接智慧城市平台时也方便统一格式。输出位置如果要做成真实地理坐标需要在标定阶段额外做一个单应变换矩阵把图像坐标映射到路面坐标这一步不展开讲但要知道有这层需求。5. 落地避坑这套方案最容易翻车的 5 个环节与排查方法这套方案从原型到实跑最大的感受是检测和跟踪的代码只要结构清晰半天就能跑通真正消耗时间的是各种边界情况。下面五个坑每个都会直接导致误报或漏报按影响程度从高到低排。5.1 跟踪器短暂丢失后被当成新车同一辆车被判两次现象一辆车在路口被公交车挡了两秒重新出现后系统生成了新 ID原来的轨迹状态全部清零。如果它之前已经进入crossed状态这次清零可能导致同一次违章被记录两次或者压根没记录到。原因跟踪器update返回False后立即删除了轨迹没有给“短暂遮挡”留缓冲。解决引入age机制连续 10 到 15 帧失败才删轨迹同时在新轨迹创建前拿检测框和所有既有轨迹做一次 IoU 匹配IoU 超过 0.3 就复用了。我见过最典型的翻车现场是把删除阈值设成 1结果一辆大货车过去身后所有小车全部换新 ID。5.2 傍晚之后检测率断崖式下跌违章漏报现象白天检测率接近 95%太阳落山后一小时开始明显下降路灯和车灯造成大面积误检树影里的小轿车直接消失。原因背景减除的阈值是固定的低照度下前景和背景对比度变小同时车灯会产生高亮拖尾两者都让掩膜质量变差。解决在取帧后先做 CLAHE 增强对比度把背景减除的学习率从默认值调低到 0.005 左右让模型慢一点适应突然的光照变化。如果场景里夜间车流占比高建议直接切到 dnn 检测方案背景减除在夜间场景的鲁棒性极限就在这里。5.3 车辆底边被遮挡导致越线误判压线停车被当成闯红灯现象行人、非机动车或前车尾部挡住了车辆框的底边跟踪框跳动几个像素后底边中心点突然越过停车线系统立刻进入crossed状态。原因直接用跟踪器输出的原始框底边做判断没有对位置做平滑。解决对底边中心点的移动距离做一维平滑连续 3 帧的位移都超过阈值才认为真正越线或者在进入crossed状态前要求连续 2 帧满足越线条件而不是单帧触发。这个坑在车流密集的路口特别容易出现单帧触发的设计无论如何都要改掉。5.4 大车挡住小车跟踪器跟着大车跑了现象公交车经过后系统把公交车后面冒出来的小轿车误当成公交车轨迹的一部分ID 没有换但框直接套在小轿车上。原因大车的框在检测阶段把周围目标全部覆盖跟踪器在下一帧匹配时把就近的新目标吸收了。解决在匹配阶段加入宽高比约束新检测框和旧跟踪框的宽高比差异超过 0.5 就不允许匹配同时限制跟踪框每次更新的最大位移防止一次性跳到远处的目标。大车驶过后的那几帧宁可让旧轨迹短暂丢失也不要让它错误吸收新目标。5.5 右转车道被误判为直行闯红灯先查这三处现象红灯亮时右转车道车辆被系统记录为违章但实际路口右转不受信号灯控制。原因系统只判断了“越线 持续前进”没有区分车道行为。解决第一把画面按车道划分成多个 ROI右转车道单独配置豁免标记第二在判定状态机里增加一个横向位移判断当车辆底边中心的横向位移超过竖直位移时判定为转弯行为而不是直行闯红灯第三确认红灯检测的 ROI 是否覆盖到了该车道对应的信号灯多车道路口信号灯可能不止一个截错 ROI 会造成红灯状态判断错误。这三处都查过仍然误报的路口就要回到停车线标定看是不是线画歪了。6. 把调参从玄学变成可验证的离线回放与三组核心参数的标定这套系统最容易被诟病的就是参数靠猜。与其上线后反复看录像人工核对不如先把一段含真实违章的录像存下来写一个离线回放脚本把每组参数跑出来的结果和人工标注结果对比让数据说话。6.1 离线回放脚本让每一组参数跑出可对比的指标def evaluate(video_path, config): tp fp fn 0 annotations load_manual_annotations(video_path) preds run_pipeline(video_path, config) for pid in preds: if pid in annotations: tp 1 else: fp 1 for aid in annotations: if aid not in preds: fn 1 return tp, fp, fn configs [ {min_area: 2500, forwad_dist: 30, hold_frames: 5}, {min_area: 3000, forwad_dist: 40, hold_frames: 8}, ] for cfg in configs: tp, fp, fn evaluate(sample_1.mp4, cfg) precision tp / (tp fp) if tp fp else 0 recall tp / (tp fn) if tp fn else 0 print(cfg, precision:, precision, recall:, recall)逻辑说明离线回放的核心价值在于不用重启摄像头服务就能对比任意一组参数。人工标注只标违章车辆的车牌或出现时段预测结果按轨迹 ID 对齐。precision衡量误报水平recall衡量漏报水平两者都要看。6.2 参数标定顺序与经验区间表调参不要一次性改多个变量顺序我一般是固定的先定min_area确保检测器不多不漏再定HOLD_FRAMES这一步决定误报大头最后定FORWARD_DIST和越线触发帧数微调边界。参数经验区间说明min_area2500 ~ 5000 像素1080p 画面按最远车道的小轿车轮廓估算越线触发帧数2 ~ 3 帧低于 2 帧单帧抖动就会误报HOLD_FRAMES5 ~ 10 帧25fps 下对应 0.2 ~ 0.4 秒FORWARD_DIST30 ~ 50 像素按停车线到路口中心距离折算轨迹删除帧数10 ~ 15 帧短遮挡不丢 ID长遮挡不留残影我的习惯是参数改动先写进配置文件再跑一遍离线回放确认召回率没有掉 3 个点以上才允许上线。误报多一张截图还能靠人工筛漏报一辆违章车会把整套系统的公信力打掉。希望帮到你。本文还有配套的精品资源点击获取
