高龍琛，邢 猛，丁 月，劉 政，邢建平

(山東大學(xué)微電子學(xué)院，山東 濟(jì)南 250101)

公安部交通管理局發(fā)布消息，2020 年全國機(jī)動(dòng)車保有量達(dá)3.72 億輛，其中汽車2.81 億輛。隨著車輛大規(guī)模的投入，人們的出行早已離不開汽車，在我們享受車輛帶來便利的同時(shí)，也伴隨著危險(xiǎn)事故的發(fā)生，疲勞駕駛已經(jīng)成為造成交通事故的主要原因之一[1]。因此，監(jiān)測、警示車輛駕駛?cè)藛T已然成為控制疲勞駕駛事故發(fā)生的主要手段之一。

本文提出的嵌入式疲勞駕駛監(jiān)測系統(tǒng)，融合了深度學(xué)習(xí)與流媒體數(shù)據(jù)傳輸，以Firefly－RK3399 開發(fā)板為硬件平臺(tái)，基于Linux 操作系統(tǒng)，設(shè)計(jì)出一套前端檢測駕駛員疲勞狀態(tài)，后端將疲勞狀態(tài)視頻流信息以推流的方式上傳至流媒體服務(wù)器，用于后臺(tái)遠(yuǎn)程監(jiān)控的嵌入式視頻監(jiān)控系統(tǒng)。方便用戶實(shí)時(shí)觀測車內(nèi)駕駛?cè)说钠跔顟B(tài)、掌握車內(nèi)具體情況、及時(shí)對車內(nèi)人員進(jìn)行警醒，降低疲勞駕駛給社會(huì)所帶來的影響。

1 嵌入式疲勞駕駛監(jiān)控系統(tǒng)設(shè)計(jì)方案

本系統(tǒng)應(yīng)用于疲勞駕駛行為監(jiān)控場景，旨在監(jiān)測司機(jī)疲勞程度，對疲勞司機(jī)進(jìn)行車內(nèi)警醒以及后臺(tái)遠(yuǎn)程監(jiān)控等。系統(tǒng)架構(gòu)圖如圖1 所示，系統(tǒng)整體主要分為車載監(jiān)控系統(tǒng)以及遠(yuǎn)程監(jiān)控系統(tǒng)兩大部分。

圖1 系統(tǒng)架構(gòu)圖

1.1 車載監(jiān)控系統(tǒng)

車載監(jiān)控系統(tǒng)包括Firefly－RK3399 開發(fā)板、攝像頭、疲勞駕駛檢測算法。主要任務(wù)為:車載攝像頭采集駕駛員面部信息，傳遞給嵌入式RK3399 開發(fā)板，開發(fā)板內(nèi)移植的疲勞駕駛檢測算法對采集到的圖像進(jìn)行人臉的定位以及人臉關(guān)鍵點(diǎn)的檢測，最終生成一個(gè)含有疲勞狀態(tài)的視頻流。

1.2 遠(yuǎn)程監(jiān)控系統(tǒng)

遠(yuǎn)程監(jiān)控系統(tǒng)包括Nginx 服務(wù)器、多線程傳輸模塊、Nginx-http-flv-module 第三方擴(kuò)展模塊。其主要工作如下:RK3399 開發(fā)板通過多線程傳輸模塊，采用FFmpeg 進(jìn)行RTMP 推流，將疲勞狀態(tài)視頻流信息以推流方式上傳至基于Nginx 流媒體服務(wù)器，客戶端可通過任意Flash 播放器即可實(shí)現(xiàn)對疲勞狀態(tài)視頻流信息的遠(yuǎn)程拉流。

2 關(guān)鍵技術(shù)點(diǎn)

2.1 疲勞駕駛檢測算法

目前針對疲勞駕駛檢測的主要方法有三種，檢測車輛行為特征、檢測駕駛員生理特征、檢測駕駛員外部特征，其中通過計(jì)算機(jī)視覺來檢測駕駛員外部特征最為便捷有效[2]。因此本文采用了YOLOv3-tiny＋Dlib 人臉68 特征點(diǎn)進(jìn)行疲勞狀態(tài)的檢測。

2.1.1 YOLOv3-tiny＋Dlib

目前主流的人臉關(guān)鍵點(diǎn)檢測算法往往計(jì)算量大，設(shè)備性能要求較高，移植復(fù)雜等，不適合嵌入式端的開發(fā)與應(yīng)用。而YOLOv3-tiny 是YOLOv3 的簡化版本，其網(wǎng)絡(luò)相對簡單，計(jì)算量較小，比較適合移動(dòng)端尤其是嵌入式設(shè)備中運(yùn)行。

