基于深度学习与关键点手势识别的电梯无接触控制系统

1. 先把题目拆开：这个毕设真正要解决的是什么

答辩现场最容易被问住的一句话是：你这不就是把按键换成了摄像头吗。如果答不上来，说明题目根本没吃透。我见过太多同类选题的最后交付物是一个能识别五根手指的脚本，加一张准确率 99% 的截图，然后被追问"电梯在哪"就哑火了。所以动手之前第一件事不是搭环境，而是把"基于深度学习的电梯无接触手势控制系统"这句话切成四块：手势怎么被看见、看见之后怎么被理解、理解之后怎么变成一条可靠的楼层指令、指令怎么驱动一个可演示的终端。四块里任何一块塌了，整个系统在评委眼里就是半个 Demo。

无接触交互这个词这两年被用得很泛，落到电梯场景其实非常具体：乘客的手可能提着东西、戴着薄手套、刚按过别的按钮不想再接触公共面板，或者在特殊时期对高频接触面有顾虑。这些动机决定了手势方案必须是单手可完成、不需要精细动作、容错窗口宽的。你要是设计一个需要五指精确捏合的手势，理论上很优雅，实际没人愿意在电梯口比划。这一点想清楚了，后面所有的类别设计、模型选型、状态机设计才有依据。

还有一层现实约束必须提前说清楚：真实电梯属于特种设备，控制指令的下发有严格的责任边界。毕业设计能做的、也应该做的，是把系统做到"手势→楼层指令码"这一层，再用一块自制的模拟楼层面板完成闭环演示。任何试图直接接管真实电梯按钮的做法都超出毕设范畴，也不该在论文里含糊其辞。我在方案里专门留了一节写这个边界，答辩时反而成了加分项，因为它证明你知道工程落地的红线在哪。

1.1 系统边界划定：把"电梯"简化成什么才不算跑题

我把整个系统分成三个物理上独立的模块，这样任何一块出问题都不至于全盘崩溃。视觉前端负责采集和推理，输出的是抽象的楼层指令码（比如"3 楼"、"开门"、"取消"），不带任何电气动作；控制中继是一块单片机，接收串口指令，做合法性校验、超时保护、冲突消解，然后驱动继电器阵列；模拟楼层面板用 LED 点阵表示楼层灯，用一个小舵机做门开合的机械演示，外加一个物理急停按钮。三层之间只有一条单向的指令通道，视觉端永远不知道继电器状态，这样即使模型抽风乱发指令，中继层还能兜底。

这么拆还有个隐性好处：论文里的实验章节可以完全聚焦在第一层。识别准确率、延迟、鲁棒性这些指标都在视觉端测，跟硬件无关，数据可复现、可对比。硬件部分只写系统集成，篇幅短但演示效果好。很多同学把实验和硬件搅在一起，最后论文里一堆"系统整体运行良好"的空话，一个可量化的表都拿不出来。

预算方面我当时列了个表，答辩 PPT 里直接放了这一页，评委对这个印象挺深，因为它说明项目是可控的。

费用不是重点，重点是这张表背后的取舍逻辑：主控只花六成预算，把钱留给结构和补光。我踩过的坑是前期把钱全砸在板卡上，结果摄像头是随手拿的一个自动曝光很激进的型号，手一动画面就忽明忽暗，模型直接崩，最后又补钱重买。视觉系统的稳定性，一半在光学，一半在算法，这个认知越早建立越省钱。

1.2 需求到指标的翻译：把"好用"变成可测的数字

毕设最容易糊弄也最容易被戳穿的地方就是指标。说"识别准确率高"没有意义，得说清楚在什么条件下、对谁、测了多少次。我给自己的系统定了四条硬指标，后面所有设计都围绕它们转。

第一条是单次交互端到端延迟不超过 800 毫秒。这个数字不是我拍脑袋的，是从人的操作体感倒推的：按物理按钮从伸手到灯亮大约 200~300 毫秒，无接触方案多了一层"确认"，如果超过 1 秒，用户会怀疑系统没反应从而重复比划，反而更乱。800 毫秒里留给算法的大约 100 毫秒以内，其余是确认窗口和硬件响应。

第二条是在 1.5 米内、300~800 勒克斯照度下，9 类指令手势的识别准确率不低于 95%。照度范围是实测出来的，普通电梯厅白天靠窗能到 600 勒克斯以上，晚上只有走廊灯的话可能掉到 150 左右，这个区间覆盖了绝大多数情况。

第三条是误触发率低于每小时 1 次。这条比准确率更难达标，因为电梯厅是公共场所，路过的人随便挥一下手、抬手看表、抱小孩，都可能被模型当成指令。准确率是"该认的认不认"，误触发率是"不该认的有没有乱认"，后者才决定这套东西能不能用。

