纯OpenCV实现的红绿灯颜色识别与路口状态模拟系统（含摄像头/视频输入、Web监控和SQLite日志）-编程实验室

本文还有配套的精品资源，点击获取

简介：用Python搭配OpenCV做的红绿灯实时识别小系统，不靠深度学习，全靠颜色阈值+轮廓检测+形态学处理来定位和判断红、黄、绿灯状态。支持两种输入方式：直接调用本地摄像头，或者读取预存的交通路口视频/图片（模拟路口文件夹里已准备好测试素材）。main.py是主程序，命令行就能切换输入源；video.py负责视频流处理；sql.py自动把每次识别结果（时间、灯色、置信依据）存进SQLite数据库；前端用Flask搭了两个简单页面——index.html看当前识别画面和状态，admin.html查历史记录；static放CSS/JS资源；requirements.txt列清了opencv-python、numpy、flask这些必须依赖；README.md和ss.md讲清楚怎么装、怎么跑、关键逻辑在哪；.gitignore、.idea、__pycache__这些开发缓存文件不用管。整个流程透明易懂，改参数、调阈值、加日志都方便，适合本科生做视觉类毕设或课程设计时快速上手、演示和调试。

1. 项目概述：一个“看得懂红绿灯”的轻量级交通视觉系统

你有没有试过站在路口，盯着红绿灯发呆，突然冒出一个念头：“如果让电脑也像人一样，一眼就认出现在是红灯还是绿灯，会是什么样？”——这个系统就是那个念头落地后的样子。它不靠GPU堆出来的深度学习大模型，也不依赖云端API调用，而是用最扎实的OpenCV图像处理链条，把“红黄绿”三个颜色从复杂的城市街景里干净利落地抠出来、判别准、记下来、还能实时看得到。核心关键词就五个：OpenCV红绿灯识别、Python交通模拟、图像阈值分割、SQLite日志记录、Flask监控界面——它们不是并列的标签，而是一条环环相扣的技术流水线：摄像头喂进画面 → OpenCV用颜色+形状双重校验锁定灯组 → 判定当前通行状态 → 把结果连带时间戳、置信依据写进本地SQLite → Flask把数据库里的数据和实时画面一起端到浏览器上，让你在index.html里看到“此刻是绿灯，已持续3.2秒”，在admin.html里翻查过去两小时里所有红灯触发时刻。整个系统跑在一台普通笔记本上毫无压力，main.py一条命令就能切摄像头或视频回放，video.py里几行代码就能控制帧率和ROI区域，sql.py建表逻辑清晰到可以直接当教学案例抄，前端HTML甚至没用任何框架，纯原生CSS+少量JS就把状态刷新和表格分页做稳了。它不是工业级产品，但恰恰因为“轻”，才真正适合本科生动手：改HSV阈值能立刻看到画面里红色区域变多变少，注释掉一行morphologyEx就能明白为什么黄灯轮廓总被误吞，把sql.py里INSERT语句换成print()就能秒变调试模式。我带过三届毕设学生，凡是选这个方向的，90%都在第一周就跑通了识别逻辑，剩下时间全花在怎么让识别更鲁棒、怎么加路口倒计时模拟、怎么把日志导出成Excel报表上——这才是教学系统该有的样子：门槛低得能踩进去，水又足够深，能让人扎下去练真功夫。

2. 整体设计思路与技术选型逻辑拆解

2.1 为什么坚持“纯OpenCV”，而不是上YOLO或CNN？

这个问题我每次给学生讲都会先问一遍。答案很实在：不是不能用，而是不该用。拿YOLOv8检测红绿灯，mAP可能做到95%，但你需要标注几百张不同光照、角度、遮挡下的路口图片，训练要配CUDA环境，模型文件动辄50MB，部署到树莓派上还得量化剪枝。而本系统用HSV色彩空间做阈值分割，红灯对应H∈[0,10]∪[160,180]（绕过色环断点），绿灯H∈[40,80]，黄灯H∈[15,35]，S>60保证饱和度，V>50保证亮度——这组参数在绝大多数白天室外场景下，单帧处理耗时稳定在12ms（i5-8250U实测），比YOLO推理快4倍。更重要的是，可解释性。当识别出错时，学生能直接cv2.imshow(‘red_mask’, red_mask)看红色掩膜图，发现是广告牌上的红色logo干扰了，马上加一步面积过滤（只保留面积>200像素的轮廓）；而YOLO出错，你只能看到“confidence=0.42”，却不知道模型到底被哪块像素迷惑了。我在ss.md里专门画了一张对比表：传统方法调试周期平均2小时/次错误，深度学习方案平均17小时/次（含数据清洗、重新训练、验证）。课程设计的核心目标是理解“视觉感知如何转化为控制信号”，不是比谁的模型参数更多。

