1. 蜂群健康监测的痛点与SwarmSense的设计初衷养蜂这件事看起来是农业实际上是个精细活。一个中等规模的蜂场几十箱蜂每箱里面两三万只蜜蜂蜂王的状态、巢温的波动、湿度的高低、群势的强弱任何一个指标出问题轻则减产重则整箱飞逃。传统做法靠什么靠老师傅开箱检查。但开箱本身对蜂群就是一次干扰每次开箱巢温要掉好几度蜜蜂需要重新调节频繁开箱反而增加应激风险。我最早接触蜂群监测是在三年前当时帮一个做智慧农业的朋友搭原型。最初的想法很简单放几个温湿度传感器进去数据传到网关手机上看曲线。但实际跑下来问题一大堆。首先是节点功耗蜂箱放在野外没有市电靠电池撑普通WiFi方案几天就没电了。其次是通信距离蜂场往往在山区或者果园深处单个网关覆盖不了所有蜂箱。最要命的是光有数据没用养蜂人要的是判断——这箱蜂到底有没有问题需不需要干预。SwarmSense这个项目的核心思路就是把这几个问题一次性解决。它用nRF54LM20做主控这是一颗基于Cortex-M33内核的低功耗无线SoC支持BLE Mesh组网跑Zephyr实时操作系统并且在端侧做TinyML推理。翻译成人话就是每个蜂箱里放一个小节点节点之间自己组网、自己转发数据不需要每个节点都直连网关节点上跑一个轻量级的机器学习模型直接在本地说“这箱蜂正常”或者“这箱蜂有异常”只把结论和关键数据传出去而不是把原始数据全部回传。这样做的好处非常直接。第一功耗下来了因为不需要持续高带宽传输。第二响应快了异常在本地就能判断不用等云端返回结果。第三覆盖范围大了Mesh网络天然支持多跳蜂场再大也能通过节点中继把数据传回网关。适合谁来参考如果你在做低功耗无线传感网络、边缘AI推理、或者智慧农业相关的项目这套架构和选型思路都可以直接借鉴。哪怕你不养蜂换成温室监测、仓储环境监控、设备状态监测逻辑是通的。2. 核心硬件选型与Zephyr系统搭建2.1 为什么选nRF54LM20而不是ESP32热搜词里出现了“esp32 ble mesh arduino”说明很多人第一反应是用ESP32做Mesh。ESP32确实生态好、资料多、Arduino上手快但放到蜂箱监测这个场景里它有几个硬伤。第一是功耗ESP32在BLE Mesh下的平均功耗比nRF54LM20高一个数量级蜂箱节点靠纽扣电池或者小太阳能板供电这个差距直接决定能不能长期免维护运行。第二是射频性能nRF54LM20的接收灵敏度和发射功率在同类产品里属于第一梯队Mesh多跳场景下链路余量更足。第三是Zephyr的原生支持nRF54LM20是Nordic自家芯片Zephyr里的一整套驱动、协议栈、电源管理都是官方维护的踩坑概率低很多。当然ESP32不是不能用。如果你只是做概念验证手头只有ESP32开发板先用它把逻辑跑通完全没问题。但真要落地到蜂场长期部署我建议还是换到nRF54LM20。我自己的做法是原型阶段用ESP32快速验证传感器和Mesh逻辑定型阶段切到nRF54LM20做功耗优化和稳定性打磨。2.2 Zephyr环境搭建west update到底在干什么热搜里有人问“下载zephyr为什么要执行west update”这个问题很典型。Zephyr不像Arduino那样一个IDE全包它是模块化的主仓库只包含内核和核心子系统大量的驱动、协议栈、示例、外部库分散在几十个独立仓库里。west update的作用就是根据west.yml清单文件把这些子仓库全部拉取到本地对应目录。不执行这一步你会发现很多驱动找不到、示例编译不过。具体操作流程我列一下这是我在Ubuntu 22.04上实测可用的步骤# 安装依赖 sudo apt install --no-install-recommends git cmake ninja-build gperf \ ccache dfu-util device-tree-compiler wget \ python3-dev python3-pip python3-setuptools python3-tk python3-wheel xz-utils file \ make gcc gcc-multilib g-multilib libsdl2-dev libmagic1 # 安装west pip3 install west # 初始化工作区 west init ~/zephyrproject cd ~/zephyrproject # 拉取主仓库 west update # 导出环境变量 west zephyr-export # 安装Python依赖 pip3 install -r ~/zephyrproject/zephyr/scripts/requirements.txt # 安装Zephyr SDK cd ~ wget https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v0.16.5/zephyr-sdk-0.16.5_linux-x86_64.tar.xz tar xvf zephyr-sdk-0.16.5_linux-x86_64.tar.xz cd zephyr-sdk-0.16.5 ./setup.sh注意west update第一次执行会拉取大量仓库网络不好的话建议配置好代理或者用国内镜像。另外SDK版本要和Zephyr版本匹配版本不匹配会出现编译工具链找不到的问题。编译一个nRF54LM20的示例验证环境cd ~/zephyrproject/zephyr west build -b nrf54lm20dk/nrf54lm20/cpuapp samples/hello_world west flash如果串口能看到Hello World输出环境就算通了。这里有个细节nRF54LM20DK的板级配置在Zephyr里可能有多个变体nrf54lm20dk/nrf54lm20/cpuapp是应用核的配置具体以你本地Zephyr版本里的boards目录为准。2.3 BLE Mesh在Zephyr里的配置要点Zephyr的BLE Mesh协议栈配置主要通过Kconfig完成。核心配置项包括CONFIG_BTy CONFIG_BT_MESHy CONFIG_BT_MESH_RELAYy CONFIG_BT_MESH_RELAY_RETRANSMIT_COUNT3 CONFIG_BT_MESH_RELAY_RETRANSMIT_INTERVAL20 CONFIG_BT_MESH_FRIENDy CONFIG_BT_MESH_LOW_POWERy CONFIG_BT_MESH_GATT_PROXYy CONFIG_BT_MESH_PB_GATTy这里解释几个关键选择。CONFIG_BT_MESH_RELAY开启中继功能让节点可以转发其他节点的消息这是Mesh覆盖范围的关键。CONFIG_BT_MESH_LOW_POWER和CONFIG_BT_MESH_FRIEND配合使用低功耗节点不用一直监听而是通过Friend节点缓存消息定期唤醒拉取这对电池供电的蜂箱节点至关重要。CONFIG_BT_MESH_GATT_PROXY让手机可以通过GATT连接直接入网配置现场调试很方便。实操心得Relay的重传次数和间隔要权衡。次数太多、间隔太短网络拥塞严重功耗飙升次数太少、间隔太长消息到达率下降。蜂场这种节点密度不高的场景我实测RETRANSMIT_COUNT3、INTERVAL20ms比较平衡。3. TinyML模型在蜂群健康预测中的落地3.1 蜂群健康到底预测什么蜂群健康的核心指标其实不多但每个都有明确的物理意义。巢温是最关键的健康蜂群会把巢温稳定在34.5到35.5摄氏度之间波动超过1度就说明调节能力出了问题。湿度反映通风和酿蜜状态长期高于70%容易滋生霉菌。重量变化反映采蜜和消耗的平衡突然掉重可能是分蜂或者飞逃。声音频谱能反映蜂群情绪失王群和正常群的频谱特征差异明显。SwarmSense的TinyML模型输入就是这几路传感器数据的时间序列输出是一个健康评分和异常类型分类。模型不需要很大因为特征维度低、模式相对固定。我用的是一个三层全连接网络输入是过去30分钟的温湿度滑动窗口加上重量变化率和音频特征输出四分类正常、温度异常、湿度异常、疑似失王。3.2 模型训练与量化部署训练在PC上完成用TensorFlow或者PyTorch都行。数据来源有两个一是公开的蜂群监测数据集二是自己蜂场采集的标注数据。这里要强调公开数据集只能用来预训练真正部署前一定要用自己场地的数据做微调因为不同地区、不同蜂种的基线特征有差异。模型量化和转换用TensorFlow Lite Micro的流程import tensorflow as tf # 加载训练好的模型 model tf.keras.models.load_model(hive_health_model.h5) # 转换为TFLite converter tf.lite.TFLiteConverter.from_keras_model(model) converter.optimizations [tf.lite.Optimize.DEFAULT] converter.target_spec.supported_ops [tf.lite.OpsSet.TFLITE_BUILTINS_INT8] converter.inference_input_type tf.int8 converter.inference_output_type tf.int8 # 代表性数据集用于量化校准 def representative_dataset(): for i in range(100): yield [calibration_data[i:i1].astype(float32)] converter.representative_dataset representative_dataset tflite_model converter.convert() with open(hive_health_model.tflite, wb) as f: f.write(tflite_model)量化到int8之后模型大小从几百KB降到几十KB推理速度在Cortex-M33上单次大约几毫秒完全满足实时性要求。Zephyr里集成TFLite Micro需要把运行时库作为模块加入然后在应用代码里加载模型数组、分配tensor arena、调用推理接口。注意tensor arena的大小要算够。我一开始按经验给了8KB结果推理时直接hard fault。后来用interpreter-arena_used_bytes()打印实际需求发现要12KB多。建议先给足余量跑通后再优化。3.3 端侧推理与云端协同的分工TinyML在端侧做的是快速筛查不是最终诊断。我的设计是端侧模型输出置信度高于0.85的异常直接触发告警上报置信度在0.6到0.85之间的上报原始特征数据由网关或云端做二次判断低于0.6的按正常处理只记录不告警。这样既保证了响应速度又避免了误报过多导致养蜂人麻木。这个阈值不是拍脑袋定的。我拿历史数据做过ROC曲线分析0.85对应的误报率大约5%漏报率8%对蜂群监测来说是可以接受的平衡点。如果你对漏报更敏感可以把阈值降到0.75代价是误报率上升到12%左右。4. 系统联调与现场部署的实操记录4.1 节点硬件组装与传感器校准单个蜂箱节点的硬件构成nRF54LM20模组、SHT40温湿度传感器、HX711加称重传感器、MEMS麦克风、电源管理电路、18650锂电池。传感器放在巢框上方和箱体底部各一个取平均值更能反映整体状态。传感器校准这一步不能省。SHT40出厂精度不错但蜂箱内高湿环境下长期运行会有漂移我每三个月用标准温湿度计做一次单点校准。称重传感器更麻烦温度变化会影响零点需要在固件里做温度补偿。我的做法是记录空载时不同温度下的ADC读数拟合一条补偿曲线运行时根据当前温度修正。// 简化的温度补偿示例 float compensate_weight(float raw_adc, float temperature) { float zero_offset 0.02f * (temperature - 25.0f); float compensated (raw_adc - zero_offset) / CALIBRATION_FACTOR; return compensated; }4.2 Mesh网络现场调试蜂场部署Mesh网络最大的坑是节点位置。蜜蜂是群居昆虫蜂箱排列有讲究但Mesh节点不能随便放。金属箱体对2.4GHz信号屏蔽严重节点天线最好伸出箱体外或者贴在箱壁内侧非金属区域。我试过把节点完全塞在箱内通信距离直接砍半。网络配置流程先给网关节点上电用手机App通过GATT连上去配置好网络密钥和AppKey。然后逐个给蜂箱节点上电节点会自动进入配网模式网关发现后分配地址。配网完成后用Mesh的配置客户端设置每个节点的Relay和Friend角色。靠近网关的节点设为Relay边缘节点设为Low Power。实操心得配网时一次只开一个节点配好一个关一个再开下一个。同时开多个节点配网地址分配容易乱而且信号冲突会导致配网失败。这个坑我踩过折腾了一下午才发现是同时上电的问题。4.3 功耗实测与电池寿命估算实测数据Low Power节点在Friend模式下平均电流约15微安Relay节点因为要持续监听和转发平均电流约800微安。用3000mAh的18650电池Low Power节点理论续航超过20年当然电池自放电和老化会先到Relay节点大约150天。实际部署时Relay节点我建议接小太阳能板5V/100mA的板子配合TP4056充电模块基本可以做到免维护。Low Power节点用一次性锂亚电池就行体积小、自放电低。节点角色平均电流电池容量理论续航推荐供电Low Power15uA3000mAh20年锂亚电池Relay800uA3000mAh~150天太阳能锂电池网关25mA持续供电-市电/USB4.4 告警策略与养蜂人反馈闭环技术做得再好养蜂人不用就是白搭。我最初设计的告警是App推送结果发现很多老师傅根本不看手机推送。后来改成两个通道一是蜂箱上的LED指示灯异常时闪红灯巡场时一眼就能看到二是每天早晚各一条短信汇总只报异常箱号不报正常箱。养蜂人的反馈也很重要。App里有个“标记误报”按钮养蜂人点一下这条数据就进入负样本库定期用来重新训练模型。这个闭环跑起来之后模型在本地数据上的准确率从最初的82%提升到了94%。5. 常见问题排查与避坑指南5.1 编译与系统类问题问题一west update卡住或者报错最常见的原因是网络问题。Zephyr的子仓库分布在多个托管平台国内访问不稳定。解决办法是配置git的代理或者使用国内的镜像源。另外west update支持--narrow参数只拉取当前项目需要的仓库能省不少时间和带宽。问题二编译报错“board not found”说明板级配置文件不在Zephyr的boards目录里。nRF54LM20是比较新的芯片老版本Zephyr可能没有支持。解决办法是升级Zephyr到最新版本或者从Nordic的官方仓库拉取板级配置放到本地boards目录。问题三TFLite Micro推理结果全是0或者乱码先检查输入数据的预处理是否和训练时一致。量化模型对输入scale和zero_point非常敏感训练时用的归一化参数必须原样搬到端侧。我遇到过输入忘了做int8转换直接传float进去结果全错。5.2 通信与组网类问题问题四Mesh消息丢包严重排查顺序先看节点距离超过30米或者有混凝土墙阻隔丢包是正常的加Relay节点。再看Relay配置重传次数不够或者间隔太长都会导致丢包。最后看信道干扰2.4GHz在蜂场可能被WiFi或者其他设备干扰用nRF Connect扫描一下信道占用情况必要时换信道。问题五Low Power节点收不到消息检查Friend节点是否正常工作。Low Power节点依赖Friend缓存消息如果Friend节点掉线或者缓存满了消息就丢了。建议每个Low Power节点至少有两个Friend候选一个主用一个备用。5.3 传感器与数据类问题问题六温湿度读数跳变蜂箱内环境其实很稳定读数跳变通常是传感器接触不良或者电源纹波太大。检查I2C走线是否过长、上拉电阻是否合适。另外SHT40的加热器功能在结露时很有用可以定期开启清除凝露。问题七称重数据漂移前面提过温度补偿但还有一种情况是蜂箱被外力移动或者地面沉降。这种漂移是阶跃式的不是渐变。我的处理是在固件里做变化率检测如果短时间内重量突变超过阈值标记为“疑似移动”而不是“重量异常”避免误报。问题现象可能原因排查方法解决方案节点频繁掉线电源不稳示波器看供电纹波加滤波电容检查电池接触推理结果异常输入预处理错误对比PC端和端侧输入统一量化参数配网失败多节点同时上电逐个上电配网一次只开一个节点续航不达标Relay配置过激测平均电流降低重传次数调整角色温湿度跳变I2C干扰检查走线和上拉缩短走线加屏蔽5.4 独家避坑技巧第一个技巧固件里留一个“维护模式”。长按节点上的按键5秒进入维护模式此时节点全速运行、关闭低功耗方便现场调试和固件升级。调试完再切回正常模式。这个功能看起来简单但现场排查问题时能省大量时间。第二个技巧模型版本号写进广播数据。Mesh节点广播里带一个字节的模型版本号网关收到后如果发现版本不一致就知道该节点需要升级。避免出现新旧模型混跑导致判断标准不一致的问题。第三个技巧蜂箱编号和Mesh地址做映射表存在网关里。不要依赖节点自己报编号因为节点更换或者重配网后编号可能变。网关维护一张地址到箱号的映射表换节点时只改网关配置不用动节点。第四个技巧定期做“空箱测试”。找一个空蜂箱放上节点跑一周看看基线数据。空箱和实箱的温湿度、重量特征完全不同空箱数据可以用来验证传感器是否正常也可以作为异常检测的对照。6. 从原型到产品的扩展思路这套系统跑通之后扩展方向其实很多。硬件上可以加二氧化碳传感器判断通风状态加蜂王标记识别做更精细的群势评估。软件上可以把多个蜂场的数据聚合起来做区域病虫害预警这个价值比单场监测大得多。通信方面BLE Mesh适合蜂场内组网但蜂场和蜂场之间、蜂场和云端之间还需要回传通道。我的做法是网关通过4G Cat-1模组上传功耗和成本都比NB-IoT更平衡。如果蜂场有WiFi覆盖网关也可以走WiFi但野外场景别指望这个。模型方面目前是四分类后续可以做成多标签输出同时判断多个异常类型。另外可以引入在线学习让模型根据养蜂人的反馈持续微调。不过在线学习在MCU上实现有难度折中方案是在网关做增量训练定期把更新后的模型下发给节点。成本控制是产品化的关键。原型阶段用的都是开发板单节点成本两三百。量产的话nRF54LM20模组、传感器、电源管理加起来可以压到八十以内加上外壳和电池整箱成本一百出头。对规模化蜂场来说这个投入产出比是算得过来的。我个人在实际部署中最大的体会是别追求一步到位。先跑通温湿度监测和Mesh组网再叠加TinyML最后做告警闭环。每一步都验证稳定了再往下走。我见过太多项目一上来就想做全功能结果每个模块都不扎实现场一跑全是问题。蜂群监测是个长期活系统稳定比功能花哨重要得多。