在 PC 上 pip install mediapipe 五分钟就能跑起来的手势识别搬到一块没有 Python、没有 GPU 生态的 RTOS 车载端侧芯片上要经历什么这是一次真实的移植记录——两个模型的接力、一条全硬件的数据通路以及那些文档里永远不会写的坑。本文记录把 Google MediaPipe 手势识别移植到车载端侧芯片上的完整过程。一、手势识别到底在识别什么1.1 手势识别用到的模型一开始我以为手势识别就是一个模型拆开 .task 包才发现是两个模型接力真正的是手势识别 手掌检测 关键点检测 手势分类3 个模型。本文关注前 2 个。手掌检测在小图192×192上跑快关键点回归只处理裁剪后的小区域准。代价是两个模型之间需要一段“胶水逻辑”——裁剪、旋转、再把 21 个点映射回原图。移植的主要工作量主要就是这些胶水代码。1.2 认识模型文件从下载到运行模型文件会以好几种格式出现新手很容易混淆格式含义与定位特性.taskMediaPipe 全家桶包本质是 Zip 压缩包含模型 图配置Python 端一键加载但脱离 MediaPipe 框架后需解包使用.tfliteTensorFlow Lite 格式移动端/嵌入式部署起点包含单个模型的权重与计算图是转换的源头.onnxOpen Neural Network Exchange通用中间交换格式各推理引擎板载推理引擎、NPU SDK 等的中转站.engine / .so端侧引擎私有格式经算子融合与硬件优化强绑定硬件架构x86 上转出的引擎无法在 Target 板子上运行二、开发环境X86 开发机跑原版 MediaPipe拿到“标准答案”ground truth后面所有移植结果都跟它对比。车载 SoC最终运行环境。没有 pip、没有 conda一切都要用 C 从零搭。原则先验证图片再验证视频在 target 上验证也一样。X86 上实现手部关键点识别比较简单用官方 Python 接口就能跑出 ground truth。三、Porting 实录从“能跑”到“跑对”的关卡破局端侧 porting 主要工作模型格式转换.tflite - .onnx - .engine/.soC 实现端侧推理模型、视频解码、显示框架等端侧性能验证真正的挑战开始于模型转换完成之后。以下记录有代表性坑点1. 手掌检测模型输出坐标不对前文说过.task 包里自带一个手掌检测模型hand_detector.tflite——解包出来转成 ONNX单独喂给推理引擎输出的数值完全不对检测框坐标动辄几千远超正常的 [0,1] 范围。换归一化、换解码公式、换坐标顺序全试了一遍都对不上。对比之下同样从这个包里解出来的关键点模型hand_landmarks_detector.tflite就很正常。这说明不是“打开方式”的问题而是这个手掌检测模型本身特殊——推测它是在训练/导出时被预做了某种变换数值被预先放大了约 192 倍依赖 MediaPipe 框架内部的某个环节还原脱离全家桶单独跑中间那层“魔法”就断了。解决办法使用 Google 同时提供独立发布的同用途模型palm_detection_lite.tflite它就是为单独部署设计的输出是标准的 [0,1] 坐标。换用它后解码一次通过。2. 关键点模型输入不识别同样一张图喂给模型PC 上的框架会帮你做好所有预处理自己写 C 后预处理必须逐字节对齐。我遇到的第一个问题是 palm 检测模型完全检测不到手——最终定位到归一化方式手掌检测模型期望输入是[0,1]范围像素值除以 255关键点模型期望输入是[-1,1]范围像素值除以 127.5 再减 12 个模型的输入/输出不匹配用错任何一个输出的就是噪声。类似的坑还有坐标顺序x 在前还是 y 在前、bbox 解码方式线性还是指数——这些差异官方文档没有集中说明只能对着输出数值一点点反推。3. 手掌关键点偏移回忆第一节的接力结构手掌检测输出的矩形框要用来裁剪图像模型输出的 21 个点又要映射回原图。这中间有旋转、缩放、平移三重变换全部手写。遇到问题是所有点都“像个手”但整体偏移——debug 数日后发现是裁剪时的旋转方向和坐标映射时的旋转方向差了一个正负号。小旋转角度下误差不明显3 度时几乎看不出大角度下直接把腕点翻到手掌对面。4. 视频显示不正常——只能偶尔看到正常输出图片模式跑通后升级到视频流接入了 SoC 的硬件解码器1080p 视频解码只要 0.5 毫秒/帧性能无忧。然后出现了本期最离奇的 bug画面大部分时间是灰的每隔几秒闪现一帧正常画面。这个 Bug 隐藏比较深最终用远程 GDB 找到了真凶——回调函数的返回值解码器框架会问应用“你准备了几个缓冲区给我存放参考帧”我初始化写死了返回 1于是解码器认为只有一个缓冲区可用每一帧都写到同一块内存——后一帧把前一帧P 帧的参考帧覆盖了。P 帧靠参考帧还原画面参考帧没了输出就是一片“中性灰”YUV 全 128只有不依赖参考帧的 I 帧关键帧是正常的——这就解释了“偶尔闪一下”闪的全是关键帧。四、实验结果测试视频1080p/30fps 示例视频dump 第 100 帧结果测试含解码、推理、显示全流程硬件表现运行平台硬件环境每帧耗时 (1080p)帧率特性/瓶颈分析车载端侧芯片RTOS含集成显卡~51.0 ms~19.5 fps硬件解码/CSC 无消耗流水线待优化专用硬件是 SoC 的核心优势视频解码走硬件解码器0.5ms/帧显示走显示引擎的硬件 CSC无需占用 CPU/GPU 算力。性能优化路径19.5 fps 距离 30fps 的瓶颈在于解码与推理的串行等待后续通过将 Decode - Inference 异步流水线化以及 UV 分量拷贝向量化预计突破 30fps。精度接近21 个关键点对比 MediaPipe Ground Truth 的平均坐标误差仅为 0.02归一化坐标视觉效果满足要求。五、总结移植这活说白了就是把 PC 上一个函数调用背后藏着的一整条链在目标板上用 C 再手搓一遍PC 上一个 recognize() 调用背后是预处理、推理、后处理、坐标变换的完整链条移植就是把这条链在目标平台上用 C 重新实现一遍。几条经验沉淀X86 上跑出“标准答案”用于对照“看着差不多”会掩盖系统性偏差。显示问题的根因可能在几行代码之外。一个返回值错误导致的参考帧覆盖表现为显示故障实际在解码器交互层。专用硬件是 SoC 的正确打开方式。能下放给硬件单元的解码、CSC、缩放就不要让 CPU 干。下一步帧率优化然后再加入手势分类模型区分“赞/握拳/比心”跑通后再接入摄像头届时这套流水线将从“回放视频”进化为“看实时世界”。