目标检测+姿态分析：防摔倒预警系统设计实现

简介：这是一套基于计算机视觉的目标检测与姿态分析实时防摔倒预警系统课程设计项目，内含完整Python源码与实验报告，适合计算机视觉、人工智能、数据科学等相关专业学生用于课程设计、毕业设计或项目实训，也适合企业员工进行技术参考。项目覆盖目标检测、人体姿态估计、摔倒行为判断与实时预警等关键环节，代码结构清晰，可读性和可扩展性较好，便于二次开发与功能定制。压缩包共1794个文件，大小约230.34MB，主要包含C++头文件与源文件（hpp/cpp）、Python脚本（py）、JSON配置文件、OpenCV模型配置（prototxt/cmake）、TXT说明文档以及AVI演示视频等，兼顾底层算法、接口调用、环境配置与运行演示。目前已有225人学习使用，内置实验报告和演示视频能帮助读者快速理解预警流程、复现典型摔倒场景，适合希望系统掌握视觉预警系统设计与实现并快速搭建演示环境的开发者。

1. 防摔倒预警系统到底在解决谁的什么问题

课程设计做防摔倒预警系统，听起来是把目标检测和姿态分析两个模型拼在一起，落地时却没这么省心。这个方向的真实需求很具体：独居老人或病房里的患者在画面中摔倒后，摄像头如果只做目标检测，只能告诉你“画面里有一个人”，没办法判断这个人是在弯腰、下蹲还是已经倒地；只做姿态分析，又容易把收拾东西、绑鞋带当成摔倒。能交付的方案，是用目标检测锁定画面中的人，用姿态分析拿到肩膀、髋关节等关键点，再靠“高速下落 → 低位静止 → 大倾角”三个时序特征做状态机判断。这篇文章把能直接抄作业的模型组合、摔倒判定算法和阈值调法整理出来，适合课程设计、毕业设计，也适合想在自己项目里加一个跌倒检测模块的从业者。

2. 目标检测 + 姿态分析：先锁定“谁在画面里”，再看“人的姿态怎么了”

2.1 为什么只用目标框做摔倒判断会翻车

早期基于摄像头的摔倒检测，常用的是轮廓宽高比、外接框最高点下降速度、前景像素占比这些特征。它们的共同问题是没有结构信息：一个蹲在地上系鞋带的人，外接框会变扁，中心点会下移，看起来和摔倒早期很像；一个弯腰捡东西的人，轮廓高度也会急剧变化，和目标框特征几乎重合。把这些特征直接喂给分类器，误报率会很高，尤其在摄像头有俯仰角时，BBox 长宽比受透视影响非常大。

姿态分析解决的是“多了结构”的问题——通过回归得到肩膀、髋关节、膝盖等人体关键点坐标，把“人躺平了没”“身体倾角多大”“髋部是不是突然快速下降”变成可计算的几何量。摔倒本质上是一连串姿态变化而不是静态画面，关键点序列能给状态机提供“过程”而非“瞬间”信息，这是目标框做不到的。

就课程设计而言，姿态估计通常用 2D 关键点就够，不需要上 3D。2D 关键点可以从普通监控摄像头获得，而 3D 姿态估计通常需要双相机或深度相机；对“防摔倒”这个目标，用肩髋连线向量和竖直方向的夹角就能定义倒地状态，多花深度成本并不会换来等价的回报。把这一条写进实验报告里，也能说明你的选型不是拍脑袋。

2.2 目标检测与姿态估计的三种协作方式

常见有三种组合路线。第一种是“先检测，再裁剪，后姿态”，这也是本项目的默认路线：

原始帧 → 缩放至 640×640 → YOLO 检测（只取 person 类） → 取面积最大的人框 → 裁剪出人体区域 → 缩放至 256×256 → MediaPipe Pose → 33 个关键点 → 归一化坐标恢复原图 → 几何特征 → 摔倒状态机 → 告警/日志

