3、TinyML概述：TinyML定义、边缘设备约束、典型硬件平台（如Arduino Nano 33 BLE Sense、STM32）、模型部署流程

TinyML（微型机器学习）是机器学习与嵌入式物联网系统交叉融合的前沿领域，其核心目标是在功耗受限、计算资源有限、存储空间极小的微控制器（MCU）上直接运行机器学习推理任务。与云端AI依赖高速网络和GPU集群不同，TinyML强调数据在本地采集、本地处理、本地决策，从而彻底解决传统物联网方案中“数据上云—云端计算—结果回传”链路带来的高延迟、高功耗和隐私泄露风险。在跌倒检测这一具体场景中，TinyML的价值尤为突出：跌倒事件通常发生在老年人居家的瞬间，系统必须在毫秒级时间内完成判断并触发告警，任何网络抖动或云端排队都可能导致救援延误。本章将系统阐述TinyML的定义边界、边缘设备的硬性约束、主流硬件平台选型依据，以及从模型训练到嵌入式部署的完整工程链路。

3.1 TinyML定义与技术边界

TinyML并非简单的“在单片机上跑神经网络”，而是一套完整的系统工程方法论。从技术定义上看，TinyML包含三个核心维度：模型维度——模型参数量通常在几十KB到几百KB之间，计算量在几万到几百万次乘加运算（MACs）范围内；硬件维度——目标设备为MCU级别，主频通常在16MHz到480MHz之间，SRAM不超过512KB，Flash不超过2MB；系统维度——强调端侧实时推理、低功耗运行、离线自治能力，以及与传统嵌入式系统的无缝集成。

在跌倒检测场景中，TinyML的技术边界需要进一步明确。一个典型的跌倒检测模型输入为三轴加速度计数据（采样率50Hz，窗口长度2.5秒），即125个采样点×3轴=375个特征值。若采用轻量级决策树模型（深度不超过10层），模型大小可控制在5KB以内；若采用1D-CNN模型（2层卷积+1层全连接），模型大小约为15-30KB。这两种方案在Arduino Nano 33 BLE Sense（主频64MHz，SRAM 256KB）上均可实现实时推理，单次推理延迟可控制在30ms以内。

3.2 边缘设备约束与工程适配

边缘设备的资源约束是TinyML设计的出发点，也是与云端AI最本质的区别。下表从五个关键维度对比了云端AI与TinyML的典型差异，帮助开发者建立清晰的资源预算意识。

针对上述约束，工程适配需要遵循三个核心原则。第一，模型轻量化优先：在跌倒检测中，优先选择决策树、随机森林、逻辑回归等传统机器学习模型，其推理计算量仅为神经网络的1/10到1/100。只有当传统模型准确率无法满足要求（如跌倒与弯腰区分困难）时，才考虑引入1D-CNN或深度可分离卷积网络。第二，量化感知训练：在模型训练阶段就引入量化噪声模拟，使模型权重适应INT8精度表达，避免训练后量化带来的精度骤降。第三，内存复用设计：在嵌入式C代码实现中，使用静态内存分配和缓冲区复用技术，将推理过程中的中间变量控制在最小范围。

3.3 典型硬件平台选型与对比

当前TinyML领域主流的硬件平台包括Arduino系列、STM32系列以及ESP32系列。在跌倒检测应用中，选择平台需要综合考量传感器集成度、算力、功耗和开发生态四个维度。以下对三个最具代表性的平台进行深入对比。

3.3.1 Arduino Nano 33 BLE Sense

该平台搭载nRF52840主控芯片（Cortex-M4F内核，主频64MHz），集成IMU传感器LSM9DS1（三轴加速度计+三轴陀螺仪+三轴磁力计），板载SRAM 256KB，Flash 1MB。其最大优势在于传感器与主控一体化设计，无需外部接线即可直接采集加速度数据，非常适合跌倒检测原型验证。在功耗方面，活跃模式电流约10mA，休眠模式可降至2μA，配合500mAh锂电池可实现约3个月的持续监测（按1%占空比计算）。开发环境使用Arduino IDE，配合TensorFlow Lite Micro库，可实现从模型部署到推理的完整流程。

