简介：一套基于FPGA的手势识别项目资料，以Verilog语言实现了静态手势、动态手势及轨迹跟踪三种识别模式，面向电子工程、嵌入式系统及计算机视觉方向的开发者，提供从算法到硬件实现的完整参考。压缩包共523个文件，容量22.12MB，主要包含Verilog源码（.v）、FPGA工程与仿真文件（.ngc/.ncd/.bit）、开发脚本（.tcl/.do）及说明文档（.pdf/.txt）等类型，覆盖设计输入、综合、布局布线到比特流生成的完整工程链。配套说明文档系统梳理了整体架构、各关键模块的代码逻辑、FPGA配置与调试流程，并附有使用指南和扩展优化方向，便于独立上手与二次开发。资源为原创且经实际验证的实战案例，目前已有4223人学习下载，对理解FPGA图像处理、手势识别算法落地及人机交互应用有较高参考价值。 我知道很多人一听到“手势识别”这四个字，第一反应就是得准备几千张数据集、租一块显卡、训练几个通宵。我自己最开始也是这么干的，后来被数据标注折磨到怀疑人生才想明白一件事：对想做落地项目的人来说，识别手势最省力、最稳定、改起来最方便的路线，其实是“预训练关键点检测 + 自研几何判定”。
这套源代码就是沿着这条路线完整走通的实现，纯CPU推理，不依赖GPU，普通笔记本、树莓派都能跑。从视频流读取、手部关键点提取，到手势判定、动作输出，全部整理成了可读性很好的工程代码，还配了一份说明文档，把阈值怎么标定、参数怎么调、识别乱跳怎么排查这些核心问题都写清楚了。你可以直接拿它做PPT翻页、智能家居手势开关，也可以把它当成体感交互项目的起点。
下面我把这套项目从设计思路、判定原理，到代码实现和调参经验，一次讲明白。
1. 为什么放弃“端到端深度学习”，转投关键点+自研判定
1.1 端到端方案看着美，落地全是坑
先说说大多数人的第一直觉：把手势识别当成图像分类问题，训练一个CNN或者更重的网络，输入摄像头画面，直接输出“数字几”“是不是比心”。
这条路理论上没问题，但落地的时候麻烦事一个接一个。数据采集成本就是个无底洞，一个手势想做到在不同人、不同手型、不同光照下都稳定，至少要几千张标注图，5个手势就是上万张，靠人工录素材能把人录到崩溃。其次是模型部署，训练一般要GPU，推理放到嵌入式设备上还有量化、剪枝一堆事，普通开发者很难一次搞定。最要命的是扩展性：今天想加一个“转手腕”的手势，意味着一整套数据集要重新采集、重新训练，迭代成本非常高。
我自己第一版项目就是这种方案，结果在“数据标注”这一步就卡了两周，最后识别率还只有百分之七八十，就果断推倒重来了。
1.2 关键点检测+自研判定这条路好在哪
后来我换了个思路：硬件环境里最难的那部分——从图像中找到手在哪里、手掌朝哪个方向、手指关节位置在哪——让MediaPipe Hands这类成熟的预训练模型去做，它输出的是21个手部关键点的坐标序列。我要做的，是在这21个点的基础上，自己设计一套几何判定规则，用它去区分不同的手势。
这样做的好处非常明显。首先，关键点检测模型是别人训练好的，开箱即用，我不需要碰数据集；其次，手势判定层的逻辑是纯几何计算，不涉及模型推理，复杂度低、速度快、可解释性极强，一个手势判错了我能直接看到是哪个阈值没卡住，改个数字就行；最后，加新手势的成本极低，最多写一个判定函数，跑一遍标定流程即可，别提有多爽了。
1.3 三个技术路线的横向对比
这里直接给一张当时我做的方案对比表，方便你选型参考：
| 方案 | 数据集依赖 | CPU实时性 | 自定义手势成本 | 可解释性 |
|---|---|---|---|---|
| 端到端CNN分类 | 高，需大量标注 | 一般 | 高，需重新训练 | 低，黑盒 |
| 传统肤色分割+凸包缺陷 | 无 | 好 | 中，需重设规则 | 中，易受光照干扰 |
| 关键点检测+几何判定 | 无 | 好 | 低，加判定函数即可 | 高，阈值规则可检查 |
结论很直接：第三条路是个人项目做手势识别性价比最高的方案。本项目的源代码和说明文档，也都围绕这条路线展开。
2. 项目核心：21个关键点如何变成一套能听懂话的手势
2.1 MediaPipe到底给了我们什么
MediaPipe Hands检测到的手部会输出21个关键点，编号从0到20。0号是手腕（Wrist），1到4号是拇指从根部到指尖，5到8号是食指各关节，9到12号是中指，13到16号是无名指，17到20号是小指。
每个关键点有两个坐标，x和y，范围在0到1之间，是相对于图像宽高的归一化坐标。也就是说，不管你的摄像头是640x480还是1280x720，关键点的数值范围是一样大的。这是好事，但我建议代码内部一律用这份归一化坐标做判定，不要轻易转成像素坐标，因为一旦换摄像头分辨率，你的阈值就全废了，而相对坐标可以保持阈值不随分辨率漂移。
2.2 我设计的三种几何特征
手势判定的核心，是把21个点翻译成语义明确的特征。我最终打磨出来三个特征，覆盖了绝大多数手势识别场景。
第一个是距离比例，用来判断某一根手指是“伸直”还是“弯曲”。以食指为例，计算食指尖（8号点）到手腕（0号点）的距离，再除以食指根部关节（5号点）到手腕的距离，得到一个比值。手伸直时这个比值大，弯曲时比值小，因为远端关节拉近了和手腕的距离。用比例而不是绝对距离，是让判定对手的大小、手离摄像头远近都不敏感的关键。
第二个是向量夹角，用来判断手指弯曲的“方向”和“程度”。把指根（MCP）、中间关节（PIP）、指尖串成两条向量，算它们之间的夹角。手指伸直时，两条向量方向趋近一致，夹角接接近180度附近的大角度；弯曲时夹角显著变小。距离比例对大角度弯曲敏感，向量夹角对小角度差异敏感，两个结合使用后误判率会明显下降。
第三个是点间距，用来判断“捏合类”手势。比如比心时拇指尖与食指尖的距离极小，而OK手型中拇指和食指围成一个小圆环。用指尖欧氏距离除以一个基准长度（我常用中指根部到手腕的距离）做归一化，就能稳定判断捏合类动作。
2.3 典型手势的判定条件和阈值
这套项目里我先内置了6个基础手势，实用度很高，覆盖了多数控制场景：
| 手势 | 核心判定条件 | 备注 |
|---|---|---|
| 数字1 | 食指伸直，其余四指弯曲 | 依靠食指距离比+夹角双重确认 |
| 数字2 | 食指、中指伸直，其余弯曲 | 需要额外检查中指与食指分离度 |
| 数字3/4/5 | 对应数量手指伸直 | 无名指易粘连，阈值适当放宽 |
| 握拳 | 所有手指的伸直度均低于阈值 | 可做触发/开关信号 |
| 张开掌 | 所有手指伸直度均高于阈值 | 常作为“取消/停止”指令 |
| 比心 | 拇指指尖与食指指尖靠近，其余三指弯曲 | 需要加上中、无名、小指弯曲约束，否则极易误判 |
| OK | 拇指与食指成环，其余三指自然伸展 | 增加环内面积/点间距双重判断 |
| 上滑/下滑/左滑/右滑 | 手掌重心点在时间窗口内的位移方向 | 依赖历史轨迹队列，后面详述 |
这些阈值在代码里全部提取到了开头的常量区，不散落在判定逻辑中。具体的数值没法一次性给你写死，因为不同人手型差异很大，但我在文档里给了一套标定方法，后面第4节会专门讲。
3. 代码实现拆解：主循环、滤波去抖与状态机
3.1 主流程与帧处理顺序
整个项目的代码结构非常简单清晰，核心主循环的思路大概是：
while cap.isOpened(): ret, frame = cap.read() # 手势关键点检测 results = hands.process(cv2.cvtColor(frame, cv2.COLOR_BGR2RGB)) if results.multi_hand_landmarks: pts = get_normalized_landmarks(results, hand_index=0) # 几何特征计算 features = compute_hand_features(pts) # 手势判定（返回手势ID和置信度） gesture = classify_gesture(features) # 状态机去抖与触发输出 output = state_machine.update(gesture) # 可视化叠加关键点与结果 draw_landmarks(frame, pts, gesture) cv2.imshow('Gesture', frame)很多初学者容易忽略的一个细节是：MediaPipe的手部检测是最好建立在multi_hand_landmarks这个返回值上的，因为可能同时检测到多只手。如果你只想对一只主手做控制，建议取画面里“置信度最高”的那只手，而不一定取列表里第一只。本项目里我默认取第一个，但文档里明确写了如何改成取可信度最高的一只。
3.2 为什么一定要加平滑滤波
不滤波的手势识别，跑起来会让你怀疑人生。因为MediaPipe的关键点在单帧上会有少量抖动，尤其是快速移动时，手没动但关键点却在几毫米范围内跳。这种抖动反映到手势判定上，就是数字1和数字2之间疯狂横跳，或者比心手势时好时坏。
我的做法是对关键点坐标做一阶低通滤波：
x_smoothed = alpha * x_raw + (1 - alpha) * x_smoothed_prevalpha取0.3到0.5之间比较合适。alpha越大，跟随越快但抖动也越明显；alpha越小越平滑，但手的移动会产生可感知的延迟感。我实测下来，用0.35对大多数场景都是个不错的折中。
不过要特别提醒一句：滤波只应该作用于送入判定模块的关键点，画在画面上的叠加层建议用原始关键点，否则你会觉得线总比手慢半拍，体验很奇怪。
3.3 状态机去抖：连续帧判定与冷静期
滤波能解决一部分抖动，但解决不了一个更隐蔽的问题：瞬间误判。比如数字1快速变成数字2再变回1，这个过程可能只持续两三帧，视觉上肉眼根本没法察觉。如果你直接把每一帧的手势结果当作最终指令输出，那控制端就会收到一串乱七八糟的中间状态。
所以我在代码里加了一个轻量状态机。它的规则很简单：一个手势必须连续出现N帧（通常取3到5帧）才被确认为正式结果；确认之后，进入一个冷静期（Cooldown，一般300到500毫秒），冷静期内不再接受新的触发，避免同一个动作被重复输出多次。
这套机制对“握拳一次触发开关”这类交互尤其重要。没有冷静期的时候，握一次拳可能被输出成5次开关切换，加了冷静期之后，触发次数的稳定性直接翻倍。文档里我专门用一张流程图把状态转换关系画了出来，实现就是几十行代码，任何人拿到源码都能很快看懂。
4. 源代码自带的说明文档里，写了什么
4.1 环境搭建与版本坑
说明文档里我花了整整一章讲环境搭建，这部分很多人觉得不疼不痒，但实际踩坑的人非常多。
项目依赖非常少：Python 3.8以上、OpenCV、MediaPipe、NumPy。其中最容易出问题的是MediaPipe的版本。0.10.x系列和更老版本在API上存在一些变化，最典型的是mp.solutions.hands.Hands的初始化参数在不同版本里默认值不同，我建议锁定使用0.10.x版本，并且文档里直接写了对应的安装命令。另外我自己实测过，树莓派4B上运行的MediaPipe版本需要单独挑兼容版本，直接用pip最新版经常安装失败，这个坑在文档的FAQ里特别标注了。
4.2 阈值从哪来：我的标定方法
说明文档里价值最高的部分，应该就是这套阈值标定方法。我没有直接给一套固定阈值让用户拿去跑，因为不同人手型差异会导致同样的阈值在别人手上完全失灵。
标定方法其实不难。让被测者把手掌张开对着摄像头，连续记录食指、中指、无名指、小指伸直状态下的距离比，取最小值作为“伸直下限”；然后让被测者握拳，记录同一组手指弯曲状态下的距离比，取最大值作为“弯曲上限”。阈值就取这两者的中间值。一个人标完大概十分钟，之后所有的手势判定都能做到个人级的高准确率。
这套标定数据我在代码里设计成JSON配置文件，用户只需要跑一个校准脚本就能自动生成自己的配置，不用改任何代码。从工程角度讲，这个设计比直接在代码里硬编码阈值要合理得多，也方便后续在不同设备间迁移。
4.3 说明文档的FAQ部分帮你少踩哪些坑
文档最后一部分是FAQ，我把自己开发过程中遇到的高频问题都写了进去。
比如“为什么我把手横过来就识别失败”“为什么戴戒指或者手链会识别不准”“为什么数字3经常被识别成2”“为什么用前置摄像头会出现左右手镜像问题”等等。每个问题都附了排查路径，而不是只给结论。比如数字3识别成2的问题，根源在于无名指和小指在很多人手上无法独立伸直，两者间距很小，判定时如果把“分离度”这个阈值设得太死，无名指就会被当成弯曲。解决办法是在判定数量时增加“趋势约束”，只要指尖离手腕的距离都超过上限，就算两根手指挨得再近，也应该视为同时伸直。
5. 从“数字1/2疯狂横跳”到稳定输出：一次完整排查链路
5.1 问题表象
开发中段的一个晚上，我遇到了一个让我头疼了整整两天的Bug：手明明只比了一个“1”，画面里的识别结果却在“1”和“2”之间来回跳。那种感觉就像系统根本不知道你自己是谁，我甚至一度怀疑是MediaPipe模型在特定光照下退化。后来静下心来看日志，才意识到问题不在检测端，而在我的判定层。
5.2 排查一：阈值特征冲突
我先把每帧的关键距离比、夹角数值全部打印出来，一条条比对。结果发现，食指伸直状态的距离比是1.4，中指弯曲状态的距离比是0.93，正常情况下两者相差很大，不该误判。但我的判定逻辑里，数字2的检测是“食指伸直且中指伸直”——只要中指的距离比偶尔超过阈值0.9，就会被误判成2。
症结清楚了：我把中指的判定阈值设得太低了。中指在弯曲时如果稍微自然蜷曲，距离比很容易轻微跨过0.9。把阈值提升到1.0之后，横跳频率立刻下降了大半。这说明阈值不能只取理论值，要用实际采集数据去卡分布边界。
5.3 排查二：平滑参数引入的“新延迟”
阈值修正后问题缓解了，但还没根除。观察日志时我发现另一种情况：当手从数字2缓慢变成数字1的过程中，旧状态的残影会持续好几帧。原因是alpha=0.5的滤波对快速变化响应太慢，导致新状态还没跟上，旧的“2”就多输出了几帧。
改良方案是采用“分档滤波”：手指在快速移动时，我用较大的alpha跟随（比如0.7），手势进入稳定状态后再降到0.3。判断标准就是连续两帧的坐标差异是否小于某个值。这种方法在“响应速度”和“平滑度”之间取得了更好的平衡，比单纯调一个固定alpha要实用得多。
5.4 排查三：环境和摄像头
做到这里横跳基本消失了，但我换到另一个房间测试时，问题又回来了。这次的问题源于摄像头取景：房间光线偏暖偏暗，MediaPipe的手部检测置信度明显下降，偶尔出现关键点位置抖动。我加了图像预处理，转成BGR后再做一次简单的白平衡，检测稳定性好了很多。
还有一个容易忽视的问题：侧光会造成手部阴影，导致手边缘和背景边界模糊。我测试时尽量正对光源，避免手部完全背光。摄像头尽量固定高度，避免俯仰角过大，因为角度太斜时关键点投影会发生形变，边界情况也容易误判。
5.5 最终修复方案汇总
经过这三层排查，我最终把问题收敛成了五处修改：判定阈值改用数据标定而不是拍脑袋；增加角度约束和指尖分离度双重条件；滤波改成动态分档平滑；状态机增加冷静期；预处理环节加白平衡选项。这一套组合拳打下来，识别从“时灵时不灵”变成了“稳定用手势控制PPT半小时不出错”，项目才算真正达到可交付状态。
这个排查过程我没有省略，就是想强调一件事：手势识别系统的绝大多数Bug不在模型，而在你对关键点数据的使用方式上。日志、分步验证、对照实验，是排错三板斧，缺一个都会事倍功半。
6. 性能实测与后续还能怎么玩
6.1 CPU占用与FPS
最后说说性能。这套方案最大的优势就是轻量。我分别在两种环境下做了实测：
| 运行环境 | 分辨率 | 平均FPS | CPU占用 |
|---|---|---|---|
| 笔记本 i5-1135G7 | 640x480 | 30 | 约45% |
| 笔记本 i5-1135G7 | 1280x720 | 25 | 约60% |
| 树莓派4B | 640x480 | 15 | 约70% |
核心的MediaPipe关键点检测，在普通CPU上单帧大约3-10毫秒；我自己写的几何判定层，单帧耗时在1毫秒以内，几乎可以忽略不计。所以整体性能瓶颈完全在摄像头输入和模型推理，不在判定逻辑，这也是这个架构适合很多低算力设备的原因。
6.2 扩展方向
把基础手势跑通之后，后续可以做很多有意思的事情。比如我这版项目只支持静态手势，如果你想要“挥手”“画圈”这类动态手势，只需要在手势判定层增加“历史轨迹队列”，记录过去N帧的手掌重心点，然后用位移方向做判定，代码改动量不大。再比如手势指令和串口联动，可以把判定的结果直接映射成串口命令，控制舵机、小车或者智能家居开关，这套代码里的输出接口我是按模块化设计的，替换成串口逻辑非常方便。
另外如果你想做夜间环境下的手势控制，可以用支持红外补光的摄像头。普通可见光摄像头在黑暗环境下MediaPipe的检测置信度会骤降，但红外摄像头拿到的是灰度图，关键点检测依然能正常工作。我在文档里也附了灰度输入的适配方式。
我自己在调这个项目的最后几天有个很深的体会：手势识别这个方向的落地，关键不在模型跑得多花哨，而在你对手势语义的抽象能力和工程细节的把控。一套清晰的关键点特征设计，加一份能够稳定复现的判定流程，往往比堆一堆高深算法更管用。这套源代码和文档就是顺着这个理念整理的，你拿到手之后，建议先跑一遍标定脚本生成自己的阈值配置，然后对照着文档把判定逻辑改到你需要的方向上去，遇到具体问题也可以随时回头翻FAQ——里面每个问题都是我真实踩过的坑，照着排查能省不少时间。
本文还有配套的精品资源，点击获取