2.2 输入源切换机制：为什么用命令行参数而非配置文件？

main.py支持--source cam和--source video=test.mp4两种模式，背后是video.py里一套统一的VideoStream抽象类。这里刻意避开config.yaml或.env这类配置方式，原因有三：第一，降低初学者认知负荷——本科生第一次接触OpenCV，让他同时学yaml语法、路径解析、异常处理，不如直接告诉“运行python main.py –source cam就是开摄像头”；第二，避免配置污染，比如学生把video路径写成相对路径./模拟路口/traffic_01.mp4，在PyCharm里能跑，在终端里cd到其他目录就报错，而命令行参数强制要求路径明确；第三，为后续扩展留接口，比如未来加--source rtsp=rtsp://192.168.1.100:554/stream，只需在VideoStream.init()里加一个elif分支，完全不影响现有逻辑。实际测试中，我们发现83%的学生在首次部署时卡在路径问题上，而命令行参数让这个错误率降到7%。

2.3 SQLite而非MySQL/PostgreSQL：轻量级日志的必然选择

sql.py只用了三张表：detection_log(id, timestamp, light_color, confidence_score, frame_path)，system_config(key, value)，event_summary(date, red_count, green_count, yellow_count)。选SQLite不是因为“简单”，而是精准匹配场景需求：单机运行、无并发写入（OpenCV主线程顺序写入）、需要原子性事务（防止程序崩溃时日志断裂）、且必须支持SELECT * FROM detection_log WHERE timestamp > '2024-05-20 09:00'这种时间范围查询。MySQL在这里是杀鸡用牛刀——要额外装服务、配用户权限、开3306端口，而SQLite一个.db文件拖到U盘就能带走。更关键的是，SQLite的WAL模式让日志写入几乎不阻塞视频流处理，我们在1080p@30fps下实测，连续写入2小时日志，视频帧率波动小于0.3fps。有个细节很多人忽略：sql.py里所有INSERT都包装在with self.conn:上下文中，确保即使程序意外退出，未提交的事务也会自动回滚，不会留下半截脏数据。

2.4 Flask双页面架构：为什么不用Vue/React做前端？

index.html只做一件事：用<img src="/video_feed">加载MJPEG流，旁边放一个<div id="status">绿灯（持续2.8s）</div>，所有更新靠JavaScript定时GET/api/status；admin.html则用原生fetch拉取/api/logs?limit=50&offset=0，渲染成table。放弃现代前端框架，是因为教学场景下“所见即所得”的调试价值远大于炫酷交互。学生想改状态显示样式？直接打开index.html，找到#status { color: green; }改成color: #28a745;，刷新页面立刻生效；想加个“导出CSV”按钮？在admin.html里加个button，写三行JS调用/api/export_csv接口就行。而如果上了Vue，他得先搞懂webpack打包、vue-router路由、axios拦截器，最后可能连“为什么点击按钮没反应”都要查两小时文档。我们统计过，使用原生HTML/JS的学生，平均前端调试时间是2.3小时，用Vue的是11.7小时——对两周毕设周期来说，这决定了他能不能把精力留给核心的图像算法优化。

3. 核心细节解析与实操要点

3.1 HSV阈值分割：为什么不用RGB，以及那些“玄学”参数怎么来的

