首页 体育 教育 财经 社会 娱乐 军事 国内 科技 互联网 房产 国际 女人 汽车 游戏

你有特斯拉,我有树莓派,纯手工打造车载车牌识别检测系统,家用车秒变智能车

2020-05-16

怎样在不换车的前提下打造一个智能车体系呢?一段时刻以来,本文作者 Robert Lucian Chiriac 一直在考虑让车具有勘探和辨认物体的才干。这个主见十分有意思,由于咱们现已才智过特斯拉的才干,雨过天晴拼装立刻买一辆特斯拉,但他有了一个主见,能够努力完结这一愿望。

所以,作者用树莓派做到了,它放到车上能够实时检测车牌。

在接下来的内容里,咱们将介绍项目中的每个进程,并供给 GitHub 项目地址,其间项目地址目的客户端东西,还其它数据集与预练习模型都能够在原博客结尾处找到。

项目地址:

https://github.com/RobertLucian/cortex-license-plate-reader-client

下面,让咱们看看作者 Robert Lucian Chiriac 是怎样一步步打造一个好用的车载检测辨认体系。

放一张制品图镇楼。

榜首步: 确认项目规模

开端之前,我脑海里呈现的榜首个问题是这样一个体系应该能够做到什么。假如说我活到现在学到了什么,那便是按部就班——从小处着手永远是最好的战略。所以,除了底子的视觉使命,我需求的目的在开车时能清楚地辨认车牌。这个辨认进程包括两个进程:

检测到车牌。

辨认每个车牌鸿沟框内的文本。

我觉得假如我能完结这些使命,再做其他相似的使命就会简略得多。我乃至或许能够创立一个向量空间来表明周围的环境——想想都觉得酷。

在确认这些细节之前,我知道我得先做到:

一个机器学习模型,以未符号的图画作为输入,然后检测到车牌;

某种硬件。简略地说,我需求连接了一个或多个摄像头的核算机体系来调用我的模型。

那就先从榜首件事开端吧——构建目标检测模型。

第二步: 挑选正确的模型

经过细心研讨,我决议用这些机器学习模型:

YOLOv3- 这是当下最快的模型之一,并且跟其他 SOTA 模型的 mAP 恰当。咱们用这个模型来检测物体;

CRAFT 文本检测器 - 咱们用它来检测图画中的文本;

CRNN - 简略来说,它便是一个循环卷积神经网络模型。为了将检测到的字符依照正确的次序排成单词,它有必要是时序数据;

这三个模型是怎样通力合作的呢?下面说的便是操作流程了:

首要,YOLOv3 模型从摄像机处接纳到一帧帧图画,然后在每个帧中找到车牌的鸿沟框。这儿不主张运用十分准确的猜测鸿沟框——鸿沟框比实践检测目标大一些会更好。假如太挤,或许会影响到后续进程的功能;

文本检测器接纳YOLOv3 裁剪过的车牌。这时,假如鸿沟框太小,那么很有或许车牌文本的一部分也被裁掉了,这样猜测成果会不忍目睹。可是当鸿沟框变大时,咱们能够让 CRAFT 模型检测字母的方位,这样每个字母的方位就能够十分准确;

终究,咱们能够将每个单词的鸿沟框从 CRAFT 传递到 CRNN 模型,以猜测处实践单词。

有了我的底子模型架构草图,我能够开端转战硬件了。

第三步: 屈服硬件

当我发现我需求的是一种低功耗的硬件时,我想起了我的旧爱:树莓派。由于它有专属相机 Pi Camera,也有满足的核算才干在不错的帧率下预处理各个帧。Pi Camera 是树莓派的实体摄像机,并且有其老练完好的库。

为了接入互联网,我能够经过 EC25-E 的 4G 接入,我曾经的一个项目里也用过它的一个 GPS 模块,概况可见:

博客地址:https://www.robertlucian.com/2018/08/29/mobile-network-access-rpi/

然后我要开端屈服外壳了——把它挂在轿车的后视镜上应该没问题,所以我终究屈服了一个分为两部分的支撑结构:

在后视镜的方向上,树莓派+ GPS 模块+ 4G 模块将保存下来。关于我运用的 GPS 和 4G 天线,你能够去看一下我关于 EC25-E 模块的文章;

在另一侧,我用一个运用球关节活动的手臂来支撑 Pi Camera

我会用我牢靠的 Prusa i3 MK3S 3D 打印机来打印这些零件,在原文文末也供给了 3D 打印参数。

图 1 :树莓派+4G/GPS 壳的外形

图 2: 运用球关节活动臂支撑 Pi Camera

图 1 和图 2 便是它们烘托时分的姿态。留意这儿的 c 型支架是可插拔的,所以树莓派的附件和 Pi Camera 的支撑物没有和支架一同打印出来。他们同享一个插座,插座上插着支架。假如某位读者想要复现这个项目,这是十分有用的。他们只需求调整后视镜上的支架就能够了。现在,这个底座在我的车上作业得很好。

图 3: Pi Camera 支撑结构的侧视图

