1. 从“看错灯”到“听灯色”一个真实需求的诞生几年前我陪一位朋友去车管所更换驾照他因为色觉辨识障碍我们通常说的色盲或色弱在体检环节遇到了麻烦。医生指着那本经典的色觉检查图他皱着眉头努力分辨最终还是有几个图案没能准确说出。虽然最终通过了其他项目的测试但那一刻他脸上的挫败感我至今记得。后来他告诉我最让他担心的其实不是体检而是每天开车上下班时对远处交通信号灯颜色的判断——在强光、阴雨天或者快速扫视的瞬间那种不确定感会让他心跳加速。这个经历让我意识到“红绿灯识别”对色觉障碍者而言不是一个炫酷的科技概念而是一个关乎日常安全与尊严的、实实在在的痛点。市面上的“色盲矫正眼镜”有一定效果但它更像是一种视觉辅助滤镜无法提供确定性的、第二感官的确认。于是一个想法开始萌芽能不能做一个小巧、非侵入式的设备不试图“治疗”或“矫正”用户的视觉而是作为一个可靠的“副驾驶”实时、准确地告知用户当前的信号灯状态这就是“帮助色觉障碍者识别交通灯的设备”这个项目的起点。它不是一个简单的“颜色传感器喇叭”玩具其核心在于在复杂的真实道路环境中实现高可靠性、低延迟的识别并将结果以无歧义的方式如语音或震动传递给用户。这涉及到嵌入式硬件选型、机器视觉算法在资源受限设备上的部署、环境干扰过滤以及人性化的交互设计等多个层面的挑战。本文将从一个硬件开发者的角度完整拆解这样一个设备从构思、原型到核心算法优化的全过程分享其中踩过的坑和验证有效的方案。2. 核心需求拆解我们要解决的到底是什么问题在动手画第一版电路图之前我们必须把“帮助识别交通灯”这个模糊的目标拆解成一系列具体、可衡量的技术指标和用户体验要求。想当然的设计注定会失败。2.1 用户场景与功能边界定义首先我们需要明确设备的使用场景。它主要服务于有色觉辨识障碍的驾驶员、骑行者和行人。因此设备必须非侵入性与安全性不能遮挡或干扰用户正常的视野。最佳形态是类似蓝牙耳机、智能眼镜或车载配件而非需要手持的设备。实时性从“看到”灯到“给出”反馈延迟必须极低理想情况200ms。高速行驶中半秒的延迟可能导致车辆驶过停车线。高可靠性识别准确率必须接近100%误报把红灯报成绿灯和漏报没识别出红灯都是不可接受的。这比识别1000种物体的通用AI模型要求苛刻得多。环境鲁棒性必须在不同天气晴、雨、雾、不同光照逆光、黄昏、夜晚、不同距离和角度下稳定工作。交互明确性反馈方式必须清晰、无歧义且不影响用户接收其他重要声音信息如鸣笛。常见的方案是差异化震动左震代表红灯右震代表绿灯长震代表黄灯或简洁语音“红灯”、“绿灯”。2.2 技术路径选择为什么是“嵌入式AI视觉”而非“简单颜色传感器”很多人的第一反应是用颜色传感器如TCS34725对准红灯读数超过阈值就报警。这个方案在实验室里对着一个红色LED灯或许可行但在现实中会彻底失败。原因如下环境光干扰夕阳、霓虹灯、刹车尾灯都可能是红色传感器无法区分它们和交通信号灯。形状与位置无关颜色传感器只认颜色不认目标。它会把任何进入其视场的红色物体都当作红灯。距离与范围交通灯可能在50米开外颜色传感器的小范围探测完全无效。因此基于计算机视觉的目标检测是唯一可行的技术路径。我们需要的是一个能理解“图像”的“大脑”它需要在一帧图像中找出交通灯的位置无论远近、大小然后判断其亮起的灯的颜色状态。这引出了我们的核心硬件选型。3. 硬件架构设计在性能、功耗与成本间寻找平衡点一个典型的设备硬件架构包含图像采集、计算核心、电源管理、交互输出四大模块。3.1 计算核心选型边缘AI芯片的角逐这是整个设备的心脏。我们有几种选择方案代表芯片/模块优点缺点适用性分析通用MCU轻量级算法STM32H7系列, ESP32-S3功耗低成本极低开发简单。算力有限只能运行非常简单的颜色 blob 检测或固定模板匹配环境鲁棒性极差基本不可用。仅适用于概念验证不推荐用于实际产品。专用视觉处理MCUHimax WE-I Plus, 安谋科技“周易”NPU IP核的芯片功耗和成本平衡较好针对视觉任务优化。生态相对小众算法部署工具链可能不成熟灵活性一般。有潜力的选择需要评估具体的模型支持情况和开发资源。高性能边缘AI计算模块谷歌 Coral USB AcceleratorEdge TPU, 英伟达 Jetson Nano算力强大能运行较复杂的视觉模型如MobileNet SSD精度和速度有保障。功耗较高尤其是Jetson Nano体积较大成本高。Coral 需要连接主机如树莓派。适合作为车载固定设备接车辆电源或作为功能验证的开发平台。片上系统SoC与协处理器树莓派AI加速卡 瑞芯微RK3566/RK3588带NPU灵活性极高生态丰富软硬件开发资源多。RK35xx系列内置NPU算力可达1-6 TOPS。树莓派方案功耗体积仍偏大。瑞芯微等方案需要一定的底层开发能力。强烈推荐的方向。例如采用瑞芯微RV1109带0.5TOPS NPU或RK35660.8TOPS NPU能在功耗1-2W级别实现高性能实时检测。我们的选择与理由经过多轮原型测试我们最终选择了内置NPU的嵌入式SoC方案如瑞芯微RK3566。理由如下算力足够0.8TOPS的算力足以流畅运行一个量化后的、专为交通灯检测优化的YOLO-fastest或MobileNetV3-SSD模型在640x480分辨率下达到95%的准确率和100ms的端到端延迟。功耗可控典型功耗在1.5W左右配合一个大容量充电宝或小型锂聚合物电池可以支持数小时的连续工作。集成度高芯片本身集成了CPU、GPU、NPU、ISP图像信号处理器外围只需搭配摄像头模组和内存/存储系统结构简洁体积可以做得很小。生态支持瑞芯微提供了完整的AI工具链RKNN-Toolkit可以将PyTorch/TensorFlow训练的模型转换、量化并部署到NPU上运行大大降低了开发门槛。3.2 图像采集模块不只是“看清楚”更要“看对”摄像头选型同样关键它决定了算法“吃”进去的原料质量。传感器类型推荐使用全局快门Global Shutter传感器而非常见的卷帘快门Rolling Shutter。在车辆或用户移动时卷帘快门会产生果冻效应导致交通灯形状扭曲影响检测。全局快门能有效避免此问题。镜头与焦距需要一个小广角镜头视场角约70°-90°既能覆盖前方多车道又能保证一定距离外的交通灯在图像中有足够的像素建议目标在图像中至少占30x30像素。需要带红外截止滤光片IR-Cut避免红外光干扰颜色判断尤其是在夜晚。接口MIPI CSI-2接口是首选带宽高与主流SoC连接方便。3.3 交互与供电设计交互输出我们采用了双马达震动器左/右和一个小型扬声器的组合。默认模式为震动模式通过不同的震动模式左单次、右单次、双侧长震分别对应红灯、绿灯、黄灯私密且不干扰环境声音。用户可通过按钮切换至简洁语音模式“Red Light”, “Green Light”。供电系统采用单节18650锂离子电池约3000mAh供电通过高效的DC-DC降压芯片为SoC和摄像头提供稳定的3.3V/1.8V电压。预计满电续航为3-4小时。加入充电管理芯片支持Type-C接口充电。4. 算法核心轻量化模型训练与真实场景优化硬件是躯体算法才是灵魂。我们的目标是训练一个专精于“交通灯状态检测”的轻量化模型。4.1 数据集构建数据的“质”远大于“量”公开的数据集如BDD100K、TT100K虽然包含交通灯但标注不够精细通常只标“交通灯”这个整体而非每个灯粒的状态且场景与国内存在差异。因此自建数据集是关键一步。我们通过行车记录仪、实地拍摄收集了超过5000张包含交通灯的图像覆盖了多种天气与光照晴天、阴天、雨天、黄昏、夜晚。多种角度与距离远、中、近景正对、侧对路口。多种干扰场景广告牌红灯、刹车灯、路灯、霓虹灯。标注工作使用了LabelImg等工具但标注规则至关重要。我们采用两级标注法第一级交通灯面板Traffic Light Panel。标注整个信号灯箱体。类别为traffic_light。第二级灯粒状态Lamp State。在每个灯箱标注框内进一步标注每个圆形灯粒的位置和状态。状态类别为red_on,red_off,green_on,green_off,yellow_on,yellow_off。这种细粒度的标注让模型不仅能找到交通灯还能直接解读其状态一步到位。4.2 模型选择与训练YOLO-fastest 的实战调优我们测试了SSD、YOLOv3-tiny、YOLOv4-tiny和YOLO-fastest系列。最终YOLO-fastest特别是YOLO-fastest-XL在精度和速度的平衡上胜出。它在RK3566 NPU上量化后仅需约30ms即可完成一帧推理640x480输入。训练过程中的几个关键调优点输入分辨率从经典的416x416提升到640x480。虽然计算量增加但对于远处小目标的检测精度提升显著是值得的交换。数据增强除了常规的翻转、裁剪、色彩抖动我们重点加强了模拟运动模糊和光照突变的增强。因为设备在移动中图像模糊是常态。损失函数针对小目标检测我们调整了CIoU损失函数中宽高比的权重并加入了聚焦于难例样本Focal Loss的思想让模型更关注那些容易判断错误的、部分遮挡或光照不佳的交通灯。后处理优化传统的非极大值抑制NMS在密集路口多个交通灯并列可能导致漏检。我们采用了加权框融合Weighted Boxes Fusion, WBF的变体对相邻且高度重叠的、同类别的检测框进行融合提高了召回率。4.3 状态判断逻辑从边界框到“红灯停”模型输出了多个灯粒的检测框和状态置信度。如何综合判断给出一个最终指令这里逻辑必须健壮def judge_light_state(detections, panel_bbox): detections: list of (lamp_bbox, class_name, confidence) panel_bbox: 当前处理的交通灯面板的边界框 red_on_conf 0 green_on_conf 0 yellow_on_conf 0 for bbox, cls, conf in detections: # 只考虑位于当前panel_bbox内部的灯粒检测 if is_inside(bbox, panel_bbox): if cls red_on and conf red_on_conf: red_on_conf conf elif cls green_on and conf green_on_conf: green_on_conf conf elif cls yellow_on and conf yellow_on_conf: yellow_on_conf conf # 决策逻辑置信度最高且超过阈值如0.6的状态为当前状态 # 加入“所有灯都off”的判断防止误触发 states [(red, red_on_conf), (green, green_on_conf), (yellow, yellow_on_conf)] states.sort(keylambda x: x[1], reverseTrue) if states[0][1] 0.6: return states[0][0] # 返回状态名 else: return unknown注意这里有一个极易踩坑的点。有些交通灯的绿灯在熄灭前会有一小段“闪烁”或“低亮度”状态容易被模型误判为green_off和yellow_on的中间状态。我们的解决方案是加入一个状态维持与滤波机制当连续3帧约100ms都检测到同一种亮灯状态时才触发最终的交互反馈。这有效消除了闪烁带来的误报。5. 系统集成与实战调试从实验室到真实马路将训练好的模型部署到RK3566开发板并整合摄像头、震动马达、电池管理就构成了第一版原型机。真正的挑战才刚刚开始。5.1 嵌入式部署流水线RKNN工具链实战RKNN工具链是将PyTorch模型转换成RK芯片能高效运行格式的关键。流程如下模型导出将训练好的PyTorch模型导出为ONNX格式。模型转换使用RKNN-Toolkit2加载ONNX模型进行量化我们采用混合量化对敏感层保留FP16精度并编译生成.rknn文件。C推理引擎开发在RK3566的Linux系统上编写C程序调用RKNN SDK的API完成图像预处理、模型推理和后处理的全流程。这里必须自己实现预处理resize, BGR2RGB, 归一化确保与训练时完全一致。性能优化零拷贝内存使摄像头采集的数据直接存入NPU可访问的内存区域省去一次内存拷贝。多线程流水线一个线程负责采集图像一个线程负责推理一个线程负责状态判断和反馈并行工作以降低端到端延迟。NPU频率调节在检测到持续有交通灯时保持NPU高频运行当一段时间内无目标时降低频率以节省功耗。5.2 真实路测与“诡异”问题排查实验室里准确率99%的模型上路第一天就出了洋相。以下是几个典型问题及解决方案问题一夕阳下的误报。黄昏时分设备频繁将橘红色的夕阳报告为“红灯”。排查检查模型输出发现夕阳区域被检测为red_on但置信度不高约0.4-0.5。同时模型没有检测到任何traffic_light面板。解决方案在状态判断逻辑中增加一个强约束只有先检测到traffic_light面板并且灯粒检测框位于该面板内部时其状态判断才有效。夕阳不符合这个空间约束被成功过滤。问题二对面车道红灯的干扰。在宽阔的多车道道路上本车道是绿灯但对向车道的红灯在图像中也非常显眼。排查模型准确检测到了两个红灯面板且都给出了高置信度。解决方案这是一个语义层面的问题。我们引入了简单的空间位置先验在图像坐标系中通常本车道的信号灯位于图像上半部分的中央区域。我们设定了一个粗略的“感兴趣区域ROI”只对该区域内的交通灯检测结果进行响应。更高级的方案可以尝试结合车道线检测但这会大幅增加计算复杂度。问题三夜间车尾灯串的误识别。夜晚跟车时前车一排刹车灯亮起红彤彤一片。排查模型将某些刹车灯误识别为red_on。观察发现刹车灯通常呈水平排列或成对出现且形状与交通灯圆粒有差异。解决方案1.形状过滤交通灯灯粒的宽高比接近1:1圆形。我们在后处理中对检测框的宽高比进行约束过滤掉明显是长条形的刹车灯。2.运动信息进阶利用连续帧间的光流信息静止在画面中的交通灯和运动的车尾灯可以被区分开。我们在后续版本中加入了轻量化的光流计算效果显著。5.3 功耗与稳定性调优持续路测中设备偶尔会无故重启。用万用表和电流探头监测发现当NPU满负荷运行且摄像头同时启动时存在一个瞬间的电流尖峰导致电压跌落触发低压复位。解决方案电源路径优化在电源输入端增加一个大容量如220μF的钽电容用于缓冲瞬间大电流需求。上电时序控制在软件启动脚本中严格规划上电顺序先让核心SoC稳定运行再上电摄像头模组最后启动NPU推理任务。避免所有高功耗模块同时启动。动态电压频率调节DVFS编写脚本监控芯片温度当温度超过阈值时主动降低NPU和CPU的频率牺牲一点速度换取稳定性。6. 产品化思考与未来展望经过数月的迭代原型机已经能够在大多数城市路况下可靠工作。但从工程原型到真正可用的产品还有很长的路要走。工业设计与人机交互当前原型是开发板加杜邦线非常粗糙。产品形态需要深思熟虑。是做成夹在遮阳板上的车载设备还是集成到蓝牙耳机或智能眼镜中不同的形态决定了不同的交互方式纯震动、骨传导语音等和供电方案。更极致的算法优化我们目前使用的是通用目标检测模型进行微调。未来可以设计一个更专用的网络结构例如第一个子网络快速定位可能的“发光圆形区域”第二个子网络对这些区域进行精细的颜色和状态分类。这种级联结构可能效率更高。多传感器融合的可能性单纯依靠视觉在极端天气如浓雾、暴雨下依然会失效。是否可以融合低成本的毫米波雷达雷达可以提供精确的距离信息辅助判断哪个发光物体是“在路口上方固定位置的”从而与移动的尾灯、广告牌进一步区分。这是一个值得探索的方向。这个项目让我深刻体会到解决一个真实世界的问题尤其是关乎安全的问题技术上的“可行”只是起点。如何在复杂、混乱、多变的环境中做到“可靠”如何在有限的资源算力、功耗、成本内做到“高效”以及如何将冷冰冰的技术转化为温暖、无感、可信赖的用户体验才是最大的挑战。每一次路测中发现的“诡异”bug都是对系统健壮性的宝贵馈赠。对于有志于嵌入式AI和辅助技术的开发者来说这类项目是一个绝佳的练手场它能让你接触到从数据、算法、嵌入式部署到硬件调试的完整链条收获远超任何一个单纯的软件或硬件项目。