OpenCV默认读取BGR格式，但直接在BGR空间做阈值分割是灾难性的。举个例子：正午阳光下，红灯表面反光会让R通道值飙升到255，但G/B通道也有120+，单纯r>200 and g<50 and b<50会把大量白色路标误判为红灯。HSV空间则把颜色（H）、饱和度（S）、明度（V）解耦，红灯的H值稳定在0°附近（色环起点），而白墙的H值是随机的（因为S≈0，H无意义）。所以video.py里核心代码是：

hsv = cv2.cvtColor(frame, cv2.COLOR_BGR2HSV) lower_red1 = np.array([0, 60, 50]) upper_red1 = np.array([10, 255, 255]) lower_red2 = np.array([160, 60, 50]) upper_red2 = np.array([180, 255, 255]) mask_red1 = cv2.inRange(hsv, lower_red1, upper_red1) mask_red2 = cv2.inRange(hsv, lower_red2, upper_red2) red_mask = cv2.bitwise_or(mask_red1, mask_red2)

这里lower_red1/upper_red1抓0-10°的红色，lower_red2/upper_red2抓160-180°的红色，是因为OpenCV的H通道是0-180（非0-360），红色在色环两端。S>60过滤掉灰蒙蒙的雾天红灯，V>50排除阴影里的暗红。这些数值不是拍脑袋定的——我们用calibrate_hsv.py工具（资源包里没放，但README.md提到可索取）让学生用滑块实时调整，对着测试视频逐帧观察mask效果。最终选定的阈值，在模拟路口文件夹所有27段视频中，红灯召回率92.3%，误检率低于4.1%（主要来自消防栓和红色汽车尾灯）。

3.2 形态学处理与轮廓精炼：为什么先开运算再闭运算

拿到颜色掩膜后，直接找轮廓会得到一堆噪点。video.py里这段代码看似简单，实则经过12次迭代：

kernel = np.ones((3,3), np.uint8) red_mask = cv2.morphologyEx(red_mask, cv2.MORPH_OPEN, kernel) # 去除小噪点 red_mask = cv2.morphologyEx(red_mask, cv2.MORPH_CLOSE, kernel) # 填充灯内空洞

OPEN（开运算=先腐蚀后膨胀）能干掉孤立的椒盐噪点，比如树叶晃动在红灯区域投下的细碎光斑；CLOSE（闭运算=先膨胀后腐蚀）则解决红灯LED灯珠之间微小间隙导致的mask断裂问题。关键在kernel尺寸：3×3是黄金尺寸。用5×5 kernel，开运算会把细长的红灯杆误删；用1×1则去不掉噪点。我们做过对比实验：3×3 kernel使有效轮廓数量提升37%，而计算耗时仅增加0.8ms/帧。另外，形态学处理必须放在阈值分割之后、轮廓查找之前——如果先找轮廓再过滤，那些被误检的小轮廓会占用CPU算力去计算面积/长宽比，纯属浪费。

3.3 灯组定位与状态判定：ROI区域约束与“灯序逻辑”的硬编码

仅仅找到红色轮廓还不够，得确认它是“红绿灯”的红灯，而不是远处广告牌。video.py里设置了两个硬约束：第一，限定ROI区域（Region of Interest），默认取画面下半部1/3区域（y>height*2/3），因为国内红绿灯基本安装在路口上方，摄像头仰角拍摄时，灯组集中在画面中上部，但考虑到部分测试视频是平视角度，取下半部能覆盖更多样本；第二，实施“灯序逻辑”：假设标准三灯垂直排列，红灯在最上，黄灯居中，绿灯在底。算法不直接识别单个灯，而是扫描同一垂直线上是否存在三个等间距的高亮圆斑。具体实现是：对每个疑似红灯轮廓，计算其质心(y_c)，然后在y_c±15像素范围内搜索黄色轮廓，再在y_c+60±15像素处搜索绿色轮廓。只有三者同时存在且间距符合预设比例（红-黄:黄-绿≈1:1），才判定为有效灯组。这个逻辑在模拟路口的27段视频中，将误判率从18.6%压到2.3%。当然，它对水平排列的灯组无效——这也是我们在README.md里明确写的限制条件，教学系统不必追求100%通用，而要让学生看清“约束条件如何影响算法边界”。

3.4 Web监控的实时性保障：MJPEG流与状态轮询的协同设计

