keras faster物体检测_【开源项目】特斯拉+树莓派实现车牌识别检测系统
怎樣在不換車的前提下打造一個智能車系統呢？一段時間以來，本文作者 Robert Lucian Chiriac 一直在思考讓車擁有探測和識別物體的能力。
本文來源：機器視覺
怎樣在不換車的前提下打造一個智能車系統呢？一段時間以來，本文作者 Robert Lucian Chiriac 一直在思考讓車擁有探測和識別物體的能力。這個想法非常有意思，因為我們已經見識過特斯拉的能力，雖然沒法馬上買一輛特斯拉(不得不提一下，Model 3 現在看起來越來越有吸引力了)，但他有了一個主意，可以努力實現這一夢想。
所以，作者用樹莓派做到了，它放到車上可以實時檢測車牌。
在接下來的內容里，我們將介紹項目中的每個步驟，并提供 GitHub 項目地址，其中項目地址只是客戶端工具，還其它數據集與預訓練模型都可以在原博客結尾處找到。
項目地址：
https://github.com/RobertLucian/cortex-license-plate-reader-client
這里有一份我下載好的(python代碼)，直接長按下載：
下面，讓我們看看作者 Robert Lucian Chiriac 是如何一步步打造一個好用的車載檢測識別系統。
第一步：確定項目范圍
開始之前，我腦海里出現的第一個問題是這樣一個系統應該能夠做到什么。如果說我活到現在學到了什么，那就是循序漸進——從小處著手永遠是最好的策略。所以，除了基本的視覺任務，我需要的只是在開車時能清楚地識別車牌。這個識別過程包括兩個步驟:
檢測到車牌。
識別每個車牌邊界框內的文本。
我覺得如果我能完成這些任務，再做其他類似的任務(如確定碰撞風險、距離等)就會容易得多。我甚至可能可以創建一個向量空間來表示周圍的環境——想想都覺得酷。
在確定這些細節之前，我知道我得先做到：
一個機器學習模型，以未標記的圖像作為輸入，從而檢測到車牌；
某種硬件。簡單地說，我需要連接了一個或多個攝像頭的計算機系統來調用我的模型。
那就先從第一件事開始吧——構建對象檢測模型。
第二步：選擇正確的模型
經過仔細研究，我決定用這些機器學習模型：
YOLOv3- 這是當下最快的模型之一，而且跟其他 SOTA 模型的 mAP 相當。我們用這個模型來檢測物體；
CRAFT 文本檢測器 - 我們用它來檢測圖像中的文本；
CRNN - 簡單來說，它就是一個循環卷積神經網絡模型。為了將檢測到的字符按照正確的順序排成單詞，它必須是時序數據；
這三個模型是怎么通力合作的呢？下面說的就是操作流程了：
首先，YOLOv3 模型從攝像機處接收到一幀幀圖像，然后在每個幀中找到車牌的邊界框。這里不建議使用非常精確的預測邊界框——邊界框比實際檢測對象大一些會更好。如果太擠，可能會影響到后續進程的性能；
文本檢測器接收 YOLOv3 裁剪過的車牌。這時，如果邊界框太小，那么很有可能車牌文本的一部分也被裁掉了，這樣預測結果會慘不忍睹。但是當邊界框變大時，我們可以讓 CRAFT 模型檢測字母的位置，這樣每個字母的位置就可以非常精確；
最后，我們可以將每個單詞的邊界框從 CRAFT 傳遞到 CRNN 模型，以預測出實際單詞。
有了我的基本模型架構草圖，我可以開始轉戰硬件了。
第三步：設計硬件
當我發現我需要的是一種低功耗的硬件時，我想起了我的舊愛：樹莓派。因為它有專屬相機 Pi Camera，也有足夠的計算能力在不錯的幀率下預處理各個幀。Pi Camera 是樹莓派(Raspberry Pi)的實體攝像機，而且有其成熟完整的庫。
為了接入互聯網，我可以通過 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 的支撐物沒有和支架一起打印出來。他們共享一個插座，插座上插著支架。如果某位讀者想要復現這個項目，這是非常有用的。他們只需要調整后視鏡上的支架就可以了。目前，這個底座在我的車(路虎 Freelander)上工作得很好。
圖 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
CRAFT & CRNN
為了找到一個合適的網絡來識別文本，我經過了無數次的嘗試。最后我偶然發現了 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 方法來接收一個有效負載(所有的 servy part 都已經被平臺解決了)，這個有效負載來可以來預測結果，然后返回預測結果。就這么簡單!
這里有一個經典 iris 數據集的預測器示例，但因為文章篇幅原因，具體細節在此就不做贅述了。項目鏈接里可以找到 cortex 使用這兩個 api 的方法——這個項目的所有其他資源都在本文的最后。
#?predictor.pyimport?boto3
import?picklelabels?=?["setosa",?"versicolor",?"virginica"]
class?PythonPredictor:
????def?__init__(self,?config):
????????s3?=?boto3.client("s3")
????????s3.download_file(config["bucket"],?config["key"],?"model.pkl")
????????self.model?=?pickle.load(open("model.pkl",?"rb"))????def?predict(self,?payload):
????????measurements?=?[
????????????payload["sepal_length"],
????????????payload["sepal_width"],
????????????payload["petal_length"],
????????????payload["petal_width"],
????????]????????label_id?=?self.model.predict([measurements])[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 以可接受的分辨率(800x450 或 480x270)收集幀速率為 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(我們這里可以用一個小分辨率，因為 Pi Camera 的視野非常窄，所以我們仍然可以很容易地識別車牌)。
不過，即使是在這個分辨率下，每一幀的 JPEG 大小也是大約 100KB(0.8MBits)。乘以每秒 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 需求數太高的問題，這可以通過優化來解決。例如，在模型中使用混合精度/全半精度 (FP16/BFP16)。一般來說，讓模型使用混合精度對精度的影響很小，所以我們并沒有做太多的權衡。
總而言之，如果所有的優化都到位，那么將 gpu 的數量從 20 個減少到一個實際上是可行的。如果進行了適當的優化，甚至一個 gpu 的資源都用不完。
【歡迎大家提供行業新聞熱點，商業合作請聯系：18562613430】
推薦閱讀
▼
免責聲明：
凡本公眾號注明“來源：XXX(非智車科技)”的作品，均轉載自其它媒體，轉載目的在于傳遞和分享更多信息，并不代表本平臺贊同其觀點和對其真實性負責，版權歸原作者所有，如有侵權請聯系我們刪除。
總結
以上是生活随笔為你收集整理的keras faster物体检测_【开源项目】特斯拉+树莓派实现车牌识别检测系统的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python utf8_肿么在Pytho
- 下一篇： centos7 界面中文都是方块_Cen