第四条是连续工作 4 小时不出现内存增长和帧率衰减。这条纯粹是被坑出来的，我第一版跑两个小时就卡死，原因后面会讲。

提示：把这四条指标写进开题报告的任务书里，中期检查时按条汇报进度，答辩时按条给结论。评委看到的是一个有闭环的工程，而不是一段能跑的代码。

2. 技术路线怎么选：三条路走下来的取舍

手势识别这个领域现成的方案特别多，多到容易迷路。我前后试了三条路线，最后选的不是最先进的那条，而是在有限算力下最稳、最好解释、最好写论文的那条。这个判断过程本身值得写进论文的"方案对比"章节，很多同学的论文缺的就是这一块，只有"我用了某某模型"，没有"我为什么不用另一个"。

2.1 三条候选路线的实测对比

第一条是端到端检测分类，用一个目标检测或图像分类网络直接吃原始画面，输出手势类别。优点是链路短、论文里看起来"深度"，缺点是极吃数据——你得让模型自己学会在任意背景、任意位置找到那只手，没有几万张标注图根本训不动。我试过用两千张图起步，模型在训练集上 98%，换到没见过的背景直接掉到 60% 出头，典型的过拟合。

第二条是手部关键点 + 轻量分类器，先用现成的手部关键点检测拿到 21 个关节坐标，归一化后送进一个很小的全连接网络或梯度提升树做分类。优点是数据需求骤降（几百到几千个样本就够）、对背景天然免疫（关键点检测器只关心手）、尺度不变（坐标按手部包围框归一化后，远近手大小不影响特征）。缺点是依赖前置检测器的稳定性，手被遮挡或出画时会丢点。

第三条是时序骨架识别，把连续若干帧的关键点序列送进时序模型，识别动态手势比如"挥手""画圈"。这条路适合做加分项，不适合做主线，因为动态手势的起止点切分很难，误触发概率高，而且电梯场景其实不需要动态手势——乘客要的是"比一个数，灯亮"。

最后落地的结构是四段式流水线：手部检测（定位 ROI）→ 关键点提取（21 点）→ 特征归一化 + 静态分类（输出类别与置信度）→ 时序状态机（投票、确认、下发）。四段之间职责清晰，任何一段出问题都能单独定位、单独替换、单独写实验。这一点在做消融实验时特别省事：我把第二段换成端到端分类器，其他三段不动，就得到了一组天然可比的对照数据。

2.2 为什么"关键点"这条路更适合毕设

说几个特别实际的理由。第一是标注成本。端到端方案要给每张图框手的位置再标类别，两千张图我一个人标了两周还标错了三百多张；关键点方案只需要把一段视频切成"这段是数字 3"的片段级标签，抽帧后自动继承，一天能搞定几千帧。毕设的时间是硬约束，这个差距是决定性的。

第二是可解释性。答辩被问"模型凭什么认为这是 3"，端到端方案你只能拿热力图糊弄；关键点方案你可以当场把手部骨架画出来，指着三根伸直的手指说"伸直度超过阈值的手指有三根，所以是 3"。这种解释在答辩现场的价值远超准确率上多零点几个百分点。

第三是尺度与位置的不变性。电梯口的交互距离从 0.3 米到 1.2 米都有可能，身高 1.5 米和 1.9 米的乘客手部在画面里的位置差很多。关键点坐标按手部包围框做归一化之后，这些差异基本被抹平了，我实测过同一个手势在三个不同距离下关键点分布的方差，归一化后能压到原始坐标的三分之一左右。端到端模型要吃遍所有这些变化，只能靠数据堆。

第四是可裁剪。分类器小到可以塞进几百 KB，用不着量化压缩的痛苦流程，板子上跑起来几乎不占算力，把宝贵的算力全留给前置检测。这套思路在工程上叫"把难的部分交给专用模块，把简单的部分自己做"，非常朴素但有效。

当然代价也有，主要是前置检测器的召回率就是系统上限。手背对镜头、手指并拢、戴深色手套，都会让检测器丢点。我的应对是加了一条"丢点即回 IDLE"的规则，宁可让用户重比一次，也不让关键点抖动导致错误分类。这条规则在测试里把误触发率从每小时四次压到零点几次，效果比调模型参数明显得多。

2.3 算力账：先算清楚再买板子

买板子之前一定要算算力账，不然很容易买回来一块跑不动的。我的算法很土：先看目标帧率，比如 25fps，那就是每帧 40 毫秒的预算；再假设检测占 60%、关键点占 25%、分类占 10%、其他 5%，倒推出每一步的允许耗时。检测这一步最重，如果用的是基于轻量骨干网络的方案，在普通 ARM 核心上单帧可能要 80~150 毫秒，那就必须上加速。

