长者康复活动识别系统设计与实现：基于姿态估计的动作分析实践

去年年底我接了一个挺有意思的项目，给某养老机构做一套长者康复活动识别系统。简单说，就是用摄像头加算法，自动识别老人做康复训练时做了哪些动作、做了几组、动作标不标准，然后生成报告给康复师参考。项目做完到现在跑了几个月，整体稳定，中间踩了不少坑，今天把整个设计思路和实现细节从头到尾捋一遍，希望能给正在做类似人体动作识别、康复医疗信息化项目的朋友一些参考。

先说说这个东西到底是干嘛的。康复训练对于长者来说不是可做可不做的附加项，而是维持身体机能的手段。但现实问题是，康复师的数量远远不够，一位康复师要同时盯着好几个老人做训练，根本看不过来。更麻烦的是，很多老人自己做着做着就偷懒了，动作变形、次数不够、组间休息时间过长，这些情况康复师很难实时发现。我们的目标就是做一个能自动识别康复动作、统计训练量、评估动作质量的系统，让康复师可以同时管理更多老人，也能拿到客观的数据辅助制定康复计划。

这篇文章主要面向做人体姿态估计、行为识别相关方向的技术同学，以及养老、康复机构里负责采购和落地信息化系统的人。我会从需求分析开始，依次讲清楚技术选型、系统架构、核心算法、数据标注、模型训练、部署落地和问题排查，尽量把每一步的思考过程和为什么这么选讲透。

1. 项目核心需求与整体设计思路

先别急着聊技术，这类项目最容易翻车的地方就是需求没搞清楚就开干。我们前期调研的时候发现，很多类似项目失败不是因为算法不行，而是做出来的东西根本不适合实际场景。所以需求分析这块我用了将近两周时间，驻场观察康复师的实际工作流程，跟三位康复师分别聊过，才最终定下需求边界。

1.1 场景约束条件决定技术路线

康复活动识别听起来是个纯视觉问题，但放在养老机构这个场景里，约束条件非常多。首先是隐私问题，老人对摄像头有天然抵触心理，不愿意自己的生活被盯着看。其次是光照问题，康复室内有大窗户，上午和下午的光照强度差异很大，还有灯光的频闪问题。第三是遮挡问题，康复师有时候会站在镜头和老人之间指导动作，还有一些辅助器械会挡住身体的一部分。

最关键的约束是老人和康复师的身体差异。老人的动作速度比年轻人慢很多，一个简单的抬臂动作可能要做三四秒，而且动作幅度参差不齐。常规的动作识别模型大多是在公开数据集上训练的，这些数据集的采集对象基本都是健康的年轻人，直接迁移到老人身上效果会很差。

另一个差点被忽略的需求是实时反馈。康复师明确提出来，希望老人在做训练的时候，系统如果有能力发现动作严重不规范，最好能当场提醒，不然老人做错了动作形成肌肉记忆，后面纠正起来很麻烦。这就把系统从离线分析推向了需要具备实时推理能力的方向。

1.2 功能模块划分与优先级排序

结合调研结果，我们把系统功能拆成了四个模块，按重要程度排序如下：

一是动作类型识别，就是判断当前老人正在做的是哪一类康复动作，比如坐姿抬臂、站立下蹲、侧平举等，准确率要求达到90%以上，这是整个系统的基础能力。

二是动作计数与组数统计，识别出动作后还需要统计每个动作做了多少次，分成几组，还原出完整的训练量。这个看似简单，但对时序切分算法要求很高，因为老人动作慢，动作和动作之间的停顿不明显，容易出现重复计数或者漏计的情况。

三是动作质量评估，通过关节角度等指标判断动作是否标准，比如手肘有没有完全伸直、膝盖有没有超过脚尖等，输出一个质量得分和具体的偏差描述。这部分最难，因为每个人身体条件不一样，不能用绝对标准去卡。

四是训练报告生成，康复师可以查看每个老人某天的训练记录、动作曲线和异常提醒，支持导出PDF报告用于存档和家属沟通。

