Quartz 4

基于ESP32-C5的无线感知系统

Created: • Updated: 16 min read

基于ESP32-C5的无线感知系统

简历描述

基于 ESP32-C5 的无线感知系统 - C++/嵌入式

  • 构建双 ESP32-C5 架构的 Wi-Fi CSI 感知系统，实现信道状态信息的采集、传输与板载处理
  • 基于 ESP-DSP 库在 MCU 上实现 FFT 与频域特征提取，完成呼吸率估计（MAE = 1.04 bpm）与运动检测（准确率达 95%）
  • 自建数据集并调优采样率，实现模型量化部署，边缘推理延迟控制在 50ms 内，功耗降低约 30%
  • 利用 FreeRTOS 事件循环与回调机制构建多任务处理系统，保障算法实时性与系统稳定性
  • 通过 MQTT 实时上传处理结果，结合 Web 前后端实现可视化监控与交互展示

问题

构建双 ESP32-C5 架构的 Wi-Fi CSI 感知系统，实现信道状态信息的采集、传输与板载处理

  1. 什么是 Wi-Fi CSI？ESP32-C5 是如何获取 CSI 数据的？是否使用了 esp_wifi_set_csi_rx_cb 回调？

    Wi-Fi CSI（Channel State Information，信道状态信息）是描述无线信号在传输过程中受到的多径效应、衰减、相位变化等特征的数据。ESP32-C5 通过调用 esp_wifi_set_csi_rx_cb() 注册回调函数，在接收到数据包时自动触发 CSI 数据采集。CSI 数据包含幅度和相位信息，可用于感知环境变化。

  2. 双 ESP32 架构是如何设计的？主从分工是怎样的？之间如何通信（UART/SPI/Wi-Fi）？

    双 ESP32 架构中，一个作为发射端（TX）持续发送探测包，另一个作为接收端（RX）采集 CSI 数据并进行处理。两者通过 Wi-Fi 通信，RX 端负责 CSI 采集、FFT 处理和特征提取，TX 端仅负责发包。这种设计避免了单设备同时收发的干扰问题。

  3. ESP32-C5 相比 ESP32/ESP32-S3 在感知任务中有哪些优势？

    ESP32-C5 支持 Wi-Fi 6，提供更高的数据吞吐和更低的延迟，CSI 数据质量更好。同时功耗优化更佳，适合长时间运行的感知任务。相比 ESP32-S3，C5 的 RF 性能更稳定，适合高精度感知应用。

  4. CSI 采集频率和数据量有多大？是否做了同步或时序对齐？

    CSI 采集频率约为 100Hz（每秒 100 个数据包），每个 CSI 数据包包含 64 个子载波的幅度和相位信息，数据量约为 512 字节/包。通过时间戳进行时序对齐，确保数据的时序一致性。

  5. CSI 原始数据如何处理噪声？是否有滤波、归一化、滑动平均等预处理？

    采用以下预处理流程：

    • 滤波：使用低通滤波器去除高频噪声
    • 归一化：对幅度数据进行归一化处理，消除信号强度波动
    • 滑动平均：使用滑动窗口平滑数据，减少瞬时噪声影响
    • 异常值检测：剔除明显异常的数据点

  6. 板载处理是完全在 ESP32 上完成的吗？涉及多少资源占用（CPU 占比、内存）？

    是的，所有处理（FFT、特征提取、推理）均在 ESP32 上完成。CPU 占用约 60-70%，内存占用约 150KB（包括 FFT 缓冲区和模型权重）。通过优化算法和使用定点运算降低资源消耗。

