自动车牌识别-XMOS方案 白皮书
ALPR – 概述
自动车牌识别 (ALPR) 在现代城市及其周边地区变得越来越普遍。按车牌收费、停车库、甚至测速仪都使用车牌号来收费。许多这样的系统依靠云计算或人类（有时两者皆要）在整个流程中准确识别车牌号。这种操作昂贵且需要大量资源，依赖于在互联网上传输大量的高分辨率图像。
ALPR系统最明显的应用之一是在高架桥上收取高速费，而不需要使用转发器或在收费站停车。ALPR也正在进入停车场，主要用于通行证和付款。
在未来，更普遍的ALPR系统将用于实现全新的用途，例如汽车定位和停车预约。
图1：当今部署的ALPR系统的例子
为了节省系统成本和电力，未来的ALPR系统将把计算机放在尽可能靠近摄像机的地方，并且只通过低带宽的通信链路发送相关数据。这将节省计算和数据传输的功率，并增加更多可选的回传技术，包括低带宽以及低能耗技术。 在许多应用中，计算模块或相机模块也有可能在大部分时间内保持睡眠状态。这意味着系统的平均功率将因该系统的工作周期而进一步降低。例如，在停车的情况下，以最小计费间隔决定的速率检查车牌可能是有意义的，或者可以使用一个具有1bit信息的传感器，在汽车进入 或离开特定空间时唤醒系统。
图二：在睡眠模式与唤醒模式下的功耗示意图
常见问题
由于车辆速度快、相机与车辆距离远以及照明条件不稳定，目前在高速公路上普遍应用的ALPR需要非常高质量、高分辨率的相机，每秒钟可以处理很多个车牌。除了高质量的光学器件和相机硬件外，这些系统还依赖于大量的云计算，并经常需要人工干预。云处理使这些系统能够顺利运行，但它们需要通过网络发送完整的视频帧，在服务器的硬件上进行计算。这反过来又会运行能效较低的代码--损耗既来自运行服务器操作系统相关的开销，也来自在内存和FLOPS不受限制的情况下，对模型的优化是趋于不严格的。
图3：一个完全基于云的解决方案使用标称值并假设每帧的图像数据为1920x1080x16bit时，它的能源和数据要求
在这种极具挑战性的情况下，从摄像机到ALPR输出的大规模管道可能是有必要的，但对于低速应用，如停车预约、计费和执法，这会导致大量的功率和带宽浪费。下图显示了通过切换到本地计算可以实现的更具性价比的操作步骤。
*为执法目的，可选择存储整个图像
图4：显示基于设备的解决方案，其能源和数据用量比图3中基于云的解决方案低得多
解决方案
大多数公布的ALPR问题的解决方案涉及一个或多个神经网络，它们执行三个不同的任务：
- 在图像中找到对应板块并生成一个子图像
- 对板块中的字符进行分段
- 进行光学字符识别（OCR）
每个推理任务也可以有一个接收者操作特性（ROC），可以进行调整以减少功耗，例如：在向片外传输任何东西之前，确认车牌是同一位置的同一字符串。通过这种方式分解问题，使得系统设计者能够为每个部分的处理选择不同的工具，并权衡准确性、速度、尺寸以及最终成本。例如，车牌定位算法将高度依赖于正在使用的相机，这将是影响系统成本和模型尺寸的一个重要因素。另一方面，字符识别模型会有一个字符必须占据的最小像素数。从这一要求出发，再加上印版尺寸和预期距离等额外的参数，我们可以确定所需最低分辨率的相机，它能够满足给定的精度阈值。例如，如果我们的OCR网络需要10个像素高的字母，那么我们就需要在6米远的距离内，30度的FOV，能够识别10厘米高的字母。
6米远时摄像机能够拍摄的高度: 2 x 6m * tan(30/2 degrees) = 3.2m
画面总高度与字母高度的比值：总高 / 字母高 = 3.2m/0.1m = 32倍字母高度
由于每个字母至少有10个像素，这个传感器至少需要320个像素高。
XMOS的xcore.ai平台非常适合用于低帧率成像应用。xcore.ai上的本地推理比从运行嵌入式操作系统的大型芯片上空转与转发数据的资源密集度耕地。xcore.ai执行的ALPR处理非常接近摄像机，这大大减少了需要能够传递高分辨率图像的设备数量，降低了整个系统的BOM。这里有一些实例应用：视觉唤醒词、特征检测以及ALPR。除了256bit宽的向量处理单元（VPU）提供的人工智能加速外，xcore.ai芯片还可以灵活地在软件中定义ALPR解决方案的以下参数：
- SPI / MIPI / 其他相机接口
- I2C 或 USB 指令和控制
- 通过 USB / I2C / UART / Wi-Fi 等方式回传
- 一个或更多的机器学习模型
- 用于微控制器或定制VPU加速代码的TensorFlow lite
- 类似OpenCV的前/后处理库功能
- 软件图像信号处理（ISP）
图5：xcore.ai框图
除了是一个低功耗和高性价比的平台外，xcore.ai还允许系统设计师在多个设备和配置中使用相同 的芯片和核心机器学习算法。
大多数可以转化为TensorFlow lite int8量化表示的模型都可以使用我们的xcore-opt工具自动转化为在xcore.ai上运行。下表显示了仅内部RAM和基于外部RAM的设计之间的权衡：
| 特性 | SRAM + FLASH | 外置RAM |
|---|---|---|
| 可达300万weights的模型 | 是 | 是 |
| 工作内存要求 > 350kB* | 否 | 是 |
| 最便宜的封装 | 是 | 否 |
| 最低的功耗 | 是 | 否 |
*在xcore-opt中，工作内存可能被用来换取执行速度
XMOS解决方案是停车应用的理想选择，这些应用需要更高分辨率的相机或几个视频帧来补偿照明条件、车辆位置或运动效果。我们可以通过MIPI快速捕获视频，并在片外RAM中存储若干帧（我们的FB265封装原生支持LPDDR，而xcore架构可以在较小的封装中轻松集成其他RAM技术）。然后，xcore可以在车辆停放/离开后的几秒钟内对这些帧进行预处理和推理。
图6：框图显示了xcore.ai上高分辨率（~1920x1080）ALPR解决方案的可能架构
这种方法突出了xcore作为整个系统组件的灵活性。在这种情况下，当需要缓冲视频帧的时候，xcore被外部传感器（雷达/激光雷达等）唤醒。 一旦帧被捕获，处理就开始了，重点是节约功耗和应用可接受的延迟。在停车 的情况下，可接受的延迟可能高达1分钟，只要摄像机在收到中断时能够捕获新的帧。这个方案允许去除昂贵的、耗电的SoC--不适合户外太阳能+电池应用。
真实世界结果
我们的合作伙伴Cloudtop将一个原本是基于云的模型的解决方案调整为完全适用于xcore.ai芯片，不需要外部LPDDR。模型尺寸的节省来自于将问题范围缩小到一个固定的车辆和一个较低分辨率的相机。 XMOS工具还能使模型权重存储在闪存中，减少了对大型模型推理的总工作内存要求。
图7：框图显示了xcore.ai上低分辨率（~640x480）ALPR解决方案的可能架构
在这种情况下，选择了1600x1200的相机传感器，以避免使用窄视场角镜头所带来的机械成本的增加。图像被实时裁剪，以便在片上SRAM中存储一个小的感兴趣的区域（约640x480）供处理。单次检测器（SSD）网络将查看该图像以确定车牌的位置。一旦确定了这个位置，xcore.ai就会向摄像头请求另一帧图像，并只存储检测到车牌的区域。这个较小的图像然后被送入第二个网络，执行OCR以获得描述车牌的字符串。由于这是一个停车应用，可以假设车牌在这两次捕获之间是静止的，我们利用这一知识来进一步减少我们对内存的需求。
这种方法通过消除对片外RAM的需求，大大降低了成本。根据相机接口的要求，xcore.ai的成本可以通过选择xcore.ai系列的其他封装进一步降低。完全适合内部存储器的解决方案的低延迟也通过减少芯片需要唤醒的时间来节省电力。双网络、模块化方法意味着可以从第一阶段得出启发式方法，以确定我们是否需要拍摄第二张照片并进行OCR，例如确定板块边界框是否在移动。
这种方法可适用于快速移动的车辆，采用窄FOV相机和组合检测/识别网络。这有待于进一步研究。
结论
ALPR的挑战可以根据预期的照明条件、视角、每个摄像头识别的车牌数量以及车辆的速度而有很大不同。基于xcore.ai的设计可以通过重新定位图像缓冲区、重新排序处理以及能够从SRAM、闪存或外部LPDDR/SDRAM执行神经网络来配置，以权衡速度、成本、外部内存要求和准确性。
xcore.ai芯片弥补了昂贵、重量级的SOC和传统微控制器之间的差距。与人工智能加速器不同，xcore的灵活性使我们能够结合建立完整系统所需的所有计算类别，包括控制、DSP、人工智能和I/O，用于众多的智能物联网应用。这使得仅使用软件就能快速建立最具成本效益的系统。
如果您想讨论您的ALPR需求并了解更多关于XMOS解决方案的信息，请联系：sales@xmos.com
Copyright © 2021，版权所有。
Xmos Ltd. 是此设计、代码或信息（统称为“信息”）的所有者或被许可人，并“按原样”提供给您，不提供任何类型的明示或暗示保证，并且不承担任何与其使用有关的责任。Xmos Ltd. 不保证信息或其任何特定实施工作不存在或将不存在任何侵权索赔，并且重申不对任何此类索赔承担任何责任。