初版我们没有做实时语音提醒，因为老人在听到机器声音时的反应不可控，有些人会紧张导致动作变形。后面在实测过程中发现光有视觉提示力度不够，又加了一个可选开关，默认关闭，康复师可以按需开启。这个决策在后面落地时证明非常重要，避免了很多老人对设备的反感。

1.3 为什么最终选择了视觉方案而不是传感器方案

其实最开始我们评估过两条技术路径。一条是可穿戴传感器方案，让老人戴上手环或者在身上贴几个惯性传感器（IMU），通过加速度计和陀螺仪的数据来判断动作。另一条是视觉方案，用普通RGB摄像头加姿态估计算法。

传感器方案的优势在于不受遮挡影响，隐私性也更好，毕竟采集的不是图像。但我们最终放弃它的原因有三个：第一，让老人每天佩戴并正确穿戴设备本身就是巨大的运营成本，很多老人不是忘记戴就是戴错位置，数据质量无法保证；第二，IMU数据的动作识别需要重新采集大量传感器数据来训练模型，而我们手头能拿到的公开数据集很少；第三，康复师明确表示不希望花时间在设备分发和回收上。

视觉方案虽然面临隐私争议和遮挡问题，但优势在于零接触、零穿戴负担、硬件成本低，而且姿态估计领域有大量成熟的预训练模型可以直接用，算法迭代速度快。最终我们通过隐私设计打消了机构顾虑：摄像头只安装在固定的康复训练区域，不覆盖生活区；视频流在本地边缘设备上完成推理，只上传骨骼关键点数据，不上传原始图像。

经验提示：做这类和医疗、养老相关的项目，技术选型之前一定要把场景里的软约束条件列全面，包括人、环境、流程各自的限制。很多时候最优技术方案不一定是工程上最好落地的方案。

2. 系统架构设计与关键技术选型

架构设计上，我没有选择那种动辄几十个微服务的大一统方案。一个养老机构的康复区，同时在线老人数撑死了二三十个，用太重的东西纯粹是给自己找麻烦。整体架构采用了两层结构：边缘计算节点做实时推理，中心服务器做数据汇聚和管理。

2.1 端边云三层拓扑与控制流

实际架构分成了三层，但逻辑上边缘和中心是两层：

第一层是端侧摄像头，选用的是普通的400万像素网络摄像头，支持RTSP协议，价格便宜且替换方便。没有选深度相机或者3D结构光相机，原因后面细说。

第二层是边缘计算节点，每个康复训练室放一台工控机，配置是CPU加一块中端推理卡，承担实时视频解码、姿态估计、动作识别和反馈提示。

第三层是中心服务器，部署数据库、报表服务和管理后台，汇总所有边缘节点上传的训练数据。

数据流向是这样的：摄像头RTSP视频流持续推给边缘节点，边缘节点以固定的频率跑姿态估计，提取出人体关键点坐标，送入动作识别模块判断当前动作类型，同时计算关节角度用于质量评估。识别结果按时间戳组织成session（一次训练过程），结束后整体上传到中心服务器，中心服务器负责统计汇总，生成报告。

2.2 为什么不用3D骨骼方案

很多做人体动作识别的项目第一步就会考虑用深度相机，比如结构光或者ToF方案，以获得3D骨骼信息。我在这件事上纠结了很久，最终还是用了2D彩色摄像头加2D姿态估计，原因是：

3D传感器的有效工作距离通常比较短，一般要求人在相机2到4米范围内，而康复室的实际布局往往需要更大的活动空间。而且3D相机对自然光非常敏感，窗口边的强光会造成深度值大量缺失，恰好康复室又都是明亮环境。第三是成本因素，3D相机的单台价格是普通网络摄像头的三倍以上，一个康复室装两台就要多花不少钱。

2D姿态估计虽然丢失了深度信息，但通过多视角几何约束，在两个摄像头交叉覆盖的区域内，我们依然可以恢复出足够准确的关键点位置。另外2D模型的预训练资源极其丰富，我们基于开源方案微调的成本低很多。对于康复动作识别来说，绝大多数关键动作信息都体现在二维平面上的关节角度变化，比如上肢伸展、肘关节屈伸、髋关节俯仰，这些用2D关键点在图像平面上的投影就能算出来，实在没必要为了追求理论上的3D精确度把工程复杂度拉高一个量级。

