蜜蜂每年為全球經(jīng)濟(jì)貢獻(xiàn)5770億美元。然而，大多數(shù)養(yǎng)蜂人(尤其是業(yè)余愛好者)直到打開蜂箱才知道蜂巢里發(fā)生了什么。到那時，蜂群已經(jīng)離開，或者蟻群已經(jīng)餓死了。

商業(yè)監(jiān)控系統(tǒng)的成本為每個蜂箱500歐元以上。它們是為工業(yè)生產(chǎn)設(shè)計的，不是為后院有八個蜂箱的人設(shè)計的。

我們需要一些不同的東西：一個可以在冬天生存的系統(tǒng)，部件成本低于50美元，并提供實際的洞察，而不僅僅是每小時上傳的溫度讀數(shù)。

解決方案

HappyBees直接在Raspberry Pi Pico 2w上運行edge ML。它會傾聽蜂群的聲音特征，區(qū)分正常的嗡嗡聲和蜂群前的管道，只在有重要事情發(fā)生時提醒你。

關(guān)鍵觀點是：我們不會將原始音頻流傳輸?shù)椒?wù)器。我們在本地處理所有內(nèi)容，6秒的音頻變成20個特征，通過TFLite模型運行，并在200毫秒內(nèi)生成分類。本地web服務(wù)器只看到結(jié)果。

技術(shù)規(guī)格:

?通過DMA捕獲16kHz音頻(每次推斷96000個樣本)

?自定義DSP：二階巴特沃斯高通(100Hz)，三階低通(6kHz)

?512點FFT， Hanning窗口，每次捕獲平均187個窗口

?TensorFlow Lite微推理RP2350

?WiFi遙測FastAPI + TimescaleDB后端

?實時儀表盤

硬件

組件

為什么是Pico 2w ?RP2350具有520KB SRAM。我們的音頻緩沖區(qū)是192KB。ESP32的320KB是不夠的。Pico也有比ESP32-S3更好的ML部署文檔和社區(qū)工具。

布線

Pico連接:

麥克風(fēng)前置放大器:

SPW2430輸出微弱信號。我們通過一個非反相放大器輸入它：

?Mic輸出→10μF交流耦合→運算放大器(+)輸入

?R1/R2分壓器設(shè)置1.65V直流偏置

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

?通過1kΩ→GP26過濾輸出

這種收獲很重要。該模型在不同的麥克風(fēng)數(shù)據(jù)上進(jìn)行了訓(xùn)練。我們的運放電路產(chǎn)生的信號強度為3-4倍。我們在軟件中使用增益因子(默認(rèn)為0.35)進(jìn)行補償。

固件

建造

Flashing

?Hold BOOTSEL on Pico

?插入USB

?beewatch_firmware副本。uf2到掛載的RP2350磁盤

配置

通過串口連接：

配置WiFi和服務(wù)器：

串行命令

DSP管道

信號處理鏈很重要。以下是每個音頻樣本的情況：

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

增益補償：縮放0.35以匹配訓(xùn)練數(shù)據(jù)的幅度

高通濾波器(100Hz，二階巴特沃斯)：

低通濾波器(6kHz，三階巴特沃斯)：兩個級聯(lián)biquads

FFT：使用Hanning窗口時的512點，平均每6秒捕獲187個非重疊窗口。

我們關(guān)心的頻率箱：指數(shù)4-19，對應(yīng)125-594 Hz。這是蜜蜂的聲音特征所在。

ML模型

Anete使用Edge Impulse的BYOM (Bring Your Own Model)工作流程開發(fā)了夏季和冬季模型。這讓我們可以用Python進(jìn)行訓(xùn)練，并自動為Pico生成優(yōu)化的c++。

夏季模型(蜂群探測)

?輸入：20個功能

?溫度、濕度、小時

?尖峰比(關(guān)鍵特征)

?16個FFT頻倉

架構(gòu)：Dense 64→Dense 32→Softmax 2 (Normal/Event)

關(guān)鍵洞察：通過系統(tǒng)測試，我們發(fā)現(xiàn)該模型主要使用尖峰比-電流音頻能量除以滾動平均值。FFT箱的影響最小。

?峰值< 0.7：活動減少→正常

?spike≈1.0：穩(wěn)態(tài)→模棱兩可(默認(rèn)為Event)

?峰值> 1.3：活動增加→事件

這解釋了為什么新啟動總是預(yù)測“事件”，沒有歷史記錄，峰值比率為1.0。5-6個讀數(shù)后，滾動平均值趨于穩(wěn)定。

冬季模型(異常檢測)

在健康冬季簇數(shù)據(jù)上訓(xùn)練的自動編碼器：

?輸入：5個功能

?溫度、濕度

?溫度穩(wěn)定性(超過12個讀數(shù)的變化)

?加熱器功率(183Hz, 213Hz， 244Hz的總和-“集群嗡嗡聲”)

?加熱器比(加熱器功率/總音頻密度)

輸出：輸入的重構(gòu)

異常評分：輸入和重建之間的MSE。高M(jìn)SE意味著模型不能識別模式：潛在的群體死亡、饑餓或集群不穩(wěn)定。

后端

堆棧

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

?用于時間序列存儲的TimescaleDB(帶超級表的PostgreSQL)

?Dash/ plot用于實時儀表板

為什么不是Grafana?我們認(rèn)為它增加了部署的復(fù)雜性，而Dash則為我們提供了簡單、純粹的端到端Python。

快速啟動

1. 啟動數(shù)據(jù)庫:

2. 開始后端:

3. 開始指示板:

4. 用模擬裝置測試：

API端點

命令隊列使用輪詢(每隔2s)而不是WebSockets。更簡單的固件，通過NAT工作，2秒的延遲對我們的用例來說很好。

故障排除

“總是預(yù)測事件”

?正常，重新開始。運行5-6次推理來構(gòu)建歷史。

?或者：在一次捕獲過程中制造噪音，然后安靜下來。尖峰比會下降。

“FFT箱子太高”

?低增益：g0.25

?目標(biāo)：安靜房間的箱子0.02-0.06

“Pico無法連接WiFi”

?必須是2.4GHz (Pico不支持5GHz)

?檢查SSID/密碼拼寫

本文編譯自hackster.io