Flask路由/video_feed返回MJPEG流，本质是不断拼接--boundary\r\nContent-Type: image/jpeg\r\nContent-Length: ...\r\n\r\n[JPEG_DATA]\r\n。关键在generate_frames()函数里，每帧前加time.sleep(0.033)（30fps对应33ms），否则CPU狂刷会导致浏览器卡死。而/api/status接口则采用极简设计：全局变量current_status = {"color": "red", "duration": 0.0}由video.py中的主循环实时更新，API直接return jsonify(current_status)，毫秒级响应。这里有个易踩坑点：不要在/api/status里重新计算状态！曾有学生把整个识别逻辑复制进API路由，导致每次浏览器刷新都触发一次OpenCV计算，CPU飙到100%。正确做法是主循环计算一次，存入共享变量，API只负责读——这是典型的生产环境思维：计算与展示分离。

4. 实操过程与核心环节实现

4.1 从零部署：五步走通全流程（附真实报错排查）

按README.md操作，但学生常卡在第三步。我整理出完整实操链：

第一步：环境准备

python -m venv cv_env source cv_env/bin/activate # Windows用 cv_env\Scripts\activate pip install -r requirements.txt

⚠️ 注意：opencv-python-headless在无GUI服务器上更快，但本地开发建议装opencv-python，否则cv2.imshow()报错。若pip install卡住，换清华源：pip install -i https://pypi.tuna.tsinghua.edu.cn/simple/ opencv-python

第二步：验证摄像头
运行python video.py --test cam，应看到摄像头画面。若报错[ERROR:0] global ... cap_v4l.cpp (893) open VIDEOIO: 检查摄像头是否被Zoom/Teams占用；若黑屏，加参数--cam-id 1尝试其他设备ID。

第三步：跑通主程序（最常卡点）

python main.py --source cam

常见报错及解法：
-ModuleNotFoundError: No module named 'flask': 检查是否激活了虚拟环境（which python应指向cv_env）
-sqlite3.OperationalError: unable to open database file: sql.py里数据库路径写死了./logs/detections.db，确保logs文件夹存在，或手动创建：mkdir logs
- 浏览器打不开http://127.0.0.1:5000: 检查Flask是否启动成功（终端最后一行应有* Running on http://127.0.0.1:5000），防火墙是否拦截端口

第四步：测试视频输入

python main.py --source video="模拟路口/traffic_day.mp4"

路径含中文必须用英文引号包裹，否则Windows下报错FileNotFoundError。若视频播放卡顿，video.py里修改cap.set(cv2.CAP_PROP_FPS, 15)降帧率。

第五步：查看日志
访问http://127.0.0.1:5000/admin，若表格空白，检查detections.db是否生成（用DB Browser for SQLite打开查看表结构），常见原因是sql.py里conn.execute("CREATE TABLE IF NOT EXISTS...")执行失败——在main.py开头加print("DB path:", os.path.abspath("./logs/detections.db"))确认路径。

4.2 关键参数调优实战：三分钟搞定你的路口

所有可调参数集中在config.py（资源包里未显式提供，但video.py顶部有# CONFIG SECTION注释）。我教学生的调优流程是：

先调HSV阈值：运行python calibrate_hsv.py --color red，弹出滑块窗口，拖动H/S/V直到红灯区域被完整勾勒，噪点最少。记下数值，替换video.py里对应lower_red1等变量。
再调轮廓过滤：在video.py里找到MIN_CONTOUR_AREA = 200，若你的路口红灯较小（如远距离监控），调到100；若误检多（如红色汽车），调到300。
最后调灯序间距：RED_YELLOW_GAP = 60是像素距离，用画图软件量测试视频里红黄灯中心距，填入即可。

提示：每次改参数后，务必用python main.py --source video=test.mp4 --debug运行，--debug会保存每帧mask图到debug/文件夹，方便肉眼比对效果。我学生做的一个校园路口项目，就是靠debug图发现黄昏时红灯V值跌到40，于是把lower_red1[2]从50改成40，准确率提升11%。

4.3 SQLite日志深度利用：不只是存数据，更是分析入口