第二种是“全图直接跑姿态”，不经过目标检测。MediaPipe 本身也可以在全图上输出多人姿态，但这意味着每一帧都做全图密集回归，CPU 帧率往往从 30 掉到 10 以下；如果画面里有多个人，还需要额外处理跨人关键点分组的问题。单人、固定机位、背景简单的 demo 可以用，但课程设计要面对普通教室或宿舍环境，这种方案不稳。

第三种是“单模型同时出框和关键点”，例如 YOLO-Pose 系列。这类模型效率高、精度也好，但实现时依赖 torch hub 或定制推理脚本，对新手不够友好，部署坑比前两种多。课程设计建议走第一种，每个模块都是预训练好的，打通管线的时间最短，调试时也能单独看是哪一段出了问题。

2.3 模型选型：课程设计的预训练模型怎么组

我给的固定组合是 YOLOv8s + MediaPipe Pose。两个都是成熟的预训练模型，不需要训练就能跑出可用效果，这是和自研网络的明显区别。

选 YOLOv8s 而不是 YOLOv8n，是因为 s 在 CPU 上处理单帧 640 输入只比 n 多 20~30ms，但对低头、遮挡、光线变化的鲁棒性更好。检测置信度 conf 设在 0.45~0.55 之间即可。检测结果取“面积最大的人框”，后面会单独做跟踪，避免多人场景下目标漂移。

很多人拿到源码后第一反应是“我要不要用自拍数据微调一下模型”，我的建议是不要。目标检测只取 person 类，COCO 预训练权重已经学得很充分；姿态模型同理，MediaPipe 的预训练覆盖了日常姿态。摔倒时的极端姿态才是挑战，但那是判断阈值和后续处理的问题，不是重新训练模型能解决的。按常见计算机视觉学习路径来看，这个项目正好把检测和姿态两条主线串起来，重点应该放在管线、状态机和工程验证上。

模块拆分上，我会把源码组织成这样，和 zip 里的实验报告对应：

fall_alert/ ├── main.py # 摄像头/视频入口，主循环 ├── detector.py # YOLO 框人模块 ├── pose_estimator.py # MediaPipe 关键点模块 ├── fall_detector.py # 摔倒状态机 ├── alarm.py # 告警动作与日志 ├── requirements.txt ├── test_videos/ # 测试视频目录 └── experiment_report/ # 实验报告与截图

每个模块独立，调试时可以对单模块输入输出做断点，不互相污染，这是实验报告里值得写的一个工程决策。

3. 跑通最小闭环：YOLO 框人 + MediaPipe 出关键点

3.1 环境准备：一套能直接复现的依赖清单

课程设计环境不建议一上来就装整套深度学习全家桶，够用就行。用 conda 建一个干净环境，Python 版本固定在 3.10：

conda create -n fall_alert python=3.10 -y conda activate fall_alert pip install opencv-python numpy mediapipe ultralytics pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu

如果机器有 N 卡，最后一行可以换成自己 CUDA 版本对应的 torch 安装命令；没有 GPU 也不用担心，YOLOv8s 在 CPU 上跑 640 输入单帧大概 100~200ms，姿态估计再用裁剪区域单独跑，整体延迟在课设验收范围内。MediaPipe 在 Windows 和 Linux 下都能直接 pip 安装，不需要额外配置 Visual Studio 或 CUDA。

3.2 先跑通姿态估计本身：最小可运行代码

不要一上来就把两个模型拼起来，先把 MediaPipe 单独跑通。下面是只做姿态估计的骨架，摄像头每帧读入后直接全图推理：

import cv2 import mediapipe as mp mp_pose = mp.solutions.pose pose = mp_pose.Pose( min_detection_confidence=0.5, min_tracking_confidence=0.5, model_complexity=1 ) cap = cv2.VideoCapture(0) # 0 表示默认摄像头；也可换视频文件路径 while cap.isOpened(): ok, frame = cap.read() if not ok: break # MediaPipe 内部按 RGB 处理，OpenCV 读出来的是 BGR rgb = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) result = pose.process(rgb) if result.pose_landmarks: h, w, _ = frame.shape for i, lm in enumerate(result.pose_landmarks.landmark): # lm.x 和 lm.y 是 0~1 的归一化坐标 x = int(lm.x * w) y = int(lm.y * h) if i in [23, 24]: # 23=左髋，24=右髋 cv2.circle(frame, (x, y), 5, (0, 255, 0), -1) cv2.imshow("pose_demo", frame) if cv2.waitKey(1) & 0xFF == ord('q'): break cap.release() cv2.destroyAllWindows()

