简介基于姿态估计的健身评分系统完整代码与配套资源面向希望用Python构建AI动作评估应用的开发者、健身教练或科技健身爱好者。项目以举哑铃动作为示例完整展示从人体关键点提取、肢节组合到骨骼向量角实时计算并与标准动作比对后输出各肢体评分及总评分的流程可细化到手腕稳定性、肘部弯曲程度、肩关节活动范围等维度。压缩包共114个文件约225.1MB包含41个Python脚本、28个编译后的pyc文件、预训练模型文件pb/h5、配置文件、图片素材及演示视频兼顾源码阅读、模型加载与效果预览可支撑环境配置、推理运行和二次开发另有启动脚本和说明文档便于快速跑通示例。目前已有42人学习下载。通过研读源码与模型结构读者还能将方案迁移到深蹲、俯卧撑等其他动作的评分场景为个性化健身反馈或教学辅助提供可落地的参考实现。1. 健身评分系统姿态估计如何把举哑铃动作拆成可量化分数健身房里的典型一幕学员对着镜子练哑铃弯举动作做没做标准眼睛说了不算教练喊“手腕稳住”喊到口干。动作质量不能靠肉眼和感觉得靠数据。姿态估计技术把这个问题变成一个可量化任务用 Python 搭一套 AI 健身评分系统先从视频帧里提取人体 18 个关键点再把肩、肘、腕组合成骨骼向量实时计算向量角最后和标准动作比对输出各肢体评分和总评分。这套方案不止能评举哑铃深蹲、硬拉、推举都能迁移使用。适合想自己动手实现动作分析、又不想从头训练模型的开发者也适合给健身类小程序增加动作评分模块的产品。下面把这份资源的原理、落地、踩坑和调参顺序一条条拆开。2. 姿态估计到骨骼向量角评分系统的计算链路与数据形态2.1 从关键点到肢节组合OpenPose 在评分系统里承担什么姿态估计模型输出的原始结果是热图不是坐标。OpenPose 的 Part Affinity Fields 后处理要把热图解析成人体的关键点COCO 标准下是 18 个关键点从鼻子、双肩、双肘、双腕一直到双踝每个关键点携带 (x, y, confidence) 三项信息。评分系统不会用到全部 18 个点举哑铃主要依赖肩、肘、腕、髋这几个部位所以实现时通常只取索引 5、6、7、8、9、10、11、12 这八个点也就是左右肩、左右肘、左右腕、左右髋。这份资源里带的 pafprocess 相关文件做的正是后处理这一步。pafprocess.h 和 pafprocess.cpp 是核心实现pafprocess.i 是 SWIG 接口定义numpy.i 负责 NumPy 数组和 C 数组之间的类型映射pafprocess_wrap.cpp 和 pafprocess_wrap.cxx 是 SWIG 生成的胶水代码_pafprocess.cp36-win_amd64.exp 是 Windows 平台 MSVC 编译产生的导出符号文件。整条链路在 Python 侧的调用方式是先由 TensorFlow 模型推理出热图再把热图传给 pafprocess 做 C 后处理返回的是关键点数组。为什么要把后处理单独拿出来编译成扩展而不是用纯 Python 遍历热图原因很实际热图的尺寸一般是 46×80 到 96×160每个像素都是一个候选响应点纯 Python 做非极大值抑制和 PAF 积分一帧要跑几十毫秒加上模型推理整个循环很难保住 20 FPS。C 实现的后处理通常能把每帧压缩到 3 到 8 毫秒收益可观。选 pafprocess 而不是直接调用 OpenPose 官方库是因为官方版的依赖链太长Windows 下配置 CUDA、Caffe 很劝退而这份资源已经把后处理单独抽出来依赖面小很多。2.2 骨骼向量角的几何计算与角度定义关键点坐标拿到手之后还不能直接用来评分。不同人的身高臂长差异会让同样的动作产生完全不同的坐标值比如一个 160cm 的用户和一个 190cm 的用户做同样的弯举肘关节的绝对坐标能差几十个像素但角度几乎相同。所以评分系统的输入必须是骨骼向量角也就是由三个关键点构成的夹角。要得到肘关节角用肩、肘、腕三个点以肘为顶点肩到肘是一个向量肘到腕是另一个向量两个向量的夹角就是我们要的角度。这个计算在数学上就是向量点积除以模长再取反余弦。写的时候要注意三件事顶点必须放中间p2 传肘而不是肩两个关键点完全重合时模长为 0要加极小值防除零浮点误差可能让点积比值略超 [-1, 1]直接交给 arccos 会返回 nan。import numpy as np def compute_angle(p1, p2, p3): 计算三个关键点 p1-p2-p3 构成的夹角度p2 为顶点。 例如肩-肘-腕p1肩, p2肘, p3腕。 v1 p1 - p2 v2 p3 - p2 norm1 np.linalg.norm(v1) norm2 np.linalg.norm(v2) if norm1 1e-6 or norm2 1e-6: return 0.0 cos_theta np.dot(v1, v2) / (norm1 * norm2) cos_theta np.clip(cos_theta, -1.0, 1.0) return float(np.degrees(np.arccos(cos_theta)))这段代码里我加了两个防御性处理norm 小于 1e-6 时直接返回 0.0避免除零np.clip 限制 cosine 的取值范围。这两个处理看着不起眼实际运行时能避开两类很隐蔽的 bug关键点被遮挡时模型可能给出两个相同坐标或者坐标精度导致 cos 为 1.0000001arccos 直接报错。用这段计算肩-肘-腕得到肘角用髋-肩-肘得到肩角用肩-髋-膝得到躯干角用肘-腕-手背参考点得到手腕角。手腕角的第三点手背参考点在 COCO 18 点里没有直接对应项惯常做法是用肘关键点和腕关键点连线的延长线方向近似或者直接取手部区域像素和腕点构成的方向。手部关键点缺失时也可以退而求其次用腕点与肘点的连线在垂直方向上的偏移来估计手腕翻转程度。这个近似在哑铃弯举场景里精度足够因为腕部动作幅度本身很小误差容忍度相对高。2.3 标准动作比对与评分映射角度值算出来后评分逻辑的核心是标准区间 线性衰减。先为每个关节组定义标准角度区间实测角度落在区间内就给满分超出区间后按超出的角度差线性扣分超过容忍度后直接给 0 分。这个映射方式比简单的在区间内 100 分否则 0 分平滑得多能给出渐进式的反馈用户可以看到自己离标准动作差了多少度。def score_angle(current, lower, upper, tolerance15.0, full_score100.0): 把实时角度映射到 0-100 分。 lower/upper: 标准动作的角度区间 tolerance: 允许超出区间的最大角度差超过后记 0 分 if lower current upper: return full_score exceed 0.0 if current lower: exceed lower - current else: exceed current - upper if exceed tolerance: return 0.0 remain 1.0 - exceed / tolerance return round(full_score * max(remain, 0.0), 1)在这个函数里tolerance 是控制扣分斜率的关键参数。tolerance 越小曲线越陡动作稍微偏差分数就掉得很厉害tolerance 越大动作明显不标准时分数依然偏高反馈不痛不痒。我一般把 tolerance 设成标准区间宽度的 1/3 到 1/2比如标准区间是 30° 到 60°宽度 30°tolerance 取 10 到 15 度比较合适。这个经验值不来自官方文档而是实际调参过程中反复试出来的你可以先按这个范围初始化再用后面说的视频回放法微调。四个肢体组的评分配置可以参考下面这张示例表。要注意它只是初始配置不同人的关节活动度差异很大真正上线前一定要用目标用户群体的动作数据重新标定。关节组关键点组合标准角度区间容忍度评分权重肘部弯曲肩-肘-腕30°–60°15°40%肩关节活动髋-肩-肘60°–90°12°30%手腕稳定性肘-腕-手背参考点170°–180°8°20%躯干保持肩-髋-膝165°–180°8°10%把每个关节组的分数按权重加权求和就得到总评分。这里有个容易忽略的点手腕角度在原始关键点里本来就不稳定confidence 也低直接把它的权重设到 20% 会导致总评分频繁抖动。如果遇到这种情况一个可行的调整是先把手腕组并入肘部组做联合判定或者提高它的置信度过滤阈值。具体做法放到避坑章节讲。3. 环境装配到主线运行Windows 下的依赖、启动脚本与推理串联3.1 环境依赖清单与版本选择资源里 _pafprocess.cp36-win_amd64.exp 这个文件名已经把关键信息写明白了cp36 代表 Python 3.6win_amd64 代表 Windows 64 位。这表明资源原本是在 Python 3.6 的环境下编译使用的。最省事的路径就是 Windows 10 64 位 Python 3.6 64 位 TensorFlow 1.x 系版本模型文件 three.h5 和 max.h5 用 tf.keras 的方式加载。如果你手头已经装了 Python 3.8 或 3.10也不用急着卸载但要知道 pafprocess 那个扩展大概率要重新编译这一点第 5 章会详细讲。安装依赖的常见流程如下python -m pip install --upgrade pip pip install numpy1.16.6 opencv-python pip install tensorflow1.14.0 pip install Cython0.29.21先说几个我实际踩过的版本坑。numpy 用 1.16.6 是因为很多旧的 C 扩展是按老 ABI 编译的新版 numpy 在 Windows 下加载时容易报DLL load failed这个报错信息极具迷惑性看起来像缺运行库其实是二进制接口不匹配。Cython 0.29.x 是包含 OpenMP 支持且较稳的系列pafprocess 源码里如果开着 OpenMP 并行就得靠这个版本配套。TensorFlow 1.14.0 在 Python 3.6 下能直接 pip 安装不需要额外配 CUDA 的 h5 加载路径对只想跑通评分链路的人来说是阻力最小的选择。装完后用一个最简单的导入测试验证环境是否通python -c import numpy, tensorflow, cv2; print(ok)如果这一步就报错先不要往下走把 numpy 和 tensorflow 的版本对齐到上面那一组再重新导入。很多人在这个环节翻车原因不是安装命令不对而是环境里已经有一个高版本 numpy 或 opencv 在捣乱。3.2 启动.bat 与模型加载流程资源里带一个启动.batWindows 下批处理脚本的作用很直接把当前目录加入模块搜索路径然后调用主程序。常见的写法是下面这个样子echo off set PYTHONPATH%CD%;%PYTHONPATH% call python main.py --model three.h5 --video 0 pause这段脚本里最重要的一行是set PYTHONPATH%CD%;%PYTHONPATH%。pafprocess 是一个本地编译的扩展模块Python 在 Windows 下默认不会把当前目录当成包搜索路径如果不加这一行运行时 import pafprocess 直接 ModuleNotFoundError。--model three.h5指定用哪个权重文件--video 0表示使用摄像头 0如果你的摄像头接在别的编号上改成 1 或 2 就行。最后的 pause 是防止程序异常退出时窗口一闪而过方便截图看报错。这里提示一下不要直接双击启动.bat 然后盯着黑窗口等结果。更好的方式是在命令行里手动执行python main.py --model three.h5 --video 0这样 stdout 和 stderr 都会留在当前终端里模型加载失败、关键点解析异常这些信息才能完整看到。批处理里的 pause 适合交付给别人用自己调试时它反而会挡住你复制报错信息。模型加载和推理的 Python 侧典型流程是这样的骨架import tensorflow as tf import numpy as np import pafprocess # 常见做法先建图再恢复 h5 权重 def load_model(h5_path): graph tf.Graph() with graph.as_default(): # TensorFlow 1.x 中创建会话并恢复权重 sess tf.Session() # saver.restore 或 tf.keras.models.load_model 视资源代码而定 return graph, sess这段代码是示意真正的主程序里已经封装好了加载逻辑。我要强调的是一个容易犯的错three.h5 和 max.h5 是两个不同文件启动参数里写哪一个决定了加载哪一套权重。有些工程会同时加载两个模型做对比有些则是不同输入分辨率对应不同权重。在动手改代码之前先把启动.bat 里实际用的文件名记下来再去主程序里搜对应的参数解析逻辑否则很容易出现换了模型文件但评分结果一点没变的诡异情况。3.3 主线流程串联从视频帧到评分输出整个评分系统的处理循环可以拆成四步取帧、推理关键点、算角度、打分并叠加显示。为了让目录职责更清晰我用一段带注释的伪代码来描述主线流程import cv2 import numpy as np import pafprocess from angle_utils import compute_angle, score_angle # 资源内的角度工具模块 cap cv2.VideoCapture(0) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) while True: ret, frame cap.read() if not ret: break # 1. 模型前向推理得到热图再交给 pafprocess 解析关键点 heatmaps, pafs model_inference(frame) # 热图形状由模型决定 pafprocess.process(heatmaps, pafs) # C 后处理 keypoints pafprocess.get_keypoints() # (N, 3): x, y, confidence # 2. 按 COCO 索引取点算向量角 elbow_angle compute_angle( keypoints[5][:2], # 左肩 keypoints[7][:2], # 左肘 keypoints[9][:2] # 左腕 ) # 3. 用标准区间打分 elbow_score score_angle(elbow_angle, 30.0, 60.0, tolerance15.0) cv2.putText(frame, felbow: {elbow_score:.1f}, (30, 60), cv2.FONT_HERSHEY_SIMPLEX, 1.0, (0, 255, 0), 2) cv2.imshow(Fitness Score, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()model_inference 是对模型前向推理的抽象实际代码里一般是 session.run。pafprocess.process 接收的热图要转成连续的 float32 数组numpy.i 干的就是这件事所以热图的 dtype 和内存布局不能乱改。关键点返回后按 COCO 索引取点5、7、9 分别是左肩、左肘、左腕右手对应 6、8、10。如果你的摄像头画面是镜像的左右手索引需要互换否则方向判断会反转。这个细节坑过不少人尤其是用笔记本内置摄像头时默认镜像画面会让评分结果左右颠倒。4. 举哑铃动作的评分实现肢体分组、阶段切分与总评组装4.1 哑铃动作的关节分组与阶段切分举哑铃不是单一姿态而是一个动态过程。同一个肘关节角度在举起阶段是正常的在放下阶段可能就说明没有离心控制。所以评分系统不能对每一帧的原始角度直接打分要先判断当前处于哪个动作阶段。哑铃弯举大致切成四个阶段举起、顶峰、放下、静止。举起时肘关节角度变小放下时变大顶峰时角度基本不变静止时腕部和躯干回到初始位置。判断阶段最常见的做法是组合两个信号腕部关键点的纵向位置以及肘角的变化方向。图像坐标系里 y 轴向下腕点 y 值小于肘点 y 值时哑铃在身体上方反之在下方再配合当前帧和上一帧的角度差就能把状态分出来。def detect_phase(wrist_y, elbow_y, prev_angle, current_angle): 根据腕部高度和角度变化方向判断动作阶段。 prev_angle/current_angle 为肘关节角度。 if wrist_y elbow_y: # 哑铃在身体上方 if current_angle prev_angle - 2.0: return lifting return holding else: # 哑铃在身体下方 if current_angle prev_angle 2.0: return lowering return resting这里 2.0 度是一个死区阈值用来过滤角度抖动。如果死区设成 0一帧的微小波动就会让阶段在 holding 和 lifting 之间反复横跳评分帧之间跳变非常难看。死区太大会让阶段切换迟钝动作都开始举起了系统还认为在 holding。用 2 度作为起始值再根据实际帧率微调30 FPS 下 2 度合理15 FPS 下建议放宽到 4 度。阶段切分完之后不同阶段启用不同的评分区间。举起阶段看肘角是否落在 30° 到 60° 的发力区间顶峰阶段看手腕是否过度翻转、躯干有没有后仰放下阶段看肘角变化是否匀速也就是离心控制。这套按阶段切换评分区间的逻辑比拿一套统一角度比对全过程的方案要合理得多。4.2 总评分权重组装与计算每个关节组在每帧都会得到一个 0 到 100 的分值总评分是对这些分值做加权求和。权重的设定依据是目标动作的主发力肌肉哑铃弯举主发力在肘屈肌群肘部权重最高肩关节在动作顶端负责维持权重次之手腕和躯干更多是保护性指标权重低一些。weights { elbow: 0.40, shoulder: 0.30, wrist: 0.20, torso: 0.10, } def total_score(scores: dict) - float: scores: {elbow: 85.0, shoulder: 90.0, wrist: 70.0, torso: 95.0} total 0.0 for key, weight in weights.items(): total scores[key] * weight return round(total, 1)这段代码逻辑很简单但有一个环节需要额外处理某一帧如果某个关节的 confidence 过低它的角度值根本不可信这时候不应该拿一个假数据参与加权。常见做法是先把不可信关节的分数置为 None然后对所有有效分数重新归一化权重而不是直接把缺失项记 0 分。比如手腕置信度不足把其余三项权重按比例放大凑成 100% 再计算总分。否则手腕那一项常年是 0 分总评分会被系统性拉低用户动作再标准也拿不到高分。4.3 实时反馈与置信度过滤实时反馈的界面层不需要太复杂在视频帧上叠加每个关节组的分数和总评分就够了。但反馈的稳定性比界面美观重要得多。常见的问题是某个关键点短暂丢失评分从 90 突然掉到 30画面上闪现一个极低分然后又弹回 90。这种闪烁会让用户觉得系统测不准影响信任。解决思路是给每个评分设置一个置信度门槛。OpenPose 返回的关键点带 confidence 值一般范围在 0 到 1 之间。只有当 confidence 高于某个阈值时这个关节的评分才参与显示和总评低于阈值时保留上一帧的分数或者显示关节丢失的提示。def filter_low_confidence(keypoint, threshold0.5): keypoint: (x, y, confidence) 置信度低于阈值时返回 None表示该关节本帧不可信。 if keypoint[2] threshold: return None return keypoint[:2]阈值 0.5 是从 OpenPose 在室内健身场景下的输出分布来看的正常光照、无遮挡时肩肘腕的置信度普遍在 0.7 以上低于 0.5 的关键点大多是遮挡、运动模糊或肢体出画造成的。阈值设得太高比如 0.8会频繁丢弃关节设得太低比如 0.3又挡不住噪声。先用 0.5再根据实际丢帧率上下调整。5. 避坑与常见问题Windows 编译、模型加载与评分抖动排查5.1 pafprocess 编译失败SWIG 工具链与 MSVC 版本不匹配现象按照网上教程执行python setup.py build_ext --inplace编译 pafprocess 时日志走到一半报错提示找不到某个头文件或者LNK2001 unresolved external symbol最终没有生成 pyd 文件。原因pafprocess 的编译链路是 SWIG 先生成 wrap 代码再用 MSVC 编译。资源里给的是 cp36-win_amd64 的导出符号文件如果你用的 Python 是 3.7 或更高版本MSVC 工具集从 VS2015 换成了 VS2019二进制接口兼容性就断了。另外 numpy.i 的路径也需要让 SWIG 能找到装完 numpy 后它的 include 目录在 site-packages/numpy/core/includeSWIG 命令行里没指到这个路径就会报找不到 numpy.i。解决优先用资源对应的 Python 3.6 64 位环境避免重编译。如果必须在新版本环境跑我把踩坑后的可行步骤列在这里先装 SWIG 4.0 及以上版本确认已安装 Visual Studio 2019 的 C 桌面开发组件在 setup.py 或命令行里显式加上 numpy 的 include 路径。编译通过的标准是当前目录下出现 pafprocess 的 pyd 文件文件名里能看到你的 Python 版本号。5.2 h5 模型加载异常tf.keras 与 TensorFlow 版本兼容性现象运行主程序时模型加载阶段报错常见的有Unknown layer、Unable to load weights或者直接提示No model found in config file。原因three.h5 和 max.h5 这类文件有两种可能一种是纯权重文件里面只存参数不存网络结构另一种是完整的 Keras 模型文件包含结构和权重。如果是纯权重文件你必须有对应的网络结构定义代码才能加载如果用高版本 TensorFlow 直接 load_model 一个老式配置的 h5也会在 layer 名称匹配上翻车。解决先确定 h5 的类型。用h5py打开文件看顶层有哪些 key如果看到model_config或model_weights这是完整模型如果只有一堆层名和权重名就是纯权重。纯权重就用model.load_weights(three.h5)配合已有的网络结构加载。TensorFlow 2.x 环境下建议先做一个最小加载测试用tf.keras.models.load_model尝试失败就退回load_weights路线不要在没确认文件类型之前反复改主程序。5.3 评分抖动剧烈置信度过滤与帧间平滑不足现象肘角评分在 60 到 95 之间无规则跳动没有任何明显动作变化屏幕上分数闪个不停总评分也跟着漂。原因这个现象几乎总是出在置信度处理环节。某个关键点在部分帧里被错误检测坐标位置偏离真实骨骼几像素到十几像素算出来的角度就大幅偏离。另一个常见原因是评分函数没有做时间平滑哪怕只有一帧的角度尖峰也会立刻变成分数尖峰。解决先给角度加滑动平均。惯常做法是维护一个长度为 5 的环形缓冲区每次取 5 帧的平均角度再打分效果比单帧打分稳定很多。如果滑动平均之后仍有小幅抖动就把该关节的置信度阈值从 0.5 提高到 0.6把置信度一般的帧直接丢弃。还有一个我常用的技巧对评分再做一次 EMA 平滑权重取 0.7 到 0.8让分数变化更跟手但不会跳变。ema_score 0.0 alpha 0.75 def smooth_score(raw_score): global ema_score ema_score alpha * ema_score (1 - alpha) * raw_score return ema_scorealpha 越大分数越平滑但反应越迟钝。0.75 在 30 FPS 下大约能让评分在 0.4 秒内跟上动作变化体感刚刚好。如果你做的是慢速动作回放alpha 可以放到 0.8做快速动作识别回到 0.7 更不容易丢失峰值。5.4 摄像头高延迟推理分辨率与输入分辨率互相拖累现象画面显示延迟明显人已经做完动作屏幕上的评分还在半秒前的状态动作连贯性看起来很差。原因两个地方容易拖慢链路。一个是摄像头采集分辨率设得太高比如 1920×1080模型推理每帧要处理的像素翻倍帧率直接掉一半。另一个是主循环里把推理、后处理、评分放在同一个线程串行执行推理耗时一长读帧也跟着卡顿。解决把模型输入分辨率降下来。姿态估计模型通常接受 368×368 或 256×256 的输入不管摄像头采多少喂给模型的图都要先 resize。如果你的摄像头是 720p把采集分辨率固定到 640×480推理输入固定到 368×368帧率通常能翻倍。另外常见做法是给摄像头读取和模型推理各开一个线程读帧线程只做采集推理线程消费最新的一帧评分画面显示推理线程的结果。这样即使某帧推理超时读帧线程也不会阻塞。6. 评分验证与调参技巧用视频回放逐帧核对角度与分数6.1 录制标准动作视频建立回放对照表调参最大的难题是没有标准答案。我实际用下来的方法是先找一位动作标准的受试者按理想动作做三组弯举每组 12 次全程录像然后把这段视频离线喂给评分系统把每一帧的角度、置信度、阶段、分数全部输出到 CSV 文件。回放时对着 CSV 逐帧检查重点看两个地方阶段切分是否与画面一致顶峰阶段是否出现明显低分。这个步骤能把分数不合理这个模糊问题转化为第 37 帧角度 81° 但画面里肘角明显小于 60°这样可定位的问题再回去查是关键点检测错了还是角度计算的多边形顺序错了还是标准区间标定错了。6.2 用批量试参脚本找出最优阈值手动改一个参数重新跑一遍视频很慢。我通常会把评分函数独立出来写一个批量试参脚本把 lower、upper、tolerance 三个参数变成可枚举的候选值一次性跑完整个视频输出每个参数组合下的平均分和方差。平均分反映整体标准性方差反映评分稳定性。理想参数组合应该是标准动作视频平均分在 90 以上方差尽量小做明显错误动作时平均分掉到 70 以下。import itertools candidates list(itertools.product( [30, 35, 40], # lower [55, 60, 65], # upper [10, 12, 15] # tolerance )) for lower, upper, tolerance in candidates: avg_score, std_score evaluate(standard.mp4, lower, upper, tolerance) print(flower{lower}, upper{upper}, tol{tolerance}, favg{avg_score:.1f}, std{std_score:.1f})evaluate 函数内部就是逐帧读取关键点、算角度、调用 score_angle 并累计统计量。这个循环看起来很暴力但实际效果好过凭感觉调参数因为角度阈值之间是相互影响的手调很难同时照顾到三个阶段。6.3 从单帧正确到整套动作稳定的调参顺序调参顺序我总结成一句口诀先对单帧再对序列最后调权重。单帧阶段只挑几帧标准动作的关键帧要求角度计算正确序列阶段用视频回放确认阶段切分和评分不抖动最后才动权重因为权重只影响总评分配比不影响单个关节评分的准确性。如果我跳过前两步直接调权重后面的坑基本都是这个序列问题。从那以后我每次调动作阈值都强制走一遍录标准视频 → 导出 CSV → 批量试参 → 回放核对的流程宁可慢一点也不要凭感觉改一个数字就交付。希望帮到你。本文还有配套的精品资源点击获取
