说实话我第一次看到Next-Gen Optical Sensors Enhance UV Protection Gesture Recognition这个项目名时脑子里冒出来的问题是UV防护和手势识别这俩东西怎么会放到同一颗传感器里后来把需求拆开一琢磨才发现这个组合逻辑其实很顺——户外场景下用户既想知道现在的紫外线强不强、要不要涂防晒又不想在骑车、跑步、做饭时腾出手去点屏幕。一颗光学传感器同时把这两件事干了这才是下一代真正的意思。这篇文章我不会去复述芯片数据手册而是以我实际做过的一套原型方案为主线把光学传感器如何做UV检测、如何做手势识别、两者怎么共用一颗模块而不互相干扰、以及我从硬件选型到代码实现的完整踩坑过程都写清楚。适合做可穿戴设备、户外电子、智能家居的硬件工程师和嵌入式开发也适合刚接触光学传感器的朋友建立整体认知。1. 需求拆解UV和手势识别为什么会拼到同一颗传感器里1.1 户外场景拉出来的真实刚需以前我们做智能手表环境光传感器只是为了自动调屏幕亮度后来加接近传感器是为了通话时熄屏。但疫情之后户外运动设备的需求明显变了用户要的不再是设备能连手机而是设备能替自己做出判断。防晒就是一个高频场景骑行一小时胳膊晒红才开始后悔没涂防晒霜带孩子去海边根本不知道几点紫外线最强。UV传感器就是来解决这个问题的它负责回答现在紫外线有多大。但问题来了——用户看UV指数需要主动操作手表这类的穿戴设备屏幕越小操作成本越高。这时候手势识别的价值就体现出来了手指在传感器上方一扫UV指数直接弹出来再扫一次收起。整个过程不需要按键、不需要找屏幕上的菜单、甚至不需要另一只手。这个交互是无感的比语音唤醒更适合公共场合。我当时验证这个逻辑时特意做了一组测试在骑行状态下戴手表看UV指数用按键需要2秒左右眼睛还要离开路面用手势扫一下只要0.3秒视线几乎不离开前方。这个体验差距直接决定了产品形态——集成手势识别的UV检测传感器不是炫技而是把防晒提醒从一个低频功能变成高频刚需。1.2 单芯片多通道背后的系统考量既然UV和手势识别都有需求为什么非要用一颗传感器而不是两颗独立的第一是光学窗口。可穿戴设备的表壳上每开一个孔都要考虑防水、结构强度、外观一致性。开两个孔就多一倍的漏水风险和维护成本。如果两颗传感器做在同一个模组里、共享一个光学窗口区域结构上就简单很多——一个2.5mm左右的圆孔既能透过UV光又能让红外手势模块工作。第二是功耗和时序协同。独立的两颗传感器各跑各的MCU得同时维护两套中断和数据流。集成方案内部可以做分时调度——手势识别在低功耗接近检测模式下休眠UV传感器以固定周期采样当检测到用户手扫过时才唤醒手势模块。这比让两颗传感器各自全速跑要省电得多。第三是成本和PCB面积。单颗多通道芯片比两颗单功能芯片的总成本要低而且I2C地址只需要一个BOM更简单贴片良率也更高。尤其对于手环这类空间极其紧张的产品少一个器件就少一堆布局烦恼。当然这套逻辑放到今天也要接受一个现实市面上成熟的UV手势单芯片确实不多更多是系统级集成也就是把一颗UV传感器和一颗手势传感器封装在同一个模组里对外用同一根I2C总线输出。我在后面实操部分采用的也是这个思路从产品角度看这并不影响达成项目标题里的下一代体验。1.3 增强不是噱头数据层面的融合价值标题里的Enhance很容易被当成营销词但实际做下来我认为这个增强至少体现在两个层面。第一层是交互增强。传统UV检测设备比如紫外线监测贴片是看数字的逻辑你凑过去看屏幕上的UV指数自己判断要不要防晒。集成手势识别后用户不再需要读数据扫一下就能听到当前紫外线指数6建议涂SPF30以上防晒霜的语音提示或者自动调整智能窗帘和穿戴设备屏显。人机交互从视觉阅读变成了动作指令。第二层是数据联动增强。UV数据和手势事件的组合可以做不少事连续检测到用户频繁扫手而UV指数又偏高说明用户对防晒提醒焦虑系统可以自动把提醒阈值调低右手扫过是查看UV左手扫过是切换防晒提醒开关——这种基于场景的差异化响应是两套独立传感器方案很难玩出来的。我甚至在原型机里实现过一个小功能用手势画圈切换防晒霜涂抹进度记录这算是把光学传感真正融入了用户健康管理闭环。2. 核心原理UV检测和手势识别到底怎么工作2.1 UV检测测的不是亮度是剂量紫外线传感器本质上是一个对紫外波段敏感的光电二极管。光照射在PN结上产生光电流电流大小正比于光强。但现代UV传感器不是简单地测个电压它需要解决三个问题波段选择性、角度响应和剂量换算。波段问题很关键。紫外线按波长分为UVA315~400nm、UVB280~315nm和UVC100~280nm。大气层基本把UVC吸收干净了到地面的主要是UVA和少量UVB。UVA穿透皮肤真皮层导致光老化UVB主要作用于表皮导致晒伤。皮肤红斑效应最大的波段在UVB附近所以在评估晒不晒伤时要给UVB更高的权重。传感器厂商的做法是在光电二极管表面集成光学滤光片让某一路对UVA敏感、另一路对UVB敏感然后用两路读数的加权和来估算紫外线指数UV IndexUVI。UVI的计算公式在气象学里是红斑加权辐照度单位mW/m²除以25得到一个通常在0~11之间的数值。工程上我们简化处理读UVA和UVB两路ADC原始值通过标定系数转换成辐照度再按大致比例加权换算成UVI。紫外线传感器的角度响应很容易被新手忽略。从头顶直射的紫外线和斜射到手腕的紫外线对皮肤的实际影响不同传感器应该模拟皮肤表面的接收特性。理想的传感器应遵循余弦响应——即响应正比于入射角度的余弦值。很多UV传感器模组顶部会加一个半球形扩散器cosine diffuser目的就是把各个角度的光均匀化后投射到光电二极管上。如果你做产品时把传感器藏在普通玻璃窗后面、不加扩散设计读到的UVI会明显偏低尤其在高角度太阳光下误差能到30%以上。此外还有温度漂移。硅基光电二极管的暗电流和响应度随温度变化户外设备从冷气房到烈日下温差可能超过40度。所以好的UV传感器比如VEML6075内部会做温度补偿。如果你的选型没有内置补偿代码里就要加查表修正。2.2 手势识别从红外反射到轨迹分类手势识别用的也是光学原理只是波段换到了红外通常850nm或940nm。模块内部集成一个红外发光管IR LED和若干光电二极管。红外光从LED发出照射到手指等物体上再反射回来被光电二极管接收处理器根据反射光的强度、时间差、以及空间分布来判断手势。要细分的话目前常见的有三条技术路线。第一条是反射强度阵列代表产品是APDS-9960。它在红外LED周围布置了四个光电二极管上、下、左、右手指滑过时四个方向的反射强度变化先后顺序不同芯片通过比较这些变化来判断UP、DOWN、LEFT、RIGHT四个方向的手势。优点是功耗低、成本低缺点是检测距离短一般10cm以内且容易受环境光干扰。第二条是飞行时间ToF代表产品是VL53L0X。它通过测量红外光发射和接收之间的相位差计算距离能获得毫米级的距离信息。单点ToF只能做接近检测和简单的hover手势如果做成ToF阵列比如VL53L5CX的8x8阵列已经可以识别静态手势和手部轨迹了这就是当前手机隔空手势的主流方案。第三条是3D结构光或激光扫描精度最高但成本和功耗也最高主要用于高端AR眼镜。在UV手势这个项目里我们用的是一条兼顾成本和功耗的中间路线手势传感器平时工作在低功耗接近检测模式只判断有没有东西靠近。一旦靠近就切换到完整的四通道手势模式用MEMS算法识别滑动方向。这个两级唤醒思路对上手需求非常有效因为用户抬手看UV指数在时间上是很短促的动作让传感器全时保持高功耗手势识别是巨大的浪费。2.3 一颗传感器里如何互不干扰把UV检测和红外手势放在同一个模组最麻烦的问题就是串扰。红外LED发出的光可能直接漏到UV光电二极管上UV光电二极管也可能被阳光里的红外分量干扰。我见过一个DIY方案手势模组一启动UV读数立刻跳变原因就是PCB内部漏光。解决手段有三个层面。第一是波长隔离。UV传感器只对280~400nm波段敏感红外波长在850nm以上理论上不会直接影响UV读数但反向就麻烦了——红外LED附近的光电二极管对可见光和近红外都敏感阳光直射时环境红外很强手势信号会被淹没。所以集成模组的红外通道也要做窄带滤光片只允许LED对应的红外波段通过。第二是时间分片。既然UV和红外在时间上可以错开就让UV采样和手势驱动不同时进行。典型做法以10ms为一个周期前5ms测量UV后关掉UV通道后5ms驱动红外LED并采样红外反射。这比一直同时上电的串扰隔离做得干净。第三是物理遮光。模组内部LED和光电二极管之间要有一堵不透光的挡墙。这堵墙高度不够或者漏光手没靠近时传感器就能收到很强的直接反射导致基线漂移。这也是我反复跟结构工程师强调的点——光学设计不是软件能救回来的。3. 硬件选型与光学结构设计3.1 市面主流传感器怎么选先列一张表我实测过的几个典型器件器件型号功能接口特点适合场景VEML6075UVAUVBI2C内置温度补偿体积小可穿戴UV检测UVIS25UVAUVBI2CST出品内置算法处理车载/工业级UV监测APDS-9960ALS近接手势I2C四通道红外手势经典方案手势交互原型MGC30303D手势I2C/SPIMicrochip能识别12种手势手势控制面板VL53L5CX8x8 ToF阵列I2C毫米级测距可做3D手势高端隔空操作选型时我建议关注四个指标UV通道的响应波长范围、手势检测距离、睡眠功耗、以及光学窗口的允许孔径。VEML6075其实非常适合入门它的UV数据是直接通过I2C读出来的16位原始值不需要自己做模拟放大省掉很多硬件调试工作。手势部分APDS-9960虽然老但资料多、驱动成熟拿来验证交互逻辑最稳。如果想更贴近Next-Gen的感觉可以考虑把手势从四通道升级成ToF单点——用VL53L0X做hover检测配合UV传感器数据逻辑更简单、阳光直射下的可靠性也更高一截。代价是模组体积变大一倍功耗也更高。我做第二版原型时用了VL53L0X确实在户外环境下比APDS-9960稳定很多。3.2 光学窗口与遮光结构细节决定成败硬件选型结束后大多数人以为接下来就是写代码其实不然。传感器能不能正常工作一半取决于周围的光学窗口怎么开。UV通道的窗口材料必须高度透过UVA和UVB。普通玻璃能透大部分UVA但UVB透过率会明显衰减读数会偏低。我实测过三种常见材料普通钠钙玻璃在310nm附近的透过率只有60%左右PMMA有机玻璃在UVB段衰减更厉害真正靠谱的是石英玻璃和某些UV级亚克力。但石英玻璃贵且脆用在手环上不一定划算。更实际的办法是选择透过率足够高的UV级聚碳酸酯并在产品端修正衰减系数。做产品时一定要拿到材料供应商的红外/紫外光谱透过率曲线别只看宣传页写的UV透明。手势通道的窗口要求恰好相反它要尽量让红外通过但对可见光没那么敏感。考虑到红外LED发射角和应用厚度窗口孔径一般建议做到2.5~4mm。窗口内侧和传感器模组之间必须做遮光泡棉或遮光盖防止红外LED的光在壳体内部多次反射后进入接收端。我第一次打样就吃了这个亏——窗口开得太小手指还没贴近壳体边缘反射的红外光已经把接收通道饱和了。还有一个容易忽略的点UV传感器和手势传感器不要离得太远。同一个光学窗口区域如果两颗传感器的敏感区相隔超过2mm手扫过手势窗口时用户会下意识地低头找手势区体验比单独一颗集成的多通道传感器差很多。我在测试机上用激光打标把操作区域圈出来实测用户命中率高了不少。4. 完整实操从驱动到识别逻辑4.1 I2C底层驱动与初始化下面这套流程我在多个项目里复用核心思路是尽量摸清寄存器再上应用层。以VEML6075 APDS-9960组合为例主控用一颗常见的Cortex-M0 MCU就够了。I2C初始化没什么特别的地址分别是VEML6075的0x10和APDS-9960的0x39总线速率跑100kHz这两个器件不支持400kHz。使用VEML6075时首先要确保上电后芯片处于正常模式而非待机模式。VEML6075的UV_CONF寄存器地址0x00直接写0x00表示POWER ON积分时间100ms动态范围1。积分时间越长越准但对快速变化的光强响应越慢。户外设备建议用50ms或100ms的折中方案。#include stm32l0xx_hal.h #define VEML6075_ADDR 0x10 #define VEML6075_UV_CONF 0x00 #define VEML6075_UVA_DATA 0x07 #define VEML6075_UVB_DATA 0x09 void veml6075_init(void) { uint8_t conf 0x00; // power on, IT100ms, normal dynamic HAL_I2C_Mem_Write(hi2c1, VEML6075_ADDR, VEML6075_UV_CONF, I2C_MEMADD_SIZE_8BIT, conf, 1, 100); }APDS-9960的初始化更绕一点因为它的寄存器分ALS、近接、手势三块。最省事的写法是把ENABLE寄存器0x80先设置成PON置位然后按需打开WENALS使能、PEN近接使能和GEN手势使能。注意只是把PON设为1芯片就会进入待机要真正开启手势识别需要同时把PON和GEN置1否则读取手势FIFO永远是空。#define APDS9960_ADDR 0x39 #define APDS9960_ENABLE 0x80 #define APDS9960_GCONF1 0xA2 #define APDS9960_GCONF2 0xA3 #define APDS9960_GPENTH 0xA0 #define APDS9960_GEXTH 0xA1 void apds9960_init(void) { uint8_t val; // 1. enable power proximity 便于后续手势 val 0x05; // PON PEN HAL_I2C_Mem_Write(hi2c1, APDS9960_ADDR, APDS9960_ENABLE, I2C_MEMADD_SIZE_8BIT, val, 1, 100); // 2. 手势近接阈值接近检测到手指后才进入手势模式 val 50; HAL_I2C_Mem_Write(hi2c1, APDS9960_ADDR, APDS9960_GPENTH, I2C_MEMADD_SIZE_8BIT, val, 1, 100); val 70; HAL_I2C_Mem_Write(hi2c1, APDS9960_ADDR, APDS9960_GEXTH, I2C_MEMADD_SIZE_8BIT, val, 1, 100); // 3. 手势模式四方向、中速 val 0x40; // GGAIN2x HAL_I2C_Mem_Write(hi2c1, APDS9960_ADDR, APDS9960_GCONF1, I2C_MEMADD_SIZE_8BIT, val, 1, 100); val 0x01; // LED on during gesture, only gesture mode HAL_I2C_Mem_Write(hi2c1, APDS9960_ADDR, APDS9960_GCONF2, I2C_MEMADD_SIZE_8BIT, val, 1, 100); }有一点要提醒APDS-9960的手势FIFO深度是32如果不及时读取数据会溢出。我写的驱动习惯是每2ms轮询一次GSTATUS寄存器0xAF的GVALID位一旦置位就连续读FIFO直到空。4.2 UV数据读取与UV Index换算UV原始数据读起来不复杂UVA_DATA寄存器0x07是16位小端UVB_DATA寄存器0x09也类似。直接读两个字节拼起来就好。uint16_t veml6075_read_uva(void) { uint8_t buf[2]; HAL_I2C_Mem_Read(hi2c1, VEML6075_ADDR, VEML6075_UVA_DATA, I2C_MEMADD_SIZE_8BIT, buf, 2, 100); return (buf[1] 8) | buf[0]; } uint16_t veml6075_read_uvb(void) { uint8_t buf[2]; HAL_I2C_Mem_Read(hi2c1, VEML6075_ADDR, VEML6075_UVB_DATA, I2C_MEMADD_SIZE_8BIT, buf, 2, 100); return (buf[1] 8) | buf[0]; }但原始值不能直接当UVI用。VEML6075数据手册给的推荐公式比较复杂涉及UVA和UVB各自的比例因子和补偿常数。我在工程上把它简化成这样的形式实测在一定范围内误差可以接受float calc_uv_index(uint16_t uva_raw, uint16_t uvb_raw) { // 标定后的经验系数窗口材料变化后需要重新标定 float uva_irr (float)uva_raw * 0.0026f; // 换算到mW/m² 量级 float uvb_irr (float)uvb_raw * 0.0019f; float erythemal uva_irr * 1.0f uvb_irr * 8.0f; // 红斑加权近似 float uvi erythemal / 25.0f; return uvi; }这个公式的1.0f和8.0f是权重近似——UVB对红斑效应的贡献远大于UVA所以给它更高的加权。实际产品绝不能直接用这一套必须在积分球或标准太阳灯下标定。我建议至少做三组标定点阴天UVI 2~3、多云转晴UVI 5~6、正午晴天UVI 10左右然后把标定系数通过查找表存到Flash里。读UV的时机也很讲究。传感器窗口正对天空时读数最高正常佩戴时传感器朝上但手臂角度多变数据会波动。我在原型里做了一件事连续采样10次丢弃最大最小各2次取中间6次的平均值。这样能把佩戴角度变化和手臂抖动的噪声压下去避免UV指数在4和6之间反复跳。4.3 手势数据读取与简单分类APDS-9960的手势读取有一个固定的套路先查GSTATUS的GVALID位再读四个方向的FIFO上、下、左、右分别对应FDATA 0xFC~0xFF最后参考驱动库里的UP/DOWN/LEFT/RIGHT判定算法。核心逻辑是比较两次读到的四个方向数据的变化趋势哪个方向上升得最早、幅度最大就判定为哪个方向。我直接把判定逻辑写得简单一点typedef enum { GESTURE_NONE 0, GESTURE_UP, GESTURE_DOWN, GESTURE_LEFT, GESTURE_RIGHT } gesture_t; gesture_t read_gesture_direction(void) { uint8_t status; uint16_t u, d, l, r; uint8_t fifo_data[4]; uint32_t diff_u 0, diff_d 0, diff_l 0, diff_r 0; static uint16_t prev_u 0, prev_d 0, prev_l 0, prev_r 0; HAL_I2C_Mem_Read(hi2c1, APDS9960_ADDR, 0xAF, I2C_MEMADD_SIZE_8BIT, status, 1, 100); if (!(status 0x01)) return GESTURE_NONE; HAL_I2C_Mem_Read(hi2c1, APDS9960_ADDR, 0xFC, I2C_MEMADD_SIZE_8BIT, fifo_data, 4, 100); u fifo_data[0]; d fifo_data[1]; l fifo_data[2]; r fifo_data[3]; diff_u u - prev_u; diff_d d - prev_d; diff_l l - prev_l; diff_r r - prev_r; prev_u u; prev_d d; prev_l l; prev_r r; if (diff_u diff_d diff_u diff_l diff_u diff_r) return GESTURE_UP; if (diff_d diff_u diff_d diff_l diff_d diff_r) return GESTURE_DOWN; if (diff_l diff_r diff_l diff_u diff_l diff_d) return GESTURE_LEFT; if (diff_r diff_l diff_r diff_u diff_r diff_d) return GESTURE_RIGHT; return GESTURE_NONE; }这段代码最需要注意的是手势方向有滞后性。手指滑过传感器后FIFO里可能连续出现多次方向数据如果不对同一动作去重就会在屏幕上反复触发。我加的防抖策略是判定到一个方向后至少要等200ms且这段时间内不碰FIFO才允许识别下一个手势。这个时间窗口是根据用户自然滑动速度标定的太快太慢都容易误触发。4.4 融合逻辑隔空查看UV指数和防晒提醒有了UV读数和手势识别最难的部分已经过去剩下的是应用层怎么编排。我的建议是设计一个简单的三状态状态机空闲态、UV展示态、提醒设置态。typedef enum { ST_IDLE, ST_SHOW_UV, ST_SETTINGS } app_state_t; void app_task_10ms(void) { static app_state_t state ST_IDLE; static uint32_t idle_count 0; switch (state) { case ST_IDLE: if (read_gesture_direction() GESTURE_LEFT) { float uvi calc_uv_index(veml6075_read_uva(), veml6075_read_uvb()); display_show_uvi(uvi); state ST_SHOW_UV; idle_count 0; } break; case ST_SHOW_UV: if (idle_count 300) { // 3秒无操作自动退出 display_off(); state ST_IDLE; } if (read_gesture_direction() GESTURE_RIGHT) { display_off(); state ST_IDLE; } break; case ST_SETTINGS: // 可以在这里扩展提醒阈值设置、查询历史UV等 break; } }实际做产品时这个状态机会更复杂。我会额外加一层UV阈值自动提醒当UVI超过5且持续超过10分钟设备通过震动或蜂鸣通知用户补涂防晒配合手势滑动确认来消除提醒。有人可能觉得这有点过度设计但防晒涂抹不只是看当下数值更讲究累积暴露量。如果能用手势快速确认已补涂再结合UV累积剂量这套系统才真正称得上增强防护。5. 实测踩坑与排查技巧5.1 UV读数漂移的元凶第一个坑是UV数据在产品里越来越低最后稳定在正常值的三分之一左右。排查半天问题出在光学窗口上——我用的护板是普通PC材料经过两周户外暴晒和频繁擦拭表面出现轻微雾化紫外线透过率大幅下降。PC本身在UVB段透光率就不算高老化后衰减更明显。解决方向有两个材料换成抗UV级高透材料或者在软件里加一个基于使用时间的衰减补偿系数。后者是治标不治本能换材料就换材料。第二个坑是传感器旁边的屏幕漏光。OLED屏幕亮度开到500nit时虽然显示的是绿光但它的光谱里也包含少量紫外成分会被UV传感器误采进去。测试时把屏幕亮度调到最高发现UVI凭空多出0.5~1.0。规避办法是在UV传感器和屏幕之间加金属遮光罩或者把UV传感器放到屏幕背面PCB的另一侧远离显示区域。第三个坑是温漂。低温环境0度以下传感器读数会偏低高温60度以上读数偏高。VEML6075内部有补偿但我手头另一颗更便宜的UV传感器没有实测从25度到60度读数漂了将近18%。解决办法是在固件里放一张温度修正表用NTC读到的壳温查表修正。5.2 阳光下手势识别失效这是手势传感器最典型的户外问题。APDS-9960的红外接收通道在强阳光下饱和手指滑过时反射信号完全淹没在环境光里。我一开始试过提高红外LED的驱动电流效果有限LED电流加大会增加功耗而且雾天/强阳光下仍不理想。后来换了两招。第一招是改用ToF单点传感器VL53L0X因为它用相位差测距对反射光强度不敏感更看重信号有没有回来阳光干扰被大幅抑制。第二招是加一个红外带通滤光片在窗口上只让940nm附近的光通过这样环境红外大部分被滤掉。这招对APDS-9960也有明显改善滤光片戴上后正午太阳下手势识别率从不到50%提升到85%左右。5.3 误触发和漏触发误触发最常见的原因是手势阈值设得太低。GPENTH和GEXTH寄存器控制进入手势模式的阈值如果设的是20手上带着水珠或靠近到5cm就可能误启动手势。我通常建议把进入阈值设在50以上离开阈值设在70以上既不会太灵敏也不至于太迟钝。还有一个细节用户扫手时经常是贴着窗口划过导致红外反射接近饱和判断出的方向不稳定。这个问题要靠算法层解决——不要只看单帧数据的峰值而是累计一个滑动窗口比如连续4帧统计哪一方向上升次数的占比最高。简单多数投票就能滤掉很多抖动。漏触发往往和手势速度和窗口大小有关。窗口孔径太小手指快速划过时在窗口上停留的时间不足传感器采不到足够多的帧。我测试下来孔径3mm左右、手势识别距离5cm是输入体验最舒服的组合。小于3mm快速扫动手势识别率急剧下降。5.4 常见问题速查表现象可能原因排查思路UV读数偏低窗口材料吸收UVB换石英玻璃或UV级PC检查光谱曲线UV读数偏高且波动大接近屏幕漏光加遮光罩调整传感器位置UV读数随温度漂移传感器未做温补加NTC查表修正或换内置温补芯片手势识别在阳光下失灵红外环境光饱和加红外滤光片/升级ToF方案手势方向混乱阈值太低/手贴窗太近提高进入阈值调整光学距离手势频繁误触发没有事件去重增加200ms去抖和状态机限制I2C读不到数据总线地址错/上拉电阻缺失检查地址确保SCL/SDA各接4.7k上拉待机功耗偏高手势传感器一直处于手势模式使用接近检测先唤醒再切手势模式我最后想分享两个小体会第一UV和手势识别这套组合最大的价值不是传感器本身多先进而是它让防护这件事从被动查看变成了主动交互。用户不用再思考我该怎么操作这个设备抬手就知道答案这是设备真正融入生活的方式。第二做这类光学项目硬件和结构设计的优先级一定要排在软件前面。很多问题一旦在光学窗口、材料选型、遮光结构上做对了代码怎么写都通一旦结构错了后面花几倍时间写算法也救不回来。我现在的习惯是先做光学结构评审再让软件工程师动手可以省掉至少三分之一的调试时间。