2.3 姿态估计模型选型：精度与速度的折中

姿态估计是整个系统的地基，这一步错了后面全完。我们对比了主流的几种方案，最终选择了基于自顶向下路线的轻量化检测加关键点模型。

自顶向下就是先做人检测把人框出来，再在框内做关键点检测。这个方案的优势在于关键点检测的精度高，因为输入区域是裁剪后的人的局部图像，避免了小目标的关键点漏检问题。代价是整体速度略慢于自底向上的方案，每个检测框都要单独过一遍关键点网络。

我们对模型选择有几个硬性指标：单人关键点检测延迟低于30毫秒，支持多人场景，模型文件大小控制在合理范围内以便在工控机上跑。基于这个目标，选了开源模型库里一个基于轻量化主干网络的关键点模型，输入尺寸设定为256乘192，输出17个COCO格式的关节点。实际测试在边缘节点上推理帧率能达到25到30帧每秒，已经满足实时性要求。

注意：很多团队在选姿态模型时只看得分齐不齐，忘了还要看关节点的空间抖动情况。康复动作识别对时间序列上的稳定性要求很高，如果关键点在帧间跳来跳去，后面做动作切分和角度计算都会出问题。实测中我发现有些模型精度指标很好，但关键点抖动大，角度曲线没法看，根本不能用。

3. 数据采集与数据集构建实战

模型选型做完后，最头疼的问题来了：数据从哪来。公开的人体姿态数据集大多是日常活动或体育动作，几乎没有老年人做康复训练的数据。而我们的动作识别模型如果只在公开数据上训练，一到真实场景迁移效果就会快速衰减，这在迁移学习里叫域偏移问题。所以必须自己采集一批真实场景数据。

3.1 动作体系定义与分类逻辑

首先和康复师一起定义了动作体系。这一步非常关键，因为动作定义不清晰会直接影响算法的复杂度。我们最终确定了六类核心动作，覆盖了机构康复训练的高频项目：

坐姿肩关节前屈、坐姿肘关节屈伸、坐姿髋关节外展、站立位原地踏步、站立位下蹲、站立位侧平举。

每个动作还定义了标准版的关键角度区间，这个后面会用来做质量评估。比如坐姿肘关节屈伸，我们记录的标准是肘关节角度活动范围在30度到150度之间，角度爬升和回落的曲线都是相对平滑的。这些标准不是我们拍脑袋定的，是康复师根据运动康复学的一般原则结合机构多数老人的能力给的参考值。

分类体系上我们没有做得太复杂，六类动作在结构上差异明显，关节运动模式完全不同，用分类模型解决绰绰有余。我也见过一些项目非要用动作检测的框架把所有动作都做成时序检测，结果数据量根本喂不饱，识别效果一塌糊涂。

3.2 数据采集流程与样本质量控制

采集工作花了三周时间，过程比预想的曲折。我们在一间空的康复室里架好相机，邀请了不同身体状况的志愿者来模拟做动作，覆盖不同身高体型、不同动作速度、不同服装颜色。同时刻意录了一些非标准动作、中途停顿、和康复师对话等干扰情况。

为了保证数据的真实多样性，我们要求每位志愿者至少完成三种不同速度和幅度的动作版本：标准动作、慢速动作、轻度偏差动作。这样做的好处是让模型学会容忍合理范围内的变化，而不是只学会识别标准动作这一个模式。

3.3 数据标注策略与质量控制

关键点数据的标注和动作标签的标注是分开走的。姿态估计模型的微调用的是自动标注加人工修正的方式，先用开源预训练模型生成初版关键点，再由标注人员修正明显的错点。动作识别模型的数据则是人工打标签，每段视频裁剪成几秒的片段，标记动作类别和起止帧。

