Python+Django+OpenCV疲劳检测系统：从EAR状态机到Web落地指南

简介：一套基于 Python、Django 与 OpenCV 的疲劳检测系统毕业设计论文文档，适用于计算机、软件工程等相关专业学生完成课程设计或毕业论文撰写。论文围绕眼动信号与人脸判断展开，借助 OpenCV 图像处理库完成眼睛闭合程度检测，并结合面部表情、眨眼频次对疲劳状态进行量化分析，同时给出基于 Python 编程语言和 MySQL 数据库实现图像识别、图片分析及照片管理等模块的设计思路，为读者梳理了从图像采集、特征提取到疲劳判定的完整流程，也能帮助理解系统整体架构、核心算法与实际编码实现之间的对应关系。资源包内为 1 个 docx 格式文档，大小约 1.01MB，包含中英文摘要、目录、绪论、相关技术介绍、系统设计、功能模块说明及参考文献等完整章节，既可作为论文写作的格式模板，也可作为疲劳检测算法与 Django 项目开发的参考资料。已有 365 人学习下载，对正在开展相关课题或准备毕业答辩的学生具有较高参考价值。

1. 疲劳检测系统不是模型比赛：先把“判疲”写成可量化状态机

基于Python+Django+OpenCV的疲劳检测系统，听起来像是一套“人脸框一画、Django一跑、论文一交”的毕设套餐，但真正自己动手做过的都会承认：最难的从来不是把Django建起来，也不是让OpenCV弹出人脸框，而是让“疲劳”这个词在代码里变成一个能落库、能回放、能解释的量化指标。这个方向能做的事很多：驾驶员疲劳预警、网课专注度分析、危险作业岗前状态监控，甚至是工厂的工时状态统计。这篇文章就按“采集—判疲—上报”的链路，把OpenCV检测、Django接口和数据库设计串起来，给你一份能直接照着搭的最小实现，以及那些论文里不会写的坑。适合正在做毕设、做小型安防Demo，或者想从单机算法转Web化交付的开发者。

2. 技术选型与参数基线：Django+OpenCV各自扛住哪一段

2.1 OpenCV只负责“看得见”，Django只负责“记得住”

很多项目从一开始就错了：想在Django里直接调用OpenCV做实时推理，于是把所有逻辑都堆在view函数里，结果一个请求进来，视频流卡住，页面也卡住。这个系统的正确拆法是：OpenCV负责摄像头采集、人脸检测、关键点提取和疲劳判定，Django只负责接收检测结果、写入数据库、对外提供查询接口。两者之间用消息队列或者直接HTTP上报解耦，吞吐能力完全不同。

我自己写这套系统时会把整个进程拆成三块：采集检测进程、消息队列、Django Web服务。采集进程是唯一能碰摄像头的进程，拿到单帧后跑OpenCV的dnn或dlib关键点模型，算出EAR、MAR这些指标，然后把结果推到队列；Django这边起一个消费线程，把队列里的数据批量落库。好处是哪怕Web服务重启、数据库暂时不可用，检测进程也不会崩，帧数据还能留在队列里补录。

为什么不把检测直接做成Django的一个依赖？因为OpenCV的VideoCapture在部分驱动下会和Django的autoreload、多线程模型打架，而且CPU推理本身会阻塞event loop。如果坚持同步接口，常见做法是把检测结果缓存到Redis，TTL设3秒，接口直接读Redis返回，这样至少不会因为一次推理就把请求线程全占住。

还有一个常见误用：把cv2.VideoCapture(0)直接写在Django模块顶部。dev server的autoreload会加载两遍模块，第二个进程再去open摄像头就会报Device or resource busy。如果你看到这个报错，先别怀疑OpenCV，去检查是不是有两个Python进程同时打开了摄像头。这也是我把采集进程独立出来的另一个原因。

2.2 先定疲劳指标，再谈算法模型

疲劳检测的“疲劳”不能靠感觉定。目前从业界到论文里被复用最多的三个指标是EAR（眼部纵横比）、MAR（嘴部纵横比）和PERCLOS（眼睛闭合时间占比）。EAR用来度量眼睛闭合程度，正常睁眼时稳定在0.3以上，闭眼时会掉到0.15以下；MAR用来度量嘴巴张开程度，打哈欠时嘴部纵横比会显著拉高；PERCLOS则是统计一段时间内闭眼帧数占窗口总帧数的比例，比单次眨眼更能代表持续的疲劳趋势。