粗算一下浮点算力需求：一个参数量约 2M 的检测网络，输入 320×320，单帧乘加运算量大约在 0.5~1 GFLOPs 量级。跑到 25fps 就是 12~25 GFLOPS 的持续算力。通用 ARM 四核在优化良好的推理框架下大概能提供 5~10 GFLOPS 的有效算力，勉强够跑低帧率；带 NPU 的板卡能到几十 TOPS（稀疏低精度下），完全够用还富余。

我最终用的是带 GPU 加速的板卡，实测整链路稳定在 30fps 以上，帧时间约 22 毫秒，其中检测 11 毫秒、关键点 5 毫秒、分类 2 毫秒、其余是绘制和通信。留出的余量后来被证明非常必要，因为加入时序投票和多帧缓冲之后，实际耗时又涨了 6 毫秒左右。

3. 手势词表与交互逻辑：别让用户猜

这部分是整个项目里我认为最有价值、也最容易被忽略的环节。绝大多数同类作品止步于"能识别九个数字"，但真实交互里，用户不知道什么时候系统在听、不知道比错了怎么撤销、不知道系统有没有看见自己。没有交互状态设计的手势系统，识别率再高也是废的。

3.1 手势类别怎么定才不像在为难用户

我最初的词表是九种数字手势加一个握拳取消，测试了十几个人之后砍掉了一半。问题出在四和五：数字四要求拇指收拢、其余四指伸直，实际做的时候大部分人拇指会不自觉地张开，跟数字五混淆；数字二和三在侧面视角下几乎一样。最后我做了三件事。

第一，按区分度而不是按数字顺序重选词表。保留了 1、2、3、5、6、8 这几个在不同视角下姿态差异明显的，把 4、7、9 换成了不需要精细动作的替代手势：四改用"拇指内扣的四指"，七改成"拇指与食指捏合"，九改成"食指单独竖直"。改完之后跨视角混淆率从 18% 掉到 5% 以内。

第二，加一个显式的"系统在听"状态。用户靠近并做出掌心朝向镜头的动作，保持 0.5 秒，屏幕亮起并显示倒计时环，表示进入输入态。这一步解决的是"我比了半天它没反应"的焦虑，也让误触发大幅下降——路人随手一挥不会触发掌心朝向保持。

第三，加一个明确的取消手势和超时退出。握拳保持 0.8 秒取消当前输入；进入输入态后 5 秒无有效手势，自动回到待机。这两个规则看着琐碎，实测下来的效果是：测试者第一次使用时的完成率从 62% 提到 91%。

表格里"保持时长"这一列很关键。太短容易误触，太长用户不耐烦，1.0 秒是在二十多个测试者身上试出来的平衡点——低于 0.7 秒误触发明显上升，高于 1.5 秒测试者普遍反映"等得慌"。

3.2 状态机：把"识别"和"执行"彻底分开

我在视觉端和硬件端之间插了一个状态机，五个状态：IDLE（待机）→ AWAKE（已唤醒）→ INPUT（采集中）→ CONFIRM（确认中）→ EXECUTE（下发），外加一个 LOCKED（异常锁定）。每次状态迁移都有明确的进入条件和超时退出，任何一环超时都退回 IDLE 并清空缓冲区。

状态机的核心是滑动窗口投票。具体做法是维护一个长度为 10 帧的队列，每帧的分类结果入队，当队列中某一类占比达到 80% 以上且连续满足该条件的时长超过保持时长，才判定为有效手势。这个机制把单帧误判基本消灭了：即使某一帧因为手抖被错分成别的手势，只要不超过两帧，都不会影响最终判定。

# 状态机核心逻辑（简化版，实际代码含日志与异常处理） WINDOW_SIZE = 10 VOTE_RATIO = 0.8 HOLD_FRAMES = 30 # 30fps 下约 1 秒 class GestureStateMachine: def __init__(self): self.state = "IDLE" self.buffer = deque(maxlen=WINDOW_SIZE) self.hold_count = 0 self.last_cmd = None def update(self, cls_id, conf, ts): # 置信度低于阈值直接视为无效帧 if conf < 0.75: self.buffer.append(-1) else: self.buffer.append(cls_id) if self.state == "IDLE": if cls_id == WAKE_ID and self._stable(WAKE_ID, 15): self.state, self.hold_count = "AWAKE", 0 return None if self.state == "AWAKE": if cls_id in CMD_IDS and self._stable(cls_id, 10): self.state, self.last_cmd, self.hold_count = "INPUT", cls_id, 0 return None if self.state == "INPUT": if cls_id != self.last_cmd: self.hold_count = 0 # 换手势即重置，防止串扰 self.last_cmd = cls_id return None self.hold_count += 1 if self.hold_count >= HOLD_FRAMES: self.state, self.hold_count = "CONFIRM", 0 return ("confirm", self.last_cmd) # 触发二次确认 return None if self.state == "CONFIRM": self.hold_count += 1 if self.hold_count >= 10: self.state, self.hold_count = "EXECUTE", 0 return ("exec", self.last_cmd) return None if self.state == "EXECUTE": self.state = "IDLE" self.buffer.clear() return None