图 4: Pi Camera 支撑结构和 RPi 底座的正视图

图 5: 估计的相机视界

图 6: 内置 4G/GPS 模块、Pi Camera,树莓派的嵌入式体系近照

明显,这些东西需求一些时刻来建模,我需求做几回才干得到巩固的结构。我运用的 PETG 资料每层高度为 200 微米。PETG 在 80-90 摄氏度下能够很好地作业,并且对紫外线辐射的抵抗力很强——雨过天晴没有 ASA 好,可是也很强。

这是在 SolidWorks 中屈服的,所以我一切的 SLDPRT/SLDASM 文件以及一切的 STLs 和 gcode 都能够在原文末找到。你也能够用这些东西来打印你自己的版别。

第四步: 练习模型

已然硬件处理了,就该开端练习模型了。咱们应该都知道,尽或许站在伟人的膀子上作业。这便是搬迁学习的核心内容了——先用十分大的数据集来学习,然后再运用这儿面学到的常识。

YOLOv3

我在网上找了许多预先练习过的车牌模型,并没有我开端预期的那么多,但我找到了一个在 3600 张车牌图上练习过的。这个练习集并不大,但也比什么都没有强。除此之外,它也是在 Darknet 的预练习模型的基础上进行练习的,所以我能够直接用。

模型地址:https://github.com/ThorPham/License-plate-detection

由于我现已有了一个能够记载的硬件体系,所以我决议用我的体系在镇上转上几个小时,搜集新的视频帧数据来对前面的模型进行微调。

我运用 VOTT 来对那些含有车牌的帧进行标示,终究创立了一个包括 534 张图画的小数据集,这些图画中的车牌都有符号好的鸿沟框。

数据集地址:https://github.com/RobertLucian/license-plate-dataset

然后我又找到运用 Keras 完结YOLOv3 网络的代码,并用它来练习我的数据集,然后将我的模型提交到这个 repo,这样他人也能用它。我终究在测验集上得到的 mAP 是 90%,考虑到我的数据集十分小,这个成果现已很好了。

Keras 完结:https://github.com/experiencor/keras-yolo3

提交兼并恳求:https://github.com/experiencor/keras-yolo3/pull/244

为了找到一个适宜的网络来辨认文本,我经过了无数次的测验。终究我偶尔发现了 keras-ocr,它打包了 CRAFT 和 CRNN,十分灵敏,并且有预练习过的模型,这太棒了。我决议不对模型进行微调,让它们坚持原样。

keras-ocr 地址:https://github.com/faustomorales/keras-ocr

最重要的是,用 keras-ocr 猜测文本十分简略。底子上便是几行代码。你能够去该项目主页看看这是怎样做到的。

第五步: 布置我的车牌检测模型

模型布置主要有两种办法:

在本地进行一切的推理;

在云中进行推理。

这两种办法都有其应战。榜首个意味着有一个中心「大脑」核算机体系,这很杂乱,并且很贵。第二个面对的则是推迟和基础设施方面的应战,特别是运用 gpu 进行推理。

在我的研讨中,我偶尔发现了一个名为 cortex 的开源项目。它是 AI 范畴的新人,但作为 AI 开发东西的下一个发展方向,这无疑是有意义的。

cortex 项目地址:https://github.com/cortexlabs/cortex

底子上,cortex 是一个将机器学习模型布置为出产网络服务的朦朦胧胧。这意味着我能够专心于我的应用程序,而把其他的作业留给 cortex 去处理。它在 AWS 上完结一切准备作业,而我仅有需求做的便是运用模板模型来编写猜测器。更棒的是,我只需为每个模型编写几十行代码。

如下是从 GitHub repo 获取的 cortex 运转时的终端。假如这都称不上美丽简练,那我就不知道该用什么词来描述它了:

由于这个核算机视觉体系不是为了完结自动驾驶而屈服的,所以推迟对我来说不那么重要,我能够用 cortex 来处理这个问题。假如它是自动驾驶体系的一部分,那么运用云供给商供给的服务就不是一个好主见,至少现在不是。

布置带有 cortex 的 ML 模型只需:

界说 cortex.yaml 文件,它是咱们的 api 的配置文件。每个 API 将处理一种类型的使命。我给 yolov3 的 API 分配的使命是检测给定帧上的车牌鸿沟框,而 crnn API 则是在 CRAFT 文本检测器和 crnn 的协助下猜测车牌号码;

界说每个 API 的猜测器。底子上你要做的便是在 cortex 中界说一个特定类的 predict 办法来接纳一个有用负载,这个有用负载来能够来猜测成果,然后回来猜测成果。就这么简略!

这儿有一个经典 iris 数据集的猜测器示例,但由于文章篇幅原因,详细细节在此就不做赘述了。项目链接里能够找到 cortex 运用这两个 api 的办法——这个项目的一切其他资源都在本文的终究。