这三个指标的阈值选取很有讲究。很多人直接抄论文里的固定值，比如EAR取0.25，一旦换摄像头、换分辨率、换关键点模型，检测就翻车。我更建议把阈值当初始值，部署前用一段人工标注视频做标定。具体怎么标定，最后一章会给出脚本。下面这张表是常见的经验基线，注意它是起点不是终点：

从表格里能看出，疲劳判断其实是“事件统计”，不是“单帧分类”。这决定了后续的代码里一定要出现计数器、滑动窗口和状态机，而不是只画一个人脸框。

2.3 版本组合：先按这套环境拉依赖

Python版本、Django版本和OpenCV版本三者必须一起定，不能各自最新。当前较稳的组合是Python 3.8或3.10、Django 3.2 LTS或4.2 LTS、opencv-python 4.5.x到4.8.x。OpenCV 4.4曾经在Windows上出现源码编译报错，很多人卡在pip install opencv-python那一步，就是版本和Python环境不匹配。后面避坑章节会专门说这个问题。先按这套组合初始化环境比较省事：

python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install django==4.2.9 opencv-python==4.8.1.78 numpy==1.24.4

Django侧还要选好数据库。默认SQLite在单机毕设里完全够用，能直接跑通；如果要做并发上报和多终端查询，建议换成MySQL，并给疲劳记录表加上personnel_id和created_at的联合索引。ORM在写入频率高的时候要记得用bulk_create或事务批量提交，避免一帧一条INSERT把数据库拖垮。

版本之外还有一对容易打架的包：opencv-python和opencv-contrib-python。前者只含主模块，后者额外带contrib算法，两个包不能同时装在同一环境，否则site-packages里会出现cv2的重复符号，import时随机报错。很多人的做法是只装opencv-contrib-python，因为里面包含了SIFT、xfeatures2d等算法；如果项目里只用dnn和人脸检测，装opencv-python就够了。确认环境的命令是pip list | grep opencv，一旦发现两个包都在，就pip uninstall掉其中一个再重装。

3. OpenCV疲劳检测的四个可复现模块：人脸框、EAR阈值、哈欠判定与状态机

3.1 人脸检测：优先用OpenCV DNN模型，而不是Haar特征

Haar级联在嵌入式或老机器上很经典，但到了低光照、侧脸、戴眼镜这些真实场景，误检漏检都偏高。我现在更习惯用OpenCV自带的dnn人脸检测器（res10 SSD模型），它在CPU上的单帧耗时大约20到40毫秒，比Haar慢一点，但稳定很多。模型文件是caffemodel，不需要额外装深度学习框架，OpenCV的dnn模块直接读。

import cv2 import numpy as np prototxt = "deploy.prototxt" caffemodel = "res10_300x300_ssd_iter_140000.caffemodel" net = cv2.dnn.readNetFromCaffe(prototxt, caffemodel) def detect_face(frame, conf_threshold=0.7): h, w = frame.shape[:2] # 模型输入固定为300x300，RGB均值做减均值预处理 blob = cv2.dnn.blobFromImage( cv2.resize(frame, (300, 300)), 1.0, (300, 300), (104.0, 177.0, 123.0) ) net.setInput(blob) detections = net.forward() faces = [] for i in range(detections.shape[2]): conf = detections[0, 0, i, 2] if conf > conf_threshold: box = detections[0, 0, i, 3:7] * np.array([w, h, w, h]) x1, y1, x2, y2 = box.astype("int") x1, y1 = max(0, x1), max(0, y1) x2, y2 = min(w, x2), min(h, y2) faces.append((x1, y1, x2, y2)) return faces

这里有个细节：blobFromImage里传入的均值是(104.0, 177.0, 123.0)，这是SSD训练时的BGR均值，不能随意改成(0,0,0)或者(127.5,127.5,127.5)，否则检测精度会明显下降。conf_threshold我习惯设0.7，人脸太小的时候降到0.5，但会有更多误检。拿到人脸框后，下一步要把框放大1.1倍再送入关键点模型，因为原框往往切得太紧，会裁掉半边眉毛。

3.2 眨眼检测：EAR和连续帧计数

