4. EyeQ视觉感知算法基础

EyeQ 系列芯片(EyeQ4/EyeQ5/EyeQ6)是 Mobileye 面向 ADAS 与自动驾驶的视觉 SoC,其核心价值在于把深度神经网络推理、传统 CV 算法与专用加速器(如 EyeQ4 的 VMP、PMA、MPC 等)整合到一颗低功耗芯片上。理解 EyeQ 的感知算法,不能只停留在“跑了一个 CNN”,而要看清从图像输入到目标、车道线、自由空间三类输出的完整数据流,以及模型如何通过工具链部署到芯片上。

一、EyeQ 上的深度学习推理链路

EyeQ 的推理链路可以概括为:摄像头 RAW/YUV 输入 → ISP 与预处理 → 张量搬运 → 加速器推理 → 后处理 → 感知输出。以 EyeQ4 为例,其算力约 2.5 TOPS,典型功耗 3W 左右,因此模型必须经过量化与剪枝,通常以 INT8 甚至更低精度运行。推理时,卷积、池化等算子被映射到 PMA(Programmable Macro Array)与 MPC(Multi-Threaded Processing Cluster)上,VMP 负责向量运算,CPU(MIPS 核)负责调度与后处理。

一个关键工程点是“张量布局”。EyeQ 工具链要求输入张量按 NHWC 或特定 tile 格式排布,若布局不匹配,会触发额外的 transpose 操作,直接吃掉算力。例如输入 1280×960 的 YUV420 图像,经 resize 到 512×512 后送入网络,若未在工具链中声明正确的 stride 与 padding,推理结果会出现边界错位。

二、目标检测:从 Anchor 到输出解析

EyeQ 上的目标检测多采用单阶段检测器(如 SSD 变体或 Mobileye 自研的 ShallowNet 系列)。以车辆检测为例,网络在多个尺度特征图上输出类别置信度与边界框偏移量。后处理阶段需要做三件事:置信度阈值过滤、NMS(非极大值抑制)、坐标反变换。

假设某层输出 16×16 个 anchor,每个 anchor 预测 4 个偏移量 (tx, ty, tw, th) 和 2 类分数(车、背景)。解码公式为:

bx = (sigmoid(tx) + cx) / grid_w
by = (sigmoid(ty) + cy) / grid_h
bw = anchor_w * exp(tw)
bh = anchor_h * exp(th)

其中 (cx, cy) 是网格坐标。解码后得到归一化框,再乘以原图尺寸。NMS 的 IoU 阈值通常取 0.45~0.5,若阈值过低,相邻车辆会被误合并;过高则同一目标出现多个框。在 EyeQ 上,NMS 由 CPU 或专用硬件完成,需注意每帧耗时预算,通常要求后处理控制在 5ms 以内。

三、车道线识别与自由空间分割

车道线识别在 EyeQ 上通常采用“分割 + 拟合”两阶段。分割网络输出车道线像素概率图,再通过多项式拟合(如三次曲线)得到车道线方程。EyeQ 的车道线模型会输出车道线类型(实线、虚线、路沿)、颜色、置信度以及曲率参数。自由空间分割则输出可行驶区域掩码,常用二分类语义分割,区分“可行驶”与“不可行驶”。

这两类任务的共同点是输出为像素级或曲线级结果,对分辨率敏感。EyeQ 上常用 512×256 或 768×384 的输入分辨率,在精度与延迟之间折中。分割结果还需做形态学后处理与连通域分析,剔除小面积噪声。例如自由空间掩码中若出现孤立的小块“可行驶”区域,应视为误检并剔除。

EyeQ 视觉感知推理与部署数据流 摄像头输入 RAW / YUV420 ISP 预处理 去噪/白平衡/缩放 张量搬运 NHWC / tile 布局 加速器推理 PMA / MPC / VMP INT8 量化 后处理 解码/NMS/拟合 CPU 调度 目标检测输出 车辆/行人/骑行者 类别 + 边界框 + 置信度 NMS IoU 0.45~0.5 车道线识别输出 车道线像素概率图 三次曲线拟合 类型/颜色/曲率/置信度 自由空间分割输出 可行驶区域掩码 二分类语义分割 形态学去噪 + 连通域 EyeQ 工具链部署流程 模型训练 PyTorch / TF 量化与转换 INT8 / 剪枝 编译与映射 算子到加速器 板端部署验证 精度/延迟/功耗

四、模型部署流程与关键参数

EyeQ 模型部署通常遵循“训练 → 量化 → 编译 → 板端验证”四步。训练阶段使用 PyTorch 或 TensorFlow,导出 ONNX 后进入 Mobileye 提供的工具链。量化阶段需要校准集(通常 500~1000 张代表性图像),统计激活值分布,生成 INT8 权重与缩放因子。若量化后精度掉点超过 2%,需检查是否某些层对量化敏感,可对这些层保留 FP16。

编译阶段将算子映射到 EyeQ 的加速器。这里有一个常见坑:某些自定义算子(如 deformable conv)不被支持,需要替换为等效实现或回退到 CPU。编译完成后会生成 .elf 或 .bin 固件,通过刷写工具加载到 EyeQ 的 DDR 中。板端验证时,重点观察三个指标:单帧推理延迟(通常要求 < 30ms)、内存占用(EyeQ4 可用 DDR 约 1GB,需留足余量)、以及感知输出与离线结果的偏差。

实操建议:在量化校准阶段,优先使用与部署场景光照、天气分布一致的图像。若校准集偏白天,夜间场景的量化误差会明显增大。可先用 200 张图快速验证量化可行性,再用 1000 张图做最终校准。

五、结果判读与常见问题

目标检测的判读不能只看 mAP,还要看小目标召回率。EyeQ 上 512×512 输入对 30 像素以下的行人召回率会下降,需通过多尺度特征融合或提高输入分辨率来补偿。车道线的判读关注曲率误差与漏检率,尤其在弯道和车道线磨损场景。自由空间分割则关注边界 IoU 和误检率,若可行驶区域“溢出”到路沿外,说明分割网络对纹理混淆区域区分不足。

常见问题包括:推理延迟突增(检查是否触发了 CPU 回退)、输出框抖动(检查 NMS 阈值与后处理平滑)、以及量化后置信度整体偏低(检查校准集分布与缩放因子)。这些问题大多能在工具链的 profiling 报告中定位到具体层,建议每次部署后保留一份层耗时与内存快照,便于回归对比。