基于YOLOv8的路口信号灯识别与通行规则判定方案

简介Python基于YOLOv8的路口交通信号灯通行规则识别模型及算法源码主要面向计算机、通信、人工智能、自动化等相关专业的学生、教师或从业者可用于毕业设计、课程设计或实际交通场景中的信号灯检测与通行规则判断。项目以YOLOv8为检测核心配套完整算法源码与文档说明能帮助使用者快速搭建识别流程理解从图像输入、目标检测到规则输出的实现思路。压缩包共17个文件以11个Python脚本为主涵盖主程序、数据处理、检测与预测等模块另含YAML配置文件、README说明文档、依赖列表及示例图片整体约705KB结构紧凑清晰。目前已有117人浏览学习具备一定参考价值。项目为个人毕设答辩评审达98分代码经过调试测试确保可运行尤其适合初学者对照学习YOLOv8的工程化实现也可在现有基础上修改算法或扩展功能完成个性化任务。1. 路口信号灯识别不是“检测到灯”就完事这套方案解决的是通行规则红灯亮了检测出红灯只是第一步。真正让交通视觉项目从“能跑demo”走向“能落地”的是检测之后的那条判断链这个灯是圆盘灯还是箭头灯当前灯色对应哪几个车道左转待转区能不能进倒计时剩3秒要不要起步这些在交规里一句话的事落到代码里就是一连串状态判断。Python 基于 YOLOv8 的路口交通信号灯通行规则识别模型及算法源码正是把“目标检测”和“规则推理”串成一个完整闭环的工程方案而不是给你一个光秃秃的检测权重。适合谁做毕业设计、做车路协同路侧感知、或者要在 RK3588 这类边缘盒子上做信号灯识别的工程师。你能从这套思路上直接拿到可复现的检测管线、可改写的规则判定逻辑以及藏在数据标注和训练参数里的那些坑。2. 为什么选 YOLOv8 扛信号灯检测精度、速度与改造成本的三方权衡2.1 信号灯检测的任务本质小目标、多状态、强时序路口的信号灯检测和通用目标检测有个非常不一样的地方灯体在画面里往往只占几十到一两百像素属于典型的小目标。用 YOLOv8 的P5模型输入 640 像素时8 倍下采样的特征图已经能覆盖大多数灯体但如果你想在远端路口相机距灯组 80 米以上也能稳定召回就得考虑P6模型或增大输入分辨率。这是选型的第一道分水岭不是哪个模型先进就选哪个而是你的相机安装位置决定了最小可检测尺寸。第二道分水岭是状态粒度。信号灯有红、黄、绿、红黄同亮、箭头左、箭头直、箭头右、倒计时数字等多种状态。有些方案把这些状态全部列为独立类别比如red_circle、green_arrow_left让检测头直接分类另一种方案是只检测灯组区域再把灯组裁剪出来交给分类网络判断颜色和方向。YOLOv8 的单阶段结构天然适合前者因为它在设计上就用anchor-free的解耦头同时输出类别和边框多类别多状态就是多几个输出维度的事不会像两阶段方案那样把“检测框质量”和“状态分类”割裂开。我们用 YOLOv8 而不是 YOLOv5 或 RT-DETR核心理由是它在同等精度下训练成本低、部署生态全而且ultralytics仓库把训练、验证、导出、推理封装得足够干净改数据加载和输出头比改 v5 的models/yolo.py省太多事。2.2 一个被低估的优点YOLOv8 的模型结构便于做输出后处理YOLOv8 的 Head 部分把分类分支和回归分支解耦每个分支独立卷积后输出。这个结构带来的直接好处是在做信号灯规则判定时可以直接从推理结果里同时拿到类别id、置信度和框坐标三者天然对齐。比如同一帧里检测到green_arrow_left和red_circle你需要用坐标判断它们是否属于同一个灯组——如果两个框的中心点距离小于阈值说明这个路口既有圆盘红灯又有左转箭头绿灯此时左转车辆可通行直行车辆停止。这种“同框多灯”场景在真实路口非常常见。另一个被忽略的点是ultralytics的predict方法返回的是一个Results对象列表里面包含boxes.cls、boxes.conf、boxes.xyxy但类别名是字符串列表坐标是 Tensor。很多新手在这步直接拿class_id去查names字典结果发现names是{0: red}这种形式而boxes.cls是tensor([0.])类型不匹配导致if cls red永远不成立。这种细节在模型推理里不算错但放到规则判定里就是“漏判”或“误判”。我的习惯是所有后处理代码里统一转成int和float并且用字典映射做类别名到判定逻辑的桥接不裸写字符串比较。2.3 模型选型对比YOLOv8s 是路口场景的甜点位我把几个常见选项放在一起比较方便你按算力选模型配置参数量640输入下的mAP路口场景表现部署算力要求YOLOv8n3.2M37.3小目标召回率偏低远端灯组易漏RK3588/NPU可实时YOLOv8s11.2M44.9权衡点近中远距离灯组表现均衡边缘盒子可用GPU无压力YOLOv8m25.9M50.2小目标更稳但推理延迟增加建议独立GPU或高性能NPUYOLOv8x68.2M53.9精度最高适合离线路测不适合实时路侧部署如果项目没有特殊精度要求我会直接选yolov8s。在真实路口数据集上n模型对 30 米外的红绿灯召回率掉得厉害而m模型在GTX 1660 Ti上跑到 640 输入也就 40 FPS 左右留给规则判定的 CPU 时间就少了。s模型在 GPU 上能到 80 FPS 以上在 RK3588 上通过rknn转换后也能跑到 15-25 FPS足够覆盖一个路口的信号周期刷新需求。如果你要训练自己的数据集建议直接以yolov8s.pt作为预训练权重不要从n往上蒸馏那套操作在信号灯这种小目标场景收益很低。3. 环境搭建与最小推理从零到看到第一个检测框3.1 Python 环境配置CPU 机器怎么跑GPU 机器怎么跑做信号灯识别环境配置是第一个劝退点。python 版本我建议锁在 3.8 到 3.11 之间ultralytics官方要求Python 3.8但 3.12 上部分旧版torch没有预编译包装起来容易踩坑。先用 conda 建一个干净环境conda create -n traffic_light python3.9 -y conda activate traffic_light pip install ultralyticsCPU 机器比如 ubuntu20.04 搭建 yolov8 环境 CPU 版本直接装 CPU 版 torchpip install torch torchvision --index-url https://download.pytorch.org/whl/cpuGPU 机器先确认驱动支持的最高 CUDA 版本再装对应 torch。我平时先在终端跑nvidia-smi看右上角 CUDA 版本然后去 pytorch.org 的get-started页面复制对应命令不推荐直接用pip install torch默认装最新版因为最新版可能要求 CUDA 12.x而很多人的机器还是 CUDA 11.8。装完之后验证一下python -c import torch; print(torch.__version__, torch.cuda.is_available())如果torch.cuda.is_available()输出False先别急着重装检查是不是装了 CPU 版 torch或者 conda 环境里存在和 pip 环境冲突的nvidia-*包。这一步的环境变量CUDA_VISIBLE_DEVICES也常见问题多卡机器上不设置的话默认用 0 号卡显存不够会直接 OOM。在vscode python 环境配置时需要注意选择解释器时容易选错环境。这里建议直接命令行启动训练不依赖 IDE 的解析选解释器时就选刚才创建的traffic_light环境而不是系统自带的 python。3.2 用官方权重跑通第一版推理最小命令与输出解读环境就绪后先用官方在 COCO 上预训练的权重验证管线通不通。虽然 COCO 里没有信号灯类别但能确认模型加载、推理、画框整条链路没问题# 用官方 yolov8s.pt 对一张本地图片做推理 yolo predict modelyolov8s.pt source./test_intersection.jpg imgsz640 conf0.25 # 或者用 python 接口便于后续二次开发 python -c from ultralytics import YOLO; model YOLO(yolov8s.pt); results model.predict(test_intersection.jpg, imgsz640, conf0.25, saveTrue, save_txtTrue)运行结束后会在runs/detect/predict/下生成标注了检测框的图片以及labels/下的 txt 文件每行是class x_center y_center width height坐标已归一化到 0-1。这说明推理链路正常。参数里重点看两个conf表示置信度阈值信号灯场景建议 0.3 起步因为灯体小、特征弱0.25 会带出不少误检imgsz是输入尺寸做路侧感知时我一般用imgsz960在算力够的前提下把小目标放大到更大的特征图上召回率提升非常明显。代价是推理时间变长RK3588这类边缘设备上需要实测权衡。3.3 理解推理输出的数据结构规则判定的第一道门槛predict返回的Results对象里藏着所有需要的信息但它的结构对新手不太友好。我通常这样取数据from ultralytics import YOLO import torch model YOLO(runs/train/your_model/weights/best.pt) # 用训练好的权重 results model.predict(frame_001.jpg, imgsz960, conf0.35) for res in results: # 检测框坐标: (N, 4) 的 tensor格式 xyxy左上角 右下角 boxes res.boxes.xyxy # 置信度: (N,) 的 tensor confs res.boxes.conf # 类别 id: (N,) 的 tensor clss res.boxes.cls # 注意boxes / confs / clss 都是 tensor取单个值要 .item() for i in range(len(boxes)): x1, y1, x2, y2 [int(v) for v in boxes[i].tolist()] conf confs[i].item() cls_id int(clss[i].item()) cls_name res.names[cls_id] print(f{cls_name} conf{conf:.2f} box({x1},{y1},{x2},{y2}))逻辑并不复杂但有个细节值得单独说res.names是一个将类 id 映射到名称的字典。在训练时如果你自定义了类别names 一定是按训练数据里的顺序而不是字母序。最常见的翻车现场是训练时类别文件里写的是[green, red]推理代码里却按{0: red, 1: green}去解析结果灯光颜色全部对调。所以我每次训练完第一件事就是把runs/train/xxx/args.yaml里的names打印出来确认和推理代码里的映射一致。4. 训练自己的信号灯数据集标签设计、转换脚本与参数调优4.1 类别体系怎么设计状态拆细还是检测分类两级信号灯项目第一个决策点就是标签体系。我见过两种主流做法各有代价。第一种是把所有状态平铺成类别red_circle、green_circle、yellow、red_left_arrow、green_left_arrow、green_right_arrow、green_straight等。类别多每个类的样本量会被摊薄训练出来的模型容易在相似颜色之间混淆比如green_circle和green_left_arrow在远距离小目标下很难区分。第二种做法是“灯组检测 状态分类”两级先检测灯组黑框再把黑框区域裁剪下来用一个小分类网络判断颜色和箭头。这种做法在小目标场景下鲁棒性好因为分类网络输入的是放大后的灯组图像特征更清晰。但工程复杂度高需要维护两个模型。基于 YOLOv8 这套方案我建议走单模型的折中方案把圆盘灯的三种颜色red_circle、yellow_circle、green_circle和最常见的几种箭头灯red_left、green_left、green_straight、green_right作为检测类别一共 7 类。黄灯和箭头灯组合在数据集中出现频率低用检测来识别性价比不高倒计时数字单列一个类其余状态交给后处理。标注时的原则是灯体本身作为框不从黑底框开始框也不把整个灯组框进去。比如箭头灯框只贴住箭头发光区域这样检测头学的是“发光形状”而不是“黑色外壳”泛化能力更强。labelme 标注之后转换即可。4.2 数据集扩增与转换Labelme JSON 转 YOLO txt 的完整脚本用 labelme 标注出来的文件是 JSON 格式YOLOv8 训练需要 txt 格式。转换脚本是必经之路我习惯把坐标归一化和类别映射写在一起import json import os from glob import glob # 类别名 - 数字 id顺序固定训练和推理共用 class_map { red_circle: 0, yellow_circle: 1, green_circle: 2, red_left: 3, green_left: 4, green_straight: 5, green_right: 6, } def convert_labelme_json(json_path, out_dir): with open(json_path, r, encodingutf-8) as f: data json.load(f) # labelme 的 imageWidth/imageHeigh 是原始尺寸 img_w data[imageWidth] img_h data[imageHeight] txt_name os.path.basename(json_path).replace(.json, .txt) lines [] for shape in data[shapes]: label shape[label] if label not in class_map: print(f跳过未定义类别: {label}) continue points shape[points] # [[x1,y1], [x2,y2]] # points 是任意四边形取外接矩形 xs [p[0] for p in points] ys [p[1] for p in points] x_min, x_max min(xs), max(xs) y_min, y_max min(ys), max(ys) # 转成 YOLO 格式: 中心点x 中心点y 宽 高都归一化到 0~1 x_center (x_min x_max) / 2 / img_w y_center (y_min y_max) / 2 / img_h box_w (x_max - x_min) / img_w box_h (y_max - y_min) / img_h lines.append(f{class_map[label]} {x_center:.6f} {y_center:.6f} {box_w:.6f} {box_h:.6f}) with open(os.path.join(out_dir, txt_name), w, encodingutf-8) as f: f.write(\n.join(lines)) # 批处理脚本遍历标注目录 for json_file in glob(labels/*.json): convert_labelme_json(json_file, yolo_labels) print(转换完成请检查输出的 txt 是否与图片一一对应)转换逻辑里有四个边界坑要处理好。第一个是imageWidth可能在部分 labelme 版本中缺失替换方案是从同名图片文件读取宽高第二个是 points 是四边形我取外接矩形但如果标的是旋转框外接矩形会把背景框进来对灯体这种矩形目标没问题箭头灯稍微斜着标也没问题第三个是类别映射的顺序class_map一旦定了就不能改训练到一半再增删类别会让已保存的 best.pt 作废第四个是类别 id 从 0 开始不是从 1 开始写错的话所有框整体错位一位。4.3 训练参数详解freeze、imgsz、batch 如何影响最终效果数据集备好后训练命令如下yolo train \ modelyolov8s.pt \ datatraffic_light.yaml \ epochs100 \ imgsz960 \ batch16 \ lr00.005 \ freeze10 \ workers8 \ device0traffic_light.yaml的内容是数据集路径和类别定义这是整个训练流程里最容易写错的文件# 换成你自己的绝对路径 path: /home/user/traffic_light_dataset train: images/train val: images/val # 顺序必须和 4.2 的 class_map 完全一致 names: 0: red_circle 1: yellow_circle 2: green_circle 3: red_left 4: green_left 5: green_straight 6: green_right几个参数的实际意义和调参经验如下。freeze10的含义是冻结前 10 层backbone 的大部分不参与梯度更新。如果你是在 COCO 预训练权重的基础上微调信号灯模型freeze层数在 0 到 10 之间取一个值能够防止小数据集上 backbone 被带偏训练速度也更快。但如果你的数据量大5000 张以上、场景覆盖广我反而会设freeze0让整个网络充分适应新域。imgsz960对信号灯小目标来说几乎是刚需不过 960 输入下如果 batch 设 16 超出显存就把 imgsz、batch 同步调低。也可以用imgsz640先跑通再在val阶段用imgsz960验证精度差异。epochs的选择上实际项目里 100 个 epoch 能看到模型明显收敛。信号灯数据集的背景变化很大晴雨、白天黑夜、逆光顺光我建议关注验证集上的mAP50-95而不是只看mAP50因为mAP50对框位置不敏感箭头灯只要大概框住就能得过且过mAP50-95才能看出小目标定位是否真的准。训练过程中损失函数曲线图要用tensorboard或ultralytics自带的results.png来观察。免费方案是直接在训练结束后查看runs/train/xxx/results.png里面有train/box_loss、val/box_loss等 8 个子图。如果val/box_loss在前 20 个 epoch 就触底然后反弹说明主要问题不是欠拟合而是优化器步长太大或数据里有误标框。数据清洗优先级高于调参这句话我在信号灯项目里反复验证过——很多所谓的“模型不收敛”其实是标注框把整个灯组黑框框进去了导致模型学到的是个矩形黑块。4.4 损失曲线与权重选择的实操经验信号灯模型训练完best.pt和last.pt之间的选择我推荐一个简单惯例直接看results.png里的val/box_loss和val/cls_loss哪个 epoch 两个损失都处于低位就用对应 epoch 的权重。因为best.pt是按总验证得分选的不是按你的特定需求选的如果你更看重小目标召回可以在val后自行计算不同conf阈值下的召回率再决定用哪个权重。还有一个细节训练时数据集的目录结构要满足 YOLO 的约定images/train下放图片labels/train下放 txt文件名保持一致不要求扩展名一致但图片和标签不能在子目录里继续嵌套。目录多一层训练时ultralytics会直接搜不到标签报错内容是found no labels很多人在这步卡半天其实是目录层级不对。5. 信号灯识别的坑清单从漏检到错判的排查路径5.1 漏检集中在 30 米外的灯组原因不是模型差而是标注框太小现象远距离的小灯体频繁漏检近处同一类别的灯都能正常识别。原因标注框在 640 像素输入下只占 10 几个像素在 YOLO 的下采样特征图上可能只剩 2 个网格点不到。模型不是没看到而是特征太弱被背景噪声淹没了。加上训练时多数样本是近处的大框模型天然偏向学习大目标特征。解决三步走。第一步把训练和推理的imgsz从 640 提到 960 或 1280第二步数据层面把远距离样本占比提到 30% 以上不要只靠随机裁剪第三步检查标注框是否过紧如果只框住发光灯珠而不含任何黑色外壳小目标下更容易丢稍微外扩 2-3 像素反而有助于召回。5.2 夜间车灯被误检成红灯颜色特征和形状特征打架现象夜间场景频繁把刹车灯、路灯误检为red_circle白天却没事。原因模型在训练时可能学到了“红色光斑”这个特征。夜间红色刹车灯和红色信号灯在颜色、亮度、大小上高度相似很多标注数据里这两类也没有区分约束。信号灯的红和刹车灯的红在 RGB 空间里无法可靠区分。解决这是数据集问题不是模型问题。处理办法是在训练数据里增加夜间负样本——把包含刹车灯、红色霓虹灯、红色尾灯但没有信号灯的图片也放进去标注为background并不参与训练或者在推理阶段加一个后置规则检测框的长宽比必须在 0.4 到 2.5 之间灯体长宽比太接近正方形的就要降低置信度权重。信号灯灯体是长方形的刹车灯大多是圆形或近似圆形这个几何约束非常有效。5.3 绿灯直行误判为可通行但同一灯组还有左转箭头红灯现象同一灯组内既检测到green_circle又检测到red_left规则引擎只看到绿灯就放行直行车辆导致误判。原因数据集里灯组是独立标注的检测模型不知道哪几个框属于同一个物理灯组。后处理少了“框聚类”这一步。解决在规则判定前先做灯组聚类。判定两个框属于同一灯组的条件有三个中心点欧氏距离小于阈值比如 80 像素、垂直方向重叠度大于 0.5、水平方向间距小于灯体宽度。聚类完后再按灯组为单位做规则判定。这个逻辑不复杂但漏了就是“闯红灯级”的误判。5.4 白天逆光时绿灯被识别成黄灯颜色偏移是训练数据的锅现象晴天逆光时段绿灯识别成黄灯的置信度还很高。原因逆光下绿色通道整体曝光不足绿色在 YUV 空间的色相偏移到黄绿交界区模型在色彩分布上没学够逆光样本。更本质的原因是训练数据里逆光图片太少模型没见过“变暗了的绿色”。解决扩充逆光场景数据同时做数据增强。在ultralytics训练参数里可以开启hsv_h、hsv_s、hsv_v增强其中hsv_h控制色调偏移默认是 0.015对信号灯这种色相敏感的场景我会调小到 0.005避免数据增强把红色变成紫色、绿色变成青色反而引入更多误判。逆光样本靠真实采集增强只能作为补充。5.5 推理速度达标但整体延迟高预处理和后处理比模型更耗时现象模型本身在 GPU 上 5ms 推理完但整个 pipeline 跑到 50ms完全达不到实时。原因很多人忽略了图像解码、缩放、颜色转换和结果绘制这几个环节的开销。ultralytics默认的predict会做 letterbox 缩放和 BGR 转换单张图的预处理在 CPU 上可能要 10-20ms。如果还用 Python 逐帧cv2.imread那 CPU 直接成为瓶颈。解决生产级做法是把解码和预处理放到 GPU 或硬件解码模块上。边缘设备用RK3588的mpp硬解x86 上用pycuda或torchvision.transforms的 GPU 版预处理。另外推理时设置device0、halfTrue启用 FP16 推理速度基本翻倍。如果必须在 CPU 上跑就把输入尺寸降到 640并关闭save和show这两个可视化开关——它们会额外复制内存和做图像编码比模型还慢。6. 从检测框到通行规则状态机设计是项目的价值放大点信号灯识别模型的输出只是一堆带坐标的框真正让这套源码变成“通行规则识别模型”的是检测之后的状态机。我常用的做法是定义一个TrafficLightState枚举然后按路口相位把灯组的状态聚合起来from enum import Enum import time class LightColor(Enum): RED 0 YELLOW 1 GREEN 2 DARK 3 class LightState: def __init__(self, color, arrow, confidence, updated_time): self.color color self.arrow arrow # circle / left / straight / right self.confidence confidence self.updated_time updated_time def is_red(self): return self.color LightColor.RED # 帧间状态滤波器连续 3 帧一致才认为状态切换 def filter_state(new_state, history, threshold3): history.append(new_state) if len(history) threshold: history.pop(0) if len(history) threshold: return None if all(h.color history[0].color and h.arrow history[0].arrow for h in history): return history[0] return None这个状态滤波器的设计逻辑很直白单帧检测结果置信度再高也不能直接作为信号状态切换的依据——因为相机的丢帧、运动模糊、传感器噪声都会产生抖动。连续 3 帧一致才切换状态能过滤掉大多数瞬时误检。updated_time字段用来做超时保护如果一个灯组超过 10 秒没有任何检测结果就置为DARK状态并用默认规则不可通行兜底。规则判定这条路的终点是和应用场景结合路侧感知设备把每个灯组的状态推给信号机或车端车端根据当前位置、目标车道和灯组状态做最后的通行决策。模型和状态机能覆盖 95% 的正常通行场景剩下的 5% 是异常情况——比如临时信号灯、施工改道、灯组故障。这部分要靠帧间逻辑和历史数据兜底而不是靠增强模型。我个人的做法是每次迭代都先跑一遍傍晚和夜间的连续视频流把状态机的日志保存下来第二天早上挑出状态切换时间点和视频逐帧对。这个习惯帮我发现过好多次“绿灯闪烁后直接变红”的时序问题——检测状态和真实信号差了半拍原因不是模型而是滤波窗口太长把短黄灯给吞掉了。从那以后我把黄灯的滤波窗口缩短到 2 帧红灯绿灯保持 3 帧。这种细节只能通过实拍数据发现单看准确率曲线永远看不到。整套方案从数据标注到状态机跑通一周时间足够值得投入的地方在数据采集和边界场景补齐上希望帮到你。本文还有配套的精品资源点击获取