# predictor.pyimport boto3
import picklelabels = [ setosa , versicolor , virginica ]
class PythonPredictor:
 def __init__:
 s3 = boto3.client
 s3.download_file
 self.model = pickle.load) def predict:
 measurements = [
 payload[ sepal_length ],
 payload[ sepal_width ],
 payload[ petal_length ],
 payload[ petal_width ],
 ] label_id = self.model.predict[0]
 return labels[label_id]

为了做猜测,你只需求像下面这样运用 curl 就行了:

curl http://***.amazonaws.com/iris-classifier \
 -X POST -H Content-Type: application/json \
 -d '{ sepal_length : 5.2, sepal_width : 3.6, petal_length : 1.4, petal_width : 0.3}'

然后你会收到相似setosa这样的反应,十分简略!

第六步: 开发客户端

有了 cortex 来帮我进行布置之后,我就能够开端屈服客户端了——这算是比较扎手的部分。

我想到了以下架构:

从 Pi Camera 以可承受的分辨率搜集帧速率为 30 FPS 的帧,并将每个帧推入一个公共行列;

在一个独自的进程中,我将从行列中取出帧,并将它们分发给不同线程上的多个作业站;

每个作业线程都会向我的 cortex API 宣布 API 恳求。首要,一个恳求到我的 yolov3API,然后,假如有任何车牌检测到,另一个恳求会带着一批裁剪的车牌发到我的 crnn API。猜测的车牌号码将以文本格局回来;

将每个检测到的车牌推到另一个行列,终究将其播送到浏览器页面。一起,还将车牌号码猜测推到另一个行列,以便稍后将其以 csv 格局保存到磁盘;

播送行列将接纳一组无序的帧。consumer 的使命是先把它们放在一个十分小的缓冲区,每次播送一个新的帧给 client 从头排序。这个 consumer 在另一个进程上独自运转,它还有必要测验坚持行列的巨细固定为指定值,以便以共同的帧速率显现帧。明显,假如行列巨细下降,那么帧率的下降是成份额的,反之亦然;

与此一起,在主进程中还会运转另一个线程,从另一个行列获取猜测和 GPS 数据。当客户端收到停止信号时,猜测、GPS 数据和时刻也会被转存到 csv 文件中。

下图是客户端与 AWS 上的云 api 之间的联系流程图。

图 7: 依据 cortex 供给的云 api 与客户端流程图

在咱们的比如中,客户端是树莓派,推理恳求发送到的云 api 由 AWS 上的 cortex 供给。

客户端的源代码也能够在其 GitHub 中找到:https://github.com/robertlucian/cortex-licens-plate-reader-client

我有必要战胜的一个应战是 4G 的带宽。最好削减此应用程序所需的带宽,以削减或许的 hangups 或对可用数据的过度运用。我决议让 Pi Camera 运用一个十分低的分辨率:480x270。

不过,即便是在这个分辨率下,每一帧的 JPEG 巨细也是大约 100KB。乘以每秒 30 帧就得到 3000KB,也便是 24mb /s,这仍是在没有 HTTP 开支的情况下,这是许多的。

因而,我用了一些小技巧:

将宽度削减到 416 像素,也便是YOLOv3 模型所需求的巨细,并且标准明显是完好无缺的;

将图画转化为灰度图;

移除图片顶部 45% 的部分。这儿的主见是车牌不会呈现在车架的顶部,由于轿车不会飞,对吧?据我所知,删去 45% 的图画并不影响猜测器的功能;

再次转化图画为 JPEG,但此刻的质量变低了许多。

终究得到的帧的巨细大约是 7-10KB,这是十分好的。这恰当于 2.8Mb/s。可是考虑到呼应等一切的开支,它大约是 3.5Mb/s。关于 crnn API,裁剪过的车牌底子不需求太多空间,即便没有进行紧缩,它们的巨细也便是 2-3KB 左右一个。

总而言之,要以 30FPS 的速度运转,推理 api 所需的带宽大约是 6Mb/s,这个数字我能够承受。

成功了!

上面这个是经过 cortex 进行实时推理的比如。我需求大约 20 个配备了 gpu 的实例才干顺利地运转它。依据这一组 gpu 的推迟,你或许需求更多的 gpu 或是更少的实例。从捕获帧到向浏览器窗口播送帧之间的均匀推迟约为 0.9 秒,考虑到揣度发生在很远的当地,这真是太奇特了——到现在我仍是觉得惊奇。

文本辨认部分或许不是最好的,但它至少证明了一点——它能够经过添加视频的分辨率或经过削减摄像机的视场或经过微调来更准确。

至于 GPU 需求数太高的问题,这能够经过优化来处理。例如,在模型中运用混合精度/全半精度 。一般来说,让模型运用混合精度对精度的影响很小,所以咱们并没有做太多的权衡。

总而言之,假如一切的优化都到位,那么将 gpu 的数量从 20 个削减到一个实践上是可行的。假如进行了恰当的优化,乃至一个 gpu 的资源都用不完。

原文地址: https://towardsdatascience.com/i-built-a-diy-license-plate-reader-with-a-raspberry-pi-and-machine-learning-7e428d3c7401

热门文章

随机推荐

推荐文章