动作识别2——问题分析
目录
一、前言
二、问题分析
2.1 考虑一个人是侧面站着，脸朝着右边的情况
2.2 遮挡问题很大 and 脚踝速度作为判定条件不太行。
一、前言
在动作识别1中我在最后提到有些问题，即我在test1.mp4里面发现算法是没问题的，但是换了test2.mp4就出现问题了。我先捋一捋动作识别1中是如何识别脚踢动作的，然后我再分析为什么test2.mp4出现了问题。
二、问题分析
2.1 考虑一个人是侧面站着，脸朝着右边的情况
一开始假设腿是站直的，那就是空闲状态（STATE_IDLE）。
设他的右腿的髋关节、膝关节、踝关节三个点分别是A、B、C，计算BA和BC的夹角angle_s。
假设他侧面站着，脸朝着右边且右脚站直的情况下，angle_s在174到177度左右，假设他现在要踢脚了，于是他向前迈开了左脚伸直支撑，然后右脚准备要踢了，于是右脚开始弯曲，假设他弯曲到168度的时候，算法判定1是angle_s小于了170度，然后设人物目标框的中心点是O，算法判定OC跟AB的夹角foot_s是7.4，算法判定2是foot_s是小于45度（用于判断脚方向是否合理），然后结合这两个判定，进入了加载状态（STATE_LOAD）并把min_angle_in_load=angle_s，也就是初始化最小的angle_s，因为这可能是他刚开始弯曲这个腿，后面可能会更弯曲。
进入加载状态之后，首先要更新min_angle_in_load为最小的角度以记录弯曲最深的位置，因为一旦弯曲最深了，可能就标注着这个人他要固定AB这个大腿，也就是固定B点，然后做BC点这个小脚的向前踢的动作（当然实际上B点可能不是完全固定的，可能会向前，但是最终踢完以后三点大概率会接近同一直线上，也就是踢完就接近伸直了腿），我们肯定得关注这个状态的变化。随后算法要计算一下angle_rebound = angle_s - min_angle_in_load，这个就是角度反弹量，用于计算伸直了多少度，比方说一开始右脚在左脚后面伸直的时候，可能是从177度，慢慢弯曲变成157度，这时候最弯曲了，然后又慢慢变大到171或者172左右，也就是一个小腿弯曲蓄力，再伸直小腿踢出去的过程。那么这个伸直小腿踢出去的过程中，角度反弹量其实会逐渐增加，根据调试结果，是从angle_rebound数值是这样变化的：0~0.3~2.5~5.6~8.3~10.2。之后呢，算法还要判断最近一段数据里是否出现了一个“局部峰值”。它用来检测速度曲线是不是在某一帧突然达到一个明显的高点，其实算法在进入LOAD加载状态之前一直都有对每帧计算和记录这个angle和speed，angle_s其实跟angle区别在于angle_s是平滑处理过的（平均值），感觉差不多；speed就是脚踝C的速度，根据调试结果，这个speed站立不动的时候确实只有0到0.1多，然后进入LOAD那一刻上升到了0.74，之后是0.86~1.04~1.29~0.75~1.13~1.33~1.05~1.21~1.35~0.81，0.81那一帧已经进入Kick状态了，可以看到小腿弯曲蓄力过程，这个脚踝速度总体来看确实有有所上升。算法通过has_local_peak判断是否出现局部峰值，也就是判断最近一段数据中的中心点是否比邻域平均值高出一定比例（比如 20%），如果是，就认为出现了局部峰值。那么什么情况下会进入Kick状态呢？ 在算法判定角度反弹量超过了6，并且进入了局部峰值而且速度大于0.6，并且foot_s小于45度（用于判断脚方向是否合理），这三个判定通过了以后就进入STATE_KICK，会立刻初始化peak_speed_in_kick = speed_s。如果angle_s > (TH_ANGLE_LOAD) and not speed_peak_cond，即如果腿已经伸直但没有速度峰值 → 回到 IDLE。
现在进入了STATE_KICK状态，算法首先检查速度是否下降，即判断speed_s < peak_speed_in_kick * 0.7，也就是判断相对峰值是否下降 30% 以上，根据调试结果，从LOAD进入KICK，脚踝速度speed是从1.35下降到0.81，这个下降超出了30%，说明脚踢出去之后停在那里定住了一瞬间，所以速度下降了。之后，算法要检查腿是否接近伸直，即判断angle_s是否大于170度，根据调试结果，踢出去停下来那一瞬间，是170~171度左右。如果两者都满足，就判定一次踢腿动作 (trigger=True)，然后回到 IDLE状态。如果foot_s >= 45 and angle_s < 170，即如果脚方向不合理且角度又弯曲 → 回到 LOAD。
2.2 遮挡问题很大 and 脚踝速度作为判定条件不太行。
我分析了test2.mp4的前面几帧，发现人站直的情况下，角度不是在170~175左右，这应该是因为视频帧有跳帧现象（剪辑过的），因为他这种平滑处理求平均值可能就是会这样，所以说这暗示着算法应对这种跳帧画面的现象是会出现错误的，先不管这个bug。
再看第46帧，根据调试结果，成功进入了KICK状态，但是因为踢完以后腿最后伸直的角度小于170度，没有触发，这是因为视频中的字幕挡住了脚，导致姿态估计的关键点飘逸了，所以说这暗示着算法中这种yolo实时姿态估计模块应对这种遮挡的情况可能要出问题，据说yolo11n-pose会比yolov8n-pose抗遮挡能力强，我试了一下，不知道是不是因为遮挡物是视频文字的原因导致，两个模型的姿态估计都应对不了文字遮挡，先不管这个bug，我记得CV领域用自监督学习的方法对遮挡问题有比较好的解决，但是姿态估计就不是很清楚是怎么应对这个遮挡问题的，是换3D特征提取还是怎么说，还是说有些不是实时的，比较慢的姿态估计算法可能应对遮挡效果比较好？。
本该在第46帧触发的，结果在那个人脚收回来的时候，第75帧触发了。查了一下调试日志，第46帧是那个人脚踢出去的帧，进入了KICK状态，然后从46到73帧一直都因为near_straight是False没有触发，而第75帧变成True了就触发了，这是因为第46帧因为关键点识别飘逸导致原本是腿伸直了的，结果是判定弯曲的，然后腿收回来的时候就发生了先弯曲后伸直。说白了，一旦进入了KICK状态，他就会一直等待你腿伸直的状态然后等到伸直之后触发了才会变回IDLE状态，或者说你的foot_s >= 45 and angle_s < 170就会回到LOAD状态，但就目前我还没有看到foot_s >= 45是什么情况，就调试日志来看看前面foot_s一直都是小于45。这是不是说目前算法对于右脚在前弯曲然后向后摆腿，最后伸直腿这一情况也会判定为脚踢动作？先不管这个bug。
第911帧误触发了，我们分析一下前面发生了什么。首先在第533帧的时候，人蹲了下来直接进入了LOAD，然后在第577帧进入了KICK，此时反弹量是7.25，foot_s是33，说明了蹲下来的时候腿在晃也会进入KICK，居然也有反弹量，也达到了了速度峰值，foot_s也小于45度，但是因为speed_drop:False和near_straight:False的原因，并没有触发，随后在581帧speed_drop:True和near_straight:False，也没有触发，然后在747帧，居然因为foot_s >= 45回到了LOAD状态，这时候min_angle_in_load:54.965，peak_speed_in = None，但是因为rebound没有超过6或者speed_peak=False或者foot_s超过了45，一直是LOAD状态，说明蹲着的状态你的腿回弹也好、加速也好，蹲下状态foot_s很容易超过45，要同时满足三个条件才能从LOAD进入KICK这倒是一定程度上规避了一些误判。但是在767帧居然进入了KICK，这一段有文字，关键点太偏了，foot_s:32.6，没有超过45，这说明蹲下的状态也是可能误触发进入KICK的，但是好在speed_drop=False，near_straight=False又一定程度规避了触发，尤其是蹲下状态腿就不可能伸直，near_straight=False这一点很稳。但是在775帧又从KICK跳到了LOAD，一直保持LOAD到866，跳到了IDLE，其实在840帧开始这个人开始起身了，回弹量居然一直在增加，没想到起身也是回弹，然后到866正好是起身完成，腿伸直，然后因为angle_s > 170 并且speed_peak_cond：False所以从LOAD回到了IDLE，可能因为他这个起身是匀速起身的，所以没有达到速度峰值。然后站立状态腿一直是超过170度的，所以一直是IDLE，但是到了898帧，腿弯曲了，进入了LOAD。说明只要右腿有一点弯曲，即使站立状态下也会进入LOAD状态，甚至站立状态下右腿微微弯曲再伸直都会有一点反弹值，但是没有超过6，并且speed_peak=False就不会误进入KICK状态，但是907帧就进入了KICK，不过speed_drop=False，near_straight=True，所以就没有误触发。但911帧就误触发了，主要是因为在脚站直的情况下速度突然下降了导致speed_drop=True，说明半弯腰再微微弯曲再站直这个算法防不住啊，光看这个脚踝速度上升，速度下降的方法，半蹲再站直也有这个速度啊，第983帧也是半弯腰再微微弯曲腿再起身误触发的。这个bug必须得管了。
1027帧误触发了，这个半弯腰加微微弯曲腿导致进入LOAD这我能理解，但是进入KICK要同时满足三个条件，居然也在1023帧进入了KICK，感觉这次可能是运镜产生的速度，1021到1023帧因向上运镜导致脚踝速度从0.36升到0.67再升到0.83，因向下运镜导致第1024帧速度降到0.77，我靠，运镜这个算法也防不住啊，判定脚踝速度这是大坑，随着一直向下运镜和微微弯曲的腿伸直到170度（尽管还是在半弯腰），直接就从KICK状态触发了（因为速度骤降）。这个bug必须得管了。
1071帧误触也是半弯腰再微微弯曲腿的问题，从弯腰到伸直腰速度上升，伸直腰定住速度下降。
1190帧本应该触发的。在1190帧确实进入了KICK状态，说明回弹量啊、速度峰值啊那三个条件满足了，但是没有进入是因为首先这一帧的人是侧面站着，面朝偏左位置，所以左脚是看得到的，而右脚是刚好只能看到脚，看不到腿，导致姿态轨迹的关键点的A点漂移严重（说明遮挡导致的姿态估计关键点漂移的问题不得不面对！），导致这个人的脚虽然是伸直了，但是angle_s是小于170度的。另一点是1190帧速度是0.86，1191帧速度是0.97，1192帧是1.32m/s，说白了，人家脚刚踢过去又立刻收回来，收回来的时候加速了，并没有我们想象的那样，脚踢出去停留一瞬间有个速度骤降的情况。然后之后居然一直是KICK状态，直到1256帧右脚伸直了就误触发了。
后面基本上都差不多是这些原因误触发。1876帧挺特别的，在左脚往前迈，右脚即将往前迈的时候，先弯曲再伸直就已经误触发了（还没踢）。
总之，问题就是右脚遮挡导致关键点漂移+脚踝速度判定问题，至于人物朝向问题目前还不清楚有无影响，至少对于现在这个算法来说，人物朝向似乎不是关键。