YOLOv3-tiny 網(wǎng)絡(luò)結(jié)構(gòu)如圖2 所示。僅保留了24 層網(wǎng)絡(luò)，相比標(biāo)準(zhǔn)版3 個(gè)尺度輸出層，YOLOv3-tiny 只有13 pixel×13 pixel 和26 pixel×26 pixel 的兩個(gè)不同尺度YOLO 輸出層[3]，計(jì)算量大大減小。相比YOLOv3 標(biāo)準(zhǔn)版，tiny 版損失了精度，但是其速度更快，因此本文選取了YOLOv3-tiny 做為疲勞駕駛算法中人臉檢測算法。

圖2 YOLOv3-tiny 網(wǎng)絡(luò)結(jié)構(gòu)

WIDER FACE 公開數(shù)據(jù)集共含有32 203 張圖像和393 703 個(gè)高精度人臉包圍框[4]，其人臉尺度，人臉姿態(tài)等具有較大的變化，與疲勞狀態(tài)相吻合，因此選取該數(shù)據(jù)集進(jìn)行模型訓(xùn)練。

調(diào)用Dlib 官方提供的預(yù)測器shape＿ predictor ＿68＿ face＿landmarks.dat 進(jìn)行人臉68 關(guān)鍵點(diǎn)的標(biāo)定。

2.1.2 疲勞狀態(tài)分析

(1)PERCLOS 值

當(dāng)駕駛過程中出現(xiàn)疲勞狀態(tài)時(shí)，駕駛員本能反應(yīng)是打哈欠、眼睛頻繁閉合等動(dòng)作，通過計(jì)算眼睛閉合的頻率和持續(xù)時(shí)間即可反映疲勞的狀態(tài)，因此本文采取Walt Wierwille 提出的PERCLOS 來度量疲勞狀態(tài)[5]。PERCLOS 定義為某時(shí)間段內(nèi)眼睛的閉合程度，當(dāng)一定時(shí)間間隔內(nèi)眼睛閉合所占的時(shí)間比例超過15%時(shí)即認(rèn)為是疲勞狀態(tài)[6]。

(2)眼睛縱橫比

眼睛縱橫比(Eye Aspest Ratio，EAR)可以檢測眼睛的開合程度[7]，其定義如式(1)所示。式(1)中:p1～p6為眼睛關(guān)鍵點(diǎn)，關(guān)鍵點(diǎn)分布如圖3 所示。

圖3 眼部縱橫比

當(dāng)眼睛縱橫比下降到一定閾值后，我們可以判斷出眼睛的閉眼動(dòng)作。

(3)嘴巴縱橫比

類似眼睛縱橫比，嘴巴縱橫比(Mouth Aspect Ratio，MAR)定義如式(2)所示。其中p1～p8為嘴巴關(guān)鍵點(diǎn)。嘴巴縱橫比同樣可反應(yīng)出嘴巴的開合程度，關(guān)鍵點(diǎn)分布見圖4。

圖4 嘴巴縱橫比

2.1.3 疲勞判斷

本文采用視頻幀數(shù)代替時(shí)間尺度來反應(yīng)疲勞狀態(tài)。

如式(3)所示，當(dāng)PERCLOS 的值大于給定閾值時(shí)，即判定為疲勞駕駛。

2.2 遠(yuǎn)程監(jiān)控系統(tǒng)框架

遠(yuǎn)程監(jiān)控系統(tǒng)主要實(shí)現(xiàn)對車內(nèi)提取的視頻流信息進(jìn)行數(shù)據(jù)上傳，工作人員實(shí)時(shí)后臺(tái)監(jiān)控，以達(dá)到對車內(nèi)信息的及時(shí)掌握以及記錄等。

由于遠(yuǎn)程監(jiān)控需要長時(shí)間作業(yè)且要求實(shí)時(shí)性相對較高，HTTP 視頻流傳輸延時(shí)多在10 s 以上，不能滿足系統(tǒng)需求，故本文采用了延時(shí)相對較低的實(shí)時(shí)消息傳輸協(xié)議(real time messaging protocol，RTMP)，且隨著互聯(lián)網(wǎng)的飛速發(fā)展，越來越多的移動(dòng)設(shè)備接入互聯(lián)網(wǎng)，IPv4 地址即將消耗殆盡，因此下一代互聯(lián)網(wǎng)應(yīng)景而生，本設(shè)計(jì)在RTMP 通信時(shí)同時(shí)支持IPv4/IPv6，用戶可根據(jù)需求采用不同的通信協(xié)議來進(jìn)行視頻流的讀取，更好地適應(yīng)下一代互聯(lián)網(wǎng)的發(fā)展趨勢。

