嵌入式疲勞駕駛遠程監測系統*

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

(山東大學微電子學院，山東 濟南 250101)

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

本文提出的嵌入式疲勞駕駛監測系統，融合了深度學習與流媒體數據傳輸，以Firefly－RK3399 開發板為硬件平臺，基于Linux 操作系統，設計出一套前端檢測駕駛員疲勞狀態，后端將疲勞狀態視頻流信息以推流的方式上傳至流媒體服務器，用于后臺遠程監控的嵌入式視頻監控系統。方便用戶實時觀測車內駕駛人的疲勞狀態、掌握車內具體情況、及時對車內人員進行警醒，降低疲勞駕駛給社會所帶來的影響。

1 嵌入式疲勞駕駛監控系統設計方案

本系統應用于疲勞駕駛行為監控場景，旨在監測司機疲勞程度，對疲勞司機進行車內警醒以及后臺遠程監控等。系統架構圖如圖1 所示，系統整體主要分為車載監控系統以及遠程監控系統兩大部分。

圖1 系統架構圖

1.1 車載監控系統

車載監控系統包括Firefly－RK3399 開發板、攝像頭、疲勞駕駛檢測算法。主要任務為:車載攝像頭采集駕駛員面部信息，傳遞給嵌入式RK3399 開發板，開發板內移植的疲勞駕駛檢測算法對采集到的圖像進行人臉的定位以及人臉關鍵點的檢測，最終生成一個含有疲勞狀態的視頻流。

1.2 遠程監控系統

遠程監控系統包括Nginx 服務器、多線程傳輸模塊、Nginx-http-flv-module 第三方擴展模塊。其主要工作如下:RK3399 開發板通過多線程傳輸模塊，采用FFmpeg 進行RTMP 推流，將疲勞狀態視頻流信息以推流方式上傳至基于Nginx 流媒體服務器，客戶端可通過任意Flash 播放器即可實現對疲勞狀態視頻流信息的遠程拉流。

2 關鍵技術點

2.1 疲勞駕駛檢測算法

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

2.1.1 YOLOv3-tiny＋Dlib

目前主流的人臉關鍵點檢測算法往往計算量大，設備性能要求較高，移植復雜等，不適合嵌入式端的開發與應用。而YOLOv3-tiny 是YOLOv3 的簡化版本，其網絡相對簡單，計算量較小，比較適合移動端尤其是嵌入式設備中運行。

YOLOv3-tiny 網絡結構如圖2 所示。僅保留了24 層網絡，相比標準版3 個尺度輸出層，YOLOv3-tiny 只有13 pixel×13 pixel 和26 pixel×26 pixel 的兩個不同尺度YOLO 輸出層[3]，計算量大大減小。相比YOLOv3 標準版，tiny 版損失了精度，但是其速度更快，因此本文選取了YOLOv3-tiny 做為疲勞駕駛算法中人臉檢測算法。

圖2 YOLOv3-tiny 網絡結構

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

調用Dlib 官方提供的預測器shape＿ predictor ＿68＿ face＿landmarks.dat 進行人臉68 關鍵點的標定。

2.1.2 疲勞狀態分析

(1)PERCLOS 值

當駕駛過程中出現疲勞狀態時，駕駛員本能反應是打哈欠、眼睛頻繁閉合等動作，通過計算眼睛閉合的頻率和持續時間即可反映疲勞的狀態，因此本文采取Walt Wierwille 提出的PERCLOS 來度量疲勞狀態[5]。PERCLOS 定義為某時間段內眼睛的閉合程度，當一定時間間隔內眼睛閉合所占的時間比例超過15%時即認為是疲勞狀態[6]。

(2)眼睛縱橫比

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

圖3 眼部縱橫比

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

(3)嘴巴縱橫比

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

圖4 嘴巴縱橫比

2.1.3 疲勞判斷

本文采用視頻幀數代替時間尺度來反應疲勞狀態。

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

2.2 遠程監控系統框架

遠程監控系統主要實現對車內提取的視頻流信息進行數據上傳，工作人員實時后臺監控，以達到對車內信息的及時掌握以及記錄等。

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

嵌入式Linux 系統內搭載Nginx 高性能的開源輕量級Web 服務器，該服務器占有內存較少、具有較強的并發能力，適用于連續高并發的視頻監控[8]。

由于Nginx 服務器默認配置是不支持RTMP 模塊，需要通過配置第三方擴展模塊來進行RTMP 協議的傳輸。本設計內的Nginx 服務器配置Nginxhttp-flv 第三方擴展模塊，支持GOP 緩存，能夠有效地降低延時，減少響應時間。

2.2.1 Nginx 服務器

Nginx 服務器采用了Master-Worker 的工作模式[9]，該模式是指同時由兩個進程協同工作，明確分工，將大任務分解為若干小任務，提高系統的吞吐量，加速服務器的工作效率。服務器的主要工作流程如圖5 所示。

圖5 服務器系統架構圖

