简介在智能交通与自动驾驶场景中交通信号灯的高效识别是车辆安全通行的关键前提。目标检测技术作为计算机视觉的核心任务常被用于定位画面中的交通灯区域但仅仅检测位置远不足以支撑通行决策。YOLOv8作为主流实时目标检测算法其Anchor-Free检测头与C2f模块在小目标特征提取上表现优越可同时输出信号灯颜色与方向状态的细粒度类别。结合HSV颜色空间校验、多帧投票和空间约束等后处理机制能够显著提升状态判断的稳定性与可靠性。本文从数据标注规范、模型训练参数到通行规则判断逻辑完整拆解一套基于YOLOv8的路口信号灯识别项目覆盖小目标漏检、夜间逆光误判等工程痛点并提供了可直接复用的工程方案适用于课程设计、竞赛演示及边缘设备部署等场景。 说实话这类“基于 YOLOv8 的路口交通信号灯通行规则识别”项目在高校课程设计和竞赛里出现频率极高但真正能从头到尾把路跑通、答得上老师追问细节的团队并不多。大部分情况是训练完一个“能框到信号灯”的模型就停了一被问到“你怎么判断现在能不能走”“红灯和汽车尾灯混淆怎么办”“夜间效果怎么保证”整个项目就露馅了。这篇博文就把我实际做过的一套完整工程拆开讲——从数据标注、模型训练到通行规则判断逻辑再到部署落地全程踩过的坑和试出来的参数都会提到给后面做类似方向的朋友一份可以直接抄的作业。这个项目最终交付物包括完整源码、训练好的权重、数据集整理脚本、项目文档和答辩PPT是一套“分数很高但完全经得起追问”的工程。我会按实际开发顺序来写而不是按目录顺序因为开发顺序本身就是踩坑顺序你跟着走一遍等于把整个项目重新实现了一次。1. 项目整体设计与思路拆解1.1 通行规则识别到底在解决什么问题先把题目的关键词拆开看“路口交通信号灯通行规则识别”。它不是说“检测出画面里有个红绿灯”就完事了而是要从连续的视频帧里判断出当前灯的状态红、黄、绿、灭灯并且结合方向箭头直行、左转、右转、掉头输出一个明确的通行结论——当前车道能不能走、需不需要等待、转弯是否受控。这里有个很多新手会忽略的点信号灯识别本质上是“目标检测 细粒度状态分类”的组合问题。你不光要知道“哪里是灯”还要知道“这个灯现在亮的是什么颜色”。如果只做检测把红灯绿都归为一类“traffic_light”那后续判断规则就得靠另外一套算法去读取灯盘内部的颜色区域这等于把一个问题拆成了两个模型。我最终的方案是让YOLOv8直接输出带状态的类别也就是把“红、黄、绿、左转红、左转绿、直行绿、右转红”等组合状态作为独立类别训练。这样后处理逻辑可以写得非常轻一个类别ID直接映射通行结论。1.2 为什么底座选了YOLOv8选YOLOv8而不是Faster R-CNN、SSD或者其他版本核心原因有三个。第一信号灯属于典型的小目标尤其在1080P甚至4K路况画面里一个灯盘可能只占几十个像素。YOLOv8的Anchor-Free检测头对中小目标的回归效果在同等算力下比老版本YOLO更好而且它引入了C2f模块特征提取的梯度流动更充分小目标的细节信息保留得比YOLOv5要好一些。第二生态成熟。YOLOv8的Ultralytics官方仓库提供了从训练、验证、导出到部署的一整套工具链文档全、社区活跃遇到问题能搜到大量同类案例。对一个还要写文档和答辩的课程项目来说这种“拿来就能用”的工程友好度非常重要。第三模型体积和推理速度的平衡点容易控制。同一个数据集上YOLOv8n可以跑到嵌入式设备YOLOv8x可以在服务器上刷精度。你可以在不动代码的情况下只换一个权重文件就能适配从PC演示到边缘设备的不同需求。这个特性在后期的扩展答辩里是非常加分的。1.3 整体技术链路整个项目的流程可以概括为四个环节数据构建 → 模型训练 → 状态后处理 → 结果输出。数据环节要解决“哪些样本、怎么标注”的问题训练环节解决“模型能不能稳定检测出灯的状态”的问题后处理环节解决“单帧结果如何变成稳定可靠的通行决策”的问题输出环节则是把结果可视化到视频流上并在日志中记录通行状态变化。其中后处理环节是区分“课程设计水平”和“工程水平”的分水岭。我见过太多项目直接拿单帧检测结果当作最终判断——灯盘被树叶挡了一帧就输出“红灯”下一帧又输出“绿灯”整个判断结果抖得没法看。所以我在后处理里加入了多帧投票、状态滞留和空间约束三个模块这些细节后面详细展开。2. 数据集构建与标注决定模型上限的关键环节2.1 信号灯数据从哪来说实话信号灯识别这个方向最难的从来不是模型而是数据。公开数据集能用的主要有几个方向LISA交通信号灯数据集、Bosch Small Traffic Lights Dataset以及国内一些机构开放的路口检测数据。但这些公开数据普遍存在样本老旧、分辨率不高、场景单一的问题尤其是国内路口的左转待转区、非机动车混行、竖排信号灯等特色场景国外数据集里基本没有。我的做法是“公开数据打底 自采数据补充”两步走。先下载公开数据集做预训练让模型学到信号灯的基本形态特征。然后用手机、行车记录仪在真实路口采集了大约两个小时的多时段视频覆盖白天强光、傍晚、夜间、雨天、逆光五种光照条件。把这些视频按帧抽取再用一个简单的清晰度筛选脚本把模糊帧剔除最终得到的自采图像大约3000张。这两部分数据合在一起后全部重新标注保证类别体系完全一致避免不同数据集的标注口径差异把模型带偏。2.2 小目标标注的细节规范标注这块我强烈建议用X-AnyLabeling它支持自动标注辅助对信号灯这种小目标能省大量时间。但更重要的是标注规范这里直接列我项目里定死的几条类别按“颜色 方向”拆分。红色直行、红色左转、红色右转、红色掉头、黄色、绿色直行、绿色左转、绿色右转、绿色掉头、灭灯共10类。方向箭头明确的灯才标方向全屏灯只标颜色。标注框贴着灯盘的外发光区域不包含灯臂和背后的黑色边框。原因很简单检测框越紧模型学到的特征越集中于灯盘本身后续做颜色判读时受背景干扰越小。夜间样本必须标出发光晕染区域。白天灯盘轮廓清晰夜间光源会溢出如果只标内部灯珠模型很难学到夜间特征。我试过把夜间样本的框往外扩2到3个像素包含光晕效果立刻改善。远处小目标宁可漏标也不滥标。小于8×8像素的灯盘人眼都很难确认颜色标进去反而会给模型注入噪声。这些极小目标在推理阶段用多尺度策略处理。标注完成后还有一个必须做的步骤统计每个类别的样本数量。如果发现“绿色左转”只有几十张而“红色直行”有上千张就需要针对性补充数据或用复制粘贴增强来平衡。这个统计脚本我直接写在项目里了跑一遍就能输出各类别分布表。2.3 数据增强策略Ultralytics仓库默认开启了Mosaic、平移、旋转、HSV扰动等增强但对信号灯这个场景有两个增强格外关键一个是亮度对比度扰动让模型适应从白天到夜间的光照跨度另一个是随机遮挡模拟树叶、大车、雨刷遮挡灯盘的情况。我还额外加了一个“色彩偏移增强”把绿色色调往青和黄两个方向随机拉。因为实际路口的绿色信号灯偏青、偏黄的情况都有如果模型只看标准的纯绿遇到偏色的灯就容易误判成黄灯。这个思路同样用在红色上往橙红和紫红两个方向扩散。需要提醒的是Mosaic增强默认是开启的但对小目标来说它有时反而有害——四张图拼在一起后小目标的尺寸被进一步压缩模型更学不到细节。我在训练时把Mosaic概率从默认的1.0降到了0.5实测小目标的recall提升了几个点这个细节很多人注意不到。3. YOLOv8训练全流程复现3.1 环境配置与模型选型先说环境我的训练机是一张GTX 1660 Ti6GB显存这套配置跑YOLOv8确实吃紧但不是不能跑。我用的是Ultralytics官方CLIPyTorch版本2.xCUDA 11.8Python 3.10。如果你也是小显存显卡有几个配置必须注意batch size设8左右图像尺寸从640升到960时显存会暴涨建议先用640跑通再逐步调大。模型选型上我最终用了YOLOv8s作为主模型。理由很实在在6GB显存下YOLOv8n精度不够看到小目标容易漏YOLOv8m在我的卡上batch稍微大一点就OOM训练效率太低。YOLOv8s是平衡点单帧推理在GPU上大约15到20毫秒精度比n明显高一个档恰好能满足“Demo演示流畅答辩精度有说服力”的双重需求。如果后期要部署到嵌入式设备再单独导出nano版本做量化这是完全独立的另一条线不影响主项目。3.2 数据配置文件与训练命令数据配置文件的写法不多说直接给一个可用的示例# traffic_light.yaml path: ./dataset train: images/train val: images/val names: 0: red 1: green 2: yellow 3: red_left 4: green_left 5: red_right 6: green_right 7: red_straight 8: green_straight 9: off训练命令yolo detect train \ datatraffic_light.yaml \ modelyolov8s.pt \ epochs200 \ imgsz960 \ batch8 \ device0 \ mosaic0.5 \ workers4 \ patience50这里我把图像尺寸设成了960而不是默认的640这是针对小目标场景最有效的一招。信号灯在640下只有二三十像素特征非常弱升到960后同等目标能多出一倍以上的像素信息。代价是训练速度慢了约40%但对最终效果来说完全值得。另一个关键参数是patience50也就是50个epoch没提升就早停。信号灯数据量不算大模型一般到120到150个epoch就收敛了没必要傻跑200个epoch早停能省训练时间还能避免过拟合。3.3 训练过程中的关键监测点训练时不要只盯着终端里的loss数字重点看两个东西训练曲线和验证集表格。Ultralytics会输出results.png里面有box_loss、cls_loss、dfl_loss三条曲线。如果cls_loss在训练后期还在持续下降但val的mAP不再上升说明模型开始过拟合应该提前停或者加大数据增强。如果box_loss在早期就掉到很低但mAP很差往往是小目标的定位学好了但分类没学好需要回头检查类别样本均衡。每次epoch结束后的验证集输出里最值得关注的是mAP50-95和每个类别的AP。如果发现某个方向类别比如red_left的AP明显低于其他类别说明这个类别的样本不足或形态差异太大需要针对补数据。当时我这边“绿色掉头”类别的mAP只有0.6左右补了八十多张真实掉头灯图片后直接提升到0.85这种针对性补数据比盲目加训练轮数有效得多。训练完成后用best.pt做验证集测试并保存一批带检测框的推理图片肉眼检查一遍。不要只看指标有的错误是mAP体现不出来的——比如把红色箭头识别成红色圆灯类别置信度差不多但通行规则完全不同这种错误必须在可视化检查里抓出来。4. 通行规则识别算法实现4.1 信号灯状态怎么从检测框里读出来模型输出的结果是一个类别ID加一个框类别ID已经携带了“红/黄/绿 方向”的信息。但做个纯分类映射在工程上不够稳因为有时候模型会在相邻类别之间摇摆比如红灯和黄色倒计时灯容易混淆。我额外做了一层颜色校验把检测框裁剪出来转到HSV空间做一个像素比例判定用来和模型输出的类别做交叉验证。HSV判色的核心代码逻辑大概是这样import cv2 import numpy as np def judge_color(crop): hsv cv2.cvtColor(crop, cv2.COLOR_BGR2HSV) mask_red1 cv2.inRange(hsv, (0, 70, 50), (10, 255, 255)) mask_red2 cv2.inRange(hsv, (156, 70, 50), (180, 255, 255)) mask_red mask_red1 | mask_red2 mask_green cv2.inRange(hsv, (35, 70, 50), (85, 255, 255)) mask_yellow cv2.inRange(hsv, (15, 70, 50), (35, 255, 255)) count_red cv2.countNonZero(mask_red) count_green cv2.countNonZero(mask_green) count_yellow cv2.countNonZero(mask_yellow) color_weights { red: count_red, green: count_green, yellow: count_yellow } return max(color_weights, keycolor_weights.get)这段代码的运行速度很快每帧所有检测框加起来也就几毫秒。当模型输出的类别与HSV判读结果一致时采信模型输出不一致时让状态进入“待确认”连续几帧都保持一致才更新最终通行状态。这个机制极大降低了单帧误判带来的干扰。4.2 多帧投票让判断结果稳定下来单帧检测结果一定是不稳定的尤其面对夜间闪烁的黄灯或正在切换的红绿灯模型很容易在相邻帧给出不同结果。我的做法是维护一个长度为5的滑动窗口每进来一帧就把当前检测结果推入窗口窗口内出现次数最多的类别且占比不低于60%时才更新最终状态。举个实际例子第100帧模型输出“green”第101帧由于反光误判成“yellow”第102到104帧又回到“green”。如果只看单帧第101帧会触发一次错误的“黄灯”警告但滑动窗口内“green”占4/5最终状态保持“green”不变误报被完全滤掉。这个窗口长度可以按场景调整。路口的信号灯最短相位一般也在15秒以上5帧窗口完全够用而且引入的延迟只有约0.2秒对通行决策来说可以忽略。4.3 方向箭头与停止线约束模型输出“红色左转”和“红色圆灯”对应的通行规则完全不同——前者意味着左转车道禁止通行但直行可能放行后者意味着所有方向都要停。所以方向信息的准确性直接决定项目的正确性。我在后处理中增加了一个空间约束模块。如果画面中检测到停止线用固定ROI或语义分割得到就把信号灯检测框与停止线的空间关系纳入判断只有信号灯位于停止线的同侧且车道方向匹配时才输出对应的通行指令。这个模块对单路口视频非常实用能过滤掉对面车道信号灯的干扰。输出方面我设计了一个简单的状态机状态包括 GO、STOP、CAUTION、NO_LANE 四类每个状态由“颜色 方向 空间位置”共同决定。状态变化时不仅更新画面上的文字标注还会写入CSV日志方便答辩时展示“算法在哪些帧做出了什么判断、为什么这么判断”的完整轨迹。5. 常见问题与排查技巧实录5.1 小目标漏检严重怎么办漏检是信号灯项目最普遍的问题尤其当灯盘在画面中占比很小。我试下来最有效的手段有三个按优先级排序提高输入分辨率。把imgsz从640提到960是投入产出比最高的一步能立刻看到小目标recall提升。用SAHI做切片推理。将大图切成带重叠的切片分别推理再合并结果对极小的目标很有效但推理耗时翻倍适合离线分析或对实时性要求不高的场景。针对小目标做数据增强。在训练时加入随机裁剪放大模拟“从远处拉近”的观察视角让模型见过更多小尺寸样本。5.2 夜间和逆光场景误判夜间信号灯的自发光特性会让HSV颜色判读很不稳定尤其是红色和黄色在过曝情况下高度相似。我采用的方案是给训练集加入大量夜间和逆光样本同时在HSV判色的阈值上对夜间场景做差异化处理——当检测框的光斑面积明显偏大时说明过曝颜色H通道的判定权重下调改为优先看亮度轮廓的形态特征。逆光场景更麻烦因为灯盘本身可能还没亮背景的强光先让模型产生了幻觉检测。我的对策是加入大量负样本把夕阳、车灯、反光牌这些“容易被误判为信号灯”的物体单独收集成no_false类让模型学会区分。另一个后处理技巧是设置一个较高的置信度阈值0.4以上宁可漏掉远处的小灯也不要频繁产生误报——在通行规则里漏报只是“没识别出来”误报可是会给出错误通行指令的。5.3 训练loss不收敛或震荡如果训练时loss一直不降或反复震荡我建议依次检查这几个地方学习率是否过大默认的0.01对大多数情况没问题但小数据集可能偏大可以降到0.005数据集的标注框是否有多边形、空框、错位问题类别数量是否和数据配置文件一致。还有一次我遇到loss曲线剧烈震荡最后发现是数据文件夹里混入了几十张没有标注对象的背景图模型对这些图无所适从删掉后立刻恢复。如果想要更精细的loss曲线Ultralytics默认只画平滑后的曲线。我在项目里加了一个脚本直接从训练日志里读取每轮的原始loss值画出细分到每个类别的loss趋势图这样能更早发现某个难例类别的过拟合起点。5.4 视频推理卡顿、FPS低演示环节最怕的就是卡。如果推理端用CPU跑YOLOv8s在960分辨率下基本只有每秒一两帧完全没法用。我在项目里预留了三种降级方案图像尺寸从960降到640模型从s换成n推理帧率限制到10FPS并开启跳帧处理。演示时一般用“640 s模型 跳帧”的组合在普通笔记本CPU上也能跑到每秒8到12帧画面基本可接受。如果要用GPU需要确保推理时GPU没被其他进程占用。我曾遇到一场演示前GPU被后台程序占用推理速度还不如CPU排查半天才找到原因。所以项目文档里我专门加了一条演示前用nvidia-smi检查GPU占用状态。6. 工程化落地与后续扩展6.1 模型导出与嵌入式部署YOLOv8导出成ONNX非常简单一行命令yolo export modelbest.pt formatonnx opset12导出后在嵌入式设备上可以先用ONNX Runtime跑在Jetson Nano级别的主板上能到每秒8到12帧做概念验证足够。如果想进一步提速可以转成TensorRT引擎用FP16精度在Jetson Orin上通常可以跑到每秒30帧以上完全满足实时路况处理的需求。对于国产平台比如瑞芯微RK3588的NPUYOLOv8也是官方重点适配的模型之一转成RKNN格式后在NPU上的延迟可以压到20毫秒以内。这一步在项目里作为扩展方案写进了文档答辩时谈到“模型如何落地到真实路侧设备”时非常加分。6.2 这个项目还能往哪些方向扩展做完基础版之后我明显感觉到有几个方向可以继续做深。第一个是加跟踪模块用ByteTrack或BoT-SORT把检测框关联成轨迹这样不仅能看到灯的状态还能判断车辆是否在红灯时越过停止线直接用于违章检测。第二个是扩展到多路摄像头联合判断解决单个视角下信号灯被遮挡时的信息缺失问题。第三个是用更轻量的分类头替代部分后处理逻辑比如在灯盘区域内直接用一个MobileNet小模型判断箭头方向与YOLOv8的检测结果做双通道校验。不过做这些扩展之前一定要先把基础版本的稳定性打磨到位。我在实际测试中最大的体会是这个项目上模型的mAP不是最关键的指标状态判断的稳定性和可解释性才是。你能不能在连续五分钟的视频里做到零误报能不能在答辩时解释清楚每一次状态切换背后的逻辑依据这才是高分项目的核心分水岭。从工程角度说后处理的多帧投票和HSV校验付出的成本远低于继续刷模型精度但带来的可靠性提升是肉眼可见的这笔账一定要算清楚。本文还有配套的精品资源点击获取 基于YOLOv8的路口信号灯通行规则识别实战解析
简介在智能交通与自动驾驶场景中交通信号灯的高效识别是车辆安全通行的关键前提。目标检测技术作为计算机视觉的核心任务常被用于定位画面中的交通灯区域但仅仅检测位置远不足以支撑通行决策。YOLOv8作为主流实时目标检测算法其Anchor-Free检测头与C2f模块在小目标特征提取上表现优越可同时输出信号灯颜色与方向状态的细粒度类别。结合HSV颜色空间校验、多帧投票和空间约束等后处理机制能够显著提升状态判断的稳定性与可靠性。本文从数据标注规范、模型训练参数到通行规则判断逻辑完整拆解一套基于YOLOv8的路口信号灯识别项目覆盖小目标漏检、夜间逆光误判等工程痛点并提供了可直接复用的工程方案适用于课程设计、竞赛演示及边缘设备部署等场景。 说实话这类“基于 YOLOv8 的路口交通信号灯通行规则识别”项目在高校课程设计和竞赛里出现频率极高但真正能从头到尾把路跑通、答得上老师追问细节的团队并不多。大部分情况是训练完一个“能框到信号灯”的模型就停了一被问到“你怎么判断现在能不能走”“红灯和汽车尾灯混淆怎么办”“夜间效果怎么保证”整个项目就露馅了。这篇博文就把我实际做过的一套完整工程拆开讲——从数据标注、模型训练到通行规则判断逻辑再到部署落地全程踩过的坑和试出来的参数都会提到给后面做类似方向的朋友一份可以直接抄的作业。这个项目最终交付物包括完整源码、训练好的权重、数据集整理脚本、项目文档和答辩PPT是一套“分数很高但完全经得起追问”的工程。我会按实际开发顺序来写而不是按目录顺序因为开发顺序本身就是踩坑顺序你跟着走一遍等于把整个项目重新实现了一次。1. 项目整体设计与思路拆解1.1 通行规则识别到底在解决什么问题先把题目的关键词拆开看“路口交通信号灯通行规则识别”。它不是说“检测出画面里有个红绿灯”就完事了而是要从连续的视频帧里判断出当前灯的状态红、黄、绿、灭灯并且结合方向箭头直行、左转、右转、掉头输出一个明确的通行结论——当前车道能不能走、需不需要等待、转弯是否受控。这里有个很多新手会忽略的点信号灯识别本质上是“目标检测 细粒度状态分类”的组合问题。你不光要知道“哪里是灯”还要知道“这个灯现在亮的是什么颜色”。如果只做检测把红灯绿都归为一类“traffic_light”那后续判断规则就得靠另外一套算法去读取灯盘内部的颜色区域这等于把一个问题拆成了两个模型。我最终的方案是让YOLOv8直接输出带状态的类别也就是把“红、黄、绿、左转红、左转绿、直行绿、右转红”等组合状态作为独立类别训练。这样后处理逻辑可以写得非常轻一个类别ID直接映射通行结论。1.2 为什么底座选了YOLOv8选YOLOv8而不是Faster R-CNN、SSD或者其他版本核心原因有三个。第一信号灯属于典型的小目标尤其在1080P甚至4K路况画面里一个灯盘可能只占几十个像素。YOLOv8的Anchor-Free检测头对中小目标的回归效果在同等算力下比老版本YOLO更好而且它引入了C2f模块特征提取的梯度流动更充分小目标的细节信息保留得比YOLOv5要好一些。第二生态成熟。YOLOv8的Ultralytics官方仓库提供了从训练、验证、导出到部署的一整套工具链文档全、社区活跃遇到问题能搜到大量同类案例。对一个还要写文档和答辩的课程项目来说这种“拿来就能用”的工程友好度非常重要。第三模型体积和推理速度的平衡点容易控制。同一个数据集上YOLOv8n可以跑到嵌入式设备YOLOv8x可以在服务器上刷精度。你可以在不动代码的情况下只换一个权重文件就能适配从PC演示到边缘设备的不同需求。这个特性在后期的扩展答辩里是非常加分的。1.3 整体技术链路整个项目的流程可以概括为四个环节数据构建 → 模型训练 → 状态后处理 → 结果输出。数据环节要解决“哪些样本、怎么标注”的问题训练环节解决“模型能不能稳定检测出灯的状态”的问题后处理环节解决“单帧结果如何变成稳定可靠的通行决策”的问题输出环节则是把结果可视化到视频流上并在日志中记录通行状态变化。其中后处理环节是区分“课程设计水平”和“工程水平”的分水岭。我见过太多项目直接拿单帧检测结果当作最终判断——灯盘被树叶挡了一帧就输出“红灯”下一帧又输出“绿灯”整个判断结果抖得没法看。所以我在后处理里加入了多帧投票、状态滞留和空间约束三个模块这些细节后面详细展开。2. 数据集构建与标注决定模型上限的关键环节2.1 信号灯数据从哪来说实话信号灯识别这个方向最难的从来不是模型而是数据。公开数据集能用的主要有几个方向LISA交通信号灯数据集、Bosch Small Traffic Lights Dataset以及国内一些机构开放的路口检测数据。但这些公开数据普遍存在样本老旧、分辨率不高、场景单一的问题尤其是国内路口的左转待转区、非机动车混行、竖排信号灯等特色场景国外数据集里基本没有。我的做法是“公开数据打底 自采数据补充”两步走。先下载公开数据集做预训练让模型学到信号灯的基本形态特征。然后用手机、行车记录仪在真实路口采集了大约两个小时的多时段视频覆盖白天强光、傍晚、夜间、雨天、逆光五种光照条件。把这些视频按帧抽取再用一个简单的清晰度筛选脚本把模糊帧剔除最终得到的自采图像大约3000张。这两部分数据合在一起后全部重新标注保证类别体系完全一致避免不同数据集的标注口径差异把模型带偏。2.2 小目标标注的细节规范标注这块我强烈建议用X-AnyLabeling它支持自动标注辅助对信号灯这种小目标能省大量时间。但更重要的是标注规范这里直接列我项目里定死的几条类别按“颜色 方向”拆分。红色直行、红色左转、红色右转、红色掉头、黄色、绿色直行、绿色左转、绿色右转、绿色掉头、灭灯共10类。方向箭头明确的灯才标方向全屏灯只标颜色。标注框贴着灯盘的外发光区域不包含灯臂和背后的黑色边框。原因很简单检测框越紧模型学到的特征越集中于灯盘本身后续做颜色判读时受背景干扰越小。夜间样本必须标出发光晕染区域。白天灯盘轮廓清晰夜间光源会溢出如果只标内部灯珠模型很难学到夜间特征。我试过把夜间样本的框往外扩2到3个像素包含光晕效果立刻改善。远处小目标宁可漏标也不滥标。小于8×8像素的灯盘人眼都很难确认颜色标进去反而会给模型注入噪声。这些极小目标在推理阶段用多尺度策略处理。标注完成后还有一个必须做的步骤统计每个类别的样本数量。如果发现“绿色左转”只有几十张而“红色直行”有上千张就需要针对性补充数据或用复制粘贴增强来平衡。这个统计脚本我直接写在项目里了跑一遍就能输出各类别分布表。2.3 数据增强策略Ultralytics仓库默认开启了Mosaic、平移、旋转、HSV扰动等增强但对信号灯这个场景有两个增强格外关键一个是亮度对比度扰动让模型适应从白天到夜间的光照跨度另一个是随机遮挡模拟树叶、大车、雨刷遮挡灯盘的情况。我还额外加了一个“色彩偏移增强”把绿色色调往青和黄两个方向随机拉。因为实际路口的绿色信号灯偏青、偏黄的情况都有如果模型只看标准的纯绿遇到偏色的灯就容易误判成黄灯。这个思路同样用在红色上往橙红和紫红两个方向扩散。需要提醒的是Mosaic增强默认是开启的但对小目标来说它有时反而有害——四张图拼在一起后小目标的尺寸被进一步压缩模型更学不到细节。我在训练时把Mosaic概率从默认的1.0降到了0.5实测小目标的recall提升了几个点这个细节很多人注意不到。3. YOLOv8训练全流程复现3.1 环境配置与模型选型先说环境我的训练机是一张GTX 1660 Ti6GB显存这套配置跑YOLOv8确实吃紧但不是不能跑。我用的是Ultralytics官方CLIPyTorch版本2.xCUDA 11.8Python 3.10。如果你也是小显存显卡有几个配置必须注意batch size设8左右图像尺寸从640升到960时显存会暴涨建议先用640跑通再逐步调大。模型选型上我最终用了YOLOv8s作为主模型。理由很实在在6GB显存下YOLOv8n精度不够看到小目标容易漏YOLOv8m在我的卡上batch稍微大一点就OOM训练效率太低。YOLOv8s是平衡点单帧推理在GPU上大约15到20毫秒精度比n明显高一个档恰好能满足“Demo演示流畅答辩精度有说服力”的双重需求。如果后期要部署到嵌入式设备再单独导出nano版本做量化这是完全独立的另一条线不影响主项目。3.2 数据配置文件与训练命令数据配置文件的写法不多说直接给一个可用的示例# traffic_light.yaml path: ./dataset train: images/train val: images/val names: 0: red 1: green 2: yellow 3: red_left 4: green_left 5: red_right 6: green_right 7: red_straight 8: green_straight 9: off训练命令yolo detect train \ datatraffic_light.yaml \ modelyolov8s.pt \ epochs200 \ imgsz960 \ batch8 \ device0 \ mosaic0.5 \ workers4 \ patience50这里我把图像尺寸设成了960而不是默认的640这是针对小目标场景最有效的一招。信号灯在640下只有二三十像素特征非常弱升到960后同等目标能多出一倍以上的像素信息。代价是训练速度慢了约40%但对最终效果来说完全值得。另一个关键参数是patience50也就是50个epoch没提升就早停。信号灯数据量不算大模型一般到120到150个epoch就收敛了没必要傻跑200个epoch早停能省训练时间还能避免过拟合。3.3 训练过程中的关键监测点训练时不要只盯着终端里的loss数字重点看两个东西训练曲线和验证集表格。Ultralytics会输出results.png里面有box_loss、cls_loss、dfl_loss三条曲线。如果cls_loss在训练后期还在持续下降但val的mAP不再上升说明模型开始过拟合应该提前停或者加大数据增强。如果box_loss在早期就掉到很低但mAP很差往往是小目标的定位学好了但分类没学好需要回头检查类别样本均衡。每次epoch结束后的验证集输出里最值得关注的是mAP50-95和每个类别的AP。如果发现某个方向类别比如red_left的AP明显低于其他类别说明这个类别的样本不足或形态差异太大需要针对补数据。当时我这边“绿色掉头”类别的mAP只有0.6左右补了八十多张真实掉头灯图片后直接提升到0.85这种针对性补数据比盲目加训练轮数有效得多。训练完成后用best.pt做验证集测试并保存一批带检测框的推理图片肉眼检查一遍。不要只看指标有的错误是mAP体现不出来的——比如把红色箭头识别成红色圆灯类别置信度差不多但通行规则完全不同这种错误必须在可视化检查里抓出来。4. 通行规则识别算法实现4.1 信号灯状态怎么从检测框里读出来模型输出的结果是一个类别ID加一个框类别ID已经携带了“红/黄/绿 方向”的信息。但做个纯分类映射在工程上不够稳因为有时候模型会在相邻类别之间摇摆比如红灯和黄色倒计时灯容易混淆。我额外做了一层颜色校验把检测框裁剪出来转到HSV空间做一个像素比例判定用来和模型输出的类别做交叉验证。HSV判色的核心代码逻辑大概是这样import cv2 import numpy as np def judge_color(crop): hsv cv2.cvtColor(crop, cv2.COLOR_BGR2HSV) mask_red1 cv2.inRange(hsv, (0, 70, 50), (10, 255, 255)) mask_red2 cv2.inRange(hsv, (156, 70, 50), (180, 255, 255)) mask_red mask_red1 | mask_red2 mask_green cv2.inRange(hsv, (35, 70, 50), (85, 255, 255)) mask_yellow cv2.inRange(hsv, (15, 70, 50), (35, 255, 255)) count_red cv2.countNonZero(mask_red) count_green cv2.countNonZero(mask_green) count_yellow cv2.countNonZero(mask_yellow) color_weights { red: count_red, green: count_green, yellow: count_yellow } return max(color_weights, keycolor_weights.get)这段代码的运行速度很快每帧所有检测框加起来也就几毫秒。当模型输出的类别与HSV判读结果一致时采信模型输出不一致时让状态进入“待确认”连续几帧都保持一致才更新最终通行状态。这个机制极大降低了单帧误判带来的干扰。4.2 多帧投票让判断结果稳定下来单帧检测结果一定是不稳定的尤其面对夜间闪烁的黄灯或正在切换的红绿灯模型很容易在相邻帧给出不同结果。我的做法是维护一个长度为5的滑动窗口每进来一帧就把当前检测结果推入窗口窗口内出现次数最多的类别且占比不低于60%时才更新最终状态。举个实际例子第100帧模型输出“green”第101帧由于反光误判成“yellow”第102到104帧又回到“green”。如果只看单帧第101帧会触发一次错误的“黄灯”警告但滑动窗口内“green”占4/5最终状态保持“green”不变误报被完全滤掉。这个窗口长度可以按场景调整。路口的信号灯最短相位一般也在15秒以上5帧窗口完全够用而且引入的延迟只有约0.2秒对通行决策来说可以忽略。4.3 方向箭头与停止线约束模型输出“红色左转”和“红色圆灯”对应的通行规则完全不同——前者意味着左转车道禁止通行但直行可能放行后者意味着所有方向都要停。所以方向信息的准确性直接决定项目的正确性。我在后处理中增加了一个空间约束模块。如果画面中检测到停止线用固定ROI或语义分割得到就把信号灯检测框与停止线的空间关系纳入判断只有信号灯位于停止线的同侧且车道方向匹配时才输出对应的通行指令。这个模块对单路口视频非常实用能过滤掉对面车道信号灯的干扰。输出方面我设计了一个简单的状态机状态包括 GO、STOP、CAUTION、NO_LANE 四类每个状态由“颜色 方向 空间位置”共同决定。状态变化时不仅更新画面上的文字标注还会写入CSV日志方便答辩时展示“算法在哪些帧做出了什么判断、为什么这么判断”的完整轨迹。5. 常见问题与排查技巧实录5.1 小目标漏检严重怎么办漏检是信号灯项目最普遍的问题尤其当灯盘在画面中占比很小。我试下来最有效的手段有三个按优先级排序提高输入分辨率。把imgsz从640提到960是投入产出比最高的一步能立刻看到小目标recall提升。用SAHI做切片推理。将大图切成带重叠的切片分别推理再合并结果对极小的目标很有效但推理耗时翻倍适合离线分析或对实时性要求不高的场景。针对小目标做数据增强。在训练时加入随机裁剪放大模拟“从远处拉近”的观察视角让模型见过更多小尺寸样本。5.2 夜间和逆光场景误判夜间信号灯的自发光特性会让HSV颜色判读很不稳定尤其是红色和黄色在过曝情况下高度相似。我采用的方案是给训练集加入大量夜间和逆光样本同时在HSV判色的阈值上对夜间场景做差异化处理——当检测框的光斑面积明显偏大时说明过曝颜色H通道的判定权重下调改为优先看亮度轮廓的形态特征。逆光场景更麻烦因为灯盘本身可能还没亮背景的强光先让模型产生了幻觉检测。我的对策是加入大量负样本把夕阳、车灯、反光牌这些“容易被误判为信号灯”的物体单独收集成no_false类让模型学会区分。另一个后处理技巧是设置一个较高的置信度阈值0.4以上宁可漏掉远处的小灯也不要频繁产生误报——在通行规则里漏报只是“没识别出来”误报可是会给出错误通行指令的。5.3 训练loss不收敛或震荡如果训练时loss一直不降或反复震荡我建议依次检查这几个地方学习率是否过大默认的0.01对大多数情况没问题但小数据集可能偏大可以降到0.005数据集的标注框是否有多边形、空框、错位问题类别数量是否和数据配置文件一致。还有一次我遇到loss曲线剧烈震荡最后发现是数据文件夹里混入了几十张没有标注对象的背景图模型对这些图无所适从删掉后立刻恢复。如果想要更精细的loss曲线Ultralytics默认只画平滑后的曲线。我在项目里加了一个脚本直接从训练日志里读取每轮的原始loss值画出细分到每个类别的loss趋势图这样能更早发现某个难例类别的过拟合起点。5.4 视频推理卡顿、FPS低演示环节最怕的就是卡。如果推理端用CPU跑YOLOv8s在960分辨率下基本只有每秒一两帧完全没法用。我在项目里预留了三种降级方案图像尺寸从960降到640模型从s换成n推理帧率限制到10FPS并开启跳帧处理。演示时一般用“640 s模型 跳帧”的组合在普通笔记本CPU上也能跑到每秒8到12帧画面基本可接受。如果要用GPU需要确保推理时GPU没被其他进程占用。我曾遇到一场演示前GPU被后台程序占用推理速度还不如CPU排查半天才找到原因。所以项目文档里我专门加了一条演示前用nvidia-smi检查GPU占用状态。6. 工程化落地与后续扩展6.1 模型导出与嵌入式部署YOLOv8导出成ONNX非常简单一行命令yolo export modelbest.pt formatonnx opset12导出后在嵌入式设备上可以先用ONNX Runtime跑在Jetson Nano级别的主板上能到每秒8到12帧做概念验证足够。如果想进一步提速可以转成TensorRT引擎用FP16精度在Jetson Orin上通常可以跑到每秒30帧以上完全满足实时路况处理的需求。对于国产平台比如瑞芯微RK3588的NPUYOLOv8也是官方重点适配的模型之一转成RKNN格式后在NPU上的延迟可以压到20毫秒以内。这一步在项目里作为扩展方案写进了文档答辩时谈到“模型如何落地到真实路侧设备”时非常加分。6.2 这个项目还能往哪些方向扩展做完基础版之后我明显感觉到有几个方向可以继续做深。第一个是加跟踪模块用ByteTrack或BoT-SORT把检测框关联成轨迹这样不仅能看到灯的状态还能判断车辆是否在红灯时越过停止线直接用于违章检测。第二个是扩展到多路摄像头联合判断解决单个视角下信号灯被遮挡时的信息缺失问题。第三个是用更轻量的分类头替代部分后处理逻辑比如在灯盘区域内直接用一个MobileNet小模型判断箭头方向与YOLOv8的检测结果做双通道校验。不过做这些扩展之前一定要先把基础版本的稳定性打磨到位。我在实际测试中最大的体会是这个项目上模型的mAP不是最关键的指标状态判断的稳定性和可解释性才是。你能不能在连续五分钟的视频里做到零误报能不能在答辩时解释清楚每一次状态切换背后的逻辑依据这才是高分项目的核心分水岭。从工程角度说后处理的多帧投票和HSV校验付出的成本远低于继续刷模型精度但带来的可靠性提升是肉眼可见的这笔账一定要算清楚。本文还有配套的精品资源点击获取