简介这是一份基于手势识别的人机交互系统完整源码适用于计算机相关专业课程设计、期末大作业及项目实战练习。项目经导师指导并获评98分包含手势检测、数据集处理、模型训练、界面交互等核心模块可帮助学习者快速掌握从视频数据预处理到模型部署的完整流程。资源共50个文件以39个Python脚本为主涵盖数据集切割与增强、MLP模型构建、手势定位与界面控制等代码辅以4份Markdown说明文档、运行依赖清单及网络结构示意图压缩包仅433KB结构清晰便于阅读调试。目前已有244人学习下载适合具备一定Python基础、希望提升计算机视觉与交互系统开发能力的学生参考。通过研读源码学习者可获得完整工程目录范式、手势识别流程拆解以及图形界面控制的实际实现思路。1. 基于手势识别的人机交互系统一份把摄像头变成鼠标的课程设计源码答辩现场用食指在摄像头前画一个圈PPT 就顺利翻到下一页这种体验对评委的冲击力比任何静态界面演示都强。这份 python 实现的手势识别人机交互系统源码就是围绕这个场景搭起来的完整工程它把视频流切成帧、标注手势、训练识别模型、再把识别结果通过 socket 传给界面控制层最终驱动 PPT 翻页和鼠标移动。适合正在做课程设计、期末大作业或者想练手完整项目链路的计算机专业学生。2. 源码结构拆解gesture_interaction-rn_all 的模块划分与数据流2.1 六个功能目录的边界dataset_process、gesture_recognition 与 show_UI整个工程的核心目录是 gesture_interaction-rn_all下面分了六个功能目录。dataset_process 负责把原始视频切成帧并生成标签是整条链路的起点gesture_recognition 里面放着 MLPmodule.py、datasets_video.py、models.py、gesture_system.py 这些训练和推理相关文件communication 是 socket 收发模块send.py 发送识别结果receive.py 在接收端解析show_UI 是界面控制层imageview_control.py 处理图像显示ppt_control.py 负责把手势转成 PPT 动作show_prepare 是前置准备脚本test.py 可以快速验证环境是否跑通dataset_process 里还有 deal_video_no_cut.py 和 deal_video_tem.py 两个不同版本的视频处理脚本以及 copyVideo.py 这类辅助文件。从依赖关系看dataset_process 的输出是 gesture_recognition 的输入gesture_recognition 的输出又通过 communication 传给 show_UI。这个方向在 README 里用 network_arch.jpg 画得很清楚简单说就是「视频 → 帧 → 标签 → 模型 → 指令 → 界面动作」。我第一次看这个工程时会先跑 show_prepare/test.py 把环境打通再按数据流方向逐个目录读代码这样比乱翻快得多。2.2 数据流与依赖关系视频 → 数据集 → 模型 → 指令 → 界面我一般会把这种工程的数据流拆成五层。第一层是原始视频deal_video_no_cut.py 和 cutVideo.py 负责把长视频按手势动作切段第二层是数据集构建process_dataset.py、get_label.py、check_datasets.py 生成带标签的图像样本第三层是模型训练run_deal_video.py 作为训练入口MLPmodule.py 定义网络结构experiment 目录存放训练配置第四层是推理与坐标映射gesture_system.py 加载模型做实时预测gesture_location_system.py 把手势类别转成屏幕坐标和滑动信号第五层是界面交互show_UI 的 main_control.py 接收指令ppt_control.py 执行翻页和鼠标动作。这份资源最有价值的是它不是一个 demo而是把五层都串起来了。很多课程设计只做到第三层就结束但这里连通信和界面控制都写了。你在复现时要注意顺序先跑数据集处理再训练最后才联调界面。如果跳过前两层直接跑 main_control.py大概率会因为缺少模型权重文件而报错。3. 数据集处理链路从原始视频到可训练的手势样本3.1 视频切割cutVideo.py 与 deal_video.py 的分工与参数视频切割是整个流程里最繁琐的一步。原始视频是一段连续录制的动作流比如手掌张开保持 2 秒 → 食指伸出画圈 → 握拳这些动作必须被切成独立片段才能逐帧标注。cutVideo.py 做的是按时间区间切割deal_video.py 则负责把切割后的视频再做帧提取和尺寸统一。常见做法是用 OpenCV 的 VideoCapture 读视频按帧号区间裁剪。比如要保留 30 秒到 45 秒这段代码可以写成这样import cv2 cap cv2.VideoCapture(raw_gesture.mp4) fps cap.get(cv2.CAP_PROP_FPS) start_time 30.0 end_time 45.0 start_frame int(start_time * fps) end_frame int(end_time * fps) fourcc cv2.VideoWriter_fourcc(*mp4v) out cv2.VideoWriter(gesture_01.mp4, fourcc, fps, (640, 480)) frame_idx 0 while cap.isOpened(): ret, frame cap.read() if not ret: break if start_frame frame_idx end_frame: out.write(frame) frame_idx 1 out.release() cap.release()这里的关键参数是 fps 和分辨率。fps 决定帧号与时间的换算关系如果你的摄像头输出是 30 帧每秒上面代码里 start_frame 就是 900end_frame 就是 1350。分辨率我一般统一成 640x480因为后续整个工程的输入尺寸都是这个规格别在切视频时用 1920x1080否则后面训练时还要再做一次缩放白白增加工作量。实际处理时切割边界不能卡太死。手势动作的起始帧和结束帧通常会有 0.3 秒左右的模糊地带我一般会在 start_time 前减 0.2 秒end_time 后加 0.2 秒宁可多切一点也不要漏掉动作主体。漏掉动作主体比多切几帧严重得多因为这会直接污染训练标签。3.2 标签生成与校验get_label.py 和 check_datasets.py 怎么配合切割完视频后每个片段对应一种手势类别。get_label.py 的任务就是给这些片段打标签它会读取文件名的前缀来识别类别比如 swipe_left_001.mp4 属于类别 0swipe_right_001.mp4 属于类别 1。打标签的过程一般是按文件名规则批量处理也可以用配置文件维护类别与索引的映射。更常见的做法是维护一个类别字典label_map { swipe_left: 0, swipe_right: 1, palm_open: 2, fist: 3, point_up: 4, point_down: 5 } def get_label(video_name): for key, val in label_map.items(): if video_name.startswith(key): return val return -1用类别名作为文件名前缀比用数字编号直观得多。我在标注时吃过亏一开始用 1、2、3 编号结果切完视频后根本分不清哪个编号对应哪个动作后面只能重新看视频。所以建议文件名写成 swipe_left_001.mp4 这种格式让 get_label.py 直接提取类别。check_datasets.py 的作用是校验数据集完整性它会统计每个类别的样本数量、检查图像尺寸是否一致、检测是否有空文件。我在跑这个脚本时会额外关注类别分布如果某个类别的样本数明显少于其他类别模型训练时就会偏向样本多的类别。遇到这种情况回到切割步骤补录或者用复制的方式扩充少数类别的视频片段。3.3 分割训练验证集choose_train_validation.py 的随机种子与比例数据集打好标签后下一步就是划分训练集和验证集。choose_train_validation.py 负责这项工作它把每个类别的样本按比例随机分成训练和验证两部分。划分逻辑看起来简单但有两个参数很关键分割比例和随机种子。分割比例我一般用 8:2即 80% 的样本训练20% 的样本验证。比例本身没有绝对标准但验证集样本太少时评估指标会有比较大的波动。比如你每个类别只有 50 个样本20% 就是 10 个验证准确率可能因为一两个样本预测失败就从 95% 掉到 85%这在答辩时会被评委追问。随机种子决定了划分结果是否可复现。如果今天划分一次、明天再划分一次切分结果不一样模型每次训练的数据都不一样很难判断模型改进是来自算法调整还是来自数据变化。我的做法是把 random.seed 固定成一个常数比如 42并在 README 里记录这个值这样别人复现你的实验时结果是可以对比的。固定种子的代码一般这样写import random import numpy as np import torch random.seed(42) np.random.seed(42) torch.manual_seed(42)这里同时固定了 Python、NumPy 和 PyTorch 三套随机数生成器因为训练过程中这三者都会产生随机数。如果只固定 Python 的NumPy 和 PyTorch 的随机性仍然会带来不可复现的结果。4. 模型训练与识别逻辑MLP 模块和 gesture_system 的协作机制4.1 模型选型为什么 MLP 在这个场景够用很多做手势识别的项目一上来就上 CNN 或更重的 ResNet但这个工程选择的是 MLP也就是多层感知机。MLPmodule.py 里定义了一个全连接网络输入是手势图像的特征向量输出是类别概率。在课程设计场景里这个选择是合理的手势识别的关键不是图像纹理有多复杂而是手指轮廓和位置的模式MLP 在输入特征设计得好的情况下完全能达到够用的准确率。我一般会用几个全连接层加 ReLU 激活中间加 Dropout 防过拟合。输入层维度取决于特征向量长度比如把 640x480 的图像缩放到 32x32展平后就是 1024 维。输出层维度等于手势类别数。训练时用交叉熵损失和 Adam 优化器学习率从 0.001 开始如果验证集 loss 不下降就按 0.1 倍衰减。这种配置在这个数据规模下通常是够用的。4.2 训练入口与数据加载run_deal_video.py 和 datasets_video.pyrun_deal_video.py 是训练入口脚本它做的事情是加载数据集 → 初始化模型 → 训练多个 epoch → 保存权重。datasets_video.py 和 dataset.py 负责数据加载它们把图片文件读进来做归一化和尺寸统一然后按批次送给模型。训练脚本的主循环通常长这样from torch.utils.data import DataLoader from dataset import GestureDataset train_dataset GestureDataset(train_list, transformtransforms.Compose([ transforms.Resize((32, 32)), transforms.ToTensor(), transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]) ])) train_loader DataLoader(train_dataset, batch_size64, shuffleTrue, num_workers4) for epoch in range(50): for batch_idx, (images, labels) in enumerate(train_loader): images, labels images.to(device), labels.to(device) outputs model(images) loss criterion(outputs, labels) optimizer.zero_grad() loss.backward() optimizer.step()这里的 transform 很关键。Resize 把输入统一到 32x32ToTensor 把 PIL 图像转成张量并缩放到 [0,1]Normalize 用均值和标准差做归一化。如果你换用别的均值和标准差模型的收敛速度会受影响。batch_size 我一般取 64显存不够就降成 32数据集小的话不需要太大。4.3 坐标映射与指令生成gesture_location_system.py 的滑动与点击逻辑gesture_location_system.py 是整个系统里最容易被忽略但最影响体验的文件。它把模型预测出的手势类别转成屏幕坐标和动作指令。比如手势类别是「手掌张开」时系统会把手掌中心位置映射到屏幕坐标实现鼠标移动当手势变为「握拳」时触发点击。映射逻辑大概是这样的def hand_center_to_screen(hand_center, frame_shape, screen_size): fx, fy frame_shape sx, sy screen_size screen_x int(hand_center[0] / fx * sx) screen_y int(hand_center[1] / fy * sy) return screen_x, screen_y这里需要关注边界条件摄像头画面和屏幕坐标系方向通常一致但宽高比不一样。如果你的摄像头是 640x480屏幕是 1920x1080那么 x 方向缩放倍率是 3y 方向是 2.25。如果不区分这两个倍率鼠标移动就会在横纵方向上不一致看起来像被拉伸过。我在调这个的时候踩过坑后来把 x 和 y 的缩放独立计算就好了。5. 联调避坑手势识别控制 PPT 的四个常见问题5.1 communication 连不上地址、端口与阻塞模式communication 目录下的 send.py 和 receive.py 是用 socket 做进程间通信的。send.py 运行在识别端receive.py 运行在界面控制端。最常见的问题是连接失败现象是 send.py 报 ConnectionRefusedError原因通常有两个IP 地址写错或者接收端根本没启动。本地联调时send.py 里的目标地址应该是 127.0.0.1端口要和 receive.py 绑定的一致。我习惯用 50007 这种高位端口避免被系统服务占用。另外还要注意 socket 的 recv 是阻塞的如果接收端没有数据可收它会一直卡在那里界面看起来就像死机了一样。我一般会加一个超时import socket sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(2.0) try: data sock.recv(1024) except socket.timeout: print(no data received)5.2 手势误触发阈值、滑动窗口与去抖在实时识别时最典型的问题是手势误触发。就好比你只抬手摸了一下额头PPT 就翻页了。原因是模型对每一帧独立预测单帧的预测结果波动很大。我一般会加一个投票窗口连续 5 帧中如果同一类手势出现 3 次以上才认为该手势生效。代码逻辑可以这样写votes [] threshold 3 def process_frame(pred_class): votes.append(pred_class) if len(votes) 5: votes.pop(0) if votes.count(votes[-1]) threshold: trigger_action(votes[-1])这个配置在实际使用中比较稳。窗口太长会导致手势响应延迟明显能明显感觉到手都划完了 PPT 才翻页窗口太短又容易误触发。阈值 3 和窗口 5 是在响应速度和稳定性之间的一个折中可以根据实际场景微调。5.3 模型部署路径相对路径与绝对路径的坑很多人在复现时会遇到模型加载失败的报错现象是 FileNotFoundError原因是代码里写的是绝对路径换了一台机器后路径就失效了。打开 gesture_system.py 或 main.py 检查一下权重文件的加载路径我一般要求自己写相对路径或者通过配置文件统一管理MODEL_PATH os.path.join(os.path.dirname(__file__), weights, gesture_model.pth)用file来定位文件所在目录这样无论工程放在哪里路径都不会错。另外要注意 PyTorch 的版本兼容性训练好的权重如果是在旧版本下保存的新版 PyTorch 加载时可能出现 key 不匹配的警告遇到这种情况建议在保存时直接用 model.state_dict()加载时用 model.load_state_dict(torch.load(path))。5.4 界面黑屏或卡死回调函数与线程阻塞show_UI 目录下的 imageview_control.py 负责把摄像头画面实时显示在界面上。如果你在同一个线程里既做视频读取又做模型推理又做界面刷新程序大概率会卡死。原因很简单模型推理耗时几十毫秒在这期间视频帧读不出来界面就冻结了。我一般会把视频采集、模型推理、界面刷新拆成三个线程。视频采集线程只管读帧推理线程消费最新的一帧界面线程用定时器刷新显示。这样即便推理慢一点视频预览也不会黑屏。这个工程里 main_control.py 已经做了线程拆分你只需要注意不要在主线程里做任何耗时操作。6. 端到端验证从训练到演示的六个检查点演示前我建议按下面的顺序做一次完整检查。第一个检查点数据集是否能正常加载。跑一下 process_dataset.py确认输出目录里有足够数量的图片。如果图片数量是 0说明视频切割或帧提取环节出了问题先回去查路径和文件名匹配规则。第二个检查点模型训练能否完成一个 epoch。不用跑完 50 个 epoch跑 1 个 epoch 能正常结束且 loss 在下降就说明数据加载、模型结构、损失函数是对的。这里最常见的翻车是 GPU 显存不足batch_size 调小到 16 再试。第三个检查点模型对单帧图片的预测结果是否正确。找一张测试图片跑一次 model.predict确认输出类别索引和标签映射对得上。很多人在联调阶段发现手势 A 触发了动作 B就是标签映射表的顺序和训练时不一致。第四个检查点communication 是否连通。在本地开两个终端先跑 receive.py 再跑 send.py手动发送一个消息确认能收到。这一步能排除大部分联调问题因为如果 send 和 receive 不通后面界面层的所有功能都是白搭。第五个检查点摄像头画面上有没有绘制手势框和类别名。imageview_control.py 应该在每一帧上画出检测结果如果能看到画框但类别名是乱的检查模型输出的类别索引。第六个检查点从摄像头到 PPT 的完整动作链路。拿一个 PPT 文件站在摄像头前做三个动作手掌左右滑动翻页、食指上划进入上一页、握拳模拟鼠标点击。这里要特别观察响应延迟如果从手势到 PPT 动作的延迟超过 0.5 秒优先检查推理线程的帧率。从第一次拿到这份源码到最终把全链路跑通我大概花了三天。第一天搭环境和跑通数据脚本第二天训练模型第三天做联调和界面调试。印象最深的是通信模块的坑当时怎么都连不上查了半天发现是两个脚本用的端口不一致这种细节问题就是在复现时最容易卡住的地方。从那以后我每次拿到类似工程都会强制先梳理数据流和各模块的端口、路径配置再动手跑代码。这份资源最难得的是把视频处理、模型训练、通信和界面控制都打通了你只要按目录顺序走一遍就能理解整套系统的协作逻辑。希望帮到你。本文还有配套的精品资源点击获取