嵌入式Linux 系統(tǒng)內(nèi)搭載Nginx 高性能的開源輕量級Web 服務(wù)器，該服務(wù)器占有內(nèi)存較少、具有較強(qiáng)的并發(fā)能力，適用于連續(xù)高并發(fā)的視頻監(jiān)控[8]。

由于Nginx 服務(wù)器默認(rèn)配置是不支持RTMP 模塊，需要通過配置第三方擴(kuò)展模塊來進(jìn)行RTMP 協(xié)議的傳輸。本設(shè)計(jì)內(nèi)的Nginx 服務(wù)器配置Nginxhttp-flv 第三方擴(kuò)展模塊，支持GOP 緩存，能夠有效地降低延時(shí)，減少響應(yīng)時(shí)間。

2.2.1 Nginx 服務(wù)器

Nginx 服務(wù)器采用了Master-Worker 的工作模式[9]，該模式是指同時(shí)由兩個(gè)進(jìn)程協(xié)同工作，明確分工，將大任務(wù)分解為若干小任務(wù)，提高系統(tǒng)的吞吐量，加速服務(wù)器的工作效率。服務(wù)器的主要工作流程如圖5 所示。

圖5 服務(wù)器系統(tǒng)架構(gòu)圖

在嵌入式開發(fā)板啟動(dòng)Nginx 服務(wù)器成功時(shí)，服務(wù)器會(huì)隨即開啟一個(gè)Master 進(jìn)程和多個(gè)Worker 進(jìn)程，Master 進(jìn)程主要負(fù)責(zé)讀取驗(yàn)證配置信息、監(jiān)控Worker 進(jìn)程的工作狀態(tài)、及時(shí)地關(guān)閉或重新配置Worker 進(jìn)程的工作。Worker 進(jìn)程數(shù)通常設(shè)置為機(jī)器處理器的數(shù)量，RK3399 嵌入式開發(fā)板搭載4 小核＋2 大核的6 核處理器，因此在配置服務(wù)器時(shí)設(shè)置Worker 數(shù)為6，實(shí)現(xiàn)真正的“同時(shí)執(zhí)行”，且避免了進(jìn)程之間額外的切換開銷。

Nginx-http-flv 第三方擴(kuò)展模塊，是基于Nginx-RTMP 模塊，兼容其所有功能，支持虛擬主機(jī)功能，且完善Nginx-RTMP 模塊中缺少Listen 配置項(xiàng)時(shí)導(dǎo)致無法進(jìn)行通信傳輸?shù)墓δ?。Nginx-http-flv 采用多進(jìn)程的方式、支持RTMP 傳輸協(xié)議、支持GOP 緩存，能夠有效地降低RTMP 實(shí)時(shí)消息傳輸協(xié)議自身的延時(shí)效果。

通過修改Nginx 服務(wù)器的配置文件(Nginx.conf)，在其RTMP 模塊中設(shè)置兩個(gè)server，分別監(jiān)聽IPv4(listen 1935)和IPv6(listen[::]:1935 ipv6only ＝on；)地址，來實(shí)現(xiàn)IPv4、IPv6 下同時(shí)訪問，順應(yīng)下一代互聯(lián)網(wǎng)發(fā)展潮流。

2.2.2 GOP 緩存

由于RTMP 是基于TCP 協(xié)議的協(xié)議族，在通信的過程中具有握手請求應(yīng)答等繁瑣的過程，因此與UDP 等協(xié)議相比傳輸速度具有“天生”的劣勢。所以，降低RTMP 傳輸協(xié)議的延時(shí)也是目前廣泛討論的問題。

本設(shè)計(jì)在合理的范圍內(nèi)，適當(dāng)降低圖像質(zhì)量來減少傳輸過程中存在的延時(shí)問題。