3.3.2 STM32系列（以STM32L4为例）

STM32L4搭载Cortex-M4F内核，主频80MHz，SRAM 128KB，Flash 512KB，典型功耗在活跃模式下为100μA/MHz。该平台的优势在于丰富的外设接口和成熟的工业级可靠性，适合产品化落地。在跌倒检测场景中，通常需要外接IMU传感器（如BMI160、MPU6050）通过I2C或SPI接口通信。ST官方提供X-CUBE-AI工具链，可将训练好的Keras或PyTorch模型自动转换为STM32优化代码，极大简化部署流程。此外，STM32CubeMX配置工具支持低功耗模式设计，可实现事件驱动的唤醒式检测。

3.3.3 ESP32系列

ESP32搭载双核LX6处理器（主频240MHz），SRAM 520KB，Flash 4MB，集成Wi-Fi和蓝牙。虽然算力更强，但功耗相对较高（活跃模式电流约80mA）。在跌倒检测场景中，ESP32的优势在于可同时实现本地推理和无线告警，适合需要将跌倒事件推送到手机APP或云端的应用场景。然而，其较高的功耗限制了电池供电的续航能力，通常需要搭配深度睡眠模式（电流约10μA）和定时唤醒策略。

3.4 模型部署完整流程

从训练好的模型到MCU上运行，需要经过一条严谨的工程链路。以下以Arduino Nano 33 BLE Sense平台为例，详细阐述跌倒检测模型的部署流程。

3.4.1 模型训练与导出

在PC端使用Python完成模型训练后，需要将模型导出为TensorFlow Lite格式。对于跌倒检测模型，推荐使用tf.keras训练一个1D-CNN或决策树模型，然后通过TFLiteConverter进行转换。关键代码示例如下：

import tensorflow as tf

# 加载训练好的Keras模型
model = tf.keras.models.load_model('fall_detection_model.h5')

# 转换为TFLite格式，使用INT8量化
converter = tf.lite.TFLiteConverter.from_keras_model(model)
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = representative_dataset_gen  # 校准数据集
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
converter.inference_input_type = tf.int8
converter.inference_output_type = tf.int8

tflite_model = converter.convert()

# 保存为C数组，便于嵌入到Arduino代码中
with open('model.h', 'w') as f:
    f.write('const unsigned char model_tflite[] = {')
    for i, byte in enumerate(tflite_model):
        if i % 12 == 0:
            f.write('\n  ')
        f.write(f'0x{byte:02x}, ')
    f.write('\n};\n')

3.4.2 嵌入式工程集成

在Arduino IDE中，需要引入TensorFlow Lite Micro库，并将生成的model.h文件放入工程目录。核心部署代码包括初始化解释器、设置输入张量、执行推理和解析输出四个步骤。以下为跌倒检测推理的核心逻辑：

#include <TensorFlowLite.h>
#include "model.h"

// 全局TFLite解释器
static tflite::MicroInterpreter* interpreter;

void setup() {
  // 初始化IMU传感器
  IMU.begin();
  
  // 加载模型
  static tflite::MicroMutableOpResolver<10> resolver;
  resolver.AddFullyConnected();
  resolver.AddConv2D();
  resolver.AddMaxPool2D();
  resolver.AddSoftmax();
  
  static tflite::MicroInterpreter static_interpreter(
    tflite::GetModel(model_tflite), resolver,
    tensor_arena, kTensorArenaSize);
  interpreter = &static_interpreter;
  
  // 分配张量内存
  interpreter->AllocateTensors();
}

void loop() {
  // 采集2.5秒加速度窗口数据
  float accel_x[125], accel_y[125], accel_z[125];
  collect_accel_window(accel_x, accel_y, accel_z);
  
  // 填充输入张量
  int8_t* input = interpreter->input(0)->data.int8;
  normalize_and_quantize(accel_x, accel_y, accel_z, input);
  
  // 执行推理
  interpreter->Invoke();
  
  // 解析输出（跌倒概率）
  int8_t* output = interpreter->output(0)->data.int8;
  float fall_probability = dequantize(output[1]);
  
  // 阈值融合判断
  if (fall_probability > 0.7) {
    trigger_local_alarm();  // 触发本地蜂鸣器告警
  }
}