眨眼判定的核心是EAR。它利用眼周关键点计算眼部高度和宽度的比值，睁眼时垂直距离大，闭眼时垂直距离趋近于零。这个算子比直接量瞳距稳定得多，因为它是归一化的，对摄像头距离不敏感。

import numpy as np def eye_aspect_ratio(eye): # 传入单眼6个关键点，顺序是右眼角顺时针 a = np.linalg.norm(eye[1] - eye[5]) b = np.linalg.norm(eye[2] - eye[4]) c = np.linalg.norm(eye[0] - eye[3]) ear = (a + b) / (2.0 * c) return ear EYE_AR_THRESH = 0.25 BLINK_CONSEC_FRAMES = 2 left_eye_index = list(range(42, 48)) right_eye_index = list(range(36, 42)) left_ear = eye_aspect_ratio(landmarks[left_eye_index]) right_ear = eye_aspect_ratio(landmarks[right_eye_index]) ear = (left_ear + right_ear) / 2.0 if ear < EYE_AR_THRESH: blink_counter += 1 else: if blink_counter >= BLINK_CONSEC_FRAMES: blink_total += 1 blink_counter = 0

这里最容易被忽略的是左右眼的索引顺序。dlib的68点模型中，36到41是右眼，42到47是左眼，但关键点顺序是“从眼角开始顺时针”，如果按数组切片直接传给EAR函数，大概率会把眼角当上下眼睑，算出一个永远不变的异常值。我建议第一次跑通后，先把每只眼的6个点可视化打印出来，确认坐标顺序再继续。

BLINK_CONSEC_FRAMES设2表示连续2帧EAR低于阈值才算一次眨眼。如果视频只有15帧每秒，这个值可以放大到3，防止眨眼被误拆成两次。

3.3 哈欠检测：MAR配合嘴型宽高比

哈欠检测的公式和EAR几乎一样，只是把目标从眼睛换成嘴巴。嘴部8个关键点取纵向距离和横向宽度的比值，张嘴时MAR上升，闭嘴时回落。和眨眼不同的是，哈欠的持续时间更长，所以判哈欠时要单独再设一个持续帧数阈值。

def mouth_aspect_ratio(mouth): # mouth为8个关键点，61, 62, 63在上唇，65, 66, 67在下唇 a = np.linalg.norm(mouth[2] - mouth[9]) b = np.linalg.norm(mouth[4] - mouth[7]) c = np.linalg.norm(mouth[0] - mouth[6]) mar = (a + b) / (2.0 * c) return mar MAR_THRESH = 0.6 YAWN_CONSEC_FRAMES = 12 mar = mouth_aspect_ratio(landmarks[list(range(60, 68))]) if mar > MAR_THRESH: yawn_counter += 1 else: if yawn_counter >= YAWN_CONSEC_FRAMES: yawn_total += 1 yawn_counter = 0

需要说明，MAR到0.6这个经验值会受模型影响。dlib的68点模型本身是拿人脸对齐任务训练的，嘴型宽度在高分辨率上识别得准，但换到低分辨率摄像头时MAR会整体偏低。我遇到过一个案例：同一张嘴，在720p摄像头下MAR能到0.8，换到480p工业相机后只有0.5，阈值不变的话哈欠就永远触发不了。这时候要么降低MAR阈值，要么把嘴部区域放大后再算。

3.4 疲劳状态机：用计数器把“单帧异常”变成“持续疲劳”

单帧的EAR小于阈值只是闭了一下眼睛，不代表疲劳。疲劳一定是个持续状态，所以需要一个状态机来聚合眨眼频率、哈欠频率和PERCLOS。这个状态机如果写在每一帧的逻辑里，代码会很快变得不可读，我一般单独抽一个类出来。

class FatigueStatus: def __init__(self, perclos_window=60, perclos_thresh=0.4, min_yawns=2): self.eye_close_frames = 0 self.total_frames = 0 self.yawn_count = 0 self.status = "normal" self.window = perclos_window self.perclos_thresh = perclos_thresh self.min_yawns = min_yawns def update(self, is_eye_closed, is_yawn): self.total_frames += 1 if is_eye_closed: self.eye_close_frames += 1 if is_yawn: self.yawn_count += 1 if self.total_frames >= self.window: perclos = self.eye_close_frames / self.total_frames if perclos > self.perclos_thresh or self.yawn_count >= self.min_yawns: self.status = "fatigue" else: self.status = "normal" # 滑动窗口：只保留最近N帧的统计，否则旧数据一直占着内存 self.eye_close_frames = 0 self.total_frames = 0 self.yawn_count = 0 return self.status