这段逻辑里有两个细节值得单独说。一是"换手势即重置"。早期版本里用户比了 3 之后想改比 5，结果因为切换瞬间抖动混入了 3 的帧，系统还是下了 3 楼。加了重置逻辑后，只要连续两帧类别变化就清空计数，用户改主意的成本降到最低。

二是 CONFIRM 和 EXECUTE 分开。CONFIRM 阶段屏幕会给出明确反馈（比如楼层数字闪烁一次），这 300 毫秒左右的时间既是给用户的确认感，也是给系统的缓冲——如果这个阶段手势突然消失（用户放下了手），直接退回 IDLE 不下发。这层保险在多人干扰的场景下救过我好几次。

3.3 多人同时在画面里怎么办

这是答辩必问题。我的处理策略是取最近者 + 区域门限。手部检测输出的包围框面积最大的那个作为主目标，因为电梯口交互距离通常是手臂伸出状态，距离镜头最近的手框面积明显更大。同时设一个 ROI 限制：只在画面中下部的一个矩形区域内接受手势，把远处走动的人排除掉。实测在两人同时举手的情况下，系统选择前台操作者的准确率大约 85%，够用但不完美。

想做得更稳可以上跟踪，给每个手部框分配 ID，锁定第一个完成唤醒动作的目标。我后来加了个轻量版本：唤醒手势触发时记录当时的手框位置，后续只接受距离该位置 200 像素以内的检测结果，跟踪丢失 1 秒才重新选目标。改动不大，多人场景下的正确率提到了九成以上。

4. 数据集：这个项目最大的体力活

算法部分其实没多少原创空间，真正拉开差距的是数据。我这套系统的数据集完全自建，没有用任何公开的静态手势库，原因有两个：公开库的拍摄条件和电梯场景差异太大，背景干净、光照均匀，训出来的模型在真实环境里掉得厉害；另外自建数据集在论文里可以详细写采集协议，这部分比算法描述更能体现工作量。

4.1 采集协议：怎么拍才不算白拍

采集之前先列清楚变量维度，否则拍着拍着就偏了。我定了四个维度：人数（12 人，男女各半，身高从 1.55 到 1.88，其中两人戴眼镜、一人留长袖口、一人戴薄手套）、光照（强光 600+ 勒克斯、常规 300 左右、弱光 150 左右三档）、距离（0.4 米、0.8 米、1.2 米三档）、视角（正面、左偏 30 度、右偏 30 度、略仰视）。四个维度全组合下来是 12×3×3×4=432 组，每组每类手势录 5 秒，总时长超过 15 小时。

拍这么多显然不现实，我做了裁剪：人数和距离全组合，光照和视角用交叉设计，只对其中 4 名受试者做全组合，其余人只录常规光照正面视角。最终实际录制约 4.5 小时素材，抽帧后得到约 9 万帧，去掉手部检测失败的、模糊的、无手的，剩下约 6.2 万帧可用，按 8:1:1 划分训练、验证、测试。关键点方案的好处在这里体现得淋漓尽致：每个样本的输入只是 21 个坐标加几个角度特征，整个特征集存成 CSV 不到 10 MB，训练时秒级加载。

采集时有个小技巧：不要让受试者看着屏幕上的提示做动作。一开始我用了引导界面，结果所有人都做成标准教科书姿势，模型在测试阶段表现很好，实际用的时候一塌糊涂——真人比划手势是随意的、带角度的、会晃的。后来改成给受试者一个口头任务（"你要去 6 楼"），让他们自己决定怎么比，数据分布立刻真实了很多。

4.2 特征归一化：比模型结构更重要的细节

关键点拿到手之后不能直接喂网络，必须先归一化，否则模型学到的是"手在画面哪个位置"而不是"手指是什么姿态"。我的做法分三步。

第一步，平移归一化：以手腕关节点为原点，所有 21 个点减去手腕坐标。这样手在画面里怎么移动都不影响特征。

第二步，尺度归一化：计算手掌上两个基准点（手腕与中指根部）的欧氏距离作为参考长度，所有坐标除以它。这样远近手的大小差异被消除，0.4 米和 1.2 米的同一个手势特征几乎一致。

第三步，旋转归一化（可选）：把手掌平面旋转到统一朝向。我试过完整实现，效果提升有限但引入了额外的奇异性问题（手掌正对镜头时旋转角不稳定），最后只做了一个弱化版本：把手腕到中指根部的向量角度作为额外特征喂进网络，让模型自己学旋转关系，比强制对齐稳。

