这两年在国产化终端方向摸爬滚打最难啃的不是应用层逻辑而是硬件落地那一坨事。正好最近做完一个基于 OpenHarmony 的人脸识别终端项目从平台选型、双目模组调试到现场环境适配踩了不少坑把整个过程梳理出来。这篇东西适合正在做智能门禁、人脸考勤、自助终端或者准备把 OpenHarmony 往带屏带摄像头的设备上迁移的工程师。我会尽量把选型逻辑、硬件参数计算、现场问题排查这些平时文档里不写的东西讲透。1. 项目背景与整体方案设计1.1 核心需求一台能“扛住”真实光线环境的人脸终端这个项目的原始需求很直白做一台基于 OpenHarmony 的人脸识别终端用于园区门禁和员工考勤。主控选型、摄像头模组选型、系统裁剪、整机结构、现场安装调优整个链条都要自己走一遍。很多人以为做人脸终端就是把摄像头接到开发板上跑个开源识别算法就完事。实际完全不是这样。人脸终端和手机人脸解锁最大的区别在于环境不可控。手机摄像头有厂商深度调优使用场景相对固定而终端设备要面对逆光、暗光、强红外干扰、雨雾、太阳直射等乱七八糟的情况而且 7x24 小时不停机硬件可靠性要求完全不同。项目启动时我拆解了四个核心需求维度系统底座必须跑 OpenHarmony满足国产化需求后续要考虑鸿蒙生态的分布式能力。系统要能裁剪去掉不需要的子系统保证启动速度和稳定性。识别性能0.5 米到 1.5 米范围内能快速抓脸、提取特征、比对返回整体识别耗时不超过 500ms。活体检测必须支持防照片、防屏幕翻拍。环境适应性室内外都能用逆光、暗光下不能罢工户外场景要防尘防水尤其要保证人脸区域曝光正常。硬件可量产性不是做个开发板 demo而是要能批量出货。器件选型要考虑供货周期和成本结构件要能配合散热、防水、防雾。1.2 整体架构RK3588 双目 IR 模组 OpenHarmony 4.0硬件平台最终确定为RK3588 双目 IR 可见光模组。整个系统框图大致是RGB 摄像头和 IR 摄像头通过 MIPI CSI 接入 RK3588NPU 跑人脸检测、关键点定位、特征提取和活体判断双目深度数据用于辅助活体和距离感知结果通过 Wi-Fi 或以太网上报后台同时驱动触控屏做人机交互。这里有个值得展开的点为什么用“双目”而不是“单目 结构光”或者“单目 ToF”后面我会专门讲选型逻辑这里先说结论——双目模组在成本、供应链成熟度、OpenHarmony 驱动适配难度上是目前人脸终端最平衡的方案。OpenHarmony 版本选的是 4.0 Release。选这个版本的原因一是 API 相对稳定二是社区里 RK3588 相关 patch 和文档比较多遇到问题能查到资料。系统裁剪方面去掉了大量用不到的模块比如一些纯音频场景的组件保留图形栈、相机框架、AI 框架、网络协议栈。2. 平台选型为什么是 RK3588以及 x86 OpenHarmony 的现状2.1 ARM vs x86人脸终端的算力、功耗与生态博弈最近网上在传“电脑版 x86 OpenHarmony”的话题很多人问为什么人脸终端不直接用 x86 平台。我的回答是现阶段量产级的智能终端设备ARM 架构依然是主流选择x86 OpenHarmony 更适合极客尝鲜和特定 PC 场景直接拿来做人脸终端会遇到不少麻烦。先看算力。人脸识别终端需要的计算量集中在几块图像采集与预处理、人脸检测、关键点定位、特征提取、特征比对、活体判断。以 RK3588 为例它内置 6 TOPS 算力的 NPU跑一个轻量级检测网络和特征提取网络完全够用。如果人脸库在 1 万人以内端侧比对也毫无压力。我做过一个粗略的算力预算给大家参考。假设摄像头输出 1080P 30fps实际人脸检测只需要在 5fps 的抽样帧上跑检测网络输入 320x320单帧推理时间约 15ms特征提取网络输入 112x112单次推理约 8ms活体检测要有深度图参与约 10ms。这样单帧全流程大约 35ms加上图像采集和编解码开销30ms 的预算也够用。整体 NPU 占用率不会超过 60%CPU 只负责调度和业务逻辑系统不会卡顿。再看功耗和散热。RK3588 典型功耗 5W 到 10W配合一块铝制散热片加风扇可以稳定运行。x86 平台哪怕是最低功耗的 N100 之类整板功耗也在 15W 以上对小型化终端来说散热压力大不少。户外场景如果做全密封防水设计功耗越高越难搞。最后看生态。OpenHarmony 的定位是面向物联网和智能终端官方适配的 SoC 里 RK3588 是社区最活跃的之一BSP 和驱动资料齐全。x86 的 OpenHarmony 目前在启动流程、图形栈、驱动兼容性上还在完善阶段很多外设驱动要自己写对于量产项目来说周期不可控。如果产品定位是桌面电脑或者工控机x86 方向值得关注但人脸终端这种嵌入式计算场景还是 ARM 更合适。2.2 RK3588 选型细节接口、NPU 与系统裁剪选定 RK3588 之后硬件设计阶段要重点确认几个点MIPI CSI 接口数量RK3588 有多个 MIPI CSI 接口支持 4-lane 或 2-lane 配置。双目模组一般需要两路 MIPI 输入所以主控至少要有两个可用的 CSI 接口同时要确认和模组的 lane 数匹配。NPU 算子兼容性RK3588 的 NPU 通过 RKNN 工具链转换模型不是所有网络结构都能直接跑。选型时要提前把目标算法模型转换一遍确认算子支持情况。我们试过一些较新的 Transformer 结构人脸模型在 RKNN 上转换就会遇到算子不支持的问题最后还是回到 MobileFaceNet 这一类轻量 CNN。内存与存储人脸识别终端建议 4GB 内存起步。OpenHarmony 图形栈加相机框架比较吃内存4GB 跑起来剩余空间大概 1GB 多如果人脸库很大需要预加载特征还是建议上 8GB。存储用 64GB eMMC 就够系统镜像和算法模型都能放下日志也能留足空间。系统裁剪OpenHarmony 本身包含很多子系统裁剪的目的是减少启动时间和内存占用。我实际裁剪掉了不少纯后端服务组件系统启动时间从原来的 30 多秒压到 15 秒左右。裁剪过程要小心裁过头会导致相机服务起不来或者图形栈异常最好是每一步裁剪后都做一次全功能回归。另外一个很重要的点是内核和驱动适配。OpenHarmony 用的是 Linux 内核大部分外设驱动可以直接移植或复用但相机 sensor 驱动需要根据具体的模组进行调试这部分后面展开讲。3. 双目模组选型与深度感知原理3.1 为什么必须是双目活体检测和距离感知是刚需人脸终端最怕什么一张 A4 纸打印的照片、手机屏幕上的照片、甚至一个 3D 打印的头模。单目摄像头在算法层面可以做一些活体判断比如让用户眨眼、张嘴但体验很差而且现在高清屏幕翻拍已经能骗过一部分动作活体算法。双目方案解决了两个关键问题深度信息通过左右两个摄像头拍摄同一场景计算视差得到深度图。照片和屏幕是平面深度基本一致真实人脸有凹凸起伏深度有明显变化。这个特征非常稳基本不需要用户配合动作。距离感知知道人脸离设备多远可以控制补光强度、判断是否在识别范围内还能防止有人拿照片怼到镜头前面。我用双目摄像头实测过一张打印照片放在镜头前 40cm深度图显示它是一个平整平面活体判断直接拒绝手机屏幕翻拍更明显屏幕本身还有固定频率的条纹噪声。真实人脸在深度图上能看到鼻子、眼睛、脸颊的梯度变化区分度非常高。3.2 双目成像原理视差计算与基线距选择双目深度估计的基本原理是三角测距。两个摄像头光心之间的距离叫基线距用 B 表示目标点 P 在左右图像上的成像位置差叫视差用 d 表示镜头焦距是 f。三者关系满足Z f × B / dZ 就是目标点到相机的距离。从这个公式能看出几个设计要点基线距 B 越大相同视差下的测距精度越高但设备体积也越大。人脸终端一般基线距做 60mm 到 110mm兼顾体积和精度。焦距 f 越长看得越远但视场角会变小。人脸识别的视场角建议在 60 度到 80 度之间过小的话人脸稍微偏一点就出画了。视差 d 是通过特征匹配算出来的图像分辨率越高、纹理越丰富匹配越准。但分辨率太高会拖慢计算速度所以一般 VGA 分辨率就够用深度图不需要太高的分辨率。在我这个项目里双目模组的左右摄像头间距是 75mmRGB 摄像头分辨率 1920x1080IR 摄像头是 1280x720 全局曝光。这个配置在 1.5 米内深度误差可以控制在 2% 以内做人脸活体和距离判断完全够用。3.3 IR 摄像头与 RGB 摄像头双 sensor 协同的取舍很多双目模组是 RGB RGB 或者 IR IR 的组合但我最终选了IR 摄像头 RGB 摄像头的组合方案。为什么IR 摄像头解决暗光问题IR 摄像头搭配 850nm 红外补光灯在完全无可见光的环境下也能拍到清晰的人脸图像。如果两个都是 RGB 摄像头暗光下图像噪点会爆炸人脸检测根本跑不动。RGB 摄像头保留彩色图像人脸特征提取和人脸比对通常使用可见光彩色图像效果更好而且终端需要拍下现场照片作为记录彩色图是必须的。IR 图像本身就是天然的活体信号850nm 红外光下真实人脸皮肤会呈现特定的反射特性照片和屏幕的反射完全不同。这个信号可以作为活体判断的辅助依据。这里有个设计细节要提醒IR 摄像头的 sensor 要选全局曝光Global Shutter而不是卷帘曝光Rolling Shutter。因为补光是主动 IR 光源帧率一般做到 30fps 甚至更高卷帘曝光在运动场景会产生果冻效应人脸稍微一动图像就变形了。全局曝光虽然成本高一些但图像质量稳定得多。RGB 和 IR 两路图像需要做时间同步和空间对齐。时间同步靠硬件触发信号空间对齐靠出厂标定得到内外参。这两个点不做好后期活体算法会出现很多莫名其妙的误判比如一个人正常站立却被判断为照片大概率就是对齐误差太大。4. 现场环境适配从实验室到园区大门的距离4.1 光线是头号敌人逆光、暗光、强红外干扰设备在实验室测得好好的一到现场就翻车十有八九是光线问题。人脸终端现场环境可以简单分成三类室内固定光照比如公司前台、会议室门口通常光线稳定问题不大。室外半开放环境比如园区门岗、地下车库入口存在太阳直射、逆光、夜间无照明等情况这是最麻烦的场景。极端光照交替比如从阴影区突然走到太阳下面摄像头需要快速调整曝光否则人脸会过曝或者欠曝。我在现场踩过的坑主要有这么几个坑一逆光下人脸全黑。终端安装在门禁立柱上下午太阳从人背后照过来摄像头对着太阳方向人脸区域严重欠曝如果不做处理检测率会掉到惨不忍睹。解决办法有三个方向一是选支持宽动态HDR的 sensor多帧合成扩大动态范围二是在结构上做遮阳设计避免阳光直射镜头三是在算法侧做人脸区域曝光补偿检测到人脸后优先保证人脸区域曝光合适。坑二夜间红外补光过曝。IR 补光灯亮度调得太大近距离人脸一片惨白活体算法反而容易误判。补光强度不能一档调到底要做成可调节的根据人脸距离和场景亮度自动调整。我最后用了 PWM 调光方式亮度分 64 级默认 40% 亮度识别距离 0.5 米内降为 20%避免近距过曝。坑三强红外干扰。户外设备旁如果有其他红外光源比如监控补光灯、阳光反射IR 图像会出现横条纹或者亮斑。这个比较难完全避免只能通过选择带窄带滤光片的 IR 摄像头来解决把波段限制在 850nm 附近滤掉其他波长的干扰。4.2 结构安装调试角度、高度与视场角覆盖硬件选型之外安装位置和角度对识别效果的影响非常大。这里分享几个实测数据人脸终端推荐安装高度是人脸中心离地 1.4 米到 1.5 米设备俯仰角 0 到 10 度。这个高度和角度适合多数成年人站立时的人脸位置也照顾到轮椅用户。如果安装得太高摄像头往下俯视角度大人脸严重变形检测率和比对准确率都会下降太低又会被路人遮挡或者照到胸部位置人脸不在视场中心。视场角计算也简单过一遍。假设摄像头水平视场角 70 度在 1 米距离处水平覆盖范围大约是 2 × 1 × tan(35°) ≈ 1.4 米。如果两个人并排站在设备前只要水平距离不超过 1.4 米就都能进入画面。如果现场过道比较窄可以考虑视场角稍小的镜头保证远处也能拍清楚人脸。另外还有一个经常被忽略的细节安装位置要避开正对太阳的方向。如果实在避不开可以考虑给设备加一个遮阳罩或者调整安装角度让阳光不能直射镜头。镜头不直接进光画面里的杂散光和鬼影会少很多。4.3 防尘防水与防雾处理户外使用的终端不可避免要面对灰尘、雨水、雾气。人脸识别终端至少要达到 IP65 等级也就是完全防尘、防水喷射。但防护等级只是结构问题真正影响使用体验的是镜头起雾。镜头起雾的原因通常是设备内部和外部的温差导致水汽在镜片内侧凝结。解决思路有三个结构上做到尽量密封减少水汽进入在设备内放置干燥剂在镜头周围加一圈加热丝通电后让镜片温度略高于露点。实际项目中我们用了前两种方案效果基本够用。防指纹和防污涂层也建议做。户外环境下用户用手指戳屏幕、摸镜头的情况非常多镜片上的指纹会让图像变得模糊。摄像头镜片选型时要确认有没有 AR 增透膜和防污膜会增加一点成本但对使用体验提升很大。5. 硬件工程细节驱动调试、标定与系统集成5.1 MIPI CSI 调试从设备树配置到出图双目模组接入 RK3588 的第一道坎就是 MIPI CSI 调试。很多人以为接上线就能出图实际上光是设备树配置就能折腾一两天。设备树里要配置的内容包括sensor 的 I2C 地址、MIPI lane 数、分辨率、帧率、时钟频率、电源时序。不同 sensor 的寄存器初始化序列还不一样有的上电需要等待稳定时间有的需要先写 PLL 配置再初始化输出。这块调试我的经验是先单路出图再双路同步。先把 RGB 摄像头接上确保单路能稳定出图确认颜色、曝光、帧率正常再接 IR 摄像头。如果两路一起调出了问题很难定位是硬件连接问题还是配置问题。还有一个常见坑MIPI 信号线尽量短线对之间要保持等长差分阻抗控制在 100 欧姆。实际项目中因为结构空间限制摄像头到主板的排线不能太短结果一开始图像有轻微雪花点。后来换了屏蔽更好的同轴排线问题才解决。5.2 双目标定出厂标定 vs 现场标定双目深度计算的准确度完全依赖标定参数。出厂时要标定的内容包括左右摄像头各自的内参焦距、主点、畸变系数、双目的外参相对旋转和平移、IR 和 RGB 之间的对齐关系。标定通常用棋盘格方法拍摄不同角度、不同距离的棋盘格照片用 OpenCV 或者厂商提供的标定工具计算参数。这里有个关键提示标定后模组的结构不能有任何松动。如果结构件受热变形或者螺丝松了标定参数就失效了深度图会出现系统性误差。所以量产时要做结构胶固定或者用金属结构件降低热胀冷缩的影响。现场标定要不要做我的建议是尽量不做。现场环境很难保证标定板的平整度和光照条件做出来的参数可能还不如出厂标定准。如果设备因为运输碰撞导致标定失效直接返厂重标定更靠谱。5.3 系统裁剪与开机优化OpenHarmony 镜像烧进去之后第一件事就是裁剪和优化。我试过的几个有效手段移除不需要的系统组件比如一些输入法、桌面相关的组件在人脸终端场景完全用不到直接裁剪掉。关闭不需要的后台服务OpenHarmony 默认会启动一些后台服务如果不需要就要在配置里禁掉能省下不少内存和 CPU。开机自启动应用终端设备不可能让用户手动去点应用所以要把主界面程序做成开机自启动并且做成 Kiosk 模式防止用户退出应用或者乱改设置。日志策略生产环境不能开全量日志日志太多会卡死系统。我一般只保留业务日志和系统错误日志日志文件按大小自动滚动防止存储写满。性能调优方面人脸识别主流程要常驻内存防止系统杀进程。关键路径上的计算尽量放到 NPU 上CPU 侧只做轻量逻辑。实测优化后整机空闲 CPU 占用率在 15% 左右识别时瞬间峰值不超过 50%系统运行非常流畅。6. 常见问题与排查技巧实录6.1 深度图异常黑屏、噪点、错位这是双目模组调试中最容易遇到的问题我整理了一张排查表现象可能原因排查方法深度图全黑左右图像没有同步检查硬件触发信号是否正常确认 sensor 是否都收到 FSIN 信号深度图大量噪点标定参数不对或 sensor 曝光不一致重新标定检查两路 sensor 曝光时间和增益是否一致人脸边缘深度错位IR 和 RGB 对齐参数不准确检查对齐矩阵确认两个 sensor 相对位置没有变化远距离深度漂移基线距太长或分辨率不足验证测距范围调小目标距离范围室内深度图正常室外异常强红外干扰检查是否在强光/强红外环境下确认滤光片是否有效6.2 识别率波动曝光、姿态与算法参数联动现场识别率有时高有时低排除光线问题后大概率是算法参数和硬件状态没有联动。比如曝光时间变化会影响图像清晰度如果人脸检测和特征提取的输入图像质量不稳定识别率必然波动。一个有效的做法是把摄像头曝光状态反馈给算法层。当检测到人脸区域过暗或者过曝时主动调整曝光参数而不是等自动曝光慢慢收敛。还可以做多帧融合取最清晰的帧做人脸比对虽然会增加一点计算量但识别稳定性提升明显。另外识别阈值不能一刀切。现场环境不同特征相似度分布也不同。我建议做一个现场调试工具实时显示识别分数分布再根据实际误识率和拒识率调整阈值。这个工具在人脸终端联调阶段非常有用。6.3 设备死机与过热工业级应用的稳定性要求人脸终端是 7x24 小时运行的设备死机和过热是绝对不能接受的。RK3588 发热量不小如果散热设计不好长时间运行会触发降频甚至死机。我这边的做法是主板背面贴导热垫连接铝合金外壳发热大的芯片上面加散热片外壳设计成自然对流结构。在户外阳光下使用场景还要考虑外壳本身的太阳辐射热量外壳颜色建议选浅色减少吸热。软件层面可以做温度保护机制温度超过阈值时先降低补光灯亮度再限制 NPU 频率最后才考虑停止识别任务。这样即使极端高温下设备也不会死机只是暂时降低识别帧率。6.4 OpenHarmony 系统级问题相机服务崩溃与内存泄漏OpenHarmony 的相机框架还不像 Android 那么成熟长时间运行偶尔会出现相机服务崩溃的情况。我遇到比较典型的是连续运行 3 到 5 天后相机服务内存占用越来越高最终被系统杀掉人脸识别流程中断。排查下来有两个原因一是 camera 回调里的图像帧没有及时释放存在内存泄漏二是 OpenHarmony 相机框架对长时间连续出流的支持还有 bug。解决办法是写一个守护进程定时检测相机服务状态如果发现异常就自动拉起重启同时在应用层加大对回调帧内存池的复用减少频繁申请释放。另外一个系统级问题是OpenHarmony 的日志系统在长时间运行后会占用大量存储。如果系统分区比较小日志会把存储写满导致各种奇怪问题。一定要配置日志轮转和清理策略。7. 一点收尾经验这个项目做下来我最深的感触是硬件工程和现场环境适配的工作量一点都不比算法和系统开发少。很多人低估了“把一个人脸识别 demo 变成一台能卖到客户现场的设备”这个过程的复杂性尤其是双目模组的选型、标定、现场光线适配这几个环节几乎决定了产品最终能用不能用。如果你也在做类似的项目有几点我可以拍胸脯说平台选型阶段一定要先跑一遍算法模型确认 NPU 转换没问题再定主控否则后期换平台成本高昂双目模组的标定参数一定要固化好结构上要保证长期稳定的相对位置现场环境调试要留足够的时间预算特别是户外场景光线变化带来的问题经常需要反复调。最后说一个实际操作里的小技巧现场做识别测试时不要只在晴天中午测一定要找一天傍晚、找一天阴天、再找一天晴天早上的逆光时段这三个时段的识别效果都稳定了这台设备才算真正能交付。正是这些看似不起眼的细节把实验室设备和工业级产品区分了开来。 
长河君 · 2026/9/8 6:37:35 · 阅读 1.2k 基于OpenHarmony的人脸识别终端硬件落地实践
这两年在国产化终端方向摸爬滚打最难啃的不是应用层逻辑而是硬件落地那一坨事。正好最近做完一个基于 OpenHarmony 的人脸识别终端项目从平台选型、双目模组调试到现场环境适配踩了不少坑把整个过程梳理出来。这篇东西适合正在做智能门禁、人脸考勤、自助终端或者准备把 OpenHarmony 往带屏带摄像头的设备上迁移的工程师。我会尽量把选型逻辑、硬件参数计算、现场问题排查这些平时文档里不写的东西讲透。1. 项目背景与整体方案设计1.1 核心需求一台能“扛住”真实光线环境的人脸终端这个项目的原始需求很直白做一台基于 OpenHarmony 的人脸识别终端用于园区门禁和员工考勤。主控选型、摄像头模组选型、系统裁剪、整机结构、现场安装调优整个链条都要自己走一遍。很多人以为做人脸终端就是把摄像头接到开发板上跑个开源识别算法就完事。实际完全不是这样。人脸终端和手机人脸解锁最大的区别在于环境不可控。手机摄像头有厂商深度调优使用场景相对固定而终端设备要面对逆光、暗光、强红外干扰、雨雾、太阳直射等乱七八糟的情况而且 7x24 小时不停机硬件可靠性要求完全不同。项目启动时我拆解了四个核心需求维度系统底座必须跑 OpenHarmony满足国产化需求后续要考虑鸿蒙生态的分布式能力。系统要能裁剪去掉不需要的子系统保证启动速度和稳定性。识别性能0.5 米到 1.5 米范围内能快速抓脸、提取特征、比对返回整体识别耗时不超过 500ms。活体检测必须支持防照片、防屏幕翻拍。环境适应性室内外都能用逆光、暗光下不能罢工户外场景要防尘防水尤其要保证人脸区域曝光正常。硬件可量产性不是做个开发板 demo而是要能批量出货。器件选型要考虑供货周期和成本结构件要能配合散热、防水、防雾。1.2 整体架构RK3588 双目 IR 模组 OpenHarmony 4.0硬件平台最终确定为RK3588 双目 IR 可见光模组。整个系统框图大致是RGB 摄像头和 IR 摄像头通过 MIPI CSI 接入 RK3588NPU 跑人脸检测、关键点定位、特征提取和活体判断双目深度数据用于辅助活体和距离感知结果通过 Wi-Fi 或以太网上报后台同时驱动触控屏做人机交互。这里有个值得展开的点为什么用“双目”而不是“单目 结构光”或者“单目 ToF”后面我会专门讲选型逻辑这里先说结论——双目模组在成本、供应链成熟度、OpenHarmony 驱动适配难度上是目前人脸终端最平衡的方案。OpenHarmony 版本选的是 4.0 Release。选这个版本的原因一是 API 相对稳定二是社区里 RK3588 相关 patch 和文档比较多遇到问题能查到资料。系统裁剪方面去掉了大量用不到的模块比如一些纯音频场景的组件保留图形栈、相机框架、AI 框架、网络协议栈。2. 平台选型为什么是 RK3588以及 x86 OpenHarmony 的现状2.1 ARM vs x86人脸终端的算力、功耗与生态博弈最近网上在传“电脑版 x86 OpenHarmony”的话题很多人问为什么人脸终端不直接用 x86 平台。我的回答是现阶段量产级的智能终端设备ARM 架构依然是主流选择x86 OpenHarmony 更适合极客尝鲜和特定 PC 场景直接拿来做人脸终端会遇到不少麻烦。先看算力。人脸识别终端需要的计算量集中在几块图像采集与预处理、人脸检测、关键点定位、特征提取、特征比对、活体判断。以 RK3588 为例它内置 6 TOPS 算力的 NPU跑一个轻量级检测网络和特征提取网络完全够用。如果人脸库在 1 万人以内端侧比对也毫无压力。我做过一个粗略的算力预算给大家参考。假设摄像头输出 1080P 30fps实际人脸检测只需要在 5fps 的抽样帧上跑检测网络输入 320x320单帧推理时间约 15ms特征提取网络输入 112x112单次推理约 8ms活体检测要有深度图参与约 10ms。这样单帧全流程大约 35ms加上图像采集和编解码开销30ms 的预算也够用。整体 NPU 占用率不会超过 60%CPU 只负责调度和业务逻辑系统不会卡顿。再看功耗和散热。RK3588 典型功耗 5W 到 10W配合一块铝制散热片加风扇可以稳定运行。x86 平台哪怕是最低功耗的 N100 之类整板功耗也在 15W 以上对小型化终端来说散热压力大不少。户外场景如果做全密封防水设计功耗越高越难搞。最后看生态。OpenHarmony 的定位是面向物联网和智能终端官方适配的 SoC 里 RK3588 是社区最活跃的之一BSP 和驱动资料齐全。x86 的 OpenHarmony 目前在启动流程、图形栈、驱动兼容性上还在完善阶段很多外设驱动要自己写对于量产项目来说周期不可控。如果产品定位是桌面电脑或者工控机x86 方向值得关注但人脸终端这种嵌入式计算场景还是 ARM 更合适。2.2 RK3588 选型细节接口、NPU 与系统裁剪选定 RK3588 之后硬件设计阶段要重点确认几个点MIPI CSI 接口数量RK3588 有多个 MIPI CSI 接口支持 4-lane 或 2-lane 配置。双目模组一般需要两路 MIPI 输入所以主控至少要有两个可用的 CSI 接口同时要确认和模组的 lane 数匹配。NPU 算子兼容性RK3588 的 NPU 通过 RKNN 工具链转换模型不是所有网络结构都能直接跑。选型时要提前把目标算法模型转换一遍确认算子支持情况。我们试过一些较新的 Transformer 结构人脸模型在 RKNN 上转换就会遇到算子不支持的问题最后还是回到 MobileFaceNet 这一类轻量 CNN。内存与存储人脸识别终端建议 4GB 内存起步。OpenHarmony 图形栈加相机框架比较吃内存4GB 跑起来剩余空间大概 1GB 多如果人脸库很大需要预加载特征还是建议上 8GB。存储用 64GB eMMC 就够系统镜像和算法模型都能放下日志也能留足空间。系统裁剪OpenHarmony 本身包含很多子系统裁剪的目的是减少启动时间和内存占用。我实际裁剪掉了不少纯后端服务组件系统启动时间从原来的 30 多秒压到 15 秒左右。裁剪过程要小心裁过头会导致相机服务起不来或者图形栈异常最好是每一步裁剪后都做一次全功能回归。另外一个很重要的点是内核和驱动适配。OpenHarmony 用的是 Linux 内核大部分外设驱动可以直接移植或复用但相机 sensor 驱动需要根据具体的模组进行调试这部分后面展开讲。3. 双目模组选型与深度感知原理3.1 为什么必须是双目活体检测和距离感知是刚需人脸终端最怕什么一张 A4 纸打印的照片、手机屏幕上的照片、甚至一个 3D 打印的头模。单目摄像头在算法层面可以做一些活体判断比如让用户眨眼、张嘴但体验很差而且现在高清屏幕翻拍已经能骗过一部分动作活体算法。双目方案解决了两个关键问题深度信息通过左右两个摄像头拍摄同一场景计算视差得到深度图。照片和屏幕是平面深度基本一致真实人脸有凹凸起伏深度有明显变化。这个特征非常稳基本不需要用户配合动作。距离感知知道人脸离设备多远可以控制补光强度、判断是否在识别范围内还能防止有人拿照片怼到镜头前面。我用双目摄像头实测过一张打印照片放在镜头前 40cm深度图显示它是一个平整平面活体判断直接拒绝手机屏幕翻拍更明显屏幕本身还有固定频率的条纹噪声。真实人脸在深度图上能看到鼻子、眼睛、脸颊的梯度变化区分度非常高。3.2 双目成像原理视差计算与基线距选择双目深度估计的基本原理是三角测距。两个摄像头光心之间的距离叫基线距用 B 表示目标点 P 在左右图像上的成像位置差叫视差用 d 表示镜头焦距是 f。三者关系满足Z f × B / dZ 就是目标点到相机的距离。从这个公式能看出几个设计要点基线距 B 越大相同视差下的测距精度越高但设备体积也越大。人脸终端一般基线距做 60mm 到 110mm兼顾体积和精度。焦距 f 越长看得越远但视场角会变小。人脸识别的视场角建议在 60 度到 80 度之间过小的话人脸稍微偏一点就出画了。视差 d 是通过特征匹配算出来的图像分辨率越高、纹理越丰富匹配越准。但分辨率太高会拖慢计算速度所以一般 VGA 分辨率就够用深度图不需要太高的分辨率。在我这个项目里双目模组的左右摄像头间距是 75mmRGB 摄像头分辨率 1920x1080IR 摄像头是 1280x720 全局曝光。这个配置在 1.5 米内深度误差可以控制在 2% 以内做人脸活体和距离判断完全够用。3.3 IR 摄像头与 RGB 摄像头双 sensor 协同的取舍很多双目模组是 RGB RGB 或者 IR IR 的组合但我最终选了IR 摄像头 RGB 摄像头的组合方案。为什么IR 摄像头解决暗光问题IR 摄像头搭配 850nm 红外补光灯在完全无可见光的环境下也能拍到清晰的人脸图像。如果两个都是 RGB 摄像头暗光下图像噪点会爆炸人脸检测根本跑不动。RGB 摄像头保留彩色图像人脸特征提取和人脸比对通常使用可见光彩色图像效果更好而且终端需要拍下现场照片作为记录彩色图是必须的。IR 图像本身就是天然的活体信号850nm 红外光下真实人脸皮肤会呈现特定的反射特性照片和屏幕的反射完全不同。这个信号可以作为活体判断的辅助依据。这里有个设计细节要提醒IR 摄像头的 sensor 要选全局曝光Global Shutter而不是卷帘曝光Rolling Shutter。因为补光是主动 IR 光源帧率一般做到 30fps 甚至更高卷帘曝光在运动场景会产生果冻效应人脸稍微一动图像就变形了。全局曝光虽然成本高一些但图像质量稳定得多。RGB 和 IR 两路图像需要做时间同步和空间对齐。时间同步靠硬件触发信号空间对齐靠出厂标定得到内外参。这两个点不做好后期活体算法会出现很多莫名其妙的误判比如一个人正常站立却被判断为照片大概率就是对齐误差太大。4. 现场环境适配从实验室到园区大门的距离4.1 光线是头号敌人逆光、暗光、强红外干扰设备在实验室测得好好的一到现场就翻车十有八九是光线问题。人脸终端现场环境可以简单分成三类室内固定光照比如公司前台、会议室门口通常光线稳定问题不大。室外半开放环境比如园区门岗、地下车库入口存在太阳直射、逆光、夜间无照明等情况这是最麻烦的场景。极端光照交替比如从阴影区突然走到太阳下面摄像头需要快速调整曝光否则人脸会过曝或者欠曝。我在现场踩过的坑主要有这么几个坑一逆光下人脸全黑。终端安装在门禁立柱上下午太阳从人背后照过来摄像头对着太阳方向人脸区域严重欠曝如果不做处理检测率会掉到惨不忍睹。解决办法有三个方向一是选支持宽动态HDR的 sensor多帧合成扩大动态范围二是在结构上做遮阳设计避免阳光直射镜头三是在算法侧做人脸区域曝光补偿检测到人脸后优先保证人脸区域曝光合适。坑二夜间红外补光过曝。IR 补光灯亮度调得太大近距离人脸一片惨白活体算法反而容易误判。补光强度不能一档调到底要做成可调节的根据人脸距离和场景亮度自动调整。我最后用了 PWM 调光方式亮度分 64 级默认 40% 亮度识别距离 0.5 米内降为 20%避免近距过曝。坑三强红外干扰。户外设备旁如果有其他红外光源比如监控补光灯、阳光反射IR 图像会出现横条纹或者亮斑。这个比较难完全避免只能通过选择带窄带滤光片的 IR 摄像头来解决把波段限制在 850nm 附近滤掉其他波长的干扰。4.2 结构安装调试角度、高度与视场角覆盖硬件选型之外安装位置和角度对识别效果的影响非常大。这里分享几个实测数据人脸终端推荐安装高度是人脸中心离地 1.4 米到 1.5 米设备俯仰角 0 到 10 度。这个高度和角度适合多数成年人站立时的人脸位置也照顾到轮椅用户。如果安装得太高摄像头往下俯视角度大人脸严重变形检测率和比对准确率都会下降太低又会被路人遮挡或者照到胸部位置人脸不在视场中心。视场角计算也简单过一遍。假设摄像头水平视场角 70 度在 1 米距离处水平覆盖范围大约是 2 × 1 × tan(35°) ≈ 1.4 米。如果两个人并排站在设备前只要水平距离不超过 1.4 米就都能进入画面。如果现场过道比较窄可以考虑视场角稍小的镜头保证远处也能拍清楚人脸。另外还有一个经常被忽略的细节安装位置要避开正对太阳的方向。如果实在避不开可以考虑给设备加一个遮阳罩或者调整安装角度让阳光不能直射镜头。镜头不直接进光画面里的杂散光和鬼影会少很多。4.3 防尘防水与防雾处理户外使用的终端不可避免要面对灰尘、雨水、雾气。人脸识别终端至少要达到 IP65 等级也就是完全防尘、防水喷射。但防护等级只是结构问题真正影响使用体验的是镜头起雾。镜头起雾的原因通常是设备内部和外部的温差导致水汽在镜片内侧凝结。解决思路有三个结构上做到尽量密封减少水汽进入在设备内放置干燥剂在镜头周围加一圈加热丝通电后让镜片温度略高于露点。实际项目中我们用了前两种方案效果基本够用。防指纹和防污涂层也建议做。户外环境下用户用手指戳屏幕、摸镜头的情况非常多镜片上的指纹会让图像变得模糊。摄像头镜片选型时要确认有没有 AR 增透膜和防污膜会增加一点成本但对使用体验提升很大。5. 硬件工程细节驱动调试、标定与系统集成5.1 MIPI CSI 调试从设备树配置到出图双目模组接入 RK3588 的第一道坎就是 MIPI CSI 调试。很多人以为接上线就能出图实际上光是设备树配置就能折腾一两天。设备树里要配置的内容包括sensor 的 I2C 地址、MIPI lane 数、分辨率、帧率、时钟频率、电源时序。不同 sensor 的寄存器初始化序列还不一样有的上电需要等待稳定时间有的需要先写 PLL 配置再初始化输出。这块调试我的经验是先单路出图再双路同步。先把 RGB 摄像头接上确保单路能稳定出图确认颜色、曝光、帧率正常再接 IR 摄像头。如果两路一起调出了问题很难定位是硬件连接问题还是配置问题。还有一个常见坑MIPI 信号线尽量短线对之间要保持等长差分阻抗控制在 100 欧姆。实际项目中因为结构空间限制摄像头到主板的排线不能太短结果一开始图像有轻微雪花点。后来换了屏蔽更好的同轴排线问题才解决。5.2 双目标定出厂标定 vs 现场标定双目深度计算的准确度完全依赖标定参数。出厂时要标定的内容包括左右摄像头各自的内参焦距、主点、畸变系数、双目的外参相对旋转和平移、IR 和 RGB 之间的对齐关系。标定通常用棋盘格方法拍摄不同角度、不同距离的棋盘格照片用 OpenCV 或者厂商提供的标定工具计算参数。这里有个关键提示标定后模组的结构不能有任何松动。如果结构件受热变形或者螺丝松了标定参数就失效了深度图会出现系统性误差。所以量产时要做结构胶固定或者用金属结构件降低热胀冷缩的影响。现场标定要不要做我的建议是尽量不做。现场环境很难保证标定板的平整度和光照条件做出来的参数可能还不如出厂标定准。如果设备因为运输碰撞导致标定失效直接返厂重标定更靠谱。5.3 系统裁剪与开机优化OpenHarmony 镜像烧进去之后第一件事就是裁剪和优化。我试过的几个有效手段移除不需要的系统组件比如一些输入法、桌面相关的组件在人脸终端场景完全用不到直接裁剪掉。关闭不需要的后台服务OpenHarmony 默认会启动一些后台服务如果不需要就要在配置里禁掉能省下不少内存和 CPU。开机自启动应用终端设备不可能让用户手动去点应用所以要把主界面程序做成开机自启动并且做成 Kiosk 模式防止用户退出应用或者乱改设置。日志策略生产环境不能开全量日志日志太多会卡死系统。我一般只保留业务日志和系统错误日志日志文件按大小自动滚动防止存储写满。性能调优方面人脸识别主流程要常驻内存防止系统杀进程。关键路径上的计算尽量放到 NPU 上CPU 侧只做轻量逻辑。实测优化后整机空闲 CPU 占用率在 15% 左右识别时瞬间峰值不超过 50%系统运行非常流畅。6. 常见问题与排查技巧实录6.1 深度图异常黑屏、噪点、错位这是双目模组调试中最容易遇到的问题我整理了一张排查表现象可能原因排查方法深度图全黑左右图像没有同步检查硬件触发信号是否正常确认 sensor 是否都收到 FSIN 信号深度图大量噪点标定参数不对或 sensor 曝光不一致重新标定检查两路 sensor 曝光时间和增益是否一致人脸边缘深度错位IR 和 RGB 对齐参数不准确检查对齐矩阵确认两个 sensor 相对位置没有变化远距离深度漂移基线距太长或分辨率不足验证测距范围调小目标距离范围室内深度图正常室外异常强红外干扰检查是否在强光/强红外环境下确认滤光片是否有效6.2 识别率波动曝光、姿态与算法参数联动现场识别率有时高有时低排除光线问题后大概率是算法参数和硬件状态没有联动。比如曝光时间变化会影响图像清晰度如果人脸检测和特征提取的输入图像质量不稳定识别率必然波动。一个有效的做法是把摄像头曝光状态反馈给算法层。当检测到人脸区域过暗或者过曝时主动调整曝光参数而不是等自动曝光慢慢收敛。还可以做多帧融合取最清晰的帧做人脸比对虽然会增加一点计算量但识别稳定性提升明显。另外识别阈值不能一刀切。现场环境不同特征相似度分布也不同。我建议做一个现场调试工具实时显示识别分数分布再根据实际误识率和拒识率调整阈值。这个工具在人脸终端联调阶段非常有用。6.3 设备死机与过热工业级应用的稳定性要求人脸终端是 7x24 小时运行的设备死机和过热是绝对不能接受的。RK3588 发热量不小如果散热设计不好长时间运行会触发降频甚至死机。我这边的做法是主板背面贴导热垫连接铝合金外壳发热大的芯片上面加散热片外壳设计成自然对流结构。在户外阳光下使用场景还要考虑外壳本身的太阳辐射热量外壳颜色建议选浅色减少吸热。软件层面可以做温度保护机制温度超过阈值时先降低补光灯亮度再限制 NPU 频率最后才考虑停止识别任务。这样即使极端高温下设备也不会死机只是暂时降低识别帧率。6.4 OpenHarmony 系统级问题相机服务崩溃与内存泄漏OpenHarmony 的相机框架还不像 Android 那么成熟长时间运行偶尔会出现相机服务崩溃的情况。我遇到比较典型的是连续运行 3 到 5 天后相机服务内存占用越来越高最终被系统杀掉人脸识别流程中断。排查下来有两个原因一是 camera 回调里的图像帧没有及时释放存在内存泄漏二是 OpenHarmony 相机框架对长时间连续出流的支持还有 bug。解决办法是写一个守护进程定时检测相机服务状态如果发现异常就自动拉起重启同时在应用层加大对回调帧内存池的复用减少频繁申请释放。另外一个系统级问题是OpenHarmony 的日志系统在长时间运行后会占用大量存储。如果系统分区比较小日志会把存储写满导致各种奇怪问题。一定要配置日志轮转和清理策略。7. 一点收尾经验这个项目做下来我最深的感触是硬件工程和现场环境适配的工作量一点都不比算法和系统开发少。很多人低估了“把一个人脸识别 demo 变成一台能卖到客户现场的设备”这个过程的复杂性尤其是双目模组的选型、标定、现场光线适配这几个环节几乎决定了产品最终能用不能用。如果你也在做类似的项目有几点我可以拍胸脯说平台选型阶段一定要先跑一遍算法模型确认 NPU 转换没问题再定主控否则后期换平台成本高昂双目模组的标定参数一定要固化好结构上要保证长期稳定的相对位置现场环境调试要留足够的时间预算特别是户外场景光线变化带来的问题经常需要反复调。最后说一个实际操作里的小技巧现场做识别测试时不要只在晴天中午测一定要找一天傍晚、找一天阴天、再找一天晴天早上的逆光时段这三个时段的识别效果都稳定了这台设备才算真正能交付。正是这些看似不起眼的细节把实验室设备和工业级产品区分了开来。