标注质量控制是我们踩坑最深的地方。刚开始标注标准写得含糊，导致不同标注人员的判断不一致，同一段动作有人标成标准有人标成偏差。后面对标注规范做了明确量化：关节角度偏离参考值多少度以上算偏差、动作速度低于多少算慢速，全部写死。这样标注一致性明显提高。

最终我们拿到了约两万段有效动作片段，按七比二比一分为训练集、验证集和测试集。这个数据量对于六类动作的分类任务来说不算大，但加上预训练模型的迁移，已经在工程上够用了。如果要从零训练一个模型，这个数据量是远远不够的。

4. 动作识别与计数算法实现

动作识别这块是系统的核心，也是踩坑最多的地方。整体方案采用了两阶段策略：先做姿态估计拿到每帧的关键点序列，再基于关键点序列做动作识别和计数。这样的好处是动作识别模块不直接处理图像，逻辑更清晰，也方便单独测试和优化。

4.1 动作特征构造

拿到17个关键点后，不能直接把原始坐标扔给分类器，因为坐标值受人体在画面中的位置和大小影响非常大。站在画面左边和右边，同一动作的坐标值完全不同。所以第一步是构造尺度无关的关节特征。

具体做法是以髋关节中心为参考点，把所有关键点坐标减去该点坐标做中心化，再除以肩髋距离做归一化。这样得到的特征在人体位置变化和距离相机远近变化时都能保持稳定。另外还加入了关键动作关节的角度值，比如肘关节角、肩关节角、膝关节角，这些角度本身就对尺度不敏感，是识别动作的重要特征。

除了单帧特征，还要考虑时序上下文。单个动作至少持续几十帧，只用单帧特征判断容易把动作中途的某个位置误判成另一类动作。我们把连续15帧的特征打包成一个序列窗口，送给时序分类模型。窗口之间用重叠滑动的策略，保证动作边界信息不会因为窗口切割而丢失。

4.2 动作分类模型对比与选择

在模型选择上，我对比了两种路线：一种是基于时序卷积的简单模型，另一种是用LSTM或者Transformer做序列建模。可能是因为数据量还不够大，再加上动作本身是低速变化的过程，简单的时序卷积模型在准确率和稳定性上反而超过了复杂的LSTM模型，而且推理速度更快，模型体积也小很多。

这里有个常被忽视的点：像LSTM这类循环网络对于长序列的记忆能力强，但我们的康复动作长度大多在两秒以内，15帧的窗口已经包含了完整的动作周期。在这样的短序列场景下，循环网络的优势发挥不出来，反而因为训练难度大、容易过拟合而拖后腿。我比较推荐先用简单模型搭一个能跑的pipeline，如果效果不达标再去加复杂度。

4.3 连续动作流中的动作切分与计数

上面说的分类模型只能对窗口片段做分类，但真实场景中摄像头前面是一个连续的动作流，需要把动作和动作切开。动作切分是整个系统里难度最高的部分。康复动作的特点决定了它比普通健身动作难切得多：老人动作速度慢，动作之间的停顿时间长，而且每个人的停顿习惯不一样，很难靠固定阈值来判断动作结束。

我们最终实现了一个有限状态机来切分动作：定义空闲态和动作执行态两个状态，根据分类模型的输出置信度和关节运动幅度来判断状态切换。当置信度超过阈值且关节移动幅度超过一定值，进入动作执行态开始计数；当置信度持续低于阈值或关节静止超过指定时长，回到空闲态完成一次计数。

这个方案早期有一个让我抓狂的问题：如果老人在动作过程中突然停住擦汗，系统会把一次动作切成两次，导致计数翻倍。后面用了一个很有效的技巧，内部分为融断时长，在动作执行态里允许出现短暂的低置信度片段而不立刻结束，必须连续低置信度帧数达到一定数量才判定动作真正结束。这个参数的调优花了很长时间，最终定为0.6秒，既能容忍中途停顿，又不会把两个连续动作合并成一个。

4.4 质量评估算法