注意这个简化版的滑动窗口是“整段清零”，严格说法是每N帧滚动一次。实际工程里更常用的是deque双端队列，窗口内只保留最近60帧的布尔值，这样PERCLOS是真正滑动的，不会出现“59秒内一直打哈欠，最后一秒清零”的假疲劳。窗口长度建议取30到60秒，太短会把一次低头误判成疲劳，太长又反应迟钝。

4. Django接入方案：数据表、REST接口与MJPEG推流页面

4.1 数据表设计：疲劳事件与检测记录分开建

从零搭Django侧时，我一般先执行django-admin startproject fatigue_web && python manage.py startapp detector，接着在settings.py里注册app，最后才是建模型和写接口。疲劳检测系统的数据库不只是存一张表，至少需要人员/设备表、检测记录表和疲劳事件表。检测记录表存每一帧或每几帧的EAR、MAR、状态，疲劳事件表只在状态从正常切到疲劳时插入一条事件，记录发生时间、持续时长、触发原因。这样既方便论文出图，也方便事后排查。

from django.db import models class Personnel(models.Model): name = models.CharField(max_length=32) personnel_id = models.CharField(max_length=32, unique=True) create_time = models.DateTimeField(auto_now_add=True) class DetectionRecord(models.Model): personnel = models.ForeignKey(Personnel, on_delete=models.CASCADE) frame_time = models.DateTimeField(auto_now_add=True) ear = models.FloatField(default=0) mar = models.FloatField(default=0) blink_rate = models.FloatField(default=0) status = models.CharField(max_length=16, default="normal") class Meta: indexes = [ models.Index(fields=["personnel", "-frame_time"]), ] class FatigueEvent(models.Model): personnel = models.ForeignKey(Personnel, on_delete=models.CASCADE) started_at = models.DateTimeField(auto_now_add=True) ended_at = models.DateTimeField(null=True, blank=True) reason = models.CharField(max_length=32)

这里把DetectionRecord和FatigueEvent分开的原因很实际：检测记录量很大，按帧存的话一分钟就有1800条，如果全塞给前端拉列表，接口迟早被打爆；事件表一天只有几十条，适合做报表。论文里的准确率统计也应该以事件表为准，而不是直接把帧记录导出来。外键和联合索引能保证按人员查历史记录时不会全表扫描。

4.2 REST接口：让检测进程把结果“报”上来

Django侧先提供一个最朴素的POST接口，让检测进程把算好的指标传过来。不用上DRF也能跑通，但生产环境建议换成DRF加Serializer。这里为了让你最小成本复现，我用JsonResponse直接返回。

import json from django.http import JsonResponse from django.views.decorators.csrf import csrf_exempt from .models import DetectionRecord, FatigueEvent, Personnel @csrf_exempt def report_detection(request): if request.method != "POST": return JsonResponse({"code": 405, "msg": "only POST allowed"}) try: data = json.loads(request.body) personnel = Personnel.objects.get(personnel_id=data["personnel_id"]) except (json.JSONDecodeError, KeyError, Personnel.DoesNotExist): return JsonResponse({"code": 400, "msg": "bad request"}) record = DetectionRecord.objects.create( personnel=personnel, ear=data.get("ear", 0), mar=data.get("mar", 0), blink_rate=data.get("blink_rate", 0), status=data.get("status", "normal"), ) # 状态切到疲劳时，写一条事件 if data.get("status") == "fatigue": FatigueEvent.objects.get_or_create( personnel=personnel, ended_at__isnull=True, defaults={"reason": data.get("reason", "perclos")}, ) return JsonResponse({"code": 0, "record_id": record.id})

为什么用get_or_create而不是create？因为检测进程每个窗口期都可能上报疲劳状态，如果不加约束，一次疲劳会生成几十条相同事件。让事件表以“ended_at为空”作为未结束的标记，下一次上报疲劳时直接复用当前未结束的事件，等到正常状态后再把ended_at写上。不这么做的话，论文里的疲劳次数统计会虚高好几倍。

上报频率也需要设计。检测进程可以每5帧算一次平均EAR/MAR再上报，不要每个单帧都打一个POST请求。这样一分钟的上报量从1800条降到360条，数据库压力小一个数量级。如果还嫌多，就在Django消费端做bulk_create，每10秒批量刷一次，接口只负责接收并暂存在内存里。

