企业官网建设流程全解析

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 个关键点对应的人体部位在官方文档里有详细定义，其中对跌倒检测最有价值的核心关键点有：

拿到原始坐标后，第一件事是置信度过滤。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 坐标差除以帧间隔时间。跌倒的特征是快速下降，所以这个值会突然变为很大的负数。但要小心，人主动蹲下或坐下时也会导致这个值快速变化，所以单靠速度会误报，必须结合其他特征一起看。

特征五：头部相对髋部的方位。跌倒后头部往往会低于髋部，或者和髋部几乎平行。而正常蹲坐时，头部虽然变低，但仍高于髋部。计算鼻子关键点和双髋中心的相对位置，可以得到一个"头部水平化指数"，用于区分"跌倒"和"蹲下/坐下"。

我专门做了一张表，对比这五个特征在不同动作下的典型表现，方便大家理解为什么不靠单个特征就能分类：

从表中能看出，"蹲下"和"跌倒"很多特征接近，区别在于变化速度和最终状态。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 lr=0.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 的组合在效果、稳定性、可解释性和部署成本上达到了最好的平衡。技术的价值在于解决实际问题，不在于模型结构够不够新。

现场数据永远比实验室数据重要。我在部署过程中形成的经验是：真正有价值的调试数据，全部来自现场持续运行后的日志分析，而不是实验室里精心拍摄的数据。所以系统从第一天就要设计日志能力，越早越好。等发现问题再去加日志，往往会错过最关键的现场证据。

跌倒检测系统本质上是一个"人机协作"系统。它不应该替代护理人员的眼睛，而是作为他们的第二双眼睛，在他们注意力分散的时候盯住画面。所以在设计交互时，我特意把"确认"按钮放在界面最显眼的位置，并且让"误报取消"的操作非常简单。护工不会因为频繁点"确认安全"而失去耐心，这个系统才真正能被用起来，而不是最后被关掉。

如果在做这个项目之前有人告诉我"算法只占一半，另一半是日志、调试和交互设计"，我可能会半信半疑。但完成这个系统之后，我完全认同了这一点。做类似项目的朋友，如果一开始就意识到这个问题，整个开发路径会顺畅很多。