智慧养老跌倒报警系统
60 GHz 毫米波雷达做初筛状态机，触发后用摄像头跑 96×96 灰度 INT8 小模型做二次确认， 多帧投票判决，在 ESP32-S3 上完成端侧判定——断网可用、图像不出设备。
独立开发端侧 AI雷达 + 视觉ESP32-S3
为什么是「雷达 + 视觉」两级
单一传感器都有硬伤：雷达看不见"是不是人躺着"，摄像头则一直开机费算力、也涉及隐私。 所以做成分级门控：
STEP 1
→
雷达初筛（规则）
LD6002B 逐字节状态机解析，按 Z 轴与姿态变化判定。该用规则的地方不用模型，几乎不耗算力。
STEP 2
→
触发才拍（门控）
只有初筛命中才连拍 3 帧。摄像头平时不工作 —— 省算力，也少碰隐私。
STEP 3
→
视觉复核（模型）
96×96 灰度 INT8 小模型（13 万参数）做二分类。
STEP 4
多帧投票
3 帧达到票数阈值才确认，避免单帧误判直接报警。
- 雷达初筛（规则，不用模型）：LD6002B 通过 UART 持续发帧， 用逐字节状态机解析（8 字节帧头 + 双校验和 + float32 点云）， 按 Z 轴高度与姿态变化做规则判定。该用规则的地方不用模型——这一步几乎不耗算力。
- 视觉复核（模型）：只有初筛触发时，摄像头才连拍 3 帧， JPEG → RGB888 → 灰度缩放 → 96×96 → INT8 量化，跑一个 13 万参数的二分类 CNN。
- 多帧投票判决：3 帧里达到票数阈值才确认，避免单帧误判直接报警。
- 上报告警：Wi-Fi/HTTP 上报事件 + 10 秒周期遥测回流（内存 / RSSI / 运行时长 / 重启原因）。
逐字节状态机的细节（为什么不用"收完整帧再解析"）见 排障案例 3。
数字与测量上下文
每个数字都标了它是怎么测出来的；没测过的一律写"未测量"。
−73.4%
INT8 量化后体积
523,556 B → 139,376 B（3.756×）
−0.24 pp
量化准确率损失
90.1176% → 89.8824%；跌倒召回 91.8182% 不变；425 例测试集只改判 1 例
129,714
模型参数量
96×96 灰度二分类 CNN
78.789 ms
单次
Invoke()⚠️ 独立冒烟工程：160 MHz、黑图输入、不含摄像头采集与网络。不是端到端延迟
50,780 B
Tensor Arena 实测占用
预留 131,072 B（余量 61.3%）；对应固件 397,072 B
2,551 帧
数据集规模
30 个源视频；训练 1,790（21 组）/ 验证 336（4 组）/ 测试 425（5 组），按源视频切分防泄漏
一个我做过的取舍：阈值不用准确率最优的那个
在 425 帧 canonical 测试集上扫了 5 个判决阈值（0.30 / 0.40 / 0.50 / 0.60 / 0.70）：
| 阈值 | 说明 |
|---|---|
| 0.70 | 准确率最高（91.06%） |
| 0.50 | 我选的——跌倒召回 91.82%，比 0.70 更愿意"报" |
| 0.30 / 0.40 | 过于敏感 |
理由：这是养老场景的跌倒报警。漏报（老人摔了没报）的代价远大于误报（报了一次虚警，人工确认即可）。 所以我不选准确率最优，选召回更优。"用哪个指标"本身是个产品决策，不是纯技术问题。
边界与未测量的部分
主动披露
- OTA 只有 fail-safe 那一层：下载/写入/校验失败 → 不动分区表 → 继续跑旧固件。 没有 bootloader 级"新固件启动崩溃自动退回"（回滚开关未启用）。
- 9 个固件版本已归档，但只有 v1.0.1 → v1.6.1 上板验证过，v1.7.0 / v1.8.0 待上板。
- 未测量：功耗、端到端延迟、事件级误报率、跨人跨房间泛化、多频率基准， 以及主固件（300 KB 模型）的推理耗时与 arena 占用。
- 没做过：剪枝 / QAT / 知识蒸馏。
- 模型指标是帧级的，不等于事件级检出率。