嵌入式疲劳驾驶远程监测系统*

高龙琛，邢 猛，丁 月，刘 政，邢建平

(山东大学微电子学院，山东 济南 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 左右，极大地改善了视频传输过程中较高延时的弊端。

本文设计的嵌入式疲劳驾驶远程监控系统实施方案相对简单，可移植性高，在嵌入式端具有较好的适配性以及较低的视频传输延时，满足嵌入式端的精度需求和实时性要求。