在視頻編碼序列中，主要存有I 幀(Intra-coded picture)、P 幀(Predictive-coded Picture)、B 幀(Bidirectionally predicted picture)三種編碼幀[10]。I 幀表示關(guān)鍵幀，其包含當(dāng)前幀的完整畫面，通俗來講在視頻解碼時(shí)只需解碼I 幀數(shù)據(jù)即可重構(gòu)完整圖像。而GOP(group of pictures)指的是一組連續(xù)的由I 幀、P幀和B 幀構(gòu)成的畫面組。在固定碼率的情況下，GOP 數(shù)值越大，P、B 幀的數(shù)量會(huì)越多，且P、B 幀在編碼過程中要遠(yuǎn)比I 幀復(fù)雜，因此，適當(dāng)降低GOP減少P、B 幀的數(shù)量可有效減少視頻延時(shí)。

本次設(shè)計(jì)下每秒傳輸幀數(shù)(frame/s)為30 幀，GOP 大小設(shè)為20，測試可將延時(shí)控制在600 ms 之內(nèi)，滿足視頻監(jiān)控的需求。

3 系統(tǒng)實(shí)驗(yàn)

本設(shè)計(jì)采用了搭載Cortex－A72＋Cortex－A53 大小核架構(gòu)的Firefly－RK3399 開發(fā)板，內(nèi)置ARM Mali－T860 MP4 四核GPU[11]，可對圖形進(jìn)行高效處理，設(shè)計(jì)選擇Linux 操作系統(tǒng)作為開發(fā)環(huán)境，開發(fā)板實(shí)物圖如圖6 所示。

圖6 開發(fā)板實(shí)物圖

車載終端硬件框圖如圖7 所示:圖像采集模塊捕獲到車內(nèi)駕駛?cè)藛T的面部信息，采用YOLOv3-tiny算法實(shí)現(xiàn)人臉定位，結(jié)合Dlib－68 點(diǎn)檢測方法實(shí)現(xiàn)人臉關(guān)鍵點(diǎn)的檢測，通過PERCLOS 疲勞判定標(biāo)準(zhǔn)即可實(shí)現(xiàn)車內(nèi)的疲勞狀態(tài)檢測，然后遠(yuǎn)程監(jiān)控服務(wù)模塊將疲勞狀態(tài)視頻流信息通過RTMP 傳輸協(xié)議推流至流媒體服務(wù)器，即可實(shí)現(xiàn)疲勞駕駛遠(yuǎn)程監(jiān)控，存儲(chǔ)模塊可保存生成的日志文件，以供后期查閱分析。

圖7 車載終端硬件框圖

系統(tǒng)整體程序設(shè)計(jì)用Python3 來實(shí)現(xiàn)，主要流程如圖8 所示。

圖8 系統(tǒng)整體開發(fā)流程

為了充分利用CPU 資源，提高系統(tǒng)的運(yùn)行效率，程序采用多線程的模式，同時(shí)執(zhí)行讀取視頻信息和開啟推流兩個(gè)線程。線程1 完成攝像頭讀取功能，讀取到的視頻流信息通過疲勞檢測算法進(jìn)行疲勞判定，然后將處理后的視頻流逐幀存入隊(duì)列中，等待推流的開啟；線程2 開啟推流后，將先前存入隊(duì)列的圖片取出，然后以管道的形式推流至Nginx 服務(wù)器，實(shí)現(xiàn)視頻流的推流過程。

4 實(shí)驗(yàn)結(jié)果

4.1 人臉關(guān)鍵點(diǎn)檢測結(jié)果

為了驗(yàn)證文中設(shè)計(jì)在嵌入式端具有較強(qiáng)的適配性以及較好的處理速度，采用了以下幾種算法進(jìn)行實(shí)驗(yàn)對比，實(shí)驗(yàn)環(huán)境統(tǒng)一部署在Firefly－RK3399 開發(fā)板上，采用了同一公開數(shù)據(jù)集YawDD 進(jìn)行測試[12]，測試結(jié)果如表1 所示。

由表1 可知，文中算法在圖片處理速度方面具有較大的提升，較為適合嵌入式端的開發(fā)，可以滿足嵌入式端監(jiān)控系統(tǒng)的設(shè)計(jì)需求。

表1 算法對比

在Firefly－RK3399 開發(fā)板內(nèi)進(jìn)行Dlib 人臉關(guān)鍵點(diǎn)檢測算法測試，視頻FPS 為16，如圖9(a)所示；而在同一硬件環(huán)境下運(yùn)行本文中的算法，可以將視頻FPS 提升至34，如圖9(b)所示，傳輸幀數(shù)具有明顯改善。

圖9 算法效果對比