4.3 实时监控页：MJPEG推流的成本最低

Django里做实时视频预览，最省事的方案是MJPEG推流。原理是HTTP响应保持不关闭，帧以multipart/x-mixed-replace格式持续下发，浏览器里的img标签就能直接播放。它比WebSocket简单，也不需要额外装channels，缺点是单路连接占带宽，只适合本地或内网预览。

import cv2 from django.http import StreamingHttpResponse def gen_frames(): cap = cv2.VideoCapture(0) while True: ok, frame = cap.read() if not ok: break # 这里可以复用第3章的检测函数，把EAR/MAR画到帧上 ret, jpeg = cv2.imencode(".jpg", frame) if not ret: continue frame_bytes = jpeg.tobytes() yield (b"--frame\r\n" b"Content-Type: image/jpeg\r\n\r\n" + frame_bytes + b"\r\n") def video_feed(request): return StreamingHttpResponse(gen_frames(), content_type="multipart/x-mixed-replace; boundary=frame")

这个推流视图有个致命问题是它会一直占用摄像头的VideoCapture对象。如果你是边推流边检测，同一个摄像头设备不能被两个进程重复open。常见解法是采集进程只做一个生产者，把OpenCV的帧放进一个带锁的全局队列，推流视图和检测模块都从队列里取帧，而不是各自open摄像头。另一个坑是Django的dev server默认单线程，推流会占掉一个worker，导致其他接口卡死，上线后用uwsgi或gunicorn多worker部署才能缓解。这个“推流和检测抢摄像头”的坑，我放到下一章细说。

5. 疲劳检测落地避坑：光照、OpenCV版本与跨线程数据库

5.1 白天准、晚上全挂，问题不在算法在补光

现象：同一套EAR阈值和关键点模型，白天检测正常，到了晚上或者逆光场景，闭眼误判率从5%涨到40%，眨眼频率直接翻倍。

原因：普通RGB摄像头在低照度下，眼部和皮肤对比度下降，关键点模型输出的坐标开始抖动，EAR的垂直距离忽大忽小，尤其是下眼睑的2个点，经常被识别到眼睛外面去。

解决：优先换红外或双光摄像头，红外图像不受可见光影响，这是很多商用疲劳驾驶方案的做法。如果手里只有普通摄像头，就在预处理阶段加CLAHE自适应直方图均衡，代码里只有一行cv2.createCLAHE(clipLimit=2.0, tileGridSize=(8,8)).apply(gray)。同时把人脸检测的置信度从0.7降到0.5，防止关键点模型拿到一个模糊的小脸硬算。实测下来，CLAHE能把夜间EAR抖动的方差缩小约30%，但并不能彻底解决，所以还要配合头部姿态过滤。

如果画面里出现低头或转头，关键点会被遮挡，EAR同样会掉到阈值以下。判断是不是真闭眼，可以用cv2.solvePnP配合人脸关键点做头部姿态估计，算出头部的俯仰角和偏航角，头部低头超过30度时不参与闭眼统计。这是很多商用系统的做法，但需要先知道摄像头的内参矩阵，否则算出来的欧拉角只有相对意义。

5.2 OpenCV装不上或cv2.error，先查版本组合

现象：pip install opencv-python报错，或者在import cv2时报cv2.error: OpenCV(4.4.0)...pip-req-build，还有更常见的ModuleNotFoundError: No module named 'cv2'。

原因：OpenCV的wheel包对Python版本和系统架构有严格限制。Python 3.9以上装opencv-python 4.4.0会因为没有对应wheel而尝试本地编译，编译时缺少CMake或MSVC工具链就直接炸掉。报错信息里出现的pip-req-build路径，就是正在源码编译而不是在下载wheel。

解决：优先用pip安装指定小版本的预编译包，比如pip install opencv-python==4.6.0.66，或者直接用更高版本pip install opencv-python -U。Windows用户要注意Python是64位还是32位，32位环境下很多新版本OpenCV已经不出wheel了。如果公司内网禁pip，那就用conda创建独立环境，conda install opencv会走conda镜像，依赖问题少很多。不要把时间浪费在源码编译上，除非你确实要改OpenCV底层源码。