这段代码里最容易踩的坑是颜色空间，忘记cvtColor会让人脸和肢体关键点漂移得像鬼影。另一个概念是 MediaPipe 返回的坐标是相对图像宽高的归一化值，画到 OpenCV 窗口上必须乘回原来的宽高。min_detection_confidence控制进入检测的门槛，min_tracking_confidence控制跟踪是否维持；跟踪失败后模型会重新回到检测模式，两者配合决定关键点断帧的频繁程度。

3.3 把 YOLO 的人框接给姿态模型

跑通单模型后，才把它们串成检测加姿态的管线。核心逻辑是：YOLO 在全图上找 person，拿到框后把框内区域裁剪出来，缩放成统一尺寸，再喂给姿态模型。这样姿态模型只需要处理一个人，计算量小、关键点也更稳定。

import cv2 import mediapipe as mp from ultralytics import YOLO class PosePipeline: def __init__(self, det_weights="yolov8s.pt", conf=0.5, pose_size=256): self.detector = YOLO(det_weights) self.conf = conf self.pose_size = pose_size self.mp_pose = mp.solutions.pose self.pose = self.mp_pose.Pose( min_detection_confidence=0.5, min_tracking_confidence=0.5, model_complexity=1 ) def detect_person(self, frame_bgr, target_size=640): h, w = frame_bgr.shape[:2] small = cv2.resize(frame_bgr, (target_size, target_size)) results = self.detector.predict( small, classes=[0], conf=self.conf, verbose=False ) scale_x = w / target_size scale_y = h / target_size boxes = [] for r in results: for box in r.boxes: x1, y1, x2, y2 = box.xyxy[0].cpu().numpy() boxes.append([ int(x1 * scale_x), int(y1 * scale_y), int(x2 * scale_x), int(y2 * scale_y) ]) return boxes def get_landmarks(self, frame_bgr, box): x1, y1, x2, y2 = box person = frame_bgr[y1:y2, x1:x2] if person.size == 0: return None person = cv2.resize(person, (self.pose_size, self.pose_size)) rgb = cv2.cvtColor(person, cv2.COLOR_BGR2RGB) result = self.pose.process(rgb) if not result.pose_landmarks: return None bw = x2 - x1 bh = y2 - y1 landmarks = [] for lm in result.pose_landmarks.landmark: # 把裁剪框内的归一化坐标换算回原图坐标 landmarks.append((x1 + lm.x * bw, y1 + lm.y * bh)) return landmarks def process(self, frame_bgr): boxes = self.detect_person(frame_bgr) if not boxes: return None, None box = max(boxes, key=lambda b: (b[2] - b[0]) * (b[3] - b[1])) landmarks = self.get_landmarks(frame_bgr, box) return box, landmarks

注意detect_person里先缩小到 640 再检测，是为了让 yolo 在 CPU 上跑得更快；返回坐标时再用scale_x和scale_y放大回原图。get_landmarks返回的关键点坐标是相对整帧图像的绝对坐标，而不是裁剪框内的相对坐标，后续画图和计算速度时都统一用这套绝对坐标，能少踩一半的偏移 bug。

3.4 帧率取舍：CPU 跑不动时怎么保报警时效

目标检测加上姿态估计，两个模型的推理耗时会在 CPU 上叠加。我一般会在主循环里做跳帧处理，姿态估计是瓶颈就每隔一帧算一次，中间帧直接用上一帧关键点顶替，保证画面显示不卡顿：

