1、课程导入：学习目标、项目总览、所需硬件与软件环境、课程适用人群

欢迎来到《ESP32环境感知项目》系列课程的第一章。本章作为整个项目的起点，将为你勾勒出完整的学习地图。我们不会直接进入代码或接线，而是先回答三个关键问题：这门课要带你完成什么？你将使用哪些工具？以及这门课是否适合你？环境感知是物联网（IoT）中最具落地价值的应用场景之一，而ESP32凭借其低廉的成本、双核处理能力、内置Wi-Fi/蓝牙以及充足的GPIO资源，成为了实现本地智能感知的理想平台。在本章中，你将清晰地看到从“原始传感器数据”到“本地TinyML决策”的完整技术链路，并了解我们为何选择特定的硬件组合与软件框架。

上图展示了本项目的核心架构。你可以看到，数据流从左侧的传感器（感知层）进入ESP32主控，经过特征提取后，在本地完成TinyML推理，最终驱动输出设备。整个过程不依赖外部服务器，这既是本项目的技术亮点，也是“边缘计算”思想的体现。接下来，我们将逐一拆解每个环节的具体内容。

1.1 学习目标：从零构建一个本地智能感知节点

本课程的学习目标并非仅仅“点亮一个传感器”或“跑通一段示例代码”，而是希望你能够独立完成一个具备实用价值的环境感知节点。具体而言，完成本课程后，你将具备以下能力：

• 硬件层面：能够正确连接DHT22温湿度传感器（单总线协议）和LD2410人体存在传感器（UART协议）到ESP32，并理解其电气特性与数据手册中的关键参数。
• 驱动开发层面：能够使用ESP-IDF或Arduino框架编写稳定的传感器驱动，处理时序问题、数据校验和异常重试机制。
• 数据处理层面：能够对原始传感器数据进行滤波（如滑动平均、中值滤波）、归一化和特征提取，为机器学习模型准备干净的输入张量。
• TinyML层面：能够将一个训练好的Keras模型（如一个简单的全连接网络或1D-CNN）转换为TensorFlow Lite格式，并部署到ESP32上执行推理，实现人体存在/温湿度异常等分类或回归任务。
• 系统集成层面：能够使用FreeRTOS任务管理不同传感器数据的采集频率，并通过队列或事件组实现任务间通信，最终将结果输出到OLED屏幕或通过串口发送。

1.2 项目总览：三层架构与功能拆解

本项目名为“ESP32环境感知节点”，其功能定位是：实时监测环境温湿度，并准确判断室内是否有人存在，同时通过本地TinyML模型对“有人/无人”状态进行智能确认，避免误报。 整个项目分为三个逻辑层次，每个层次都有明确的输入、处理和输出。

层次	核心组件	输入	处理逻辑	输出
感知层	DHT22、LD2410	温湿度模拟信号、毫米波反射信号	信号调理、模数转换、数据帧解析	数字化的温度值（℃）、湿度值（%RH）、人体存在状态（0/1）及运动/静止信号
主控层	ESP32-S3	感知层输出的原始数据	FreeRTOS任务调度、数据滤波、特征拼接（如过去10秒的温度变化率、人体信号强度）	固定长度的特征向量（例如1×8的浮点数组）
边缘智能层	TFLite Micro	特征向量	加载预训练模型，执行矩阵乘法和激活函数运算	分类结果（有人/无人）及置信度分数

在课程推进过程中，我们会按照“先感知层，再主控层，最后智能层”的顺序逐步搭建。每一章都会在前一章的基础上增加新的功能模块，最终形成一个完整的、可独立运行的项目。值得注意的是，LD2410传感器本身具备一定的存在判断能力，但我们的TinyML模型将融合温湿度变化率（例如人体呼吸带来的微小温升）来进一步降低误报率，这是本项目的差异化亮点。

1.3 所需硬件与软件环境：清单与选型理由

为了确保学习过程顺利，我们推荐以下硬件配置。虽然部分硬件有替代方案，但为了与课程中的代码和接线图完全匹配，建议尽量使用相同型号。

硬件清单

• 主控板：ESP32-S3-DevKitC-1（或任意带有USB-UART桥接的ESP32-S3开发板）。选择S3而非经典ESP32，是因为其拥有更好的AI加速指令（向量指令）和更大的SRAM（512KB），对TinyML推理更友好。
• 温湿度传感器：DHT22（又称AM2302）。精度为±0.5℃，湿度±2%RH，测量范围覆盖日常环境。注意：DHT22为单总线协议，对时序要求严格，适合学习底层驱动。
• 人体存在传感器：LD2410（24GHz毫米波雷达模块）。它通过UART输出目标存在状态、运动能量和静止能量。相比PIR红外传感器，它不受热源干扰，且能检测静止人体。
• 显示与交互：0.96寸I2C接口OLED（SSD1306），用于显示实时数据与推理结果；一个无源蜂鸣器（可选），用于本地报警提示。
• 辅助元件：面包板、杜邦线若干、10kΩ电阻（用于DHT22上拉）、5V/3.3V电源（开发板USB供电即可）。

软件环境

我们推荐使用ESP-IDF v5.x作为主开发框架，因为它提供了更精细的FreeRTOS控制和底层驱动接口。同时，为了降低初学者的门槛，部分章节（尤其是TinyML部署）会提供Arduino框架的兼容示例。你需要准备以下软件工具：