3.4.3 阈值融合与告警策略

在实际部署中，单纯依赖模型输出概率往往不够可靠。工程上通常采用模型输出+物理阈值双重判断的融合策略。例如，当模型输出跌倒概率超过0.7且加速度幅值超过2.5g时，才触发告警。这种融合策略可以有效降低误报率。告警方式包括本地蜂鸣器、LED闪烁、可选蓝牙通知等，具体根据应用场景配置。

3.5 案例拆解：从模型到告警的完整闭环

为帮助读者建立整体认知，以下通过一个完整的案例展示TinyML跌倒检测系统的部署全过程。

项目背景与约束：某养老机构需要为独居老人配备跌倒检测设备，要求设备体积小、电池供电、无Wi-Fi环境可用，跌倒检测准确率不低于90%，误报率低于5%。硬件选型为Arduino Nano 33 BLE Sense，电池容量500mAh，目标续航≥2个月。

初始现象与目标：初期使用云端AI方案（4G模块上传数据），实测端到端延迟约2.3秒，功耗高达120mA，且养老院部分区域无4G信号。项目组决定转向TinyML方案，目标将延迟降至100ms以内，平均功耗降至10mA以下。

关键输入数据与参数：采集了5名志愿者共2000组动作样本（800组跌倒、1200组日常活动），采样率50Hz，窗口长度2.5秒。特征工程提取了均值、方差、峰值、信号幅值面积（SMA）等12个时域特征。模型选用随机森林（树数量20棵，最大深度8），训练后准确率94.2%，召回率92.5%。

分析判断过程：将随机森林模型转换为TFLite格式后，模型大小为18.6KB，满足Flash空间要求。但实测推理延迟为85ms，接近100ms上限。进一步分析发现，20棵决策树的串行推理是主要瓶颈。项目组将模型替换为1D-CNN（2层卷积+1层全连接），量化后模型大小12.3KB，推理延迟降至42ms，准确率提升至95.1%。

实际操作步骤：① 使用TensorFlow训练1D-CNN模型；② 进行INT8量化并生成model.h文件；③ 在Arduino IDE中集成TFLite Micro库；④ 编写数据采集、推理和告警逻辑；⑤ 使用串口输出调试信息，验证推理结果与PC端一致；⑥ 进行为期3天的连续运行测试，记录功耗和误报情况。

结果对比与复盘：最终系统平均功耗8.5mA，500mAh电池理论续航约59天，满足2个月目标。实际测试中，跌倒检测延迟78ms（含数据采集50ms+推理28ms），准确率95.1%，误报率3.2%。复盘发现，误报主要发生在老人快速坐下或弯腰捡物场景，后续通过增加陀螺仪数据融合（角速度变化率阈值）将误报率降至1.8%。

3.6 常见误区与总结复盘

在TinyML开发实践中，以下五个误区最为常见，需要开发者特别警惕。

• 误区一：模型越大越准。在MCU上，模型大小与推理延迟、功耗直接相关。一个200KB的模型即使准确率高出2%，但推理延迟增加5倍、功耗增加3倍，在跌倒检测这种实时性要求高的场景中反而不可用。
• 误区二：忽视数据采集的硬件差异。PC端使用的加速度计与Arduino板载的LSM9DS1在噪声特性、量程范围上存在差异。训练数据必须使用目标硬件采集，否则部署后准确率会显著下降。
• 误区三：忽略内存峰值。推理过程中的中间张量（如卷积层的输出特征图）可能占用大量SRAM。一个输入为125×3的1D-CNN，第一层卷积输出特征图可能达到125×16=2000个浮点数，即8KB内存。设计网络结构时必须计算峰值内存占用。
• 误区四：告警策略过于简单。仅依赖模型输出概率触发告警，容易在边缘情况下（如传感器受到撞击）产生误报。应采用“模型概率+物理量阈值+时间持续性”三重判断。
• 误区五：忽视功耗优化。即使模型推理本身功耗很低，如果系统设计为持续采样和推理，总功耗依然很高。应采用中断唤醒、低功耗模式、事件驱动等策略，将平均功耗降至μA级别。