cap = cv2.VideoCapture(0) pipeline = PosePipeline() last = None frame_id = 0 while True: ok, frame = cap.read() if not ok: break frame_id += 1 # CPU 性能不足时把 1 改成 2，表示每两帧做一次完整检测 if frame_id % 1 == 0: box, landmarks = pipeline.process(frame) if landmarks: last = (box, landmarks) else: box, landmarks = last if last else (None, None) if landmarks: for idx in (11, 12, 23, 24): x, y = int(landmarks[idx][0]), int(landmarks[idx][1]) cv2.circle(frame, (x, y), 4, (0, 255, 0), -1) cv2.imshow("fall_alert", frame) if cv2.waitKey(1) & 0xFF == ord('q'): break cap.release() cv2.destroyAllWindows()

跳帧带来的风险是速度特征失真。如果上一帧关键点被跳过了，状态机里“这一帧的位移”必须用真实时间差来算，不能按固定 30fps 来算。摔倒整个过程一般持续 0.5~1 秒，跳一帧造成的速度误差可能高达 30%~50%，后面状态机里那个速度阈值就会被拖死。所以跳帧只能用于显示和冗余判断，核心的fall_detector一定要记录每一帧的真实时间戳。

4. 摔倒判定状态机：三个特征和一组阈值怎么调

4.1 提取哪些特征：髋部中心、速度和身体倾角

摔倒判定的输入是姿态关键点，但关键点本身太原始，需要先抽象成特征。我常用的只有三个：髋部中心位置、髋部中心速度、肩髋连线与竖直方向的夹角。髋部中心比头部或脚都稳定，摔倒时它会经历一次明显下坠；身体倾角则能区分“人躺平了”和“人只是站低了”。

import math def compute_features(landmarks): """ landmarks: 长度 33 的 [(x, y), ...] 列表，顺序与 MediaPipe 一致 这里只用到 11、12、23、24 号关键点 """ sh_l = landmarks[11] # 左肩 sh_r = landmarks[12] # 右肩 hip_l = landmarks[23] # 左髋 hip_r = landmarks[24] # 右髋 hip_x = (hip_l[0] + hip_r[0]) / 2.0 hip_y = (hip_l[1] + hip_r[1]) / 2.0 sh_x = (sh_l[0] + sh_r[0]) / 2.0 sh_y = (sh_l[1] + sh_r[1]) / 2.0 dx = hip_x - sh_x dy = hip_y - sh_y # 肩髋连线与竖直向下方向的夹角：站立时约 0~20 度，倒地时接近 90 度 cos_angle = abs(dy) / (math.hypot(dx, dy) + 1e-6) angle = math.degrees(math.acos(max(0.0, min(1.0, cos_angle)))) return { "hip_x": hip_x, "hip_y": hip_y, "shoulder_y": sh_y, "body_angle": angle }

取肩髋连线而不是整条躯干线段，是因为左右肩和左右髋各自取中心点后，能抵消关键点偶发的左右不对称抖动。无论人往前倒、往后倒还是侧倒，肩髋连线与竖直方向的夹角都会从接近 0 度拉到接近 90 度，这个特征对摔倒方向不敏感，正好适合单摄像头的通用场景。

速度特征需要结合时间窗口。我维护一个最近 1 秒的髋部中心坐标列表，每秒算一次位移差，除以真实时间差得到速度。这个速度值是归一化坐标单位每秒，不是米每秒，所以阈值只能在固定画面尺寸和摄像头距离下复用。

4.2 状态机实现：stable → falling → fallen 的完整代码

特征值算出来之后，单独看任何一个特征都不可靠，必须做时序状态机。我的做法是三个状态：stable 表示日常站坐活动，falling 表示检测到高速下落的疑似过程，fallen 表示倒地已经被确认。只有 fallen 状态且持续一段时间才触发报警。

