简介这是一份基于OpenCV与Mediapipe的手势识别控制打地鼠游戏完整项目面向学习计算机视觉和人机交互的本科生或开发者可用于课程设计、实验报告或交互方式对比研究。资源共27个文件涵盖6个Python源码、5张效果图片、4个XML配置、4个Markdown说明文档以及Excel原始数据、PDF项目报告、MP4演示视频和UI设计文件压缩包整体约60.1MB目录结构清晰。项目以真实实验为基础六名参与者分别使用有线鼠标、无线鼠标、触摸板和手势识别完成多轮游戏记录得分并制作问卷最终得出交互效果排序同时利用Mediapipe识别8号与12号骨节点状态实现不同手势的光标操作与地鼠打击。已有272人学习下载。除可直接运行的游戏代码带详细注释外还包含原始数据表、数据分析方法说明、实验报告和操作录屏方便复现实验、理解实现细节或在此基础上扩展交互方案。1. 一个打地鼠游戏为什么值得用 OpenCV 手势识别来做做课程设计或者练手 OpenCV 的时候最怕的是“图像处理写了一堆最后只输出了一张处理过的图”既没有交互也没有实时性答辩时没法讲出彩。基于 OpenCV 的手势识别控制的打地鼠游戏刚好把计算机视觉里的肤色检测、轮廓分析、指尖识别和实时控制串在一套完整玩法里是典型的“人机交互”方向项目。它能解决的核心问题是不碰鼠标键盘只靠摄像头里的手部动作——伸手掌点击地鼠、握拳移动光标——就能玩完一局游戏。这个方案适合正在做视觉课设、准备毕设开题或者想把 OpenCV 从“调 API”推进到“做产品原型”的开发者。别小看这几十局游戏它背后涉及的是实时视频流处理、坐标映射、线程同步和误触抑制踩的坑比调几十张静态图多得多。2. 手势识别的三条技术路线为什么先选肤色检测2.1 YCrCb 肤色分割课程设计里最稳的起点做手势识别第一件事是把手从背景里摘出来。常见路线有三条背景差分、深度学习检测、肤色检测。背景差分要求摄像头固定、背景不能变化教室里走来走去就废了深度学习方案比如 MediaPipe 或 YOLO 手势检测效果好但依赖权重文件和环境项目报告里能写的内容会被“调库”占掉大半。我通常会选肤色检测因为它只需要一个摄像头加一段阈值分割代码原理能讲清楚Color 空间的参数还可以做成可调旋钮答辩时当场演示“调阈值让误检消失”比放 PPT 有用得多。肤色检测的经典做法是把 RGB 转成 YCrCb 空间然后对 Cr 和 Cb 做范围过滤。RGB 对光照太敏感同一块皮肤在阴影里和阳光下 RGB 值能差出一个数量级而 YCrCb 把亮度 Y 和色度 Cr/Cb 分开Cr 落在 133 到 173、Cb 落在 77 到 127 的范围时能覆盖大部分亚洲肤色。如果用 HSV 也可以但 H 分量在低饱和度下很不稳定调起来更费劲。import cv2 import numpy as np def skin_mask(frame): # 高斯模糊是给后面的阈值分割降噪核大小取 (5, 5) blurred cv2.GaussianBlur(frame, (5, 5), 0) ycrcb cv2.cvtColor(blurred, cv2.COLOR_BGR2YCrCb) # Cr 范围略放宽到 130Cb 上界收到 125避免把灰色背景吸进来 lower np.array([0, 130, 77], dtypenp.uint8) upper np.array([255, 173, 127], dtypenp.uint8) mask cv2.inRange(ycrcb, lower, upper) # 开运算去掉零星噪点闭运算填平手心里的空洞 kernel cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (7, 7)) mask cv2.morphologyEx(mask, cv2.MORPH_OPEN, kernel, iterations2) mask cv2.morphologyEx(mask, cv2.MORPH_CLOSE, kernel, iterations2) return mask这段代码里GaussianBlur不是玄学它的作用是抑制摄像头噪点对边缘的干扰。inRange用上下界数组做通道过滤比逐像素写循环快两个数量级。形态学的开运算先腐蚀再膨胀能把背景里孤立的小色块清掉闭运算先膨胀再腐蚀能把手背上的纹路和反光空洞补上。两个iterations2是我调试后的折中太大会让手指边缘粘在一起太小则手心始终有个洞。2.2 轮廓与凸包把一团像素变成一只手拿到肤色 mask 之后下一步是把白色区域的外形描述成可计算的几何结构。cv2.findContours是这一步的核心它会返回一组点的集合每个集合代表一个连通域。手和背景偶尔会有相似色所以不能只看第一个轮廓我一般会按面积排序取最大的那个并且在面积小于某个阈值时直接判定“没有手”。轮廓的原始点太碎没法直接数手指所以要做凸包。凸包是包裹住轮廓的最小凸多边形。手心区域因为手指根部的凹陷凸包和轮廓之间会出现一块块空白这些空白就是凸性缺陷convexity defects。手指之间的缝隙和虎口就是缺陷点的来源。数缺陷点就能推出手指数听起来很顺但实际写代码时要处理一个问题缺陷点不仅包括指缝还包括手腕边缘的干扰。def find_hand_info(mask): contours, _ cv2.findContours(mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) if not contours: return None max_contour max(contours, keycv2.contourArea) area cv2.contourArea(max_contour) if area 8000: return None hull cv2.convexHull(max_contour, returnPointsFalse) defects cv2.convexityDefects(max_contour, hull) hand_info {contour: max_contour, defects: defects} return hand_infoRETR_EXTERNAL只取最外层轮廓避免手心的空洞生成一堆内轮廓。cv2.convexityDefects的输入必须是凸包的索引形式所以convexHull要传returnPointsFalse这是新手最容易翻车的地方——如果传默认的 True下一步直接报错。面积阈值 8000 是我在 640x480 摄像头上调出来的分辨率不同要按比例缩放。这里还有一个容易被忽略的点findContours在 OpenCV 4.x 返回两个值在 OpenCV 3 返回三个值代码写contours, _ 的话换版本就会崩这个我放到避坑章节细说。2.3 指尖计数与手势判定用角度识别“掌”还是“拳”数手指不能只看缺陷点个数因为算出来的缺陷可能包含手肘、手腕等非手指凹陷。更稳的做法是用多边形的逼近点配合角度判断。把最大轮廓用cv2.approxPolyDP压缩成一条折线然后遍历折线上每个顶点计算它和前后相邻点之间的夹角。手指指尖的特征是角度尖锐通常小于 60 度而且指尖到手掌重心的距离远大于普通轮廓点。我用“伸出指尖数”区分两种基本手势五个指尖都出现判定为“掌”对应打地鼠的点击动作没有明显指尖判定为“拳”对应移动光标。这样设计是为了减少误触——如果伸一根手指就算点击操作时手一晃就疯狂锤地鼠。def count_fingertips(contour, defectsNone): # 这句 collect 是新版本 OpenCV 必须的不要去掉 collect list(contour[:, 0, :]) # 实际项目里这里会结合凸包缺陷的深度做过滤 # 简单版本用多边形逼近 角度 epsilon 0.02 * cv2.arcLength(contour, True) approx cv2.approxPolyDP(contour, epsilon, True) fingertips 0 for i in range(len(approx)): p0 approx[i - 1][0] p1 approx[i][0] p2 approx[(i 1) % len(approx)][0] # 向量夹角计算 v1 p0 - p1 v2 p2 - p1 cos_angle (v1[0] * v2[0] v1[1] * v2[1]) / ( np.linalg.norm(v1) * np.linalg.norm(v2) 1e-6 ) angle np.degrees(np.arccos(np.clip(cos_angle, -1, 1))) if angle 60: fingertips 1 return fingertips角度小于 60 度的阈值是我反复试出来的低于 40 度会把手指尖漏掉高于 80 度会把关节折痕也算进来。epsilon取轮廓周长的 2%折线点数会从几百个压缩到十几个否则算角度时每个像素点都可能是极值。注意p1是当前顶点的坐标p0是前一个p2是后一个角度的顶点是p1。我最初写成p0当顶点结果所有手指都识别不出来因为方向向量反了锐角变成了钝角。3. 游戏怎么接到手势上从摄像头坐标到地鼠坐标3.1 Pygame 游戏窗口与识别线程的共用内存手势识别算出来的是摄像头画面里的坐标和手势类型游戏逻辑要的是窗口坐标和点击事件。如果识别和游戏放在同一个循环里摄像头每帧要处理几十毫秒游戏帧率会被拖到肉眼可见的卡顿。常见做法是拆两个线程一个线程跑 OpenCV 识别把结果写进共享变量主线程跑 Pygame 游戏循环每帧从共享变量读最新值。Python 的多线程受 GIL 限制但 OpenCV 的cvtColor、inRange这些计算密集操作会释放 GIL实际跑下来识别线程和游戏线程能并行。共享变量不能用一个普通 Python 对象裸写因为多个线程同时读写会出现撕裂——读到的坐标可能是旧帧的一半。我用threading.Lock保护一组变量或者用一个队列只放最新一帧的结果。队列做覆盖写更优雅但锁的代码更直观适合写进课程设计报告里解释。import threading import time class HandState: def __init__(self): self.lock threading.Lock() self.x 0.0 # 0~1 的相对坐标 self.y 0.0 self.is_click False self.stamp time.time() def update(self, x, y, is_click): with self.lock: self.x x self.y y self.is_click is_click self.stamp time.time() def read(self): with self.lock: return self.x, self.y, self.is_click, self.stampHandState把坐标存成 0 到 1 的浮点数而不是绝对像素值。好处是摄像头分辨率从 640x480 换成 1280x720游戏侧一行代码都不用改。stamp字段很重要它记录识别结果的时间戳游戏侧可以判断数据是否过期如果手势超过 0.3 秒没更新说明手已经离开画面这时应该触发“暂停”而不是继续用旧坐标乱打。3.2 坐标映射与“空气鼠标”的实现从摄像头画面到游戏窗口的坐标映射不是简单的等比缩放。首先摄像头看到的画面是镜像的也就是你往左挥手图像里的手往右移动。如果不做镜像反转光标方向会反游戏根本没法玩。其次手在画面中心区域移动的灵敏度比边缘高直接把 0~1 坐标映射到窗口像素会让人感觉光标飘。def map_coordinates(cam_x, cam_y, width, height): # 先镜像反转否则左右方向是反的 mirrored_x 1.0 - cam_x # 做一点中心死区压缩让手在画面中心时移动更细腻 dx mirrored_x - 0.5 dy cam_y - 0.5 # 指数衰减让边缘移动幅度更大中心更稳 mapped_x 0.5 dx * 1.2 mapped_y 0.5 dy * 1.2 # 映射到窗口像素 px int(mapped_x * width) py int(mapped_y * height) return px, pydx * 1.2是灵敏度系数大于 1 会让手小幅移动时光标大幅移动适合打地鼠这种需要快速定位的场景如果做绘画类应用这个系数要降到 0.8 以下。mirrored_x 1.0 - cam_x这步很容易漏漏掉后所有左右操作都是反的。mapped_y不用镜像因为上下方向在摄像头里和直觉一致。像素坐标超出窗口范围时Pygame 不会报错但地鼠点击会失灵我习惯在外面套一层max(0, min(...))做边界钳制。3.3 点击事件的防抖与锁定手势点击判定天然存在抖动伸掌动作从“收拢”到“张开”的过程中手指尖计数会在 3 到 5 之间跳变。如果识别结果一变成“掌”就触发点击一次动作可能触发两三次。游戏表现就是地鼠刚冒头就被锤掉看起来像开了连点器。解决办法是加一个状态锁只有从“拳”变“掌”的上升沿才触发点击且点击后 200 毫秒内不再接受新的点击信号。class ClickDebounce: def __init__(self, cooldown0.2): self.last_click_time 0.0 self.last_was_click False self.cooldown cooldown def update(self, is_click, now): # 只在非点击-点击的边沿触发 if is_click and not self.last_was_click: if now - self.last_click_time self.cooldown: self.last_click_time now self.last_was_click True return True if not is_click: self.last_was_click False return Falsecooldown0.2不是乱定的。打地鼠游戏里地鼠从出现到消失的时间通常设置成 600 到 900 毫秒200 毫秒冷却能保证每次挥掌最多打一次又不至于让玩家觉得反应迟钝。状态锁的思想在硬件按键防抖里很常见移植到手势交互里也一样好用。但要注意last_was_click必须在非点击状态时立刻复位否则下一次握拳再伸掌会被当成“保持点击”导致误触。4. 跑通识别链路前先定好这 3 个关键参数4.1 肤色阈值的初始值和自适应更新肤色检测对阈值极其敏感这也是项目“数据”目录里通常放着大量测试帧的原因。我拿到一个项目包第一步不是跑游戏而是先把data里标注好的测试帧扔进skin_mask统计每张图的 mask 面积面积突然增大或缩小的那张往往是阈值失效的开始。Cr 和 Cb 的阈值在早上九点的教室、晚上十点的宿舍、白炽灯和日光灯下最优值能差出 20 个灰度级。自适应更新的一个稳定做法是每一帧计算 mask 覆盖区域的 Cr/Cb 均值然后让阈值中心缓慢朝着这个均值移动。注意只能缓慢移动移动速度过快会导致“追尾巴”——背景一旦有暖色物体进入阈值被带偏后整个画面都变成肤色。参数初始值调整步长说明Cr 下限130±1 / 帧调太低会吸入橙色背景Cr 上限173±1 / 帧调太高会丢掉暗部皮肤Cb 下限77±0.5 / 帧对黄色光源敏感步长要小Cb 上限127±0.5 / 帧过曝时 Cb 会异常升高这个表是我在三种灯光环境下都调过之后留下的经验值。自适应更新不是必须做的很多比赛项目里直接把阈值写死也能跑但写死的代价是每次换场地都要手工调一次。建议把三组阈值存成配置文件运行时按环境切换。4.2 形态学核大小和帧率的关系形态学操作的核越大噪点清理效果越好但运算量也越大而且会吃掉手指缝。同样是 3x3 和 15x15 的核在 640x480 分辨率下单帧处理时间能从 8 毫秒涨到 35 毫秒。游戏要保持在 30 FPS 以上留给图像处理的预算不能超过 25 毫秒。我一般把核控制在 5x5 到 9x9 之间并且只在最开始的 2 次迭代用大核之后的迭代用小核精细修边。def build_kernel(side): return cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (side, side)) # 大核先清噪点小核再保细节 kernel_big build_kernel(9) kernel_small build_kernel(3) mask cv2.morphologyEx(mask, cv2.MORPH_OPEN, kernel_big, iterations1) mask cv2.morphologyEx(mask, cv2.MORPH_CLOSE, kernel_small, iterations2)这里的迭代次数和核大小是联动关系大核 1 次开运算的效果约等于小核 3 次但耗时少一半。闭运算的迭代次数不要超过 2否则手指之间的缝隙会被彻底填平五根手指粘成一块后面数指尖就数不出来了。如果发现识别速度只有十几帧优先砍的不是分辨率而是形态学迭代次数。4.3 指尖角度阈值多指粘连的根源指尖角度阈值是另一个和摄像头分辨率强相关的参数。在 320x240 的低分辨率下手指尖大概只有 5 个像素宽approxPolyDP压缩后会丢失尖锐特征60 度的阈值会漏掉大部分指尖。反之在 1280x720 下手指关节的折痕会被误判成指尖。我在写代码时会把角度阈值暴露成运行时可调参数摄像头靠近或远离人脸效果完全不同。判断一个指尖是不是真指尖还有一个辅助条件看这个点到轮廓质心的距离是否大于平均半径的 1.5 倍。手指尖一定是离质心最远的点之一而关节折痕离质心近。这个条件加上角度阈值双保险能显著降低误判。我见过不少把convexityDefects里的start点全部当作指尖的写法那会把虎口和大拇指根部也数成手指最终手势识别准确率惨不忍睹。5. 避坑把项目跑起来之前这 5 条先存着5.1 人脸比手更容易被识别成“手”现象游戏启动后光标一直漂在屏幕左上角切换手势没反应打开识别预览窗口发现一大片皮肤区域把手包围了。原因肤色检测不区分人脸和手摄像头正对着脸时脸的轮廓面积比手大max(contours, keyarea)必然选中人脸。解决预览窗口画出检测框让用户把脸移出画面更稳的做法是把手部区域限定在画面下半部——游戏时手自然放在摄像头前方偏下脸的默认位置在上半部做一个 ROI 截取。5.2 摄像头画面是镜像的光标方向永远反着现象玩家向左挥手游戏光标向右跑怎么调灵敏度都没用。原因摄像头默认输出的是镜像画面相当于你站在镜子前挥右手图像里挥的是左手。解决cv2.flip(frame, 1)做水平翻转。注意这个翻转必须在坐标映射之前做翻转之后再提取的轮廓和坐标才是正确的。如果你在坐标映射里用1.0 - cam_x来翻转那cv2.flip就不要再做一次否则方向又反了这俩只能选一个。5.3 OpenCV 版本差异导致 convexityDefects 直接崩掉现象cv2.findContours返回数量不符或者cv2.convexityDefects报参数类型错误。原因OpenCV 4.x 的findContours只返回contours, hierarchy两个值旧代码解包成 3 个会报ValueError而convexHull的索引模式在 NumPy 新版本下会有 silent 的类型变化。解决写代码时无条件做版本兼容判断contours cv2.findContours(...)[0] if cv2.__version__.startswith(4) else ...。实测 OpenCV 4.4 以上convexityDefects的返回结果里defect[0][3]是深度值的相反数有时取绝对值后依然有 1 像素的偏移过滤的时候要留余量。5.4 Pygame 主线程被识别循环卡死游戏假死现象启动后窗口能打开但画面像幻灯片甚至几秒后弹“无响应”。原因有人把VideoCapture.read()和skin_mask写进了游戏主循环一帧图像处理耗时 100 多毫秒Pygame 的事件队列没人处理系统就判定程序假死。解决严格按第 3 章的思路拆线程read()和skin_mask跑在识别线程主线程只读HandState里的最新值。识别线程里每帧之间可以sleep(0.01)让出 CPU不要 100% 占满一个核。5.5 光线一变肤色阈值就集体失效现象白天窗口前玩得好好的晚上开台灯后整个 mask 变成一个大黑洞或者像马赛克一样闪烁。原因YCrCb 空间虽然分离了亮度但色度分量在极端光照下依然会漂移。LED 灯光谱偏窄会让 Cb 值集体上移。解决不要只用一组固定阈值采用 4.1 节说的均值反馈做自适应或者在项目里保存三组预设阈值自然光、白炽灯、日光灯界面里加一个下拉框手动切换。验收时大概率会有评委问“换个地方还能用吗”能当场切预设并解释原理就能把这个坑变成加分项。6. 进阶用一段回放代码把你的识别准确率“量”出来数值验证是最容易被忽略的环节。很多项目跑起来“看起来还行”但问准确率多少没人答得上来。我的习惯是写一个独立的小脚本用项目data目录里带人工标签的帧图片跑一遍识别流程输出命中率。这个脚本不进游戏主循环纯粹在离线状态跑输出的数就能写进项目报告里。import os import cv2 # 标签文件格式文件名, 期望手势(1掌, 0拳)一行一个 labels {} with open(data/labels.txt, r, encodingutf-8) as f: for line in f: parts line.strip().split(,) if len(parts) 2: labels[parts[0]] int(parts[1]) correct 0 total 0 for name, expected in labels.items(): frame cv2.imread(os.path.join(data, name)) if frame is None: continue mask skin_mask(frame) info find_hand_info(mask) if info is None: actual 0 else: tips count_fingertips(info[contour], info[defects]) actual 1 if tips 5 else 0 if actual expected: correct 1 total 1 print(f准确率: {correct / max(total, 1) * 100:.1f}%)运行环境是离线回放不存在实时性压力正好用来调阈值。我的做法是把这个脚本跑一遍把判错的帧单独复制到data/fail/目录然后一张张看是skin_mask错了还是count_fingertips错了改完再跑直到准确率过 90%。这个“跑一遍—看错例—调参—再跑”的循环比在游戏里盲调快得多。有了这个量化数字项目报告里“系统识别准确率达到 XX%”这句才有底气。如果还想让阈值自适应能力再前进一步可以试用 HSV 空间的直方图反向投影开局第一帧让用户把手伸到画面中央程序记录这一小块区域的色调直方图之后每帧用cv2.calcBackProject找手。这个方案对光线变化更鲁棒但初始化失败时整个系统直接不可用所以我只在答辩演示时才开。日常开发还是 YCrCb 加自适应靠谱。最后说个教训我做这个项目时第一次把“伸掌点击”实现完玩了十分钟发现手腕很酸因为只要手张开着就得一直保持姿势。后来我想明白一个道理——手势交互不只是识别对错问题还是人机工程问题。把点击改成“握拳后张开”的上升沿触发让玩家在等待时手能放松游戏体感立刻好了一个档次。希望这点经验帮你在调通代码之后还能想到去调交互细节。本文还有配套的精品资源点击获取