1. ESP-IDF：乐鑫官方物联网开发框架，包含丰富的驱动库和构建工具。安装方法参考官方文档（v5.1及以上版本）。
2. Python 3.8+：用于训练TinyML模型、转换模型格式以及运行辅助脚本。
3. TensorFlow 2.x：用于构建和训练模型，并导出为TensorFlow Lite格式。
4. 串口调试工具：如PuTTY、minicom或VS Code的Serial Monitor插件，用于查看日志输出。
5. Git：用于版本管理和获取课程示例代码。

1.4 课程适用人群：你需要具备哪些基础？

本课程定位为中级进阶课程，但并非高不可攀。我们假设你具备以下基础，如果某些方面有所欠缺，建议先补充相关知识：

• 编程基础：熟悉C语言或C++的基本语法（指针、结构体、函数回调）。如果你只熟悉Python，也不用担心，课程中会提供详细的代码注释和逻辑讲解，但你需要额外花时间熟悉C语言的内存管理概念。
• 电子基础：了解面包板的使用方法，能看懂简单的电路原理图（VCC、GND、信号线），知道什么是上拉电阻和I2C/UART通信协议的基本概念。
• 机器学习基础（可选但推荐）：了解什么是特征、标签、训练集和测试集。即使没有实际训练过模型，只要理解“输入-输出”的映射关系，就能跟上TinyML部署的节奏。

如果你是一名正在学习物联网专业的学生、一名希望将AI能力落地到硬件产品的创客，或者一名对边缘计算感兴趣的嵌入式工程师，这门课都非常适合你。课程中会涉及大量的实战调试和排错过程，这些经验将直接迁移到你的实际工作中。

1.5 案例拆解：一个典型的“无人值守机房”监测场景

为了让你更直观地理解本项目的价值，我们来看一个实际部署场景。假设某数据中心需要对机房环境进行远程监控，但又不希望部署昂贵的工业级传感器。传统方案是使用带有云端的智能传感器，但存在数据延迟和隐私风险。我们使用本项目的方案进行改造：

场景约束：机房面积约20平方米，要求检测到人员闯入（即使该人员静止不动），同时监测服务器区域的温湿度变化。网络条件有限，无法保证稳定的Wi-Fi连接。

初始现象：使用单一PIR传感器时，如果入侵者保持静止，系统无法触发报警。此外，空调故障导致温度缓慢上升，但未达到阈值，无法提前预警。

我们的方案：

1. 使用LD2410雷达传感器，其“静止能量”输出可以感知静止人体。
2. 使用DHT22每5秒采集一次温湿度，并计算过去1分钟的温度变化斜率。如果斜率持续为正且超过0.1℃/分钟，则判定为异常升温。
3. 将“人体存在状态”、“运动能量”、“静止能量”、“温度变化率”四个特征输入一个简单的TinyML分类器（一个两层全连接网络，参数量约200个），输出“正常/有人闯入/温度异常”三分类结果。

关键数据与调试过程：在初始测试中，我们发现LD2410在无人环境下偶尔会输出“有人”的误报（由于电磁干扰）。通过串口日志分析，发现其“运动能量”值在0-5之间波动，而“静止能量”在0-3之间。我们决定在特征工程中，将这两个值进行滑动平均滤波（窗口大小为10），并增加一个“持续存在时间”计数器。经过调整后，误报率从每小时2次降低到每48小时1次。

结果对比：部署后，系统成功在3次模拟闯入测试中全部报警（包括一次静止站立测试），并在空调故障演练中提前15分钟发出温度异常预警。相比传统方案，成本降低了约60%，且响应时间从云端的2-3秒缩短到本地的50毫秒。

复盘经验：这个案例告诉我们，传感器原始数据往往带有噪声，不能直接作为模型输入。特征工程（滤波、变化率、持续时间）是提升TinyML模型鲁棒性的关键。同时，本地推理带来的低延迟优势在安防场景中至关重要。

1.6 常见误区与总结复盘

在开始动手之前，我们先指出几个初学者容易踩的坑，这些经验将贯穿整个课程：

• 误区一：忽视电源稳定性。ESP32在开启Wi-Fi时电流峰值可达500mA，如果使用劣质USB线或供电不足，会导致传感器读数异常或系统重启。建议使用带屏蔽层的USB线，并尽量使用独立5V电源为传感器供电。
• 误区二：混淆逻辑电平。LD2410的UART电平为3.3V，但部分雷达模块的VCC需要5V供电。务必确认模块的VCC和TX/RX电平匹配，否则可能损坏GPIO口。
• 误区三：TinyML模型“越大越好”。ESP32-S3虽然有512KB SRAM，但TFLite Micro运行时需要占用约100KB，模型权重和中间张量必须精打细算。我们课程中会教你如何量化模型（从FP32到INT8），将模型大小压缩4倍，而精度损失控制在1%以内。
• 误区四：忽略FreeRTOS的任务栈大小。如果某个任务使用了较大的局部变量或递归调用，会导致栈溢出，系统会不断重启。我们会在调试章节教你如何通过uxTaskGetStackHighWaterMark()检查栈余量。