class FallDetector: def __init__(self, fps=30, vel_thresh=0.12, fallen_angle=60, fall_height_ratio=1.35, trigger_time=0.4, cooldown_time=8): self.fps = fps self.vel_thresh = vel_thresh self.fallen_angle = fallen_angle self.fall_height_ratio = fall_height_ratio self.history = [] self.baseline_hip_y = None self.state = "stable" self.state_frames = 0 self.trigger_frames = int(fps * trigger_time) self.cooldown_frames = int(fps * cooldown_time) self.cooldown = 0 self.alert_count = 0 def update(self, hip_x, hip_y, body_angle): self.cooldown = max(0, self.cooldown - 1) self.history.append((hip_x, hip_y)) if len(self.history) > self.fps: self.history.pop(0) # 站立基线只在躯干直立、髋部高度没有异常下沉时慢更新 if body_angle < 25: if self.baseline_hip_y is None: self.baseline_hip_y = hip_y elif hip_y < self.baseline_hip_y * 1.3: self.baseline_hip_y = 0.9 * self.baseline_hip_y + 0.1 * hip_y # 速度：滑动窗口首尾位移 / 窗口真实时长 speed = 0.0 if len(self.history) >= 2: dx = self.history[-1][0] - self.history[0][0] dy = self.history[-1][1] - self.history[0][1] dt = (len(self.history) - 1) / self.fps speed = math.hypot(dx, dy) / dt ratio = hip_y / (self.baseline_hip_y + 1e-6) if self.baseline_hip_y else 0 if self.state == "stable": if speed > self.vel_thresh: self.state = "falling" self.state_frames = 0 elif self.state == "falling": # 高速阶段结束后，必须同时满足“低于基准、大倾角”才算真正倒地 if speed < self.vel_thresh * 0.5: if ratio > self.fall_height_ratio and body_angle > self.fallen_angle: self.state = "fallen" self.state_frames = 0 else: self.state = "stable" # 虚惊一场，回到正常状态 elif self.state == "fallen": # 倒地静止持续一段时间才报警，抑制瞬时误报 if ratio > 1.2 and body_angle > 45: self.state_frames += 1 if self.state_frames >= self.trigger_frames and self.cooldown == 0: self.cooldown = self.cooldown_frames self.alert_count += 1 self.state = "stable" return True else: self.state = "stable" return False

这个状态机的核心思想是“过程确认”。stable 到 falling 只看速度，防止把起身、下蹲这类瞬间动作漏掉；falling 到 fallen 必须等速度回落后，再检查低位和角度，防止把捡东西这种“有向下的位移但最终站了起来”的动作判成摔倒。fallen 状态里再叠加连续帧计数，只有倒地维持够 0.4 秒才触发一次报警，并用冷却时间避免报警后反复响铃。

4.3 参数表与调法：先录视频，再改阈值

下面这些参数是侧视角摄像头、画面里单人、归一化坐标下的参考值，不要不做实验直接抄：

调参的关键不是看单帧效果，而是看整段视频。我会准备 10 段正常行为视频和 10 段摔倒视频，先打印每一帧的 speed、angle、ratio 值，看两个类别在哪个区间分得开，再把阈值取在两端分布的中间。最忌讳的是对着摄像头摆几个动作就拍板，那样只能调出一组“对你自己姿势有效”的参数。

提示：把这些特征值写入日志再做阈值分析，比盯着实时画面调参高效得多。后面第六章会给出落盘方法。

4.4 摄像头视角不同时，哪些判断要重新校准

同一个算法在不同安装角度下，特征趋势会变。侧视角最舒服，angle 和 ratio 都敏感；俯视角时，人倒地后髋部中心仍在画面中间，height_ratio 变化不明显，这时要以 body_angle 和 bbox 宽高比为主；平视角时，髋部的绝对高度受人和摄像头之间距离影响大，ratio 不可靠，反而 angle 最稳定。

所以部署时先固定摄像头位置，再录一小段正常活动的参考视频，把 baseline_hip_y 的初始化和参数调好。课程设计如果是在实验室演示，别把摄像头拿在手里边走边测，那样 baseline 一直在变，状态机基本没法工作。

5. 避坑记录：从关键点丢失到误报警的 5 个典型场景

5.1 倒地瞬间姿态关键点消失，状态机停在 falling

现象：人在画面里确实摔倒了，但倒地那一两帧 MediaPipe 返回的 landmarks 为空，状态机一直停在 falling，永远进不了 fallen，最终没有报警。

