构建一个智能蜂窝监视器

蜜蜂每年为全球经济贡献5770亿美元。然而，大多数养蜂人(尤其是业余爱好者)直到打开蜂箱才知道蜂巢里发生了什么。到那时，蜂群已经离开，或者蚁群已经饿死了。

商业监控系统的成本为每个蜂箱500欧元以上。它们是为工业生产设计的，不是为后院有八个蜂箱的人设计的。

我们需要一些不同的东西：一个可以在冬天生存的系统，部件成本低于50美元，并提供实际的洞察，而不仅仅是每小时上传的温度读数。

解决方案

HappyBees直接在Raspberry Pi Pico 2w上运行edge ML。它会倾听蜂群的声音特征，区分正常的嗡嗡声和蜂群前的管道，只在有重要事情发生时提醒你。

关键观点是：我们不会将原始音频流传输到服务器。我们在本地处理所有内容，6秒的音频变成20个特征，通过TFLite模型运行，并在200毫秒内生成分类。本地web服务器只看到结果。

技术规格:

•通过DMA捕获16kHz音频(每次推断96000个样本)

•自定义DSP：二阶巴特沃斯高通(100Hz)，三阶低通(6kHz)

•512点FFT， Hanning窗口，每次捕获平均187个窗口

•TensorFlow Lite微推理RP2350

•WiFi遥测FastAPI + TimescaleDB后端

•实时仪表盘

硬件

组件

为什么是Pico 2w ?RP2350具有520KB SRAM。我们的音频缓冲区是192KB。ESP32的320KB是不够的。Pico也有比ESP32-S3更好的ML部署文档和社区工具。

布线

Pico连接:

麦克风前置放大器:

SPW2430输出微弱信号。我们通过一个非反相放大器输入它：

•Mic输出→10µF交流耦合→运算放大器(+)输入

•R1/R2分压器设置1.65V直流偏置

•增益= 1 + (100k/5k) = 21倍

•通过1kΩ→GP26过滤输出

这种收获很重要。该模型在不同的麦克风数据上进行了训练。我们的运放电路产生的信号强度为3-4倍。我们在软件中使用增益因子(默认为0.35)进行补偿。

固件

建造

Flashing

•Hold BOOTSEL on Pico

•插入USB

•beewatch_firmware副本。uf2到挂载的RP2350磁盘

配置

通过串口连接：

配置WiFi和服务器：

串行命令

DSP管道

信号处理链很重要。以下是每个音频样本的情况：

DC去除：减去平均值(对于以1.65V为中心的12位ADC，通常为~2048)

增益补偿：缩放0.35以匹配训练数据的幅度

高通滤波器(100Hz，二阶巴特沃斯)：

低通滤波器(6kHz，三阶巴特沃斯)：两个级联biquads

FFT：使用Hanning窗口时的512点，平均每6秒捕获187个非重叠窗口。

我们关心的频率箱：指数4-19，对应125-594 Hz。这是蜜蜂的声音特征所在。

ML模型

Anete使用Edge Impulse的BYOM (Bring Your Own Model)工作流程开发了夏季和冬季模型。这让我们可以用Python进行训练，并自动为Pico生成优化的c++。

夏季模型(蜂群探测)

•输入：20个功能

•温度、湿度、小时

•尖峰比(关键特征)

•16个FFT频仓

架构：Dense 64→Dense 32→Softmax 2 (Normal/Event)

关键洞察：通过系统测试，我们发现该模型主要使用尖峰比-电流音频能量除以滚动平均值。FFT箱的影响最小。

•峰值< 0.7：活动减少→正常

•spike≈1.0：稳态→模棱两可(默认为Event)

•峰值> 1.3：活动增加→事件

这解释了为什么新启动总是预测“事件”，没有历史记录，峰值比率为1.0。5-6个读数后，滚动平均值趋于稳定。

冬季模型(异常检测)

在健康冬季簇数据上训练的自动编码器：

•输入：5个功能

•温度、湿度

•温度稳定性(超过12个读数的变化)

•加热器功率(183Hz, 213Hz， 244Hz的总和-“集群嗡嗡声”)

•加热器比(加热器功率/总音频密度)

输出：输入的重构

异常评分：输入和重建之间的MSE。高MSE意味着模型不能识别模式：潜在的群体死亡、饥饿或集群不稳定。

后端

堆栈

•用于API的FastAPI (async, auto-documented)

•用于时间序列存储的TimescaleDB(带超级表的PostgreSQL)

•Dash/ plot用于实时仪表板

为什么不是Grafana?我们认为它增加了部署的复杂性，而Dash则为我们提供了简单、纯粹的端到端Python。

快速启动

1. 启动数据库:

2. 开始后端:

3. 开始指示板:

4. 用模拟装置测试：

API端点

命令队列使用轮询(每隔2s)而不是WebSockets。更简单的固件，通过NAT工作，2秒的延迟对我们的用例来说很好。

故障排除

“总是预测事件”

•正常，重新开始。运行5-6次推理来构建历史。

•或者：在一次捕获过程中制造噪音，然后安静下来。尖峰比会下降。

“FFT箱子太高”

•低增益：g0.25

•目标：安静房间的箱子0.02-0.06

“Pico无法连接WiFi”

•必须是2.4GHz (Pico不支持5GHz)

•检查SSID/密码拼写

本文编译自hackster.io