质量评估是这次项目中我觉得最有价值的部分。实现思路是在识别动作类型后，针对每个动作类型的关键关节角度序列做回归分析，和标准角度区间做对比，输出偏差分值。

以坐姿肩关节前屈为例，系统会提取肩关节角度随时间的曲线，和康复师给出的参考角度曲线做比较。为了让不同人的动作曲线可比较，我们把时间轴做了归一化，把动作周期映射到0到1的区间。然后用动态时间规整（DTW）算法度量测试曲线和参考曲线的差异。

不过做质量评估的前提是曲线对齐准确。DTW虽然能对齐非线性的时间变化，但对噪声非常敏感，关键点抖动会让对齐结果漂移。所以进入质量评估前要先对角度序列做平滑滤波。我试过几种滤波算法，最后选了基于局部加权回归的平滑方法，效果明显优于滑动平均滤波，曲线失真小，推荐程度极高。

实操心得：做质量评估时不要试图用一个全局得分覆盖所有问题。更好的做法是分项输出，比如肘关节角度偏差、动作完成度、动作连贯性，每个维度单独给分和文字描述。康复师真正想看到的是具体哪里不行，不是一个看不懂的综合得分。我们最终报告的形式就是每个动作一张三线表加一段摘要文字，康复师反馈说清晰度提升明显。

5. 部署落地与边缘计算优化

算法在开发机上能跑只是第一步，真正考验人的是部署到现场后的表现。康复室的边端环境远比实验室复杂，光线变化、网络波动、设备老化都会让系统性能大幅退化。这部分我把现场部署和优化的实践完整记录下来。

5.1 边缘节点的硬件选型与量化

边缘节点我们选的是某品牌的紧凑型工控机，CPU八核，16G内存，加了一块中端推理卡。开始也考虑过纯CPU推理，实测下来姿态估计的帧率只有不到10帧每秒，远远不够，加上推理卡后提升到25帧以上，体感翻了一倍。

功耗和散热也是选型的重要指标。康复室没有专门的机房，设备放在室内的柜子里，夏天室温高，如果设备散热不好容易降频或者死机。我们选的工控机是无风扇设计，虽然噪音小但散热能力有限，后来在机柜里加了一个小风扇朝外排风，才把运行温度稳定在60度以内。

模型量化方面，我们用推理卡自带的工具把姿态估计模型从浮点精度量化到半精度，损失了大概1到2个百分点的关键点准确度，但推理速度提升了接近一倍。对于动作识别这类对细节敏感的任务，我建议不要直接上整型量化，半精度的性价比已经足够。

5.2 视频流接入与异常断开处理

现场摄像头用的是RTSP协议接入边缘节点，最常遇到的问题就是视频流不稳定，经常出现花屏、卡顿、断流。排查后发现很大一部分原因是摄像头和交换机之间的网线质量差，加上现场有电磁干扰，后来全部换成屏蔽网线后问题明显缓解。

代码层面，视频流处理模块必须实现自动重连机制。我们封装了一个视频流客户端，用独立的线程维持连接，一旦探测到帧率下降或者解码失败就自动断开重连，同时向上层抛出状态事件供系统记录。这个看起来很简单的功能，在长期运行中比算法本身还要重要。

5.3 数据上报与离线缓存机制

边缘节点识别出来的训练数据不能保证实时上传到中心服务器，因为养老机构的网络并不可靠，偶尔会出现断网。我们在边缘节点上做了一个轻量级本地队列，每个训练session生成后先写入本地SQLite数据库，再异步上传到中心服务器。上传成功打个标记，上传失败留待下次重试。

这个缓存机制最后救了项目一次。有一段时间中心服务器磁盘满了导致写入失败，边缘节点依靠离线缓存完整保存了三天多的数据，网络恢复后全部补传成功，没有丢一条训练记录。如果当时不上缓存，这些数据就全没了。

6. 常见问题与排查技巧实录

这个项目前后跑了大半年，积累了很多实际运行中的问题和排查经验。我把遇到频率高的、有代表性的问题整理成速查表，后面接手的同学可以直接对着排查。

6.1 问题速查表与解决手段