原因：摔倒瞬间身体折叠、肢体遮挡严重，姿态模型检测置信度掉到门槛以下；画面模糊或运动拖影也会造成关键点输出中断。

解决：分两层处理。第一层，把min_detection_confidence从 0.5 降到 0.4，让模型更容易重新进入检测；第二层，在 landmarks 为空但前一帧状态不是 stable 时，用 YOLO 人框的宽高比做兜底——如果框高已经不足站立基准的 60%，且框宽大于框高，说明人大概率还在地上：

if landmarks is None and last_box is not None: box_h = last_box[3] - last_box[1] box_w = last_box[2] - last_box[0] if box_h < stand_h * 0.6 and box_w > box_h: fall_detector.keep_fallen_state()

这里的stand_h来自入场后前 30 帧的人框高度平均值。兜底逻辑不要做得太长，连续 10 帧无关键点就得重新锁定目标，否则会把后进来的其他人都算进状态里。

5.2 弯腰捡东西被当成摔倒

现象：测试时人在画面里弯腰捡起地上的水瓶，躯干一压低就触发了报警。

原因：弯腰时肩髋连线的夹角很容易超过 60 度，髋部位置也会下沉，恰好满足了 fallen 的两个条件。问题出在缺少“高速下落”的过程约束。

解决：状态机必须要求先进入 falling，也就是速度先超过 vel_thresh，等速度回落再复查低位和角度。弯腰动作再快，速度峰值通常也达不到摔倒的一半。把 vel_thresh 调到正常弯腰峰值速度的 1.5 倍以上，同时把 trigger_time 提到 0.5~0.6 秒，弯腰捡完东西的恢复过程会先让状态机回到 stable，自然就不会报警。

5.3 多人同框导致报警对象漂移

现象：画面里两个人交错行走，被监测目标本来是画面左侧的老人，两人一交叉，YOLO 的最大面积框跳到了右侧的年轻人身上，老人摔了没报警，年轻人蹲了一下反而报警。

原因：每一帧都取最大面积框，没有任何跨帧关联。

解决：做一个最简单的 IoU 跟踪。上一帧的目标框与当前帧所有框求 IoU，选最大的那个作为当前目标；如果 IoU 低于 0.3，说明目标丢失，连续丢失超过 30 帧再重新取最大面积框：

def iou(a, b): xx1 = max(a[0], b[0]); yy1 = max(a[1], b[1]) xx2 = min(a[2], b[2]); yy2 = min(a[3], b[3]) w = max(0, xx2 - xx1); h = max(0, yy2 - yy1) inter = w * h area_a = (a[2] - a[0]) * (a[3] - a[1]) area_b = (b[2] - b[0]) * (b[3] - b[1]) return inter / (area_a + area_b - inter + 1e-6) def pick_target(boxes, track_box): if track_box is None: return max(boxes, key=lambda b: (b[2] - b[0]) * (b[3] - b[1])) best = max(boxes, key=lambda b: iou(track_box, b)) return best if iou(track_box, best) > 0.3 else None

IoU 跟踪在课程设计里够用，不用上 DeepSORT。实验报告里把这个逻辑画成模块图，能明显体现出工程意识。

5.4 微调目标检测模型后反而崩了

现象：有同学用自拍数据集微调 YOLOv8s 后，原来能检测的人反而检测不到了，val 精度大幅下降。

原因：项目需要的只是 person 类，COCO 预训练已经覆盖得足够好。自作主张用几百张小图微调，学习率稍微大一点就发生灾难性遗忘，把原有表观特征冲掉了。

解决：默认不训练，直接用预训练权重。如果实验报告要求展示自建数据集的流程，一定要把训练参数控制住：