基于 ESP-DSP 库在 MCU 上实现 FFT 与频域特征提取，完成呼吸率估计（MAE = 1.04）与运动检测（准确率达 95%）

  1. 为什么选择 ESP-DSP？是否评估过 CMSIS-DSP 或自实现 FFT？

    ESP-DSP 是 Espressif 官方优化的 DSP 库，针对 ESP32 架构进行了汇编级优化，性能优于通用库。相比 CMSIS-DSP，ESP-DSP 更适配 ESP32 的 Xtensa 架构，FFT 性能提升约 30%。

  2. FFT 使用的是多少点？采样窗口长度是多少？是否应用了窗函数？

    使用 256 点 FFT，采样窗口长度为 2.56 秒（100Hz 采样率）。应用了汉明窗（Hamming Window）减少频谱泄漏，提高频域分辨率。

  3. 呼吸率估计的算法原理是什么？是通过主频率检测还是包络分析？

    通过主频率检测实现。对 CSI 幅度数据进行 FFT 后，在 0.2-0.5Hz 频段（对应 12-30 次/分钟的呼吸频率）寻找峰值频率，该频率即为呼吸率。结合峰值强度判断呼吸的置信度。

  4. MAE = 1.04 是在什么基准下评估的？单位是 bpm 吗？是否在多人体环境测试过？

    MAE（平均绝对误差）= 1.04 bpm（次/分钟），基准为医用呼吸带测量结果。测试在单人环境下进行，多人环境下精度会下降，需要更复杂的信号分离算法。

  5. 运动检测的特征是频域能量变化还是基于模式识别？是否引入了机器学习？

    基于频域能量变化和方差特征。运动时 CSI 数据波动剧烈，频域能量显著增加。使用简单的阈值分类器，未引入复杂的机器学习模型，保证实时性和低功耗。

  6. 准确率 95% 是在多大样本量的数据集上得到的？有无混淆矩阵或 ROC 曲线？

    在约 5000 个样本（包含静止、走动、挥手等场景）上测试，准确率 95%。混淆矩阵显示主要误判发生在微小动作和静止之间。未绘制 ROC 曲线，但 F1-score 约为 0.94。

自建数据集并调优采样率，实现模型量化部署，边缘推理延迟控制在 50ms 内，功耗降低约 30%

  1. 数据集是如何采集和标注的？包括哪些场景（静止/呼吸/走动）？

    数据集包含以下场景：

    • 静止：无人或人员静坐
    • 呼吸：正常呼吸、深呼吸
    • 走动：室内走动、挥手、转身

    采集时使用时间戳标注，结合视频录像进行人工标注，确保标签准确性。

  2. 采样率是如何选取和调优的？对延迟、准确率、功耗分别有什么影响？

    初始采样率为 200Hz，经过测试发现 100Hz 已足够捕捉呼吸和运动特征。降低采样率后：

    • 延迟：FFT 窗口时间增加，但仍满足实时性要求
    • 准确率：几乎无影响（下降 < 1%）
    • 功耗：降低约 20%（减少数据处理和传输）

  3. 模型是自研还是迁移已有结构？部署使用了哪种框架（如 TFLite Micro）？

    使用简单的阈值分类器和规则引擎，未使用深度学习模型。对于更复杂的场景，可使用 TensorFlow Lite Micro 部署轻量级 CNN 模型。

  4. 模型量化是采用哪种策略（Post-training、QAT）？精度损失有多大？

    如果使用深度学习模型，采用 Post-training Quantization（训练后量化），将 FP32 模型量化为 INT8。精度损失约 2-3%，但推理速度提升 3-4 倍，内存占用减少 75%。

  5. 推理延迟 50ms 是如何测试的？包含数据预处理和 FFT 吗？

    推理延迟包含完整流程：CSI 数据接收（10ms）→ 预处理（5ms）→ FFT（20ms）→ 特征提取（10ms）→ 分类（5ms）。使用 ESP32 的高精度定时器测量。

  6. 功耗下降 30% 是对比优化前后的吗？通过哪种方式测得（电流采样/功率分析仪）？

    对比优化前后的功耗，使用功率分析仪（如 Nordic PPK2）测量平均电流。优化措施包括：降低采样率、使用 Light Sleep 模式、优化算法减少 CPU 占用。