4.2 疲勞駕駛檢測結(jié)果

本文對YawDD 數(shù)據(jù)集中27 名來自不同種族、不同性別的測試者進(jìn)行實(shí)驗(yàn)，實(shí)驗(yàn)結(jié)果如表2 所示。

表2 疲勞駕駛檢測結(jié)果

Quantity 為同一種族、同一性別下的多組實(shí)驗(yàn)對象，Sleepiness 為本數(shù)據(jù)集打哈欠以及眼睛長時(shí)間閉合次數(shù)，Test-sleepiness 為本文算法的測試結(jié)果。在進(jìn)行多組實(shí)驗(yàn)對比分析后，本系統(tǒng)的疲勞狀態(tài)檢測精度可達(dá)95%。

圖10 為本系統(tǒng)針對行車過程中不同疲勞狀態(tài)下的實(shí)驗(yàn)結(jié)果，圖10(a)為行車過程中正常駕駛行為，圖10(b)為駕駛員眼睛長時(shí)間閉合時(shí)的狀態(tài)，圖10(c)為駕駛員打哈欠的狀態(tài)。

圖10 疲勞狀態(tài)檢測

4.3 GOP 優(yōu)化效果

為了測試本系統(tǒng)中視頻傳輸延時(shí)，設(shè)計(jì)如下測試方案。在PC 端開啟一個(gè)毫秒級計(jì)時(shí)器，如圖11(a)所示，與RK3399 開發(fā)板相連接的攝像頭拍攝該計(jì)時(shí)器，與此同時(shí)，在PC 端打開本地流媒體播放器(測試采用的流媒體播放器為PotPlayer)如圖11(b)所示，通過系統(tǒng)的推流后，采用截圖軟件將同一時(shí)刻下的兩個(gè)畫面一起截下，如圖11 表示，即可測出本系統(tǒng)下的視頻延時(shí)效果。

圖11 優(yōu)化前延時(shí)效果圖

以上測試均為同一實(shí)驗(yàn)環(huán)境下多組測試所得，圖11 為未采用本系統(tǒng)中優(yōu)化方案的延時(shí)結(jié)果，圖12為優(yōu)化后延時(shí)效果，多次測試采集數(shù)據(jù)，數(shù)據(jù)結(jié)果對比如圖13 所示，由圖可知，采用本系統(tǒng)的設(shè)計(jì)方案后，由1 560 ms 的延時(shí)減少到610 ms，延時(shí)問題得到明顯的改善。

圖12 優(yōu)化后延時(shí)效果圖

圖13 優(yōu)化效果對比圖

4.4 監(jiān)控系統(tǒng)效果圖

系統(tǒng)整體效果圖如圖14 所示，圖14(a)為疲勞駕駛監(jiān)控系統(tǒng)在IPv4 網(wǎng)絡(luò)下的測試結(jié)果，圖14(b)為系統(tǒng)在IPv6 網(wǎng)絡(luò)下的測試結(jié)果。當(dāng)識別出疲勞狀態(tài)時(shí)，可進(jìn)行抓拍，將監(jiān)控記錄上傳至服務(wù)器。本系統(tǒng)可以在兩種不同網(wǎng)絡(luò)下正常運(yùn)行。

圖14 嵌入式遠(yuǎn)程監(jiān)控效果圖

5 結(jié)束語

本文在嵌入式端尋求一個(gè)低延時(shí)高幀率的疲勞駕駛遠(yuǎn)程監(jiān)控系統(tǒng)為切入點(diǎn)，采用基于YOLOv3-tiny＋Dlib68 點(diǎn)的算法進(jìn)行疲勞狀態(tài)檢測，輔以低延時(shí)的遠(yuǎn)程視頻監(jiān)控系統(tǒng)進(jìn)行實(shí)時(shí)視頻監(jiān)控。通過多組實(shí)驗(yàn)對比，結(jié)果表明，該系統(tǒng)對疲勞駕駛行為識別率可達(dá)95%，嵌入式端視頻傳輸延時(shí)僅為600 ms 左右，極大地改善了視頻傳輸過程中較高延時(shí)的弊端。

本文設(shè)計(jì)的嵌入式疲勞駕駛遠(yuǎn)程監(jiān)控系統(tǒng)實(shí)施方案相對簡單，可移植性高，在嵌入式端具有較好的適配性以及較低的視頻傳輸延時(shí)，滿足嵌入式端的精度需求和實(shí)時(shí)性要求。