import numpy as np def normalize_landmarks(lm, eps=1e-6): """lm: (21, 2) 归一化到 [0,1] 的图像坐标""" wrist = lm[0] pts = lm - wrist # 平移 ref = np.linalg.norm(lm[9] - wrist) + eps # 中指根部距离 pts = pts / ref # 尺度 # 手掌朝向角作为附加特征，不强制旋转 vec = lm[9] - wrist angle = np.arctan2(vec[1], vec[0]) # 指节弯曲度：每根手指三个关节的夹角余弦 angles = [] for finger in FINGER_JOINTS: # 每根手指 3 个点索引 for i in range(len(finger) - 2): a = pts[finger[i]] - pts[finger[i + 1]] b = pts[finger[i + 2]] - pts[finger[i + 1]] cos = np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b) + eps) angles.append(np.clip(cos, -1, 1)) return np.concatenate([pts.flatten(), [angle], angles]) # 43 维特征

最终特征向量是 43 维：42 个归一化坐标加 1 个朝向角，再加上手指弯曲度得到的十几维就是完整输入。分类器用的是两层隐藏层的全连接网络，参数量两万出头，训练在普通笔记本上几十秒一轮，非常适合反复做消融实验。这也是我选择这条路线的隐性收益：实验迭代成本极低，一晚上能跑十几组对比。

4.3 增强与难例：让模型见过"脏"数据

关键点方案的数据增强和图像方案完全不同，不是旋转裁剪，而是在坐标空间加噪声。我做了四种：坐标高斯噪声（模拟检测器抖动，标准差取 0.01~0.03 个归一化单位）、随机丢弃单指关键点（模拟遮挡）、随机缩放（±10%，模拟检测框误差）、随机小角度旋转（±8 度）。其中坐标噪声最有效，加上之后测试集准确率没有提升，但实际场景下的稳定性提升明显——因为它让模型对检测器的抖动脱敏了。

难例我专门建了一个文件夹，把测试中所有分错的样本存下来，标注真实类别后混回训练集。三轮迭代下来，难例从最初的 1400 多帧降到 200 多帧。剩下的顽固难例集中在三种情况：戴深色手套时食指和中指的伸直度判断失效、袖口遮住手腕导致归一化基准偏移、侧视角下拇指被手掌挡住。针对第一种我加了一条规则——当手部区域的图像亮度均值低于阈值时，降低手指伸直度的权重，改用相对角度判断，简单粗暴但管用。

5. 模型训练、量化与端侧部署

训练本身没什么玄学，值得写的是那些调参之外的事：怎么选指标、怎么做量化不掉点、怎么在板子上跑得稳。

5.1 训练细节与指标选择

损失函数用的是带标签平滑的交叉熵，标签平滑系数 0.1，主要作用是抑制模型过度自信——不加平滑的时候模型对错误样本也给出 0.99 的置信度，导致后面基于置信度的过滤机制完全失效。优化器用 AdamW，初始学习率 1e-3，余弦退火，批大小 128，训练 200 轮，早停耐心值 20。

评估指标除了准确率，我重点看了两个：混淆矩阵和各类别的 F1。整体准确率 98% 听起来漂亮，但如果"取消"手势的召回率只有 80%，意味着用户想撤销却撤不掉，体验是灾难性的。实测下来最差的是数字 5 和取消握拳之间的混淆，因为五指张开和握拳在关键点空间里只差手指伸直度这一组特征。解决办法是给握拳单独加了一维特征——手掌包围框的长宽比，握拳时这个比值接近 1，张开时接近 0.6，一维特征就把两类分开了。

最终在留出测试集上的结果是整体准确率 98.2%，九类手势的 F1 最低 96.1%（出现在"取消"），最高 99.3%。这个成绩在论文里不算惊艳，但配上分光照、分距离的细分表格就很扎实了：弱光下掉到 94.5%，1.2 米距离掉到 95.8%，戴手套场景掉到 91.2%。把短板诚实地列出来，比报一个 99.9% 更让评委信服。

5.2 量化：不量化也能跑，但量化之后更从容

因为分类器本身很小，我在主线方案里其实没做量化，直接跑浮点。真正做量化的是对照组——那个端到端分类网络，用来做方案对比。过程踩了几个坑，值得记一笔。

第一个坑，校准集必须来自真实分布。第一次量化我随手用了训练集的一个子集做校准，结果模型在测试集上掉点严重。后来改用从测试集里单独划出的 500 张未参与训练的图做校准，掉点从 4.3 个百分点降到 0.5 个百分点。校准集的作用是确定每层激活值的动态范围，用训练集的分布去定范围，等于用已知答案去考试。

