3、传感器数据采集：使用Arduino/树莓派/ESP32等硬件采集传感器数据，数据格式与时间戳处理
传感器数据采集是Edge AI异常检测项目的数据源头，其质量直接决定后续特征工程与模型推理的上限。本章聚焦于三种主流嵌入式平台（Arduino、树莓派、ESP32）的传感器数据采集实现，重点解决两个核心问题：一是如何从硬件层面稳定、高效地读取传感器原始信号；二是如何为采集到的数据附加统一、可靠的时间戳，使其成为可被时序模型消费的标准数据集。我们将从硬件选型与接口协议出发，逐步深入到数据帧格式设计、时钟同步策略与工程化落地方案。
3.1 硬件平台选型与接口协议
在Edge AI项目中，传感器数据采集的硬件选型需要综合考虑采样率、精度、功耗、实时性与开发效率。Arduino系列（如Uno、Nano）基于AVR单片机，主频16MHz，适合单传感器、低功耗、微秒级响应的场景；ESP32搭载双核Xtensa处理器，主频240MHz，内置WiFi/蓝牙，支持FreeRTOS多任务调度，适合多传感器融合与边缘预处理；树莓派运行完整Linux系统，拥有丰富的外设接口与Python生态，适合需要复杂信号处理或本地模型推理的场景，但GPIO中断延迟通常在几十微秒到毫秒级，不适合高频采样。
接口协议方面，I2C（地址寻址、两根线）适用于短距离、低速（100kbps-400kbps）的多传感器连接，如MPU6050六轴惯性传感器、BME280环境传感器；SPI（四线制、全双工）支持更高吞吐量（可达10Mbps以上），适合高速数据流如ADXL345加速度计或外部ADC；模拟量输入（ADC）用于光敏电阻、电位器等连续信号源，Arduino Uno的ADC为10位分辨率，ESP32为12位，树莓派本身无ADC需外接模块。UART串口则常用于GPS模块、激光雷达等异步数据源。
| 平台 | 主频 | ADC分辨率 | 典型采样率 | 时间精度 | 适用场景 |
|---|---|---|---|---|---|
| Arduino Uno | 16MHz | 10-bit | 1kHz-10kHz | 4μs (micros) | 单传感器、实时控制 |
| ESP32 | 240MHz (双核) | 12-bit | 1kHz-50kHz | 1μs (esp_timer) | 多传感器、无线传输 |
| 树莓派 4B | 1.5GHz (四核) | 无内置 | 100Hz-1kHz | ~50μs (系统抖动) | 复杂处理、模型推理 |
3.2 数据帧格式设计与统一时间戳
多平台采集的数据最终需要汇聚到统一的数据管道中，因此必须设计一种与硬件无关的数据帧格式。推荐使用JSON Lines（每行一个JSON对象）或CSV格式，但JSON在嵌套结构和自描述性上更优。一个标准的数据帧应包含：设备ID、传感器类型、时间戳、数据值、质量标志。时间戳是异常检测时序模型的关键特征，必须统一为Unix时间戳（毫秒或微秒精度），并明确时区（推荐UTC）。
// 统一数据帧示例 (JSON Lines)
{"device_id":"esp32_01","sensor":"imu","ts":1710000000123,"data":{"ax":0.12,"ay":-0.98,"az":9.81},"quality":1}
{"device_id":"rpi_02","sensor":"temperature","ts":1710000000123,"data":{"temp":23.5,"humidity":45.2},"quality":1}
{"device_id":"arduino_03","sensor":"vibration","ts":1710000000123,"data":{"freq":120.5,"amp":0.03},"quality":0}时间戳处理是本章的难点。Arduino没有实时时钟（RTC），通常使用millis()获取上电后的相对时间，需要在上位机或网关处转换为绝对时间。ESP32支持NTP网络对时，可获取UTC时间，但需注意WiFi连接延迟和网络抖动。树莓派自带RTC（或通过NTP同步），系统时间精度较高，但GPIO读取时的软件抖动仍会影响时间戳准确性。对于多传感器同步采集，建议在硬件层使用中断或定时器触发采样，并在中断服务函数（ISR）中立即记录时间戳，避免数据在缓冲区中排队造成的时间偏移。
3.3 实战案例：ESP32多传感器振动监测节点
我们以一个工业电机振动监测节点为例，展示完整的采集流程。硬件配置：ESP32-WROOM-32开发板、ADXL345三轴加速度计（SPI接口，±16g量程）、DHT22温湿度传感器（单总线）。目标：以1kHz采样率采集振动数据，同时每5秒记录一次环境温湿度，数据通过WiFi上传至本地MQTT Broker。
初始现象与约束：电机正常运行时振动幅值约0.5g，异常时可达2g以上。现场无外部时钟源，需通过WiFi NTP同步。ESP32的ADC在1kHz采样时，若使用Arduino框架的analogRead()，单次读取耗时约100μs，三轴数据需300μs，加上SPI传输时间，实际采样率只能达到约2kHz，满足需求但余量不大。
关键实现步骤：
- SPI初始化与DMA传输：使用ESP32的SPI外设驱动ADXL345，配置为3.2MHz时钟，启用DMA通道，将三轴数据读取时间压缩至50μs以内。
- 定时器触发采样：使用
esp_timer创建1ms周期定时器，在回调函数中触发SPI读取，并记录esp_timer_get_time()（微秒精度）作为时间戳。 - 数据缓冲与打包：在内存中维护一个环形缓冲区，每100个样本（100ms）打包为一个JSON帧，包含起始时间戳和采样间隔，减少网络传输次数。
- NTP同步与漂移补偿：启动时通过NTP获取UTC时间，之后每10分钟校准一次。由于ESP32内部RC振荡器精度有限（约±30ppm），每秒钟可能产生30μs漂移，需在软件中记录本地时钟与NTP的偏差，并在时间戳中补偿。
- 异常质量标记：当SPI读取超时或数据超出量程时，将quality字段置为0，并在数据中附加错误码，便于后续清洗。
结果对比与复盘：优化后，实际采样率稳定在998Hz-1002Hz之间，时间戳抖动小于±50μs，满足1kHz分析需求。相比未优化前（使用Arduino框架的Wire库读取I2C版本），采样率提升了4倍，时间戳精度从±500μs提升至±50μs。复盘发现，初始方案使用I2C接口是性能瓶颈，改为SPI+DMA后CPU占用率从45%降至12%，为后续边缘侧FFT计算预留了算力。
3.4 常见误区与工程化建议
误区一：所有平台的时间戳精度相同。实际上，Arduino的micros()在中断中调用时精度较高，但在主循环中可能因其他操作被延迟；树莓派的Pythontime.time()受GIL和系统调度影响，抖动可达毫秒级。建议在C/C++层使用clock_gettime(CLOCK_MONOTONIC)获取单调时钟，避免系统时间跳变影响。
误区二：数据帧格式随意设计。在项目初期就应定义清晰的Schema，包括版本号、单位、坐标系约定。例如，加速度计数据应明确是重力加速度g还是m/s²，陀螺仪单位是°/s还是rad/s。否则后期数据清洗成本极高。
误区三：忽略传感器上电稳定时间。多数MEMS传感器在上电后需要几十毫秒至几百毫秒才能输出稳定数据，DHT22首次读取需等待2秒。应在初始化流程中加入延时和自检，丢弃前N个样本。
工程化建议清单：
- 为每个传感器分配独立的任务/线程，避免阻塞式读取影响其他传感器。
- 在数据帧中加入序列号（seq），便于检测丢包和乱序。
- 使用固定采样率而非“尽可能快”的循环，以便后续频谱分析时频率轴对齐。
- 在边缘端进行简单的有效性检查（如范围检查、变化率检查），减少无效数据上传。
- 为时间戳使用64位整数存储（微秒级Unix时间），避免2038年问题。
通过本章的硬件选型、数据帧设计、时间戳处理与实战案例，读者应能构建一个稳定、可扩展的多传感器采集前端，为后续的异常检测特征工程提供高质量数据基础。在实际项目中，建议先在单一平台上完成端到端验证，再扩展到多节点部署，并始终将时间戳精度作为系统性能的关键指标进行监控。