在嵌入式開發板啟動Nginx 服務器成功時，服務器會隨即開啟一個Master 進程和多個Worker 進程，Master 進程主要負責讀取驗證配置信息、監控Worker 進程的工作狀態、及時地關閉或重新配置Worker 進程的工作。Worker 進程數通常設置為機器處理器的數量，RK3399 嵌入式開發板搭載4 小核＋2 大核的6 核處理器，因此在配置服務器時設置Worker 數為6，實現真正的“同時執行”，且避免了進程之間額外的切換開銷。

Nginx-http-flv 第三方擴展模塊，是基于Nginx-RTMP 模塊，兼容其所有功能，支持虛擬主機功能，且完善Nginx-RTMP 模塊中缺少Listen 配置項時導致無法進行通信傳輸的功能。Nginx-http-flv 采用多進程的方式、支持RTMP 傳輸協議、支持GOP 緩存，能夠有效地降低RTMP 實時消息傳輸協議自身的延時效果。

通過修改Nginx 服務器的配置文件(Nginx.conf)，在其RTMP 模塊中設置兩個server，分別監聽IPv4(listen 1935)和IPv6(listen[::]:1935 ipv6only ＝on；)地址，來實現IPv4、IPv6 下同時訪問，順應下一代互聯網發展潮流。

2.2.2 GOP 緩存

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

本設計在合理的范圍內，適當降低圖像質量來減少傳輸過程中存在的延時問題。

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

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

3 系統實驗

本設計采用了搭載Cortex－A72＋Cortex－A53 大小核架構的Firefly－RK3399 開發板，內置ARM Mali－T860 MP4 四核GPU[11]，可對圖形進行高效處理，設計選擇Linux 操作系統作為開發環境，開發板實物圖如圖6 所示。

圖6 開發板實物圖

車載終端硬件框圖如圖7 所示:圖像采集模塊捕獲到車內駕駛人員的面部信息，采用YOLOv3-tiny算法實現人臉定位，結合Dlib－68 點檢測方法實現人臉關鍵點的檢測，通過PERCLOS 疲勞判定標準即可實現車內的疲勞狀態檢測，然后遠程監控服務模塊將疲勞狀態視頻流信息通過RTMP 傳輸協議推流至流媒體服務器，即可實現疲勞駕駛遠程監控，存儲模塊可保存生成的日志文件，以供后期查閱分析。

圖7 車載終端硬件框圖

系統整體程序設計用Python3 來實現，主要流程如圖8 所示。

圖8 系統整體開發流程

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

4 實驗結果

4.1 人臉關鍵點檢測結果

為了驗證文中設計在嵌入式端具有較強的適配性以及較好的處理速度，采用了以下幾種算法進行實驗對比，實驗環境統一部署在Firefly－RK3399 開發板上，采用了同一公開數據集YawDD 進行測試[12]，測試結果如表1 所示。

由表1 可知，文中算法在圖片處理速度方面具有較大的提升，較為適合嵌入式端的開發，可以滿足嵌入式端監控系統的設計需求。

表1 算法對比

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

圖9 算法效果對比

4.2 疲勞駕駛檢測結果

本文對YawDD 數據集中27 名來自不同種族、不同性別的測試者進行實驗，實驗結果如表2 所示。

表2 疲勞駕駛檢測結果

Quantity 為同一種族、同一性別下的多組實驗對象，Sleepiness 為本數據集打哈欠以及眼睛長時間閉合次數，Test-sleepiness 為本文算法的測試結果。在進行多組實驗對比分析后，本系統的疲勞狀態檢測精度可達95%。

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

圖10 疲勞狀態檢測

4.3 GOP 優化效果

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

圖11 優化前延時效果圖

以上測試均為同一實驗環境下多組測試所得，圖11 為未采用本系統中優化方案的延時結果，圖12為優化后延時效果，多次測試采集數據，數據結果對比如圖13 所示，由圖可知，采用本系統的設計方案后，由1 560 ms 的延時減少到610 ms，延時問題得到明顯的改善。

圖12 優化后延時效果圖

圖13 優化效果對比圖

4.4 監控系統效果圖

系統整體效果圖如圖14 所示，圖14(a)為疲勞駕駛監控系統在IPv4 網絡下的測試結果，圖14(b)為系統在IPv6 網絡下的測試結果。當識別出疲勞狀態時，可進行抓拍，將監控記錄上傳至服務器。本系統可以在兩種不同網絡下正常運行。

圖14 嵌入式遠程監控效果圖

5 結束語

本文在嵌入式端尋求一個低延時高幀率的疲勞駕駛遠程監控系統為切入點，采用基于YOLOv3-tiny＋Dlib68 點的算法進行疲勞狀態檢測，輔以低延時的遠程視頻監控系統進行實時視頻監控。通過多組實驗對比，結果表明，該系統對疲勞駕駛行為識別率可達95%，嵌入式端視頻傳輸延時僅為600 ms 左右，極大地改善了視頻傳輸過程中較高延時的弊端。

本文設計的嵌入式疲勞駕駛遠程監控系統實施方案相對簡單，可移植性高，在嵌入式端具有較好的適配性以及較低的視頻傳輸延時，滿足嵌入式端的精度需求和實時性要求。