第二个坑，输入预处理要和量化前的实现完全一致。量化模型的输入是 int8，如果归一化方式（比如减均值除方差）在预处理环节和训练时不一致，误差会被放大。我是把预处理直接融进模型图里，导出时一次性搞定，运行时不再单独做归一化，避免了这个问题。

具体数值会随硬件和模型结构变化，但趋势是稳定的：FP16 基本无损，INT8 通常掉 0.3~0.8 个百分点。在分类器本身只占 2 毫秒的场景下，这点加速意义不大，反而是 FP16 的显存占用优势更实在。如果是端到端方案，量化就是必选项了。

5.3 端侧工程化：帧率掉下去的三个真凶

模型训完只是开始，部署到板子上才是噩梦。我遇到的三个问题都是纯工程问题，跟算法一点关系没有。

第一个是内存泄漏。系统跑两小时必卡死，帧率从 30 掉到 5。原因是我在每帧回调里都创建了一个新的图像对象和若干中间数组，没有及时释放，加上推理框架的对象池配置没调好，内存缓慢增长。用系统监控工具看内存曲线，是标准的锯齿状爬升。解决办法是把图像缓冲和推理会话都做成全局单例，回调里复用，内存曲线立刻变平。

第二个是摄像头自动曝光。这个坑最隐蔽，因为程序没崩、帧率也没掉，就是识别率莫名其妙变差。后来把输入画面录下来逐帧看才发现，手接近镜头时画面整体变暗，摄像头自动提高增益，导致手部边缘过曝、关键点检测抖动。解决办法是关闭自动曝光和自动白平衡，手动锁定参数，同时加一组固定亮度的补光。锁定之后，同一场景下的识别稳定性提升非常明显。

第三个是线程与队列积压。早期版本采集和推理在同一个线程，一旦某帧推理超时，后面的帧就排队，延迟越积越大，用户看到的是"比完手势半天才反应"。改成采集、推理、显示三个线程，中间用长度为 1 的队列连接（满了就丢最旧的），延迟立刻稳定在 60 毫秒以内。宁可丢帧也不要排队，这是实时系统的通用原则。

注意：如果你的板子只有单核或双核，多线程反而会因为调度开销变慢。上线前一定用实际硬件测，别照搬网上的配置。

6. 硬件搭建与联动实现

视觉部分做完，项目只完成了一半。毕业设计的评分里，系统完整性的权重比很多人想象的高。我见过算法做得不错但只有一个命令行的作品，分数并不理想。

6.1 安装位置不是随便挂上去就行

摄像头装多高、俯角多少，直接决定了交互区能不能被完整覆盖。我先量了交互区的尺寸：按钮面板正前方，横向 ±0.35 米，纵向 0.3 到 1.0 米。选定模组的水平视场角约 78 度，按最远距离 1.0 米算，覆盖宽度是 2×1.0×tan(39°)≈1.62 米，绰绰有余；按最近距离 0.3 米算，覆盖宽度约 0.49 米，刚够用。所以安装高度定在 1.55 米（比面板上沿高约 0.2 米），俯角 18 度，这样 0.3 米近处的横向覆盖刚好包住交互区。

为什么高度要可调？因为测试时发现身高 1.55 米的人和 1.88 米的人，手部出现的画面位置差了将近画面高度的三分之一，虽然归一化能缓解，但手出画或贴近画面边缘时关键点检测会丢。把支架做成可上下调 20 厘米的，测试和演示时都能快速适配。

补光的位置也有讲究。最初我把灯装在摄像头正下方，结果手指之间产生阴影，关键点检测在指缝处频繁跳变。改成双侧 45 度打光之后，阴影被中和，指缝清晰度明显提升。这个小改动对弱光场景的准确率贡献了大概 3 个百分点，成本只有几十块钱。

6.2 指令通道与失效降级

视觉端通过串口发指令，帧格式定得很简单：帧头 0xAA、指令码、校验和、帧尾 0x55。指令码用两个字节，高字节是类型（楼层、开门、关门、取消），低字节是参数。校验和用简单的累加取反，够用且开销小。

下位机收到之后要做三件事。校验：帧头帧尾校验和任一不对就丢弃并计数，连续十次错误就主动发一条复位请求。互锁：如果当前正在执行开门动作，收到楼层指令就排队等待，不并发执行。超时保护：如果 1 秒内没有收到视觉端的"心跳"，认为上位机异常，所有输出复位到安全状态，面板显示待机。

演示效果上我花了点心思：楼层 LED 用点阵模块显示数字，选中时数字下方有一条呼吸灯带；门用一块亚克力板加舵机，开合动作 1.5 秒完成。这些细节不增加任何技术难度，但演示时评委的注意力会明显被吸引，讲解也更容易展开。毕业设计的演示是给人看的，可视化反馈的性价比极高。