利用 FreeRTOS 事件循环与回调机制构建多任务处理系统，保障算法实时性与系统稳定性

  1. 系统中划分了哪些任务？每个任务负责哪部分功能？优先级如何设置？

    系统划分为以下任务：

    • CSI 采集任务（优先级：高）：接收 CSI 数据，写入队列
    • 数据处理任务（优先级：中）：FFT 和特征提取
    • MQTT 上传任务（优先级：低）：上传处理结果
    • 看门狗任务（优先级：最高）：监控系统健康状态

  2. 事件循环机制是如何实现的？是否用了队列、信号量或 Event Group？

    使用 FreeRTOS 队列（Queue）在任务间传递数据，使用信号量（Semaphore）同步任务执行。CSI 采集任务将数据写入队列，处理任务从队列读取数据进行处理。

  3. CSI 采集、FFT 处理和 MQTT 上传分别在哪些任务中？它们如何同步？

    • CSI 采集：在 CSI 回调函数中触发，写入队列
    • FFT 处理：在数据处理任务中执行
    • MQTT 上传：在 MQTT 任务中执行

    通过队列和信号量实现任务间同步，确保数据流顺畅。

  4. 是否遇到任务阻塞、堆栈溢出或死锁问题？如何调试与避免？

    遇到过堆栈溢出问题，通过增加任务堆栈大小（从 2KB 增加到 4KB）解决。使用 FreeRTOS 的堆栈水印（Stack High Water Mark）监控堆栈使用情况，避免溢出。

  5. 使用了 Watchdog 吗？任务异常是否会触发系统重启？

    使用了任务看门狗（Task Watchdog）和中断看门狗（Interrupt Watchdog）。如果任务长时间阻塞或系统异常，看门狗会触发重启，确保系统可靠性。

  6. 系统稳定性测试做了多久？有没有长时间运行压力测试（如 24 小时稳定性）？

    进行了 72 小时连续运行测试，系统稳定无崩溃。监控内存泄漏、任务阻塞、看门狗触发等指标，确保长期稳定运行。

通过 MQTT 实时上传处理结果，结合 Web 前后端实现可视化监控与交互展示

  1. 为什么选用 MQTT 协议？相比 HTTP/CoAP 有哪些优势？

    MQTT 是轻量级的发布/订阅协议，适合 IoT 场景：

    • 低带宽：消息头小，适合低功耗设备
    • 实时性：支持推送，延迟低
    • 可靠性：支持 QoS 保证消息送达

    相比 HTTP，MQTT 更适合持续连接和实时数据传输。

  2. MQTT 是同步发送还是异步？是否支持断点续传？QoS 等级是多少？

    MQTT 采用异步发送，不阻塞主任务。使用 QoS 1（至少一次送达），确保消息可靠性。支持断线重连，重连后自动恢复订阅。

  3. 发送的数据格式是 JSON 吗？包含了哪些字段（时间戳、特征值、状态标签等）？

    使用 JSON 格式，包含以下字段：

    {
  "timestamp": 1234567890,
  "breath_rate": 16.5,
  "motion_detected": false,
  "confidence": 0.92,
  "device_id": "esp32_001"
}

  4. Web 可视化用的是什么技术栈？前端是否使用 ECharts/Vue？后端是否用了 Flask/Node.js？

    前端使用 Vue.js + ECharts 实现实时图表展示，后端使用 Node.js + MQTT.js 订阅消息并通过 WebSocket 推送到前端。

  5. 消息发布频率是多少？网络波动下如何保证可靠性？是否使用了重传机制？

    消息发布频率约为 1Hz（每秒一次）。网络波动时，MQTT 的 QoS 1 机制会自动重传未确认的消息。同时使用本地缓冲队列，网络恢复后批量上传。

  6. MQTT 是否配置了 TLS 加密？是否使用用户名密码/Token 做身份认证？

    生产环境配置了 TLS 加密（MQTT over TLS），使用用户名密码认证。敏感数据传输前进行加密，确保数据安全。

  7. Web 可视化展示哪些核心指标？是否支持实时刷新与历史查询？

    展示以下核心指标：

    • 实时呼吸率曲线
    • 运动检测状态
    • CSI 信号强度
    • 系统健康状态

    支持实时刷新（1 秒更新）和历史数据查询（存储在数据库中）。

参考资料

官方文档与开源项目

技术文章与教程

学术资源与开源项目

Graph View

Backlinks