sql.py的insert_detection()方法不仅存基础字段，还存了confidence_score（基于轮廓面积/ROI面积比值）和frame_path（若输入是视频，则存为video_name_frame_1234.jpg）。这意味着你可以做这些事：
-查误检时段：SELECT * FROM detection_log WHERE light_color='red' AND confidence_score < 0.3 ORDER BY timestamp DESC LIMIT 10，找出低置信度红灯，针对性优化阈值。
-统计通行效率：SELECT date(timestamp), COUNT(*) FROM detection_log WHERE light_color='green' GROUP BY date(timestamp)，看每天绿灯总时长。
-导出训练数据：SELECT frame_path FROM detection_log WHERE light_color='yellow' LIMIT 50，批量导出黄灯截图，用于后续训练CNN模型——这就是传统方法向深度学习演进的自然路径。

注意：SQLite默认不支持NOW()函数在INSERT中自动填时间戳，所以sql.py里用datetime.datetime.now().strftime('%Y-%m-%d %H:%M:%S')生成，确保时区一致。若部署到海外服务器，需在main.py开头加os.environ['TZ'] = 'Asia/Shanghai'。

4.4 Flask监控界面定制：三行代码加功能

index.html和admin.html是教学友好型设计，所有增强功能都只需改前端：
-加倒计时显示：在index.html的<div id="status">旁加<div id="countdown">剩余: 0s</div>，然后在updateStatus()函数里加：
javascript if (data.color === 'red') { document.getElementById('countdown').innerText = `剩余: ${Math.max(0, 60 - data.duration).toFixed(1)}s`; }
（假设红灯周期60秒）
-加历史曲线图：在admin.html里引入Chart.js CDN，用/api/logs?hours=24拉取24小时数据，画折线图。
-加报警推送：在sql.py的insert_detection()末尾加：
python if color == 'red' and duration > 120: # 红灯超2分钟 send_alert_email("红灯异常", f"持续{duration}s，请检查设备")
这些都不是框架限制，而是“能力边界清晰”带来的自由——你知道每一行代码的因果，改起来心里有底。

5. 常见问题与排查技巧实录

5.1 典型问题速查表（附根本原因与修复命令）

问题现象	根本原因	修复方案	验证命令
摄像头画面卡在第一帧	OpenCV未释放摄像头资源，上次程序异常退出导致设备被锁	`sudo lsof -i :5000`查占用进程，`kill -9 PID`；或重启摄像头驱动`sudo modprobe -r uvcvideo && sudo modprobe uvcvideo`	`ls /dev/video*`确认设备存在
Web界面显示“Loading…”不更新	Flask未开启调试模式，静态文件404	在app.run()前加`app.config['SEND_FILE_MAX_AGE_DEFAULT'] = 0`禁用缓存	浏览器开发者工具Network标签，看/static/css/style.css是否200
SQLite日志里timestamp全是‘1970-01-01’	系统时间未同步，`datetime.now()`返回纪元时间	`sudo ntpdate -s time.nist.gov`同步时间	`date`命令确认系统时间正确
黄灯识别率极低（<30%）	黄灯HSV阈值太窄（H∈[25,35]），且S值要求过高（S>100）	扩展H范围至[15,45]，S下限降至50	运行`python calibrate_hsv.py --color yellow`实时调参
admin.html表格数据为空但数据库有记录	前端fetch请求跨域被拦截（Chrome安全策略）	在Flask路由里加响应头：`response.headers['Access-Control-Allow-Origin'] = '*'`	浏览器Console看是否有CORS错误

5.2 “踩坑”经验谈：那些文档里不会写的真相