6.3 安全设计：那些"用不上但不能没有"的东西

有三个设计我从头到尾没在正式演示中用到，但每一个都写进了论文的安全章节。

物理急停。面板侧面一个红色按钮，按下直接切断继电器供电，不经过任何软件逻辑。这条是底线，任何自动化系统都该有。

异常锁定。连续三次无效输入或连续两次下发冲突指令，系统进入 LOCKED 状态，屏幕显示"请稍候"，锁定 5 秒后自动恢复。这条针对的是儿童反复比划或恶意干扰的场景。

降级提示。当光照低于阈值或关键点检测连续丢失超过 2 秒，屏幕显示"环境光不足，请靠近操作"，同时把唤醒保持时长从 0.5 秒降到 0.3 秒，降低用户操作难度。降级不是关闭功能，而是让系统在不利条件下仍然可用。

这三条加起来代码量不到两百行，但在答辩时是实打实的加分点。评委问"如果识别错了怎么办"，你可以指着急停按钮和状态机回答，而不是说"准确率很高所以不会错"。

7. 联调实测：那些只有跑起来才会遇到的问题

实验室里跑通和真实场景可用，中间隔着至少二十个坑。这一节记录几个印象最深的，附排查思路。

7.1 典型故障速查表

这张表是我在联调阶段一条条填出来的，每一条背后都至少花了两三个小时。比如"反复触发同一条指令"这个问题，现象是用户比一次手势，面板连续亮三次。原因是 EXECUTE 状态只停留了一帧就回 IDLE，但缓冲队列里还留着之前的帧，回到 AWAKE 之后立刻又被判为有效。修复方法很简单——执行完清空缓冲，并加一个 500 毫秒的冷却期，冷却期内不接受任何手势。

7.2 三次印象深刻的翻车

第一次是"演示前五分钟模型罢工"。答辩前一天彩排，系统在实验室好好的，搬到会场之后识别率断崖式下跌，几乎所有手势都被判成取消。排查了半小时才发现，会场的投影仪正对着我们的演示台，投影光打在摄像头前方形成一片强光区，手部进入这个区域时严重过曝。紧急处理是把演示台往侧面挪了一米，避开投影主光路，同时把曝光再压低一档。这件事之后我养成了一个习惯：任何演示前都要在实际场地做一次全流程走查，不看代码看环境。

第二次是"戴手套的评委"。中期检查时一位老师戴着深色薄手套上来试，系统完全不认。这个场景我数据集里只有一个人的少量样本，泛化不了。事后补救是加了那条亮度自适应的规则，同时允许在检测到"手部区域亮度异常低但形状符合手部"时，跳过颜色相关特征，纯用几何特征分类。准确率当然会掉，但至少能用。这件事让我在论文的"局限性"一节写得特别实在。

第三次是"连续跑四小时"。答辩前一晚我让系统通宵跑压力测试，第二天早上发现它停在两小时十七分的地方。日志显示串口写入阻塞，一路追下去是下位机在某个异常指令后进入了等待状态，没返回应答，上位机就一直等。修复是给串口读写都加超时，超时后主动复位链路。任何跨设备通信都必须假设对面会挂，这是那次通宵最大的收获。

7.3 指标怎么测才站得住

测试方案我做了三套，分别对应论文里的三张表。

第一套是离线测试，用留出的测试集跑，得到混淆矩阵和各类 F1。这套最快，几分钟出结果，但只能证明模型本身。

第二套是受控场景测试，找 8 名没参与数据采集的受试者，在三种光照、三个距离下各做 20 次指定手势，记录成功率和平均完成时间。这套最能体现真实体验，我记得平均完成时间是 2.3 秒（从进入交互区到指令下发），其中唤醒占 0.6 秒、手势保持 1.0 秒、确认 0.3 秒，剩下是人的反应时间。

第三套是干扰测试，模拟路人经过、两人同时操作、有人在旁边打电话挥手，统计每小时的误触发次数。这套最难做也最有说服力，最终结果是常规时段每小时 0.6 次，高峰时段（模拟人流量大）每小时 1.8 次，略超我定的指标，论文里如实写了。

提示：受试者一定要找没参与过数据采集的人，最好是没听过你项目的人。熟悉系统的人会不自觉地用"系统喜欢的方式"比手势，测出来的数据没有意义。

8. 从工程到论文：怎么把做过的事讲成研究

很多同学项目做得不错，论文写得像产品说明书。区别在于：产品说明书讲"我做了什么"，论文还要讲"为什么这样做比其他做法好，证据是什么"。这一节说说怎么把前面这些工作翻译过去。

8.1 消融实验：把每个设计决策都变成一组数据

