让启元 T1 Pro 认出点赞、V 字、布和石头：一次从相机到模型的二次开发实录

让启元 T1 Pro 认出点赞、V 字、布和石头一次从相机到模型的二次开发实录让启元 T1 Pro 认出点赞、V 字、布和石头一次从相机到模型的二次开发实录一、第一步不是训练模型而是让电脑真正读到机器人二、120 帧里没有手问题出在镜头而不是模型三、392 张图片怎么分关键是不能让连续帧互相“串门”四、三种做法都试了效果差距比预想中大五、成绩单正确识别、误判和拒识一起看六、真机开发的三个小经验七、复现这次实验先从已有照片跑起写在最后你好这里是 晓雨的笔记本在所有感兴趣的领域扩展知识感谢你的陪伴与支持~ 欢迎添加好友 is_yu_ei不定期掉落福利资讯原创技术实践转载请注明作者和出处。本文配图包含技术流程图、实验统计图及 T1 Pro 真实右目完整画面与自动手部 ROI 对照。让启元 T1 Pro 认出点赞、V 字、布和石头一次从相机到模型的二次开发实录关键词启元 T1 ProROS 2PrimeConsoleMediaPipeMobileNetV3手势识别真机实测为什么要教机器人认手势比如机器人在展厅讲解用户想继续下一步没必要每次都喊口令在嘈杂现场或不方便讲话时手势也能成为快捷输入。点赞可以约定为确认V 字切换步骤张开手掌暂停握拳结束。T1 Pro 本身就有摄像头如果能看懂这些简单动作就多了一种不依赖手机遥控器的交互方式。第一次对着 T1 Pro 比手势我觉得应该很简单张开手掌、跑一下模型、屏幕上显示OpenPalm这不就通了结果程序读了 120 帧连一只手都没找到。换成点赞和 V 字之后又遇到了另一种情况明明拍到了手模型却认错了。先看一组真机实拍T1 Pro 右目摄像头看到的是完整的室内场景手只占画面的一小块。我们让程序先自动找手、再裁剪局部识别。下面每一行的左右两张图来自同一帧并非分别摆拍。图 1真实场景下的自动手部定位与 ROI 识别。左侧保留 2592 × 1944 的完整取景范围绿色框是自动检出的手部右侧为对应帧的模型 ROI。四行依次是点赞、V 字、布和石头。图中为已有数据中筛选出的识别成功样例人物面部已做隐私处理。更有意思的是我们原来的 MobileNetV3-Small 在公开测试图片上能答对35/40 张87.5%。一接上真实机器人问题却接二连三。于是这次我没有急着换更大的网络而是从相机、手部定位、裁剪、特征和数据集这几个环节往下查。最后把此前采集的真机照片与公开手势图片整理在一起一共392 张完整跑了一遍训练、验证和测试。这次先用四种容易辨认的手势验证视觉识别链路 点赞ThumbsUp、✌️ V 字PeaceSign、️ 布OpenPalm、✊ 石头Fist。手从镜头里消失后还需要及时返回“无手”避免继续报告上一帧的姿势。一、第一步不是训练模型而是让电脑真正读到机器人我们这次用的是 T1 Pro 的右目摄像头。设备端负责拍照Windows 电脑负责解码和推理我先把两个部分分开调通。开始时电脑上的 PrimeConsole 已经安装好但输入设备 SN 后依然无法直接进入开发流程。后来在手机 PrimeBOT App 里检查并开启了二次开发相关功能再回到电脑端确认连接。接着改为有线连接通过独立开发网段检查两块板卡和 ROS 2 通信。这一步花的时间比想象中多。网线松动时控制台看起来还在ROS 2 的相机调用却会超时。最后我把排查顺序固定下来网卡状态 → 设备连通 → 摄像头 Service → JPEG 数据 → 模型推理。以后遇到“识别不动了”先看哪一层断了少走很多弯路。在本次 SDK 环境中右目 JPEG 抓拍的核心调用是fromaimdk_msgs.msgimportCommonRequestfromaimdk_msgs.srvimportCaptureJpegImage clientnode.create_client(CaptureJpegImage,/aima/hal/camera/CaptureJpegImage)assertclient.wait_for_service(timeout_sec5.0)reqCaptureJpegImage.Request()req.requestCommonRequest()req.request.header.stampnode.get_clock().now().to_msg()req.camera_idhead_stereo_rightreq.timeout_ms3000futureclient.call_async(req)rclpy.spin_until_future_complete(node,future,timeout_sec5.0)resfuture.result()ifresisNoneorres.response.header.code!0:raiseRuntimeError(相机抓拍失败)jpeg_bytesbytes(res.jpeg.image.data)这里截取的是关键接口完整运行还需要创建 ROS 2 节点、初始化与清理资源。把jpeg_bytes验证并解码成图片之后才进入下一步手势识别。还有一个实际踩过的坑ROS 2 和模型推理最好使用隔离的 Python 环境。我们碰到过 NumPy 的_multiarray_umathDLL 加载失败原因是推理进程继承了 ROS 2 环境的PYTHONPATH把两套库混在了一起。分开运行通信与推理进程问题就解决了。二、120 帧里没有手问题出在镜头而不是模型第一次正样本测试没检测到手我马上检查了右目的抓拍照片画面里大部分是桌子下面、地面和鞋子。人确实站在机器人前摆了手势但手根本没处于所选摄像头的有效视野里。于是先写了一个很简单的采集窗口可以看右目预览按“点赞 → V 字 → 布 → 石头”倒计时采图并把每一轮照片单独保存下来。这样模型错了至少可以回头确定究竟是手没入镜、手太小还是分类器真的判断错了。解决视野后第二个问题才浮出来。右目 JPEG 约为2592 × 1944手掌可能只占画面很小一块。直接把整张图缩到分类器输入大小手指细节就丢了不少。我后来把流程换成了“先找手再识别手势”MediaPipe 先定位手如果下一帧整图漏检就借助上一帧的手部位置在附近的 ROI 重新检测拿到关键点后再看五指伸展、弯曲以及相对位置。图 2当前视觉处理链路。真机连续帧与公开静态图片采用不同的识别路径82 维关键点分类器另作固定数据集对照。这项改动的效果很直观第二轮真机 64 张图整图检手只有42/64加上前帧 ROI 补检后这轮离线回放检出了64/64。这里提升的是手部检出率后面的四类分类仍需单独测试。三、392 张图片怎么分关键是不能让连续帧互相“串门”采到足够的手势图后接下来是训练。最省事的办法是把所有图片随机打散比如 8:1:1。但同一次摆手连续拍出的十几张照片几乎一模一样随机划分很容易把同一个动作和背景同时送进训练集、测试集。我们最后把采集轮次当作一个整体第一轮真机用于训练第二轮用于验证最后一轮留作测试。原来的公开 train / validation / test 也保持原有划分。图 3固定划分Train 183 张、Validation 110 张、Test 99 张。颜色区分公开手势、真机手势和无手图片。数据集数量组成训练集 Train183公开训练 120 第一轮真机 63验证集 Validation110公开验证 40 第二轮真机 64 无手 6测试集 Test99公开测试 40 最新真机 47 无手 12先核验图片哈希确认没有跨集合重复文件再只用验证集选前端阈值和分类方案。MediaPipe 手部检测门限从0.65调到0.35公开验证图的检出由25/40提高到31/40这次的 T1 Pro 验证图仍为64/646 张无手背景没有触发手部检测。接着我们提取三种手部特征5 维手指关节角、19 维局部几何距离以及82 维归一化关键点姿态。与把整张室内照片送进网络相比这些特征更直接地描述“手是怎么摆的”。四、三种做法都试了效果差距比预想中大方案 A原 MobileNetV3 直接识别整张图片。它仍然很适合原来的公开图片公开测试集得到35/40。但机器人画面有桌椅、衣物、地面手还经常只占很小一块。最早一轮真机 63 张图片直接整图分类甚至没有一张与采集提示类别一致。方案 B检测手后把关键点交给小分类器。我们在训练集上比较了 Logistic Regression、SVM、RandomForest以及 5 / 19 / 82 维特征。验证集选出的组合是82 维归一化关键点 Logistic RegressionC1置信度低于0.60就暂不输出手势。随后合并 Train 和 Validation 的可检测手部特征固定参数重新训练再评估 Test。方案 C根据输入来源走不同路径。机器人连续相机画面优先走 MediaPipe、时序 ROI 和手指几何判断普通公开静态图片沿用原 MobileNetV3。机器人画面来自哪一路相机本来就是系统知道的信息不必让分类器猜。这个方案不涉及再训练一个统一的大网络优势在于各取所长。期间我们也试了裁剪后 MobileNet 特征微调分类头、降低早期真机样本权重、加关键点扰动、多个分类器投票。它们有时能改善局部结果但在验证集上的整体收益有限最终没有继续堆这些模块。五、成绩单正确识别、误判和拒识一起看先看固定三分法选出来的 82 维模型。测试集中共有 87 张四手势图模型正确接受56 张错误接受7 张其余24 张拒识另外 12 张无手图全部拒识。在最新的 T1 Pro 真机手势中正确接受34/47。再看后续做的按输入来源路由。把前面保存的同一批图片重新离线回放T1 Pro 真机44/47正确接受公开测试35/40正确接受合计79/87另外有 6 张误判、2 张拒识无手 12 张全部拒识。图 4两种方案在相同测试图上的结果。绿色为正确接受红色为误判灰色为拒识右侧显示正确数与全分母比例。测试切片82 维 LR固定训练来源路由离线优化T1 Pro 真机47 张34/4744/47公开图片40 张22/4035/40四手势合计87 张56/8779/87无手背景12 张12/12 拒识12/12 拒识怎样理解这两组数据固定训练模型的参数按 Train / Validation 选定后评估来源路由是在排查既有图片时逐步开发出来的79/87是这批图片的回顾性回放成绩。图片中的姿势标签主要来自采集时的界面提示部分测试照片此前也参与过方法排查。我们用这组数据比较方案不把它当成新用户、新场景的上线准确率。另外还有一轮很值得留下的“差成绩”第一轮真机 63 张图在后来的路由流程下也只有13 张正确、1 张误判、49 张拒识。当镜头里根本没有完整的手时后面的分类器很难弥补前端丢失的信息。六、真机开发的三个小经验先看相机再看模型。当检测器输出NoHand先打开右目图看看目标是不是在视野里。花十秒确认画面往往比反复调整网络参数更快。手离开后要让跟踪器学会放手。一次五阶段实时测试中手已移开旧 ROI 却短暂把衣物背景当成了手。我们在后续回放中加入“小得异常的手部框直接拒绝并清除追踪锚点”的处理避免它一路沿着错误位置跟踪下去。换一轮照片比在原来的照片上多跑几遍更重要。早期曾出现训练图全部正确、换个采集时段就明显下降的情况。按会话保留数据再分别看检出、误判和拒识能更快判断问题出在数据还是模型。此外我们在真机 JPEG 试验中观察到约1.96 FPS的短时采样处理速率。对于这样一个原型这足以做可视化调试如果以后要做连续交互还需要专门考虑端到端延迟与姿势切换。七、复现这次实验先从已有照片跑起本机已经保留训练划分清单、模型、原始采集和两条识别路径。下面的命令只读取本地图片# T1 Pro 的真实连续右目抓拍python t1pro_optimized_source_router.py --mode robot --directoryD:\T1ProDev\gesture_live_runs\live_20261027_193102--temporal# 独立的公开静态测试图片python t1pro_optimized_source_router.py --mode photo --directoryD:\T1ProDev\benchmark_dataset\test--temporal使用前帧手部位置只适合按时间连续采集的画面。train.csv、val.csv、test.csv和完整测试结果位于D:\T1ProDev\gesture_fixed_split_20261027。要复用基础的 SDK 连接和抓图代码可以参考 AtomGitt1-pro-sdk-demos本次训练图片和实验脚本存放在本机项目目录。写在最后这次做 T1 Pro 手势识别最有收获的反而是一次次“认不出来”。先发现镜头根本没拍到手再发现全图缩放让手指信息变少后来又看到时序 ROI 能找回漏检却也可能把背景误认为手。真正可复用的经验是先把相机、检手、手势判断和拒识拆开每一步都留下原图与结果。这样不管下一次换成别的摄像头还是增加新的手势都知道该从哪里开始检查。本文阶段先把视觉识别与结果展示跑通相关开发文档和社区资源可以从启元机器人开发者社区继续查阅。资料与代码启元 T1 Pro 产品资料 · 开发者工具下载 · AtomGit SDK 示例