1. 感知模块里红绿灯检测到底在做什么红绿灯检测这件事听起来像是计算机视觉里最基础的目标检测任务但真正落到自动驾驶的感知模块里它的复杂度会瞬间上一个台阶。我最初接触这块代码的时候也以为无非就是拿个检测网络跑一下输出红绿灯的类别和位置就完事了。实际翻完整个模块才发现从相机图像输入到最终给规划控制模块输出一个可用的信号灯状态中间要经过检测、裁剪、分类、时序融合、坐标投影等一连串环节任何一个环节出问题车都可能在一个路口做出错误决策。先把这个模块的定位说清楚。在自动驾驶的感知体系里红绿灯检测属于交通信号识别的一部分它的输出不是简单的“红灯”或“绿灯”而是包含了信号灯在三维空间中的位置、当前颜色状态、以及这个状态的置信度。规划模块拿到这些信息后才能判断当前是否允许通行、是否需要减速停车。所以这个模块的核心价值在于把图像空间里的视觉信号转化成车辆可以理解和执行的结构化决策依据。适合谁来参考这份解析如果你已经有一定深度学习基础了解目标检测的基本概念想深入理解工业级自动驾驶系统里红绿灯检测是怎么工程化落地的那这份内容会很有帮助。如果你是完全的新手建议先补一下卷积神经网络和相机成像模型的基础知识否则看代码里的坐标变换部分会比较吃力。我下面会尽量把每个环节的“为什么”讲透让你不仅知道代码怎么写更知道为什么这么设计。整个红绿灯检测的流程我习惯把它拆成四个阶段来理解检测阶段负责在图像中找到信号灯的位置裁剪阶段把信号灯区域从原图中抠出来分类阶段判断这个信号灯是什么颜色后处理阶段把结果做时序融合并投影到三维空间。这四个阶段环环相扣每个阶段都有各自的坑我后面会逐个拆开讲。2. 整体架构与核心设计思路拆解2.1 为什么采用“检测分类”两阶段方案很多人第一反应会问为什么不直接用一个端到端的网络同时输出信号灯的位置和颜色这个问题我在实际项目里也纠结过。直接端到端看起来更简洁但工程落地时会遇到几个现实问题。第一是数据分布问题。红绿灯在图像里通常只占很小的像素区域直接做多类别检测的话小目标分类精度很难保证。而两阶段方案里检测阶段只负责“是不是信号灯”分类阶段再单独判断颜色每个阶段的任务更单一模型更容易收敛。第二是灵活性问题。实际道路上信号灯的样式差异很大有横排的、竖排的、带箭头的、带倒计时的。如果检测和分类耦合在一起每次新增一种信号灯类型都要重新训练整个网络。而拆开之后检测模型可以复用只需要针对分类模型做增量训练。第三是可解释性问题。两阶段方案里如果最终结果错了你可以快速定位是检测框偏了还是分类判错了。端到端方案出问题时排查起来就麻烦得多。这在功能安全要求极高的自动驾驶场景里是很重要的考量。提示两阶段方案虽然精度和可维护性更好但会带来额外的计算开销。实际部署时要根据算力平台做权衡有些低算力平台会采用轻量化的单阶段方案作为兜底。2.2 检测网络选型的考量检测阶段用的网络结构核心要求是对小目标友好且推理速度快。红绿灯在远距离时可能只有十几个像素常规的检测网络在这个尺度上召回率会明显下降。所以选型时会重点关注特征金字塔结构通过多尺度特征融合来提升小目标检测能力。另一个关键点是锚框设计。红绿灯的宽高比相对固定竖排信号灯通常是高大于宽横排信号灯则是宽大于高。锚框的尺寸和比例需要根据实际数据统计来设定不能直接套用通用检测模型的默认配置。我见过有项目直接拿通用配置跑结果召回率一直上不去后来重新聚类了锚框尺寸才解决。推理速度方面检测阶段需要在车载计算平台上实时运行所以骨干网络通常会选择计算量适中的结构而不是一味追求精度。实际项目中检测阶段的时间预算一般在十几毫秒量级留给分类阶段的时间就更少了。2.3 分类网络的轻量化设计分类阶段的任务相对简单就是把裁剪出来的信号灯区域分成几个颜色类别。因为输入区域很小而且类别数不多所以分类网络可以做得非常轻量。常见做法是用几层卷积加全连接参数量控制在很小的范围内。这里有个容易忽略的细节裁剪区域的分辨率。如果裁剪得太小颜色信息可能不够裁剪得太大又会引入背景干扰。实际项目中会根据信号灯在图像中的实际尺寸分布选一个折中的固定分辨率比如将裁剪区域统一缩放到某个尺寸再送入分类网络。分类网络的输出通常还会经过一个颜色空间转换的预处理。因为红绿灯的颜色在RGB空间里受光照影响很大转换到HSV或者LAB空间后颜色特征会更稳定。这个预处理步骤虽然简单但对分类精度的提升很明显尤其是在逆光或者夜间场景下。2.4 时序融合的必要性单帧检测的结果往往是不稳定的可能这一帧检测到红灯下一帧因为遮挡或者运动模糊就漏检了。如果直接把单帧结果送给规划模块车辆就会出现“一脚刹车一脚油门”的抖动。所以时序融合是必须的。时序融合的基本思路是维护一个滑动窗口记录最近若干帧的检测结果然后通过投票或者滤波的方式输出一个稳定的状态。这里的关键参数是窗口长度和融合策略。窗口太短抗抖动能力不够窗口太长又会导致状态切换延迟车辆可能已经过了停止线才更新状态。实际项目中融合策略通常会结合信号灯的物理特性来设计。比如红灯变绿灯时中间会有一个黄灯过渡融合逻辑要能正确处理这个过渡状态不能简单地把黄灯当成红灯或绿灯。3. 核心细节解析与实操要点3.1 检测阶段的输入预处理检测网络的输入是相机采集的原始图像但原始图像不能直接送进网络。预处理主要包括去畸变、缩放和归一化三个步骤。去畸变是因为相机镜头存在畸变尤其是广角镜头边缘的畸变很严重。如果不去畸变检测框的位置会不准确后续投影到三维空间时误差会更大。去畸变需要用到相机的内参和畸变系数这些参数通常来自相机标定。缩放是把图像调整到网络输入尺寸。这里要注意保持宽高比避免信号灯被拉伸变形。常见的做法是等比缩放后填充或者直接裁剪。填充的好处是不丢失边缘信息裁剪的好处是不引入无效区域。实际项目中会根据信号灯在图像中的分布特点来选择。归一化是把像素值映射到网络期望的范围内。这个步骤看似简单但归一化参数必须和训练时保持一致否则精度会明显下降。我见过有项目因为归一化参数写错导致检测结果完全不可用的情况。# 图像预处理示例 def preprocess_image(image, camera_matrix, dist_coeffs, target_size): # 去畸变 undistorted cv2.undistort(image, camera_matrix, dist_coeffs) # 等比缩放 h, w undistorted.shape[:2] scale min(target_size[0] / w, target_size[1] / h) new_w, new_h int(w * scale), int(h * scale) resized cv2.resize(undistorted, (new_w, new_h)) # 填充到目标尺寸 canvas np.zeros((target_size[1], target_size[0], 3), dtypenp.uint8) canvas[:new_h, :new_w] resized # 归一化 normalized canvas.astype(np.float32) / 255.0 return normalized, scale3.2 检测框的筛选与后处理检测网络输出的原始框通常很多需要经过筛选才能得到最终结果。筛选逻辑主要包括置信度阈值过滤、非极大值抑制和尺寸过滤。置信度阈值过滤是最基本的低于阈值的框直接丢弃。阈值设得太高会漏检设得太低会引入大量误检。实际项目中会根据场景调整比如高速场景可以设高一点城区复杂场景要设低一点。非极大值抑制用来去除重叠的框。这里的关键参数是IoU阈值设得太大会保留太多重叠框设得太小会误删相邻的信号灯。红绿灯场景下同一个灯组里的多个信号灯可能挨得很近所以IoU阈值不能设得太小。尺寸过滤是去掉明显不合理的框。比如太小的框可能是噪声太大的框可能是误检到了其他发光物体。尺寸范围要根据实际数据统计来设定不能拍脑袋决定。注意非极大值抑制在红绿灯场景下有个特殊问题就是同一个灯组里的多个信号灯可能被抑制掉。实际项目中会针对这种情况做特殊处理比如先按灯组聚类再在组内做抑制。3.3 裁剪区域的坐标映射检测框是在缩放后的图像坐标系里的要裁剪原始图像需要把坐标映射回去。这个映射过程要考虑缩放比例和填充偏移。映射的准确性直接影响裁剪区域的质量。如果映射错了裁剪出来的区域可能偏出信号灯导致分类失败。实际项目中通常会在检测框的基础上适当扩大裁剪区域留一些余量避免因为检测框轻微偏移导致信号灯被裁掉一部分。扩大余量的比例也需要权衡。余量太小抗偏移能力不够余量太大引入的背景干扰太多。常见做法是在宽高方向各扩大百分之十到百分之二十具体数值根据检测框的精度来定。3.4 分类阶段的颜色判断逻辑分类网络输出的是每个颜色类别的概率最终取概率最高的类别作为结果。但这里有个细节概率阈值。如果最高概率低于某个阈值说明分类结果不可靠这时候应该输出“未知”而不是强行给一个颜色。这个机制在实际运行中很重要。比如信号灯被部分遮挡时分类网络可能给出一个模棱两可的结果如果强行输出颜色可能导致规划模块做出错误决策。输出“未知”虽然保守但更安全。另外分类阶段还可以结合颜色先验来提升鲁棒性。比如在HSV空间里红色和绿色的色调范围是已知的可以用这个先验来校验分类结果。如果分类网络说是红色但HSV分析显示色调更接近绿色那就需要进一步判断。# 颜色校验示例 def verify_color(image_region, predicted_color): hsv cv2.cvtColor(image_region, cv2.COLOR_BGR2HSV) # 统计色调分布 hue_channel hsv[:, :, 0] # 红色在HSV里跨越0和180附近 red_mask ((hue_channel 10) | (hue_channel 170)) green_mask ((hue_channel 40) (hue_channel 90)) red_ratio np.sum(red_mask) / red_mask.size green_ratio np.sum(green_mask) / green_mask.size # 根据先验校验 if predicted_color red and red_ratio 0.1: return unknown if predicted_color green and green_ratio 0.1: return unknown return predicted_color3.5 时序融合的窗口设计时序融合的窗口长度是个需要仔细调参的量。我试过用固定窗口也试过用指数衰减的加权窗口各有优劣。固定窗口实现简单就是维护一个长度为N的队列每帧结果入队然后统计队列里各类别的数量取最多的作为输出。这种方式的缺点是状态切换有延迟延迟时间大约是窗口长度的一半。指数衰减加权窗口给近期的帧更高的权重状态切换更快但对噪声的抑制能力弱一些。实际项目中我倾向于用固定窗口加状态机的方式状态机负责处理状态切换的逻辑窗口负责提供稳定的观测。状态机的设计要考虑信号灯的物理约束。比如红灯不能直接跳到绿灯中间必须经过黄灯如果有黄灯的话。这个约束可以用来过滤掉一些不合理的状态跳变。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先把运行环境搭起来。这个模块依赖的东西不算多主要是深度学习推理框架和图像处理库。我下面列的是常见配置具体版本可以根据你的平台调整。# 基础依赖 pip install numpy opencv-python # 深度学习推理框架根据你的平台选择 pip install onnxruntime # 或者 tensorrt、pytorch 等相机标定参数需要提前准备好包括内参矩阵和畸变系数。这些参数通常由标定环节产出格式一般是YAML或者JSON。如果你手头没有标定参数可以用棋盘格标定法自己标一组但精度可能不如专业标定设备。模型文件也需要提前准备好包括检测模型和分类模型。模型格式取决于你用的推理框架ONNX格式通用性最好TensorRT格式在NVIDIA平台上性能最优。4.2 检测模型的加载与推理模型加载这块关键是输入输出节点的名称要对上。不同框架导出的模型节点命名规则不一样加载时要仔细核对。我见过有项目因为节点名写错推理结果全是乱的。推理过程本身不复杂就是把预处理后的图像送进模型拿到输出。但要注意批处理维度有些模型要求输入是四维张量批大小、通道、高、宽有些要求是三维。这个在模型导出时就要确认好。# 检测推理示例 class TrafficLightDetector: def __init__(self, model_path, input_size, conf_threshold0.5): self.session onnxruntime.InferenceSession(model_path) self.input_size input_size self.conf_threshold conf_threshold self.input_name self.session.get_inputs()[0].name def detect(self, image): # 预处理 input_tensor, scale preprocess_image(image, self.input_size) input_tensor np.expand_dims(input_tensor.transpose(2, 0, 1), axis0) # 推理 outputs self.session.run(None, {self.input_name: input_tensor}) # 后处理 boxes self.postprocess(outputs, scale, self.conf_threshold) return boxes推理耗时是实际部署时最关心的指标之一。在车载平台上检测阶段通常要控制在十几毫秒以内。如果超了就要考虑模型量化或者剪枝。量化是最常用的手段把浮点模型转成定点模型速度能提升不少精度损失通常在可接受范围内。4.3 裁剪与分类的完整流程裁剪和分类是连在一起的裁剪出来的区域直接送进分类网络。这个流程里最容易出问题的是坐标映射我单独拎出来说。检测框的坐标是在网络输入尺寸下的要映射回原始图像需要除以缩放比例再减去填充偏移。这两个操作顺序不能反反了结果就错了。我建议写个单元测试用已知的坐标验证映射逻辑避免低级错误。# 坐标映射示例 def map_box_to_original(box, scale, padding): x1, y1, x2, y2 box # 先减去填充偏移 x1 max(0, x1 - padding[0]) y1 max(0, y1 - padding[1]) x2 max(0, x2 - padding[0]) y2 max(0, y2 - padding[1]) # 再除以缩放比例 x1 int(x1 / scale) y1 int(y1 / scale) x2 int(x2 / scale) y2 int(y2 / scale) return [x1, y1, x2, y2]裁剪区域送进分类网络之前还要做一次预处理包括缩放到固定尺寸和归一化。这里的归一化参数必须和分类模型训练时一致否则精度会掉。我一般会把训练时的预处理配置存成一个文件推理时直接读避免手写参数出错。分类网络的输出是各类别的概率取最大值对应的类别。但前面说过要加一个置信度阈值低于阈值就输出未知。这个阈值需要根据实际数据调我一般从0.7开始试根据误报和漏报的情况调整。4.4 时序融合的实现细节时序融合我习惯用一个状态机加一个观测窗口来实现。状态机维护当前的状态观测窗口提供每帧的观测结果。状态机的状态包括红灯、绿灯、黄灯、未知。状态转移规则根据交通规则来定。比如当前是红灯观测到绿灯不能直接跳要先经过黄灯如果该路口有黄灯。如果观测到未知保持当前状态不变。观测窗口我一般用长度为5到10的队列。每帧的观测结果入队然后统计各类别的数量。如果某个类别的数量超过窗口长度的一半就认为观测结果是该类别。这个“一半”的比例也可以调设高一点更稳定但切换更慢设低一点切换更快但容易抖动。# 时序融合示例 class TemporalFusion: def __init__(self, window_size7, majority_ratio0.5): self.window deque(maxlenwindow_size) self.majority_ratio majority_ratio self.current_state unknown def update(self, observation): self.window.append(observation) # 统计各类别数量 counts {} for obs in self.window: counts[obs] counts.get(obs, 0) 1 # 找最多的类别 max_count 0 max_label unknown for label, count in counts.items(): if count max_count: max_count count max_label label # 判断是否达到多数 if max_count len(self.window) * self.majority_ratio: self.current_state max_label return self.current_state4.5 三维投影与输出红绿灯检测的最终输出需要包含三维位置这样才能和地图里的信号灯关联起来。三维投影需要用到相机内参和外参以及信号灯在图像中的位置。投影的基本原理是图像上的一个点对应三维空间中的一条射线。要确定三维位置还需要知道信号灯的高度或者距离。实际项目中通常会结合地图信息来估计距离或者用信号灯的已知尺寸来反推。投影的精度直接影响后续关联的准确性。如果投影位置偏了可能关联到错误的信号灯。所以投影之后通常还会做一个关联校验检查投影位置附近是否有地图中的信号灯如果没有就认为这次检测不可靠。# 三维投影示例 def project_to_3d(box_center, camera_matrix, camera_extrinsic, light_height): # 归一化坐标 fx camera_matrix[0, 0] fy camera_matrix[1, 1] cx camera_matrix[0, 2] cy camera_matrix[1, 2] u, v box_center # 计算射线方向 x (u - cx) / fx y (v - cy) / fy z 1.0 ray np.array([x, y, z]) # 根据信号灯高度估计距离 # 这里假设相机高度已知信号灯高度已知 camera_height camera_extrinsic[2, 3] scale (camera_height - light_height) / (ray[1] * -1) point_3d ray * scale # 转到世界坐标系 point_world camera_extrinsic[:3, :3] point_3d camera_extrinsic[:3, 3] return point_world5. 常见问题与排查技巧实录5.1 检测漏检的排查思路漏检是红绿灯检测里最常见的问题排查起来要分情况。如果是远距离信号灯漏检大概率是模型对小目标的能力不够可以考虑增大输入分辨率或者优化特征金字塔结构。如果是近距离信号灯漏检可能是置信度阈值设得太高或者非极大值抑制把正确的框抑制掉了。还有一种情况是特定颜色漏检。比如红色信号灯检测正常绿色信号灯总是漏。这通常是训练数据分布不均衡导致的需要补充绿色信号灯的样本重新训练。排查时我习惯先把中间结果可视化出来看看是检测阶段就没框还是后处理阶段把框过滤掉了。如果是检测阶段没框那就是模型问题如果是后处理过滤掉了那就是参数问题。这个区分很重要能帮你快速定位方向。5.2 分类误判的常见原因分类误判的原因比较多我列几个常见的。光照影响是最常见的。逆光时信号灯可能过曝颜色信息丢失夜间时信号灯可能过暗颜色偏色。这种情况下前面提到的颜色空间转换和颜色先验校验能帮上忙。遮挡也会导致误判。信号灯被树枝或者前车挡住一部分时分类网络可能只看到部分区域判断出错。这种情况可以通过时序融合来缓解因为遮挡通常是暂时的。相似颜色干扰也需要注意。比如黄色信号灯和路灯的暖色调比较接近容易混淆。这种情况下可以在分类网络里加入更多的负样本让模型学会区分。5.3 时序融合的抖动问题时序融合的抖动通常表现为状态频繁切换。比如红灯和未知之间来回跳。这种问题一般是观测窗口太短或者多数比例设得太低。解决方法是增大窗口长度或者提高多数比例。但这两个操作都会增加状态切换的延迟所以要权衡。我一般会先增大窗口长度因为窗口长度对延迟的影响是线性的而多数比例的影响是非线性的调起来更敏感。还有一种抖动是状态机逻辑问题导致的。比如状态机没有正确处理未知状态导致未知状态被当成有效状态参与切换。这种情况要检查状态机的转移规则确保未知状态不会触发状态切换。5.4 性能优化的实操经验性能优化这块我踩过的坑不少。最有效的优化手段是模型量化把浮点模型转成定点模型速度能提升一倍以上精度损失通常在百分之一以内。但量化要注意校准数据的选取校准数据要能覆盖实际场景的分布否则量化后的精度会掉得厉害。输入分辨率也是个优化点。降低输入分辨率能显著提升速度但会牺牲小目标的检测能力。实际项目中我会先统计信号灯在图像中的最小尺寸然后选一个能覆盖这个尺寸的最低分辨率。推理框架的选择也很关键。同样的模型不同框架的推理速度可能差很多。NVIDIA平台上TensorRT通常是最快的但转换过程比较麻烦。ONNX Runtime通用性好但速度一般。实际选型时要根据平台和团队熟悉程度来定。优化手段速度提升精度影响实施难度模型量化高低中降低分辨率高中低模型剪枝中中高推理框架优化中无中批处理低无低5.5 常见问题速查表问题现象可能原因排查方法解决方向远距离漏检小目标能力不足可视化检测输出增大分辨率或优化特征融合特定颜色漏检数据不均衡统计各类别召回率补充样本重新训练分类误判光照或遮挡检查裁剪区域质量颜色先验校验或时序融合状态抖动窗口太短观察状态切换频率增大窗口或提高多数比例投影偏差大标定参数不准用已知点验证投影重新标定或校正参数推理超时模型太大统计各阶段耗时量化或降低分辨率提示排查问题时一定要先把中间结果可视化出来。我见过太多人直接盯着最终输出猜原因结果绕了一大圈才发现是预处理阶段的一个小错误。可视化能帮你快速缩小范围。6. 一些实操后的个人体会这个模块我前后调了挺长时间有几个体会比较深。第一个是数据质量比模型结构更重要。我试过换更复杂的网络结构精度提升很有限但补充了一批夜间和逆光的样本后精度提升很明显。所以如果你精度上不去先别急着改模型看看数据是不是覆盖够了。第二个是时序融合的参数没有万能值。不同路口的信号灯周期不一样有的路口红灯很长有的很短。固定参数的融合逻辑在某些路口表现好换个路口就不行了。后来我的做法是把融合参数做成可配置的根据路口类型动态调整效果好了不少。第三个是投影精度对整体效果影响很大。一开始我只关注检测和分类的精度忽略了投影环节。后来发现投影偏了会导致关联错误整体效果大打折扣。所以标定参数一定要准投影逻辑一定要仔细验证。最后分享一个小技巧调试的时候可以把每一帧的检测框、分类结果、融合状态都画在图像上存成视频。这样回放的时候能直观看到整个流程哪里出了问题比看日志高效得多。这个习惯帮我省了很多排查时间。
1. 感知模块里红绿灯检测到底在做什么红绿灯检测这件事听起来像是计算机视觉里最基础的目标检测任务但真正落到自动驾驶的感知模块里它的复杂度会瞬间上一个台阶。我最初接触这块代码的时候也以为无非就是拿个检测网络跑一下输出红绿灯的类别和位置就完事了。实际翻完整个模块才发现从相机图像输入到最终给规划控制模块输出一个可用的信号灯状态中间要经过检测、裁剪、分类、时序融合、坐标投影等一连串环节任何一个环节出问题车都可能在一个路口做出错误决策。先把这个模块的定位说清楚。在自动驾驶的感知体系里红绿灯检测属于交通信号识别的一部分它的输出不是简单的“红灯”或“绿灯”而是包含了信号灯在三维空间中的位置、当前颜色状态、以及这个状态的置信度。规划模块拿到这些信息后才能判断当前是否允许通行、是否需要减速停车。所以这个模块的核心价值在于把图像空间里的视觉信号转化成车辆可以理解和执行的结构化决策依据。适合谁来参考这份解析如果你已经有一定深度学习基础了解目标检测的基本概念想深入理解工业级自动驾驶系统里红绿灯检测是怎么工程化落地的那这份内容会很有帮助。如果你是完全的新手建议先补一下卷积神经网络和相机成像模型的基础知识否则看代码里的坐标变换部分会比较吃力。我下面会尽量把每个环节的“为什么”讲透让你不仅知道代码怎么写更知道为什么这么设计。整个红绿灯检测的流程我习惯把它拆成四个阶段来理解检测阶段负责在图像中找到信号灯的位置裁剪阶段把信号灯区域从原图中抠出来分类阶段判断这个信号灯是什么颜色后处理阶段把结果做时序融合并投影到三维空间。这四个阶段环环相扣每个阶段都有各自的坑我后面会逐个拆开讲。2. 整体架构与核心设计思路拆解2.1 为什么采用“检测分类”两阶段方案很多人第一反应会问为什么不直接用一个端到端的网络同时输出信号灯的位置和颜色这个问题我在实际项目里也纠结过。直接端到端看起来更简洁但工程落地时会遇到几个现实问题。第一是数据分布问题。红绿灯在图像里通常只占很小的像素区域直接做多类别检测的话小目标分类精度很难保证。而两阶段方案里检测阶段只负责“是不是信号灯”分类阶段再单独判断颜色每个阶段的任务更单一模型更容易收敛。第二是灵活性问题。实际道路上信号灯的样式差异很大有横排的、竖排的、带箭头的、带倒计时的。如果检测和分类耦合在一起每次新增一种信号灯类型都要重新训练整个网络。而拆开之后检测模型可以复用只需要针对分类模型做增量训练。第三是可解释性问题。两阶段方案里如果最终结果错了你可以快速定位是检测框偏了还是分类判错了。端到端方案出问题时排查起来就麻烦得多。这在功能安全要求极高的自动驾驶场景里是很重要的考量。提示两阶段方案虽然精度和可维护性更好但会带来额外的计算开销。实际部署时要根据算力平台做权衡有些低算力平台会采用轻量化的单阶段方案作为兜底。2.2 检测网络选型的考量检测阶段用的网络结构核心要求是对小目标友好且推理速度快。红绿灯在远距离时可能只有十几个像素常规的检测网络在这个尺度上召回率会明显下降。所以选型时会重点关注特征金字塔结构通过多尺度特征融合来提升小目标检测能力。另一个关键点是锚框设计。红绿灯的宽高比相对固定竖排信号灯通常是高大于宽横排信号灯则是宽大于高。锚框的尺寸和比例需要根据实际数据统计来设定不能直接套用通用检测模型的默认配置。我见过有项目直接拿通用配置跑结果召回率一直上不去后来重新聚类了锚框尺寸才解决。推理速度方面检测阶段需要在车载计算平台上实时运行所以骨干网络通常会选择计算量适中的结构而不是一味追求精度。实际项目中检测阶段的时间预算一般在十几毫秒量级留给分类阶段的时间就更少了。2.3 分类网络的轻量化设计分类阶段的任务相对简单就是把裁剪出来的信号灯区域分成几个颜色类别。因为输入区域很小而且类别数不多所以分类网络可以做得非常轻量。常见做法是用几层卷积加全连接参数量控制在很小的范围内。这里有个容易忽略的细节裁剪区域的分辨率。如果裁剪得太小颜色信息可能不够裁剪得太大又会引入背景干扰。实际项目中会根据信号灯在图像中的实际尺寸分布选一个折中的固定分辨率比如将裁剪区域统一缩放到某个尺寸再送入分类网络。分类网络的输出通常还会经过一个颜色空间转换的预处理。因为红绿灯的颜色在RGB空间里受光照影响很大转换到HSV或者LAB空间后颜色特征会更稳定。这个预处理步骤虽然简单但对分类精度的提升很明显尤其是在逆光或者夜间场景下。2.4 时序融合的必要性单帧检测的结果往往是不稳定的可能这一帧检测到红灯下一帧因为遮挡或者运动模糊就漏检了。如果直接把单帧结果送给规划模块车辆就会出现“一脚刹车一脚油门”的抖动。所以时序融合是必须的。时序融合的基本思路是维护一个滑动窗口记录最近若干帧的检测结果然后通过投票或者滤波的方式输出一个稳定的状态。这里的关键参数是窗口长度和融合策略。窗口太短抗抖动能力不够窗口太长又会导致状态切换延迟车辆可能已经过了停止线才更新状态。实际项目中融合策略通常会结合信号灯的物理特性来设计。比如红灯变绿灯时中间会有一个黄灯过渡融合逻辑要能正确处理这个过渡状态不能简单地把黄灯当成红灯或绿灯。3. 核心细节解析与实操要点3.1 检测阶段的输入预处理检测网络的输入是相机采集的原始图像但原始图像不能直接送进网络。预处理主要包括去畸变、缩放和归一化三个步骤。去畸变是因为相机镜头存在畸变尤其是广角镜头边缘的畸变很严重。如果不去畸变检测框的位置会不准确后续投影到三维空间时误差会更大。去畸变需要用到相机的内参和畸变系数这些参数通常来自相机标定。缩放是把图像调整到网络输入尺寸。这里要注意保持宽高比避免信号灯被拉伸变形。常见的做法是等比缩放后填充或者直接裁剪。填充的好处是不丢失边缘信息裁剪的好处是不引入无效区域。实际项目中会根据信号灯在图像中的分布特点来选择。归一化是把像素值映射到网络期望的范围内。这个步骤看似简单但归一化参数必须和训练时保持一致否则精度会明显下降。我见过有项目因为归一化参数写错导致检测结果完全不可用的情况。# 图像预处理示例 def preprocess_image(image, camera_matrix, dist_coeffs, target_size): # 去畸变 undistorted cv2.undistort(image, camera_matrix, dist_coeffs) # 等比缩放 h, w undistorted.shape[:2] scale min(target_size[0] / w, target_size[1] / h) new_w, new_h int(w * scale), int(h * scale) resized cv2.resize(undistorted, (new_w, new_h)) # 填充到目标尺寸 canvas np.zeros((target_size[1], target_size[0], 3), dtypenp.uint8) canvas[:new_h, :new_w] resized # 归一化 normalized canvas.astype(np.float32) / 255.0 return normalized, scale3.2 检测框的筛选与后处理检测网络输出的原始框通常很多需要经过筛选才能得到最终结果。筛选逻辑主要包括置信度阈值过滤、非极大值抑制和尺寸过滤。置信度阈值过滤是最基本的低于阈值的框直接丢弃。阈值设得太高会漏检设得太低会引入大量误检。实际项目中会根据场景调整比如高速场景可以设高一点城区复杂场景要设低一点。非极大值抑制用来去除重叠的框。这里的关键参数是IoU阈值设得太大会保留太多重叠框设得太小会误删相邻的信号灯。红绿灯场景下同一个灯组里的多个信号灯可能挨得很近所以IoU阈值不能设得太小。尺寸过滤是去掉明显不合理的框。比如太小的框可能是噪声太大的框可能是误检到了其他发光物体。尺寸范围要根据实际数据统计来设定不能拍脑袋决定。注意非极大值抑制在红绿灯场景下有个特殊问题就是同一个灯组里的多个信号灯可能被抑制掉。实际项目中会针对这种情况做特殊处理比如先按灯组聚类再在组内做抑制。3.3 裁剪区域的坐标映射检测框是在缩放后的图像坐标系里的要裁剪原始图像需要把坐标映射回去。这个映射过程要考虑缩放比例和填充偏移。映射的准确性直接影响裁剪区域的质量。如果映射错了裁剪出来的区域可能偏出信号灯导致分类失败。实际项目中通常会在检测框的基础上适当扩大裁剪区域留一些余量避免因为检测框轻微偏移导致信号灯被裁掉一部分。扩大余量的比例也需要权衡。余量太小抗偏移能力不够余量太大引入的背景干扰太多。常见做法是在宽高方向各扩大百分之十到百分之二十具体数值根据检测框的精度来定。3.4 分类阶段的颜色判断逻辑分类网络输出的是每个颜色类别的概率最终取概率最高的类别作为结果。但这里有个细节概率阈值。如果最高概率低于某个阈值说明分类结果不可靠这时候应该输出“未知”而不是强行给一个颜色。这个机制在实际运行中很重要。比如信号灯被部分遮挡时分类网络可能给出一个模棱两可的结果如果强行输出颜色可能导致规划模块做出错误决策。输出“未知”虽然保守但更安全。另外分类阶段还可以结合颜色先验来提升鲁棒性。比如在HSV空间里红色和绿色的色调范围是已知的可以用这个先验来校验分类结果。如果分类网络说是红色但HSV分析显示色调更接近绿色那就需要进一步判断。# 颜色校验示例 def verify_color(image_region, predicted_color): hsv cv2.cvtColor(image_region, cv2.COLOR_BGR2HSV) # 统计色调分布 hue_channel hsv[:, :, 0] # 红色在HSV里跨越0和180附近 red_mask ((hue_channel 10) | (hue_channel 170)) green_mask ((hue_channel 40) (hue_channel 90)) red_ratio np.sum(red_mask) / red_mask.size green_ratio np.sum(green_mask) / green_mask.size # 根据先验校验 if predicted_color red and red_ratio 0.1: return unknown if predicted_color green and green_ratio 0.1: return unknown return predicted_color3.5 时序融合的窗口设计时序融合的窗口长度是个需要仔细调参的量。我试过用固定窗口也试过用指数衰减的加权窗口各有优劣。固定窗口实现简单就是维护一个长度为N的队列每帧结果入队然后统计队列里各类别的数量取最多的作为输出。这种方式的缺点是状态切换有延迟延迟时间大约是窗口长度的一半。指数衰减加权窗口给近期的帧更高的权重状态切换更快但对噪声的抑制能力弱一些。实际项目中我倾向于用固定窗口加状态机的方式状态机负责处理状态切换的逻辑窗口负责提供稳定的观测。状态机的设计要考虑信号灯的物理约束。比如红灯不能直接跳到绿灯中间必须经过黄灯如果有黄灯的话。这个约束可以用来过滤掉一些不合理的状态跳变。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先把运行环境搭起来。这个模块依赖的东西不算多主要是深度学习推理框架和图像处理库。我下面列的是常见配置具体版本可以根据你的平台调整。# 基础依赖 pip install numpy opencv-python # 深度学习推理框架根据你的平台选择 pip install onnxruntime # 或者 tensorrt、pytorch 等相机标定参数需要提前准备好包括内参矩阵和畸变系数。这些参数通常由标定环节产出格式一般是YAML或者JSON。如果你手头没有标定参数可以用棋盘格标定法自己标一组但精度可能不如专业标定设备。模型文件也需要提前准备好包括检测模型和分类模型。模型格式取决于你用的推理框架ONNX格式通用性最好TensorRT格式在NVIDIA平台上性能最优。4.2 检测模型的加载与推理模型加载这块关键是输入输出节点的名称要对上。不同框架导出的模型节点命名规则不一样加载时要仔细核对。我见过有项目因为节点名写错推理结果全是乱的。推理过程本身不复杂就是把预处理后的图像送进模型拿到输出。但要注意批处理维度有些模型要求输入是四维张量批大小、通道、高、宽有些要求是三维。这个在模型导出时就要确认好。# 检测推理示例 class TrafficLightDetector: def __init__(self, model_path, input_size, conf_threshold0.5): self.session onnxruntime.InferenceSession(model_path) self.input_size input_size self.conf_threshold conf_threshold self.input_name self.session.get_inputs()[0].name def detect(self, image): # 预处理 input_tensor, scale preprocess_image(image, self.input_size) input_tensor np.expand_dims(input_tensor.transpose(2, 0, 1), axis0) # 推理 outputs self.session.run(None, {self.input_name: input_tensor}) # 后处理 boxes self.postprocess(outputs, scale, self.conf_threshold) return boxes推理耗时是实际部署时最关心的指标之一。在车载平台上检测阶段通常要控制在十几毫秒以内。如果超了就要考虑模型量化或者剪枝。量化是最常用的手段把浮点模型转成定点模型速度能提升不少精度损失通常在可接受范围内。4.3 裁剪与分类的完整流程裁剪和分类是连在一起的裁剪出来的区域直接送进分类网络。这个流程里最容易出问题的是坐标映射我单独拎出来说。检测框的坐标是在网络输入尺寸下的要映射回原始图像需要除以缩放比例再减去填充偏移。这两个操作顺序不能反反了结果就错了。我建议写个单元测试用已知的坐标验证映射逻辑避免低级错误。# 坐标映射示例 def map_box_to_original(box, scale, padding): x1, y1, x2, y2 box # 先减去填充偏移 x1 max(0, x1 - padding[0]) y1 max(0, y1 - padding[1]) x2 max(0, x2 - padding[0]) y2 max(0, y2 - padding[1]) # 再除以缩放比例 x1 int(x1 / scale) y1 int(y1 / scale) x2 int(x2 / scale) y2 int(y2 / scale) return [x1, y1, x2, y2]裁剪区域送进分类网络之前还要做一次预处理包括缩放到固定尺寸和归一化。这里的归一化参数必须和分类模型训练时一致否则精度会掉。我一般会把训练时的预处理配置存成一个文件推理时直接读避免手写参数出错。分类网络的输出是各类别的概率取最大值对应的类别。但前面说过要加一个置信度阈值低于阈值就输出未知。这个阈值需要根据实际数据调我一般从0.7开始试根据误报和漏报的情况调整。4.4 时序融合的实现细节时序融合我习惯用一个状态机加一个观测窗口来实现。状态机维护当前的状态观测窗口提供每帧的观测结果。状态机的状态包括红灯、绿灯、黄灯、未知。状态转移规则根据交通规则来定。比如当前是红灯观测到绿灯不能直接跳要先经过黄灯如果该路口有黄灯。如果观测到未知保持当前状态不变。观测窗口我一般用长度为5到10的队列。每帧的观测结果入队然后统计各类别的数量。如果某个类别的数量超过窗口长度的一半就认为观测结果是该类别。这个“一半”的比例也可以调设高一点更稳定但切换更慢设低一点切换更快但容易抖动。# 时序融合示例 class TemporalFusion: def __init__(self, window_size7, majority_ratio0.5): self.window deque(maxlenwindow_size) self.majority_ratio majority_ratio self.current_state unknown def update(self, observation): self.window.append(observation) # 统计各类别数量 counts {} for obs in self.window: counts[obs] counts.get(obs, 0) 1 # 找最多的类别 max_count 0 max_label unknown for label, count in counts.items(): if count max_count: max_count count max_label label # 判断是否达到多数 if max_count len(self.window) * self.majority_ratio: self.current_state max_label return self.current_state4.5 三维投影与输出红绿灯检测的最终输出需要包含三维位置这样才能和地图里的信号灯关联起来。三维投影需要用到相机内参和外参以及信号灯在图像中的位置。投影的基本原理是图像上的一个点对应三维空间中的一条射线。要确定三维位置还需要知道信号灯的高度或者距离。实际项目中通常会结合地图信息来估计距离或者用信号灯的已知尺寸来反推。投影的精度直接影响后续关联的准确性。如果投影位置偏了可能关联到错误的信号灯。所以投影之后通常还会做一个关联校验检查投影位置附近是否有地图中的信号灯如果没有就认为这次检测不可靠。# 三维投影示例 def project_to_3d(box_center, camera_matrix, camera_extrinsic, light_height): # 归一化坐标 fx camera_matrix[0, 0] fy camera_matrix[1, 1] cx camera_matrix[0, 2] cy camera_matrix[1, 2] u, v box_center # 计算射线方向 x (u - cx) / fx y (v - cy) / fy z 1.0 ray np.array([x, y, z]) # 根据信号灯高度估计距离 # 这里假设相机高度已知信号灯高度已知 camera_height camera_extrinsic[2, 3] scale (camera_height - light_height) / (ray[1] * -1) point_3d ray * scale # 转到世界坐标系 point_world camera_extrinsic[:3, :3] point_3d camera_extrinsic[:3, 3] return point_world5. 常见问题与排查技巧实录5.1 检测漏检的排查思路漏检是红绿灯检测里最常见的问题排查起来要分情况。如果是远距离信号灯漏检大概率是模型对小目标的能力不够可以考虑增大输入分辨率或者优化特征金字塔结构。如果是近距离信号灯漏检可能是置信度阈值设得太高或者非极大值抑制把正确的框抑制掉了。还有一种情况是特定颜色漏检。比如红色信号灯检测正常绿色信号灯总是漏。这通常是训练数据分布不均衡导致的需要补充绿色信号灯的样本重新训练。排查时我习惯先把中间结果可视化出来看看是检测阶段就没框还是后处理阶段把框过滤掉了。如果是检测阶段没框那就是模型问题如果是后处理过滤掉了那就是参数问题。这个区分很重要能帮你快速定位方向。5.2 分类误判的常见原因分类误判的原因比较多我列几个常见的。光照影响是最常见的。逆光时信号灯可能过曝颜色信息丢失夜间时信号灯可能过暗颜色偏色。这种情况下前面提到的颜色空间转换和颜色先验校验能帮上忙。遮挡也会导致误判。信号灯被树枝或者前车挡住一部分时分类网络可能只看到部分区域判断出错。这种情况可以通过时序融合来缓解因为遮挡通常是暂时的。相似颜色干扰也需要注意。比如黄色信号灯和路灯的暖色调比较接近容易混淆。这种情况下可以在分类网络里加入更多的负样本让模型学会区分。5.3 时序融合的抖动问题时序融合的抖动通常表现为状态频繁切换。比如红灯和未知之间来回跳。这种问题一般是观测窗口太短或者多数比例设得太低。解决方法是增大窗口长度或者提高多数比例。但这两个操作都会增加状态切换的延迟所以要权衡。我一般会先增大窗口长度因为窗口长度对延迟的影响是线性的而多数比例的影响是非线性的调起来更敏感。还有一种抖动是状态机逻辑问题导致的。比如状态机没有正确处理未知状态导致未知状态被当成有效状态参与切换。这种情况要检查状态机的转移规则确保未知状态不会触发状态切换。5.4 性能优化的实操经验性能优化这块我踩过的坑不少。最有效的优化手段是模型量化把浮点模型转成定点模型速度能提升一倍以上精度损失通常在百分之一以内。但量化要注意校准数据的选取校准数据要能覆盖实际场景的分布否则量化后的精度会掉得厉害。输入分辨率也是个优化点。降低输入分辨率能显著提升速度但会牺牲小目标的检测能力。实际项目中我会先统计信号灯在图像中的最小尺寸然后选一个能覆盖这个尺寸的最低分辨率。推理框架的选择也很关键。同样的模型不同框架的推理速度可能差很多。NVIDIA平台上TensorRT通常是最快的但转换过程比较麻烦。ONNX Runtime通用性好但速度一般。实际选型时要根据平台和团队熟悉程度来定。优化手段速度提升精度影响实施难度模型量化高低中降低分辨率高中低模型剪枝中中高推理框架优化中无中批处理低无低5.5 常见问题速查表问题现象可能原因排查方法解决方向远距离漏检小目标能力不足可视化检测输出增大分辨率或优化特征融合特定颜色漏检数据不均衡统计各类别召回率补充样本重新训练分类误判光照或遮挡检查裁剪区域质量颜色先验校验或时序融合状态抖动窗口太短观察状态切换频率增大窗口或提高多数比例投影偏差大标定参数不准用已知点验证投影重新标定或校正参数推理超时模型太大统计各阶段耗时量化或降低分辨率提示排查问题时一定要先把中间结果可视化出来。我见过太多人直接盯着最终输出猜原因结果绕了一大圈才发现是预处理阶段的一个小错误。可视化能帮你快速缩小范围。6. 一些实操后的个人体会这个模块我前后调了挺长时间有几个体会比较深。第一个是数据质量比模型结构更重要。我试过换更复杂的网络结构精度提升很有限但补充了一批夜间和逆光的样本后精度提升很明显。所以如果你精度上不去先别急着改模型看看数据是不是覆盖够了。第二个是时序融合的参数没有万能值。不同路口的信号灯周期不一样有的路口红灯很长有的很短。固定参数的融合逻辑在某些路口表现好换个路口就不行了。后来我的做法是把融合参数做成可配置的根据路口类型动态调整效果好了不少。第三个是投影精度对整体效果影响很大。一开始我只关注检测和分类的精度忽略了投影环节。后来发现投影偏了会导致关联错误整体效果大打折扣。所以标定参数一定要准投影逻辑一定要仔细验证。最后分享一个小技巧调试的时候可以把每一帧的检测框、分类结果、融合状态都画在图像上存成视频。这样回放的时候能直观看到整个流程哪里出了问题比看日志高效得多。这个习惯帮我省了很多排查时间。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