我的消融实验设计了四组，每组只改一个变量，其他保持不动。

这四组数据把"我为什么这么设计"讲得清清楚楚：投票窗口主要降误触发，难例增强主要提准确率，状态机两者都有贡献。答辩时评委问"你这个状态机有什么用"，直接指表格第三行，比说十句都管用。

另外还做了一组方案对比实验，把关键点方案和端到端方案放在同一测试集上比。端到端方案在训练集上准确率 99.1%，测试集 88.4%，跨场景掉点严重；关键点方案训练集 98.9%，测试集 98.2%，差距很小。这组数据是整篇论文最有力的论证，说明在小样本条件下选关键点路线是对的。

8.2 演示脚本：把不确定性关在笼子里

答辩演示只有五到八分钟，任何意外都是灾难。我准备了三级预案。

一级是正常流程：走到交互区，掌心唤醒，比数字 6，面板亮起 6 楼，再比握拳取消，灯灭。全程控制在 40 秒内，动作干脆，不解说细节，让评委先看到结果。

二级是环境异常：如果现场光照不理想，直接切到"演示模式"，这个模式下补光灯常亮、唤醒门槛降低、置信度阈值下调，牺牲一点严谨性换取演示成功率。切换方式是一个隐藏按键，不说出来。

三级是硬件故障：提前录好一段两分钟的全流程视频，存在本地，随时可以播放。同时准备一个"数据回放"模式，用提前录好的视频流喂给系统，看起来像实时运行。这不是作弊，是工程上标准的降级方案，评委问起来如实说明即可。

还有个小细节：演示前把日志级别调低。我的第一版演示时控制台疯狂打印调试信息，屏幕上滚动的日志把画面挡住了，特别狼狈。后来改成只打印关键状态迁移，画面干净了很多。

8.3 答辩高频问题的准备思路

我把被问到的问题整理了一下，大致分四类。

第一类问准确率的水分。"你这个 98% 是在什么条件下测的？"标准答案是分维度报数据：常规光照 98.2%，弱光 94.5%，1.2 米距离 95.8%，戴手套 91.2%，并说明测试集和训练集的受试者完全不重叠。数据越细，可信度越高。

第二类问安全性。"识别错了会不会把人送错楼层？"回答要分两层：软件层有置信度阈值、多帧投票、二次确认三道过滤；系统层有指令合法性校验和超时保护；物理层有急停。同时明确说明本设计只做到指令生成，真实电梯控制有严格的责任边界，这部分不在毕设范围内。

第三类问创新点。"你这个跟网上开源的有什么区别？"别硬吹算法创新，讲工程创新更实在：手势词表是按区分度重新设计的、状态机把识别和执行解耦、弱光下的自适应降级策略、多人场景的目标锁定。这些在开源项目里确实少见，而且是实打实做出来的。

第四类问扩展性。"能不能用到别的场景？"可以说同一套流水线换个词表就能用在无障碍交互、展馆导览、医疗设备非接触操作上，但要注意不同场景对手势的社会可接受度不同——在电梯口比数字没人觉得奇怪，在安静场所可能就不合适。这种带反思的回答通常比一味吹嘘更受欢迎。

9. 一些踩坑之后的个人体会

做这个项目最大的感受是，毕业设计的分数差距，往往不在算法多新，而在系统多完整、边界多清楚。我见过用最前沿模型但演示时只有命令行的作品，也见过用传统方法但交互设计得极顺滑、论文数据极扎实的作品，后者的评价通常更高。

如果重做一遍，我会在三个地方做得不一样。一是把数据采集放在第一周，而不是等模型跑通了再补数据，因为数据决定了模型的天花板，前期数据分布没设计好，后面调参全是白费。二是更早做端到端联调，不要等视觉部分完美了才接硬件，硬件的问题往往反过来影响视觉的参数选择，早接早发现。三是给交互流程做用户测试的时间翻倍，我最后只找了八个受试者，样本太少，好几条设计决策其实是拍脑袋定的。

还有一条很实际的建议：把每天的实验参数和结果记在本子上。不是记在脑子里，也不是记在聊天记录里。我后期做消融实验时，想找一个两周前的参数组合，翻了半天找不到，只能重跑。后来固定用一个表格记日期、改动点、准确率、备注，效率提升非常明显，而且这些记录直接就是论文实验章节的素材。

最后说个技术上的小心得。当你在纠结模型结构、损失函数、学习率这些的时候，不妨先回头看看输入特征。我前前后后调了两周模型，准确率卡在 96% 上不去，最后是靠加了一维"手掌长宽比"特征突破的——一维特征，一行代码，比调参管用得多。特征工程在中小规模问题上永远比模型结构更值得投入时间，这个经验在后来做别的项目时反复被验证。