关于光照变化：所有阈值参数都是针对“晴天正午”校准的。阴天时V值整体下降，必须动态调整——我在video.py里埋了个开关：if is_cloudy: lower_red1[2] = 30，通过分析画面平均亮度自动切换。学生常以为调一次阈值就一劳永逸，其实真实路口需要自适应。
关于摄像头选型：罗技C920比手机USB摄像头强太多。后者自动白平衡频繁跳变，导致HSV值忽高忽低；C920支持手动曝光锁定（cap.set(cv2.CAP_PROP_AUTO_EXPOSURE, 0.25)），这是稳定识别的前提。
关于性能瓶颈：不是OpenCV计算慢，而是Flask的MJPEG流占带宽。实测1080p流在局域网延迟达800ms，解决方案是video.py里加cv2.resize(frame, (640,480))降分辨率，延迟压到120ms，人眼完全无感。
关于“假阳性”：最大的干扰源是红色汽车尾灯。我们的对策不是提高阈值（会漏检红灯），而是在灯组定位阶段加“运动一致性”判断：连续5帧都出现在同一位置才计入。这行代码藏在video.py的detect_light_group()函数里，注释写着“防车灯干扰”，但很多学生直接忽略了。

5.3 毕设答辩高频问题预演（附满分回答逻辑）

Q：为什么不用YOLO做检测？精度不是更高吗？
A：（微笑）精度高是事实，但毕设考察的是“问题分解与工程实现能力”。YOLO把红绿灯识别封装成黑盒，学生调参只是改learning_rate，而本系统里每一行cv2.inRange()都对应一个视觉原理——HSV解耦、形态学去噪、轮廓几何约束。答辩时我可以现场演示：把S阈值从60改成30，mask立刻变糊，说明饱和度是关键判据；而YOLO模型文件是二进制，您让我现场改哪个权重？（停顿）这就像教学生做菜，重点不是端出米其林菜品，而是让他亲手切丝、掌火、调味，知道盐放多会咸——本系统就是那把菜刀。

Q：系统在雨天/雾天失效怎么办？
A：（坦诚）确实会，这是传统CV的固有局限。但我的改进方案是分层设计：第一层保持现有HSV逻辑，作为快速响应基线；第二层加一个轻量级CNN（MobileNetV2，仅1.2MB），只在HSV判定置信度<0.5时触发，做二次确认。这样既保留了可解释性，又提升了鲁棒性——这正是我在“后续工作”章节里写的演进路径。

Q：SQLite并发写入会不会丢日志？
A：（自信）不会。sql.py里所有写操作都包裹在with self.conn:中，SQLite的WAL模式保证了原子性。我做过压力测试：用10个线程同时写日志，连续运行48小时，用PRAGMA integrity_check验证数据库完整性，100%通过。不过教学场景下，单线程写入足够，这也是我们选SQLite的初心——够用、可靠、不添乱。

6. 教学延伸与毕设升级指南

这个系统真正的价值，不在它“能做什么”，而在它“能长成什么”。我指导过的优秀毕设，基本都沿着三条路径深化：

路径一：从“识别”到“控制”
在main.py里加一个traffic_controller.py模块，根据识别结果输出GPIO信号：红灯时拉高树莓派某个引脚，接继电器控制真实路口模型的红灯亮起。这里的关键不是硬件，而是时序控制——如何让软件识别的“红灯开始”时刻，与物理灯亮起时刻误差<100ms？答案是用threading.Timer做异步触发，而非阻塞等待。有个学生用这个做了毕业答辩实物，评委当场让他演示“突然插入一辆车，系统能否紧急转红灯”，他提前在video.py里加了运动检测模块，一旦ROI区域出现快速移动物体，立即触发红灯，全场掌声。

路径二：从“单点”到“多路口协同”
把多个摄像头实例化，用Redis做消息队列。A路口绿灯结束前10秒，向Redis发布{"intersection": "A", "next_state": "red", "time": "2024-05-20 14:30:00"}，B路口订阅此消息，提前调整自身绿灯时长——这就是智能交通系统的雏形。难点在于时间同步，我们用NTP服务器+RTT补偿，把多路口时钟误差控在50ms内。

路径三：从“规则”到“学习”
把sql.py里积累的10万条日志导出，用LightGBM训练一个分类器：输入是HSV各通道均值、轮廓数量、面积比等12维特征，输出是灯色。模型体积仅800KB，可嵌入OpenCV pipeline替代阈值分割。有趣的是，这个模型在测试集上准确率96.2%，但它的特征重要性排序显示，“H通道标准差”排第一——说明灯组内部颜色均匀性比绝对H值更能区分真假红灯。这反过来指导我们优化形态学参数，形成“数据反馈算法”的闭环。