需要特别强调第一条，摄像头安装位置是决定系统效果的第一要素。我们第一次在机构安装时贪图美观，把摄像头装在大厅角落的高处，结果拍出来的人很小，关键点检测质量直线下降。后来改成在康复区正上方三米高的位置，斜向下拍摄，画面中人高约占图像高度的60%左右，关键点检测准确度才回到理想水平。

6.2 实际运行中的性能和稳定性数据

系统上线运行四个月后的数据可以给大家一个参考：边缘节点连续运行的稳定性在99.2%左右，也就是平均每天大概有一次短暂的视频断流或进程重启。系统整体实时识别帧率稳定在每秒20帧以上，动作识别准确率为92.7%，在排除了光照恶劣时段后可以达到95%以上。

动作计数的准确率是91.5%，整体偏高。但在个别动作上准确率明显偏低，主要是站立位下蹲这个动作，因为下蹲过程中髋关节和膝关节离摄像头更近，肢体遮挡严重，关键点经常丢。针对这个情况，我们在对应训练区域加装了一个辅助视角的侧方摄像头，融合两侧关键点才解决了。

训练报告从生成到出PDF耗时平均不到1秒，机构康复师表示可以接受。实际使用过程中，康复师看重的不是报告里的各种图表有多美观，而是数据的可追溯性，每一条训练记录要能对应到某天的某个时间段，方便他们和家属沟通时调出原始证据。

6.3 用户反馈驱动的迭代优化

系统上线后，康复师提了不少改进建议，其中两个被采纳并在后续版本中落地。第一个是训练量周报功能，自动汇总每位老人一周的训练总量和动作分布，并给出是否达标的提示。第二个是风险评估预警，当系统检测到老人某个动作角度连续多次超过安全范围时，自动生成提醒事件。这两个功能都极大地提高了机构端的接受度，也证明了这个系统的价值不止于识别本身，而是通过数据帮助管理者做出更好的决策。

注意：做这类项目一定不能闭门造车。我们每次迭代都先和康复师对需求，产品原型做出来后在真实环境试用一周再收集反馈。有时候算法团队觉得某个指标已经很好了，但用户根本不关注那个指标，反而提了一个我们不以为意的小痛点。保持和用户的紧密沟通，是项目能否被真正用起来的关键。

7. 经验总结与项目复盘

项目交付后我花了不少时间复盘整个过程，很多经验和教训值得在这里记录下来。

我最大的体会是：算法不是这类系统的全部，数据链路和工程可靠性往往决定生死。算法准确率可以慢慢调优，但系统用着用着就断流、丢数据、界面卡死，再好的算法也没人愿意用。我们后来花在稳定性调试上的时间远超算法优化，这个时间比例是完全值得的。

另一点是关于模型持续迭代的必要性。系统上线的第一版模型在夏天表现很好，但到了秋冬换季，康复室关了空调开了暖气，加上室内光线变化，识别准确率下降了几个点。如果没有建立一套定期数据回流和微调的机制，系统性能会随着时间推移不断衰减。我们最后做了一个简易的主动学习循环：每周把置信度低于阈值且被康复师确认为错误样本的数据挑出来，加入训练集重新微调。这个机制让模型越用越准，机构那边也非常认可。

如果你准备做类似的长者康复或者运动识别项目，我建议先想清楚三件事：第一，你的模型拿到真实场景数据能否保持性能，域偏移问题有没有预案；第二，系统在断网断电等异常情况下数据是否安全；第三，你有没有一套和领域专家持续沟通的机制，而不是只在项目开始时采访一次就完了。把这三件事想透，项目至少不会跑偏到不可收拾的地步。

最后分享一个小细节：摄像头的清洁频率。我们项目早期频繁出现关键点检测质量下降，排查了很久才发现是摄像头镜头上落了一层灰。机构保洁阿姨不会主动去擦悬挂在高处的摄像头，后来我们在运营手册里明确写了每周清洁一次摄像头的安排，问题就再没出现过。这类不起眼的运维细节，往往比高级算法更能决定系统的长期成效。