5.3 眨眼次数统计翻倍，EAR阈值不能一刀切

现象：一个人的正常眨眼频率，从统计上的每分钟15次变成了30次，甚至连续眨眼被拆成两三次单独事件。

原因：EAR阈值设得太高，比如默认0.25在某个摄像头下人脸偏小，睁眼时的EAR本来就只有0.22，于是代码把“睁眼”当成“闭眼”；还有一种情况是检测帧率不稳定，同一帧被处理两次，眨眼计数器被重复累加。

解决：先做离线标定，录一段10秒正常睁眼和10秒闭眼的视频，分别统计EAR分布，把阈值取在两类分布的中间位置。这比抄论文参数可靠得多。处理上再做两层过滤：第一层对EAR序列做3帧滑动平均，抑制单帧抖动；第二层记录每次眨眼事件的最小闭合帧数，小于2帧的丢弃。如果摄像头存在丢帧，要给每帧带上时间戳，按时间窗口统计，不要按帧数统计。

5.4 Django收不到检测数据，别着急加线程

现象：检测进程是单独的Python脚本，往Django接口POST数据时偶尔成功偶尔超时，重启Django后能恢复一阵，然后又不行。

原因：最典型的是检测进程里有人在子线程中直接用了Django ORM。Django的数据库连接是基于thread-local的，子进程或threading线程拿到的连接是父进程复制出来的脏连接，写入时MySQL会报“commands out of sync”或直接卡死。常见表现就是前几次写入成功，后面越积越慢。

解决：检测进程只把结果推给Redis队列，Django里单独起一个management command做消费端，从Redis取数据后统一落库。这样Django的ORM只在它自己的进程里使用，不跨线程。另一个更简单但够用的方案是检测进程只用requests.post调第4章写的接口，把ORM彻底留在Django侧。加线程解决不了本质问题，只会把并发问题变成连接池问题。

6. 从“能跑”到“能用”：离线回放调参和阈值自标定脚本

疲劳检测系统交到用户手里被吐槽最多的一句话是“它乱报警”。乱报警的来源通常不是算法不够新，而是阈值是抄来的。我这两年养成的习惯是：任何疲劳检测项目，上线前必须先录一段真实场景视频，做离线回放，把EAR、MAR逐帧打点，再和人工标注对比，用脚本搜出当前场景的最优阈值。这个步骤在论文里还可以变成一张数据表，比空谈准确率更能说服人。

离线标定的思路很直接：录三段视频，一段正常睁眼、一段频繁眨眼、一段打哈欠，人工把疲劳起止时间标出来；然后对候选阈值做网格搜索，跑一遍视频算出检测结果，和人工标注计算IoU或F1分数，取最高分对应的阈值。

import cv2 import numpy as np def search_ear_threshold(video_path, gt_events, candidates): best = None best_score = -1 for thr in candidates: pred = run_detector(video_path, ear_threshold=thr) score = event_iou(pred, gt_events) if score > best_score: best_score = score best = thr return best, best_score # candidates: 从0.15到0.35每隔0.01取一个 best_thr, score = search_ear_threshold( "normal.mp4", gt_events, np.arange(0.15, 0.35, 0.01) )

这段代码只是给了网格搜索的骨架，实际跑的时候要先把run_detector封装成接收阈值参数的纯函数，不要让它去读全局变量。candidates的步长不要小于0.01，否则标定时间翻倍但精度提升有限。除了阈值，还可以把关键点模型本身加入搜索范围，对比dlib和OpenCV自带的人脸关键点模型在同一段视频上的表现，这也是一种常见的模型选型验证手段。

另一个能用的小技巧是给Django后台加一个“回放页面”，上传一段视频，页面上能拖动进度条看到每一帧的EAR曲线和疲劳状态标记。这样验收时直接拉着用户看曲线，比看密密麻麻的报警记录直观得多。这套做法帮我把误报率从最初抄阈值的每小时七八次压到了一两次，也让我养成了一个习惯：以后再做疲劳检测，第一件事永远先问对方要一段真实场景视频，不要拿着实验室的标清录像去估阈值。希望这份从选型到避坑的记录能帮你少走点弯路。如果你也打算在这个方向做毕设或产品原型，建议把上面这些模块先拆开跑通，再合到一起，最后补上标定和回放，这套链路的抗风险能力会高很多。希望帮到你。

本文还有配套的精品资源，点击获取