基于OpenPose与DNN的跌倒检测系统：姿态特征工程与部署实战

1. 为什么我最终选了 OpenPose DNN 这套组合做跌倒检测先说结论跌倒检测这个需求看起来只是识别一个人倒没倒但真落地的时候会发现轮不到高深算法上场大多数坑都藏在怎么把姿态变化稳定地提取出来这件事上。我在做这个软件系统之前先试过两条更省事的路都碰了一鼻子灰最后才回到 OpenPose DNN 的组合。第一条路是直接用目标检测框做判断。用 YOLO 检测人体然后根据检测框的宽高比判断是否跌倒。这个思路很直观人站着的时候框是高的倒下的时候框是扁的。但问题是YOLO 框的抖动太厉害人稍微侧个身、弯个腰、蹲下系鞋带宽高比就乱了。而且摄像机视角一变同样的动作在不同角度下宽高比差别巨大做出来的模型换个房间就失灵。第二条路是用可穿戴设备比如手环里的加速度计。这个方案在实验室里数据很漂亮但实际使用面临一个大问题老人不愿意戴或者经常忘记充电。我去过养老机构调研护工阿姨直接跟我说你要能让他晚上睡觉不摘手环你就成功了一半。这话很扎心但也敲醒了我——这类场景必须是非接触式的摄像头方案才是唯一现实的选择。那为什么不直接用 OpenPose 输出的关键点坐标喂给神经网络就完事因为原始坐标对摄像机位置、人体距离、画面尺寸极度敏感直接把坐标丢进网络模型学到的会是这套摄像机位下的经验换个角度基本报废。正确的做法是先用 OpenPose 拿到关键点然后在这些点上做空间几何变换转出一批有物理意义、对视角相对不敏感的特征再把这些特征交给 DNN 做分类。这也是我为什么把系统命名为基于 OpenPose 和 DNN而不是基于深度学习——因为真正的判断依据是经过几何加工的姿态特征DNN 只是最后那个做决策的裁判。另外这套组合还有一层优势是解释性。OpenPose 给出的关键点可以直接叠加在画面上出问题的时候护工或者家属能看到一条骨架叠在视频上知道系统是根据什么判断的。这种可解释性在实际部署中非常重要——如果一个系统告诉你说检测到跌倒但画面上完全没有可验证的标记没有人敢信它。我后面会详细说正是靠这个可视化能力我在现场调试时才找到了大量误报的根源。2. 系统的完整链路从摄像头画面到告警推送整个系统的流程可以拆成五层我画个顺序给大家后面每一层我会讲关键决策。视频帧获取 → OpenPose关键点提取 → 特征工程计算 → DNN跌倒分类 → 告警与记录2.1 数据采集层兼容多路视频源数据采集层我做的第一个决策就是不要绑定某一个摄像头品牌。系统要能读本地摄像头、RTSP 网络流、本地视频文件三种来源。原因很现实——不同养老机构的硬件基础差异巨大有的一分钱预算没有只有一台老电脑和一个 USB 摄像头有的已经装了整套海康/大华的监控系统你只需要接入 RTSP 流。若系统只能接一种源很多机构的现场根本跑不起来。用 OpenCV 的VideoCapture接本地摄像头和视频文件都很简单但接 RTSP 流的时候有几个坑值得说一下。第一RTSP 流的缓冲延迟问题OpenCV 默认会积压几帧导致画面越来越滞后解决方法是手动清空缓冲# 降低 RTSP 延迟的常用处理 cap cv2.VideoCapture(rtsp_url) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) # 只保留最新一帧 while running: ret, frame cap.read() # 如果缓冲里还有多余帧全部丢弃只处理最新帧 for _ in range(3): cap.grab()第二摄像头断线重连问题。实测下来RTSP 流在 WiFi 环境下两三天必断一次。所以系统里必须有一个探活线程每 10 秒检查一次cap.isOpened()断了就 sleep 5 秒后重新创建VideoCapture对象。这个逻辑看着简单但少了它系统运行三天后就会变成悄悄哑火的状态——画面早就断了界面还显示正常。2.2 姿态估计层OpenPose 的模型选择与内置姿态估计层是全系统最耗算力的一层。OpenPose 模型的配置在效率和准确率之间有个明显的跷跷板关系。我在实际测试中对比了多个输入尺寸和网络结构最终选的是输入尺寸 432x368 的 BODY_25 模型。这版模型输出 25 个关键点比 COCO 模型的 18 点多了额头、双脚拇指等对于判断跌倒时头朝下趴地这类姿态非常关键。说一个很多教程里不会强调的点OpenPose 官方库的 Python 接口不太好用编译老出问题。我当时用了两天时间在 Linux 上编译 OpenPose 依赖库踩了一堆坑之后换了个思路——直接调用编译好的 OpenPose 库的pybind11接口并且把关键点提取封装成一个独立的推理服务进程。这样做的最大好处是如果模型推理崩溃不会连带拖垮主系统。后来我干脆改成通过 ZeroMQ 传输图像帧主进程只负责读视频和界面展示推理进程专门做 OpenPose 推理。这个进程隔离的设计让我在后面做性能优化时省了很多事——我可以随时重启推理进程而不影响整个软件的运行。2.3 特征计算层把关键点坐标翻译成物理量从 OpenPose 拿到的 25 个关键点只是一堆像素坐标直接扔给 DNN 是不行的。我在特征层设计上花的时间比训练模型的时间还多。经过多轮实验最终保留了一组对视角变化相对稳健的特征核心就是基于关键点的相对距离和角度。怎么让特征对视角稳健我的核心思路是不求绝对高度只求相对关系和变化量。例如某个特征计算人体中心相对脚踝的距离用像素距离除以人体身高的像素长度得到的就是一个无量纲的比例值这个值对不同距离的摄像头视角都比较稳定。姿态特征向量示例每帧计算一次 [躯干倾斜角余弦值, 中心点竖向比例, 头部离地高度比, 人体宽高比, 中心点竖向速度, 躯干角变化率, 关键点置信度均值]这部分我会在第 3 章展开讲计算细节因为它是整个系统里决定成败的核心。2.4 DNN 分类层不要迷信复杂模型分类层我一开始试过 LSTM、时序卷积网络折腾了很长时间最后发现一个反直觉的结果用简单的多层感知机 滑动窗口投票在效果和稳定性上完全不输那些复杂时序模型甚至误报率更低。原因也不复杂。跌倒这个过程本质是一个时间窗口内特征的剧烈变化而不是长期的时序依赖。LSTM 在长序列记忆上有优势但也会引入额外的过拟合风险。我把连续 15 帧每帧 7 维特征拼成一个长度为 105 的向量输入到 MLP模型结构是 105-128-64-2训练快推理极快单帧分类耗时在微秒级根本不成瓶颈。真正影响运行速度的是 OpenPose 推理那一层而不是 DNN 分类。2.5 告警与展示层人在回路系统的最后一步是告警。我在设计时坚持一个原则任何单帧的判断都不要给出告警至少连续 5 帧判定为跌倒才触发。这个5 帧确认机制能过滤掉大量瞬间误报。另外告警不是弹个窗就完事必须有人在回路的闭环——否则系统探测到异常但没有任何人处理等于白搭。告警策略我用了三级界面弹窗 警报音提示当前画面出现疑似跌倒自动保存事件截图和前后各 5 秒的视频片段方便回看通过邮件/企业微信 Webhook 推送通知让不在现场的家属或管理员也能及时知道这三层在后面的章节里会有更细的讨论。3. 跌倒判定的核心姿态特征工程与分类决策这一章是整个软件系统的灵魂。我把特征工程和数据流拆开讲因为很多人在 OpenPose 上跑通了推理但不知道怎么把关键点转换成跌倒这个结论最后只能粗暴地用一个角度阈值去做判断效果很差。3.1 关键点定义与坐标规约我用的是 BODY_25 模型25 个关键点对应的人体部位在官方文档里有详细定义其中对跌倒检测最有价值的核心关键点有关键点索引部位在跌倒检测中的用途0鼻子判断头部高度1颈部人体中心参考点8右髋 / 11 左髋躯干下沿9右膝 / 12 左膝腿部姿态14右踝 / 17 左踝地面参考点18, 19右/左脚拇指判断脚是否扬起拿到原始坐标后第一件事是置信度过滤。OpenPose 每个关键点会输出一个置信度分数0~1低于阈值的点不能用。我在实际调试中发现如果直接使用置信度很低的点比如被遮挡的脚踝特征值会出现剧烈的无规律跳变直接导致误报。我的处理策略是低于 0.4 置信度的关键点直接标记为缺失如果有连续 5 帧以上的关键点缺失就不再往下走分类逻辑将该帧标记为跟踪丢失。3.2 五个核心特征的计算方式这些特征是我在实际项目中反复验证后留下的。每一个我都解释计算方法和背后的物理含义。特征一人体中心竖向比例。定义颈部到踝关节的平均距离除以颈部到脚踝的最大历史距离通常取最近 5 秒内的最大值得到一个 0~1 的比例。这个比例的含义是人体当前直立程度。站着的时候接近 1躺下的时候会骤降到 0.3 左右。用比例而不是绝对像素是为了不受摄像头距离影响。def center_height_ratio(neck, ankle_l, ankle_r): # 颈部到两脚踝的平均距离 d_avg (dist(neck, ankle_l) dist(neck, ankle_r)) / 2 # 历史上限动态更新 global d_max if d_avg d_max: d_max d_avg * 0.98 # 缓慢跟踪 return d_avg / d_max if d_max 0 else 0特征二人体外接框宽高比。把 25 个关键点中有效的点取最小外接矩形计算宽高比。站立时宽高比小于 1倒地时大于 1。这个特征虽然简单但确实是最有区分度的指标之一而且它天然包含了身体在水平方向上的展开程度。特征三躯干倾斜角。计算肩部中心点与髋部中心点连线与垂直方向画面竖直方向的夹角余弦值。这个特征能捕捉身体是否倒向一边的信息。需要注意OpenPose 给出的肩部中心并不直接对应某个输出关键点需要取左右肩两个关键点的中点来计算。def torso_cosine(shoulder_l, shoulder_r, hip_l, hip_r): shoulder_c midpoint(shoulder_l, shoulder_r) hip_c midpoint(hip_l, hip_r) vec shoulder_c - hip_c # 余弦值 vec 与竖直方向(0, -1)的点积 / vec长度 return -vec.y / norm(vec)特征四中心点竖向速度。用最近两帧的颈部关键点 y 坐标差除以帧间隔时间。跌倒的特征是快速下降所以这个值会突然变为很大的负数。但要小心人主动蹲下或坐下时也会导致这个值快速变化所以单靠速度会误报必须结合其他特征一起看。特征五头部相对髋部的方位。跌倒后头部往往会低于髋部或者和髋部几乎平行。而正常蹲坐时头部虽然变低但仍高于髋部。计算鼻子关键点和双髋中心的相对位置可以得到一个头部水平化指数用于区分跌倒和蹲下/坐下。我专门做了一张表对比这五个特征在不同动作下的典型表现方便大家理解为什么不靠单个特征就能分类动作中心竖向比例宽高比躯干倾斜角余弦中心速度头部水平化指数正常站立高~0.951接近1接近0高弯腰捡东西中~0.6~1中等较小中蹲下低~0.35~1高变化后趋稳中坐下中低~0.45~1较高中等速度后趋稳中等跌倒骤降0.31较低高速下降低从表中能看出蹲下和跌倒很多特征接近区别在于变化速度和最终状态。DNN 的作用就是把这些特征综合起来学习出速度最终角度高度三者叠加的模式。我试过用纯规则去判断效果远不如一个小的 MLP。3.3 滑动窗口与投票确认机制DNN 每帧输出一个 0~1 的跌倒概率但单帧结果波动很大。为了避免误报我引入了滑动窗口记录最近 15 帧的分类结果只有当窗口内超过 60% 的帧判定为跌倒才触发告警状态。这个设计在实践中被验证非常有效。15 帧在 10fps 的帧率下相当于 1.5 秒的观察窗口足够覆盖一次跌倒动作的核心阶段又不会像太长窗口那样引入严重的延迟。窗口内大多数帧判定为跌倒时才进入疑似跌倒状态如果窗口内的判定比例掉到 40% 以下则自动恢复正常状态。还有一个容易忽略的细节冷却时间。一旦确认跌倒并触发告警在 60 秒内不再重复告警防止同一个跌倒事件发出 10 条通知把管理员打扰到崩溃。这个逻辑虽然简单但在真实部署中是刚需。4. 训练数据从哪来公开数据集、自制采集与数据增强DNN 分类器的效果一半取决于特征工程另一半取决于训练数据。这部分我讲一下数据来源和我在数据上踩过的坑。4.1 公开数据集的利与弊业界常用的跌倒检测公开数据集有 UR Fall Detection Dataset、Le2i Fall Detection Dataset、MultiCam 等。这些数据集里有大量的人跌倒和日常活动视频帧可以直接用来训练。但我实际用下来发现一个严重问题公开数据集的摄像角度往往比较理想多为平视或稍微俯视而真实养老机构的摄像头通常装在墙角高处俯角很大。这意味着用公开数据集训练出来的模型在我自己拍摄的俯视视角视频上误报率会明显升高。针对这个问题我的解决方法是公开数据集用于预训练然后用自己的数据做微调。用迁移学习的思路先在 UR Fall Detection 上训练一个初始模型再用现场视角拍摄的数据做二次训练。这个过程不必重复只需在部署新环境时采集一小段该环境的视频标注少量跌倒样本即可更新模型。4.2 自制数据集安全是第一优先级自制数据集的难点不在技术而在于安全。跌倒动作如果是真人表演摔几次很容易导致受伤。我强烈建议做跌倒动作采集时一定要在软垫上进行并且动作要做半主动控制的倒落不要真摔。我当时的采集方案是这样的准备一块 2m x 2m 的加厚瑜伽垫铺在平整的地面上志愿者穿长袖长裤戴护腕护肘和护膝采集动作包括站立平地跌落到侧卧、仰卧、俯卧走路时绊倒站立后仰跌倒弯腰时自然滑倒坐在椅子上滑落一侧日常动作包括蹲下捡东西、坐下、躺下休息、弯腰系鞋带、蹲下整理物品、躺在地上做拉伸每个动作录制 5~10 秒用 30fps 采集然后抽帧并只保留人体的关键帧。我最后积累了大约 8000 帧跌倒画面和 12000 帧日常活动画面比例为 1:1.5这个比例对训练来说是比较健康的。4.3 数据增强给关键点序列加噪声因为我的 DNN 输入是特征向量而不是原始图像所以数据增强的方向也和图像增强不同。我用了三类增强手段关键点抖动增强。对 OpenPose 输出的关键点坐标加上高斯噪声模拟低光照或遮挡情况下关键点定位不准的情况。噪声标准差取关键点之间平均距离的 0.5%~1% 比较合适太大反而让模型学到错误模式。随机丢失增强。随机将某个关键点的置信度设为 0模拟关键点被遮挡。这样训练出来的模型在真实环境中遇到有人被桌角挡住半边身体时不会立即失效。时间尺度扰动。对序列做随机的时间缩放比如把一段 2 秒的跌倒序列压缩成 1.5 秒模拟更快或更慢的动作节奏。这能增强模型对不同速度人群的适应性——毕竟有的老人跌倒过程很慢是渐渐滑倒有的则是瞬间摔倒特征的时间尺度差异非常大。5. 训练与调优实测准确率、误报率与推理速度的三角博弈这一章分享我在模型训练和现场调参中反复折腾出来的经验。可以说所有在实验室里觉得差不多了的模型到了真实场景都会被误报狠狠打脸。这里记录我实际遇到的最典型的几个问题。5.1 训练配置与最终指标我的 DNN 模型用 PyTorch 实现结构是输入层: 105 (15帧 × 7特征) 全连接层1: 128 ReLU Dropout(0.4) 全连接层2: 64 ReLU Dropout(0.3) 输出层: 2 Softmax 优化器: Adam lr0.001 损失函数: 交叉熵损失 Batch size: 64 Epochs: 80在这个配置下我的测试集准确率能达到 96% 左右。但请注意这个数字只能当作理想环境下的参考现场指标完全不同。在真实的养老机构测试时系统的准确率下降到了 88%~90%原因主要是现场光线复杂、摄像头俯角大、人物频繁遮挡。这里我要特别强调一个实战体会测试集一定要留出不同时间段的数据。我最初的训练集只在白天采集部署后晚上走廊灯一开误报率突然飙升。后来才发现夜间走廊的灯光从侧面打过来人体在地面上的影子会在 OpenPose 中被误识别成第二个人或关键点导致特征混乱。这个问题的解决方案是必须在模型训练的数据里就包含各种光照条件并且对 OpenPose 的置信度阈值做动态调整。5.2 误报类型分析与针对性解决这是我整个项目中最有价值的调研环节。我把现场反馈的所有误报事件收集起来分析之后归纳出了三大类。第一类弯腰捡东西被误判。这个问题最频繁。老人弯腰捡地上的物品时躯干倾斜角很大、中心点高度下降和跌倒的特征非常接近。解决办法引入恢复确认逻辑——正常弯腰捡东西后人会在 1~2 秒内恢复直立而跌倒发生后人不会快速恢复。所以在检测到疑似跌倒后如果后续 2 秒内中心点高度能恢复到正常水平的 70% 以上则自动取消告警状态。第二类影子被误识别为人。这个在夜间特别常见。OpenPose 对画面中所有像人的区域都会尝试估计姿态地上的人形阴影有时也会被识别出关键点。解决方向有两个一是用人的检测框先过滤——先用 YOLO 做人检测只对置信度高于 0.5 的人体框区域跑 OpenPose二是对 OpenPose 返回的关键点整体置信度求平均如果平均置信度过低说明这是疑似人影而不是真实的人。第三类画面中被挡住的半个人。比如老人坐在轮椅上只露上半身关键点缺失严重。这种场景下特征值很容易产生奇异值。解决办法设置关键点有效数量下限例如必须至少有 12 个关键点有效否则不进入分类流程。这样既防止误报也避免了大量无效计算。5.3 推理性能优化让系统跑得动OpenPose 对算力的要求是出了名的高。我的实测数据在 NVIDIA GTX 1060 上输入尺寸 432x368 的 OpenPose 推理大约需要 80~120ms换算成帧率也就是 8~12FPS。这个帧率对于跌倒检测来说够用但如果同时接多路摄像头就会出现掉帧问题。我优化推理性能做了三件事第一跳帧策略。跌倒动作的持续时间大多在 1~2 秒以上在 10FPS 下每帧做一次姿态估计完全是浪费。我把 OpenPose 推理从每帧降为每 3 帧一次中间两帧沿用上一帧的关键点特征向量则用线性插值估计。这样直接把整个系统的平均运算负担降低了约 60%。第二只对运动区域做姿态估计。如果当前帧与上一帧的目标检测框位置和大小几乎没有变化说明画面中的人没有大幅移动就没有必要重新跑 OpenPose。我用帧差法检测运动显著性只有当画面变化超过阈值的时候才执行完整的 OpenPose 推理。第三输入尺寸动态调整。检测框内的人体区域很大时用高分辨率输入人体较小时用低分辨率输入。推理时间能进一步压缩。不过这个策略需要注意一个坑分辨率切换时关键点坐标的噪声特性会发生变化因此我最终只用了两种固定分辨率做切换并且保证切换频率不能太高避免抖动。6. 软件系统落地界面、告警、日志与中英双语设计系统的算法部分做扎实之后剩下的工作就是把所有能力包装成一个真实可用的软件产品。这个阶段很多人容易低估工作量其实至少占了整个项目一半的时间。我拆开来逐个说。6.1 系统模块划分与进程架构软件采用多进程架构主界面进程、视频采集进程、OpenPose 推理进程、告警推送进程各自独立。进程间通信用 ZeroMQ图像数据和特征数据都用 MessagePack 做序列化。主界面我用 PyQt5 实现左侧是视频实时预览区右侧是系统状态面板和事件日志区。视频预览区上会实时绘制 25 个关键点和骨架连线状态面板显示当前帧率、当前分类结果、最近一次告警时间。考虑到现场操作人员可能不是技术人员界面语言要清晰菜单项也要尽量少——不能一上来就甩出一堆专业参数。6.2 告警逻辑不要只弹一个窗口前面提到告警分三级这里我详细说下告警策略的实现细节。第一级是界面告警。当判断为疑似跌倒时视频预览区边框变成红色同时弹出非模态警告窗口显示当前预览画面和疑似跌倒请确认按钮。按钮提供两个选项确认安全和立即救援。这两个选项对应的日志记录不同方便事后审计。第二级是音视频记录。触发疑似跌倒时程序立即保存从触发前 5 秒到触发后 5 秒的视频片段共 10 秒保存为 MP4 文件同时保存一张带骨架标注的截图。这个功能在取证和事后分析中非常重要也是家属最信任系统的原因——真出事的时候有据可查。第三级是远程通知。通过 HTTP Webhook 推送告警信息到企业微信群或邮件。系统内置了一个简单的告警客户端配置界面只需要填 Webhook 地址和标题模板就能用。为了不造成通知轰炸系统会在一次确认后进入 60 秒冷却期冷却期内同一目标不再重复推送。6.3 日志系统给排查问题留后门日志系统是软件落地后最重要的调试工具但往往被忽略。我的做法是每 5 分钟记录一条统计摘要总帧数、平均帧率、OpenPose 推理耗时、分类结果分布每次告警记录一条事件日志时间戳、视频帧路径、关键点特征值、DNN 输出概率。所有日志统一写入 SQLite 数据库并提供查询界面。这套日志的价值在一次现场调试中被充分体现用户反馈系统总是误报我看了一眼数据库里的关键点特征值发现某一时刻起所有样本的特征向量都出现了规律性的周期波动。再到现场一看原来是一台落地扇的扇叶在画面边缘规律摆动被 OpenPose 当成了人。这种问题如果没有特征值日志光靠肉眼看摄像头画面几乎不可能定位到原因。6.4 中英文双语的实现别用硬编码软件系统名叫跌倒检测软件系统对应的英文是Fall Detection Software System。既然要做中英文两个版本最忌讳的就是在代码里硬编码中文字符串然后想着事后翻译。我一开始就这么干的结果界面七八十处文案改起来后悔莫及。正确做法是用 Qt 的国际化机制QTranslator .ts/.qm 文件来实现。所有界面文案写英文然后用tr()包裹再通过语言文件加载中文翻译。启动时根据配置文件里的语言选项加载不同的语言文件。实际做下来熟悉这套流程后中英文切换只要改一个配置项就完成而且翻译团队哪怕是让同事帮忙核对也能并行工作。我还额外做了一个细节告警通知的语言也跟随系统语言。中文环境下企业微信推送中文消息英文环境下推送英文消息。模板放在独立的配置文件中运营人员自己就能改措辞不用动代码。# 语言配置示例 (config.json) { language: zh_CN, fall_alert_template_zh: 【跌倒告警】{time} 在 {location} 检测到疑似跌倒事件请尽快确认。, fall_alert_template_en: [Fall Alert] Suspected fall detected at {location} at {time}. Please check. }7. 部署环境适配与实时运行细节算法跑通了软件也出来了但距离真正能在一个养老机构里稳定运行一整个月不出问题还有一段路。我把自己在部署阶段遇到的最棘手的问题汇总在这里。7.1 摄像机视角标定每个房间都要做一次不同房间的摄像头安装高度、俯角、距离完全不同。我测试过一个模型在同一楼道的两个不同位置误报率差了 3 倍。原因很简单靠近窗户的位置逆光严重OpenPose 关键点提取质量明显下降。所以我在系统里增加了一个环境配准流程部署新房间时运行一次简单的向导。向导会让一位工作人员在镜头前做几次指定动作站立、蹲下、躺下系统自动采集这些动作的特征值计算出该环境下站立高度比例的基线然后基于这个基线微调分类器的阈值。这个步骤不会重新训练模型只是做阈值自适应但效果立竿见影。7.2 低算力设备上的运行方案不是所有机构都有带独立显卡的电脑。我们的目标设备一度定为普通办公电脑——没有 GPU只有 CPU。在这种机器上OpenPose 的 CPU 推理速度大约是 2~4FPS对于单路摄像头做跌倒检测也勉强够用但一旦有多个目标进入画面性能会进一步下降。针对 CPU 环境我做了两个针对性优化使用 OpenVINO 将 OpenPose 模型转换并加速在 Intel CPU 上推理时间可以缩短到原来的 1/3 左右将检测区域限制为固定的感兴趣区域ROI只有落入 ROI 的人才做姿态估计其他区域直接忽略需要提醒的是OpenVINO 转换经过一轮优化后关键点的精度会有一点下降大约 2%~3%需要通过宽容的阈值来补偿。实际测试下来跌倒检测的整体性能指标并没有明显劣化。7.3 现场网络与数据隐私运行时系统的主程序完全在本地运行视频流不会上传到任何云端服务器。这一点在部署时务必要跟机构说明——很多养老机构对老人隐私非常敏感如果系统还需要把视频上传到云端做分析合规审核这关就过不了。我的设计原则是所有推理都在本地完成只有告警事件中极小的一段截图和视频片段10秒会通过告警渠道发送给指定接收人而且这些内容由机构自己配置分发渠道系统本身不做任何云存储。7.4 长期运行稳定性内存、帧同步与视频兼容性系统计划 7x24 小时运行稳定性要求比实验室高得多。我最开始用 OpenCV 读 RTSP 流长时间运行后内存占用会缓慢增长三天后从 800MB 涨到 2GB最终崩溃。后来查资料发现是 OpenCV 底层在反复建立和断开 RTSP 连接时的内存泄漏问题解决办法是定时重启视频采集进程每 12 小时重启一次重启后重新拉流。内存之外还有一个容易踩的坑不同摄像头的时间戳同步。多路摄像头同时开启时如果各路视频的时间戳不统一告警截图里的时间可能有几秒的偏差。我的做法是所有告警事件统一以系统本地时间为基准只把摄像头视频流里的人物动作作为内容时间戳一律以系统事件时间为准。8. 一些意料之外但很重要的经验项目走到这里模型、软件、部署都算是跑通了。最后再分享几条我在这整个过程中体会最深、但又不是某个具体功能点的经验。别为了追求新技术而上模型。一开始我也纠结要不要用更强的姿态估计模型、要不要用图神经网络做行为识别。但在跌倒检测这个场景下OpenPose 特征工程 MLP 的组合在效果、稳定性、可解释性和部署成本上达到了最好的平衡。技术的价值在于解决实际问题不在于模型结构够不够新。现场数据永远比实验室数据重要。我在部署过程中形成的经验是真正有价值的调试数据全部来自现场持续运行后的日志分析而不是实验室里精心拍摄的数据。所以系统从第一天就要设计日志能力越早越好。等发现问题再去加日志往往会错过最关键的现场证据。跌倒检测系统本质上是一个人机协作系统。它不应该替代护理人员的眼睛而是作为他们的第二双眼睛在他们注意力分散的时候盯住画面。所以在设计交互时我特意把确认按钮放在界面最显眼的位置并且让误报取消的操作非常简单。护工不会因为频繁点确认安全而失去耐心这个系统才真正能被用起来而不是最后被关掉。如果在做这个项目之前有人告诉我算法只占一半另一半是日志、调试和交互设计我可能会半信半疑。但完成这个系统之后我完全认同了这一点。做类似项目的朋友如果一开始就意识到这个问题整个开发路径会顺畅很多。