from ultralytics import YOLO model = YOLO("yolov8s.pt") model.train( data="fall_person.yaml", # 自建 person 标注数据集 epochs=30, lr0=1e-4, # 微调必须用很小的学习率 batch=8, freeze=10, # 冻结前 10 层骨干网络 imgsz=640 )

数据标注可以用 labelme 这类常见标注工具，但 person 类目标至少 300 张起步，而且要包含站、坐、躺、遮挡、不同光照。freeze 前 10 层骨干是防止把通用特征洗掉，lr0 超过 1e-3 基本必崩。

5.5 视频帧率不一致，速度阈值忽高忽低

现象：摄像头是 30fps，录下来的测试视频只有 15fps，用同一组阈值，实机演示不报，回放测试反而狂报。

原因：速度特征用的是“每秒位移”，但滑动窗口按帧数计算时间。帧率不同，实际时间差就不同，速度计算值成倍偏移。

解决：所有速度计算统一用真实时间差。记录每一帧到达的time.time()，窗口总时长取窗口首尾时间戳之差，不按帧数除以 fps 估算。

import time last_ts = None history = [] def update_history(hip_x, hip_y): now = time.time() history.append((now, hip_x, hip_y)) if len(history) > 30: history.pop(0) if len(history) < 2: return 0.0 dt = history[-1][0] - history[0][0] if dt <= 0: return 0.0 dx = history[-1][1] - history[0][1] dy = history[-1][2] - history[0][2] return math.hypot(dx, dy) / dt

这样不管视频源是摄像头、录制视频还是网上下载的 demo，速度特征都能对齐到同一套尺度。

6. 再进一步：把状态判断变成可回放的日志和验证闭环

6.1 小规模测试集 + 混淆矩阵，回答“准不准”

课程设计答辩里最容易被问的问题是“你这系统到底准不准”。与其说“感觉挺准的”，不如自己录一组小视频，做最简单的统计。我一般会准备 12 段短视频：6 段正常行走/弯腰/坐下，6 段不同方向的摔倒，每段 10~20 秒，跑完统计报警次数：

stats = {"tp": 0, "fp": 0, "fn": 0, "tn": 0} for video_path, label in test_set.items(): alarms = run_once(video_path) # 返回整段视频的报警次数 pred = 1 if alarms > 0 else 0 if pred == 1 and label == 1: stats["tp"] += 1 elif pred == 1 and label == 0: stats["fp"] += 1 elif pred == 0 and label == 1: stats["fn"] += 1 else: stats["tn"] += 1

这个统计很粗糙，但对课设来说足够直接。把混淆矩阵画进实验报告，比贴十张检测截图都有说服力。

6.2 特征时间序列落 CSV，让每个报警都能复盘

另一个被我写进很多次报告的习惯是特征落盘。每一帧把时间、状态、速度、角度、高度比写进 CSV，报警后回去看那一分钟的曲线，一眼就能看出阈值设置是否合理：

import csv, time with open("fall_log.csv", "a", newline="") as f: writer = csv.writer(f) writer.writerow([ time.strftime("%H:%M:%S"), state, f"{speed:.3f}", f"{angle:.1f}", f"{ratio:.2f}", "1" if alarm else "0" ])

参数调优时，这份 CSV 就是“后悔药”。改了阈值后跑同一段视频，对比报警点前后的特征值，不会出现调完 A 场景又挂掉 B 场景的黑匣子状态。

6.3 一个轻量平滑与可替换的告警接口

最后补两个小改进。一是对关键点做指数平滑，抑制 PortalMedia 输出的小抖动：

smoothed = alpha * raw + (1 - alpha) * smoothed # alpha 取 0.3~0.5

alpha 不要低于 0.3，否则速度峰值会被抹没，摔倒的“下落过程”就识别不出来了。二是把告警动作单独抽象成一个接口，后续接蜂鸣器、串口、HTTP 推送都只改一个类：

class AlertHandler: def notify(self, level, info): with open("alarm.txt", "a") as f: f.write(f"{time.time()} {level} {info}\n")

我做这套系统的最大教训是：阈值从来不是一次调出来的，而是一遍遍回放 CSV 日志磨出来的。每个报警背后都要有数据支撑，答辩时才不会被问倒，投入产出比最高的时间都在录测试视频和看日志上。希望帮到你。

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