利用边缘AI和树莓派能将汉尼瓦模型改造成智能灌溉系统
扫描二维码
随时随地手机看文章
愿景:陶俑守护者——菜园守护者
我打算将汉尼瓦模型改造为“陶土灌溉”与“动态稻草人”的混合体,用于我的小型花园。——陶土灌溉:利用黏土的多孔特性实现自动、低技术的灌溉。与一个 2 瓦的树莓派 Pico 一起使用,它将监测土壤湿度并控制陶俑内部的水位。它不仅会为植物浇水,还会通过 Telegram 通知我何时需要补充水源。——动态稻草人:基于我之前的一个项目,即将监控摄像头重新用于观鸟,它将能够触发陶俑眼睛处的发光 LED 以及一个蜂鸣器,以驱赶乌鸦或猫。
在空间有限的日本,多功能设计展现出了独特的美感。让我们为这种古老的形式注入新的活力吧。
伟大的统一——为汉瓦遗迹奠定坚实基础
我不得不面对一个严峻的现实:我的古董复制品底部有一个大洞(确切尺寸为 78.45 毫米)。如果这要成为一个“陶土灌溉”系统的话,那么这个底部就必须能够容纳水。
未上釉的黏土具有极强的吸水性,非常适合用于缓慢释放灌溉(可以将其视为一种低科技、古老的“奥拉”陶罐)。然而,这个复制品的结构稳定性对于长期户外使用来说存在疑问,而底部的那个洞更是成了致命缺陷。
我需要的解决方案应具备以下特点:——防水性:能够容纳蓄水池的水份。——结构完整性:能为土壤提供稳固的支撑。——类似“黑客”风格:价格实惠且易于获取。
100 日元商店的奇迹走进了日本的 100 日元商店(这是我们对“廉价商店”的一种称呼)。我用卡尺仔细查看了园艺用品区,最终找到了理想之选:一个标准的、未上釉的陶制花盆(在日本被称为“suyaki”)。
尺寸上的契合度令人十分满意。但在硬件破解领域,“近乎匹配”在马蹄铁和手榴弹这类物件上才有实际意义。而我需要的是完美无缺、严丝合缝的契合度。
精密粘合为了将这一有着 1500 年历史的设计与这款 1 美元的现代陶罐相结合,我使用了一种硅胶密封剂。经过多次尝试和调整,这个面人俑终于能够避免尿湿自己了。
我将树脂涂抹在 50 日元罐子的边缘,并小心翼翼地将其插入哈尼瓦的底座中。这是一种摩擦式的连接方式,最终形成了一个永久性的、防水的密封效果。这样就形成了一种无缝且统一的结构。哈尼瓦的下半部分现在有了一个坚固、防水的“桶状”结构。它看起来就像一种史前的“火焰式陶器”容器。
整合气象情报——哈尼瓦的“大脑”
“你是否曾给花园浇水,结果一小时后却突然下起了倾盆大雨?”我们都遇到过这种情况。这是一种既浪费资源又耗费精力的令人沮丧的现象。为了避免这种情况发生,我认为仅仅采用“陶土灌溉系统”是不够的。我的哈尼瓦不仅仅需要一个土壤湿度传感器,它还需要预见性的力量。我决定将天气预报数据整合进来,创建一个“智能灌溉顾问”。
提及“瓦达奇博士”:作为哈尼瓦人的大脑,这个气象服务部门被命名为“瓦达奇博士”,以此纪念日本气象学的先驱、日本气象厅首任厅长官基约·瓦达奇。
从我记事起,我就读过一本大学时期的书籍。瓦达奇博士曾说过,他投身这一领域是因为“仅凭借观测数据和人类智慧就能取得重大发现。”我对此深表同情。在大学时期,我使用的是价值几亿日元(超过一百万美元)的尖端设备。而如今,我却用一台价值 30 美元的二手电脑和一台 5 美元的树莓派 Pico 2W 来追寻同样的发现精神。
设置流程:
API 通行证:我使用了 OpenWeatherMap 的 API。每天发出一个智能请求就能获取到足够的数据来预测海马市的天气,而且还能保持资源利用效率。
获取 API 通行证 - 注册:在 OpenWeather.org 上创建一个免费账户(每天可使用 1000 次请求)。- 激活:在验证您的电子邮件后,导航至“我的 API 密钥”标签页。- 生成:通常会提供一个默认密钥,但您可以创建一个专用的密钥,命名为“Haniwa_Project”。
逻辑:思维与行动的共生 这个项目的核心智能分布在三个不同的角色中,从而在云端人工智能、边缘人工智能以及物理接口之间形成了一个反馈循环。
A. 沃达奇博士(“天文学家”/云人工智能):Python 服务充当核心分析角色。它不仅获取数据,还会解读环境:预测性灌溉:它将来自哈尼瓦的实时土壤湿度数据与 48 小时的降水预报进行关联。安全监督:它监测风速,以决定“观鸟者”是否可以安全操作。指令发布:它编写一个集中式的 JSON“状态报告”,规定其他组件的行为。
B. 鸟类观察者(《点灯者》/ 边缘人工智能)此组件负责处理高强度的视觉处理任务。它不仅能识别鸟类,还能识别猫、狗和人类等其他访客。《点灯者》休息逻辑:忙碌的点灯者需要适当的休息。当瓦达奇博士报告风速超过 9 米/秒时,鸟类观察者会进入“羊群计数”模式的睡眠状态。它每隔 10 秒检查一次 JSON 状态,保持足够的警觉性,以便在风势减弱时立即醒来,而在风暴期间不会浪费 CPU 资源。
C. 哈尼瓦(“狐狸”/人机界面) 哈尼瓦是通往现实世界的桥梁。它保持安静以节省能量,但在需要时会变得具有交互性:人存在感知与安全:当观鸟者检测到附近有“人”时,它会立即通知哈尼瓦。这具有双重作用:它为哈尼瓦做好了互动的准备,并起到了视觉上的安全威慑作用。
感谢您耐心读到这里。您可能已经注意到,我还非常喜欢安托万·德·圣埃克苏佩里的《小王子》。特别是其中这样一个情节:当这位天文学家换上新衣服时,他突然就获得了其他学者们的关注;点灯人是王子唯一觉得可以成为朋友的人(作为读者,我真希望他能休息一下);还有狐狸给我们上的重要一课:需要有规律、具体的日常安排。我试图将这些元素都融入到这个系统中,同时对这位伟大的作家怀有最大的敬意。
首次报告成功!
系统运行正常。首份报告显示,海沼的风速为 9.32 米/秒——刚好处于临界值!因为我发现当风速超过 9 米/秒时,我的“观鸟者”人工智能就会变得焦躁不安,会把摇曳的树枝误认为是鸟儿,所以我请和田博士让“观鸟者”休息一下。
因此,该项目已正式从“屏幕上的代码”转变为“具有生命力的实体显示器”,并充分尊重了米乌拉半岛的自然环境。
超越“简单主义”潮流:为何我选择不同颜色对应不同电阻值的电阻器
我的专业并非电子学,而是机械学。在机械领域,“简洁”往往等同于“安全”。摒弃冗余部件、减少零部件数量、降低成本,并构建出直接且精简的架构,这种做法被盲目地视为工程实力的巅峰。
减少连接点、减少运动部件——这些都是我们追求的目标。所以,当我最初看到一份用于通过微控制器(Raspberry Pi Pico 2 W)驱动 RGB 发光二极管的常见电路图时,我的机械直觉立刻被激发了。为什么要使用三个或四个独立的电阻呢?为什么不将输出合并起来,并共用一个电阻连接到公共地(阴极)呢?起初,这似乎是一个显而易见的优化方案。一个电阻比三个电阻要简单得多。
但随后,我仔细研究了发光二极管的物理原理。就在那时,作为一名机械工程师的我的世界观开始发生了转变。问题出在光本身的固有特性上,或者更确切地说,是在用于产生不同颜色光子的材料上。
首先,我尝试使用一种共阳极的 RGB 灯,但很快就放弃了这个想法。在这种配置中,红、绿、蓝这三种颜色共用一个输入端(阳极),而三个独立的输出端(阴极)则连接到地线。我完全搞糊涂了:由于我的 Pico 2W 只有公共地线,我认为对于像我这样的初学者来说,使用这种元件非常困难。于是我决定分别使用红色、绿色和蓝色的 LED。
让我们回到正题吧。我原以为如果在公共地线路上使用一个共用的电阻,理论上就能限制总电流。但单个电阻无法满足每种颜色的特定需求。这就是令人惊讶之处所在:红色 LED 的正向电压明显低于绿色或蓝色 LED 的电压。红色 LED:1.8V 至 2.0V,而绿色和蓝色 LED 则使用 3.0V 至 3.2V 的电压。
我的微控制器——Pico 2 W,通过其 GPIO 引脚输出稳定的 3.3 伏电压。如果我驱动绿色或蓝色的 LED,电压差很小(3.3 伏 - 3.1 伏 = 0.2 伏)。一个 220 欧姆的电阻能很好地限制电流。然而,如果我用同样的 220 欧姆电阻驱动红色 LED,电压差就非常大(3.3 伏 - 1.9 伏 = 1.4 伏)。根据欧姆定律 I = V/R,这意味着红色 LED 中会流过比之前大得多的电流。结果呢?正如你所想象的那样,它可能会被损坏。即使在最坏的情况下,微控制器引脚也会受损。
冗余的必要性:为了控制红色 LED 的亮度,使其与其他颜色的亮度保持平衡,我需要更高的电阻值。我经过计算得出,如果在红色通道中串联一个 220Ω 的电阻(这样红色通道的总电阻就达到了 440Ω),就能打造出完美的“哨兵”效果。
这是我选用的带有多个电阻的设计方案:- 红色通道:Pico 2W GP13(引脚17)→ 220Ω + 220Ω → 红色阳极 - 绿色通道:Pico 2W GP14(引脚19)→ 220Ω → 绿色阳极 - 蓝色通道:Pico 2W GP15(引脚20)→ 220Ω → 蓝色阳极 - 公共地:共阴极 → Pico 2W GND(跳接到引脚18)
结论:视角的转变作为一名机械工程师,看到原本只需一个电阻器的地方却装了两个电阻器,感觉……效率低下。这感觉就像是给飞机机身增加了重量。但我正在逐渐明白,在电子领域,冗余并非浪费,而是保护措施。通过使用两个独立的电阻器,我不仅限制了电流,还确保了每个颜色系统之间的独立性。我防止了红色通道出现故障(比如短路)从而引发连锁反应并影响绿色或蓝色通道,甚至更糟的是影响到微控制器本身。将设计简化为一个共享的单一电阻器会更便于结构设计。但这样会形成一个脆弱、不平衡且电气上不安全的系统。
我的电气初学者设计现在已经变得稳定、安全且完美地达到了平衡状态。我开始学会欣赏这种新的复杂性——它并非设计上的失败,而恰恰是安全性和性能所必需的架构。最终,工程学并非只是遵循一种单一的理念。它在于理解你所从事领域独特的物理特性。
添加触觉感应:选择一款土壤湿度传感器
为了赋予哈尼瓦“触觉”功能,我选择了某种土壤湿度传感器。以下是做出这一选择符合可持续及全球工程理念的原因:
1. 通过电容式感应实现耐用性 尽管简单的电阻式传感器可以通过直接在陶土中插入电极来制造,但它们往往在数周内就会因电解作用而腐蚀。这种电容式传感器的特点是其电极被保护,避免与土壤直接接触。通过测量电容的变化而非电阻值,我们能够确保更长的使用寿命,这对于旨在留在花园中的守护者来说是一项至关重要的特性。
2. 低功耗设计(通过 GPIO 供电):该传感器的工作电流约为 5 毫安至 7 毫安(小于 10-12 毫安),其耗电量完全处于单个 Raspberry Pi Pico 2 瓦 GPIO 引脚的功率限制范围内。这使得能够采用“按需供电”的策略:在测量期间,传感器仅被供电几十毫秒,从而大幅降低了电池供电部署中的能耗。
3. 通过大规模生产实现成本效益这些传感器价格极其低廉(大量购买时通常不到 2 美元)。这种低价格是由于规模经济所致,而非质量不佳。通过采用成熟、可靠、基于模拟的电路,我们利用了可靠的大规模生产技术。这使得该项目不仅对爱好者来说易于实现,而且可能对任何寻求低成本农业解决方案的人也都有可行性。
硬件设置(原理图)这是连接原理图。设置过程很简单,传感器与 Pico 2 W 之间只需三根电线即可连接。
布线详情: - 传感器地(黑色) -> 皮科 2 型 W 地(引脚 33) - 传感器 AOUT(黄色) -> 皮科 2 型 W ADC0(引脚 31) - 传感器 VCC(红色) -> 皮科 2 型 W GP22(引脚 29)
节能功能:虽然您可以将 VCC(红色导线)连接至 3V3(36 号引脚)以实现更简单的设置,但这样做会使传感器持续保持通电状态。这会导致不必要的能源消耗,并可能加速电极的损坏。
在该项目中,我将 VCC 与 GP22(第 29 号引脚)相连。这样就能让 Pico 2W 只在测量时为传感器供电,从而显著提高了能源效率——非常适合电池供电或长期监测的设备。
软件配置(Pico SDK) 为了节省电量,我使用了 GP22 作为可切换电源,相关代码如下:
注意:我将稳定等待时间设置为 50 毫秒。根据您所使用的具体传感器,您或许能够将其缩短至 10 毫秒以进一步节省电量,但 50 毫秒的设置能提供非常稳定的读数。
验证步骤:连接完成后,您会看到原始数据直接流进串行终端。要验证传感器的功能,请只需用手指轻触其电容式表面即可。
如图所示,当检测到手指上的湿气时,读数从约 10 突然跃升至约 200,这证实了从传感器到终端的整个管道系统均处于正常运行状态。
《飞行员的盒子:揭示无形的联系》
这个谜题的最后一块拼图是“tcp_connector.py”以及“隐形”无线网络连接的建立。这就像飞行员画的那幅“绵羊盒子”图一样。如果我可以这么大胆地说的话,我小时候也曾放弃画画。在高中时,我去参加职业咨询,原本打算成为一名工业设计师,但周围的大人们阻止了我,让我改学机械工程。
但如今,作为一名工程师,我意识到我无需成为“画家”来展现其精髓。通过将复杂的 Wi-Fi 握手过程和 TCP 协议封装在“tcp_connector.py”这个文件中,我正在向哈尼瓦展示一个“盒子”。
哈尼瓦无法看到代码;它只看到“绵羊”(即关键数据)所存在的状态。“这就是我的绘画方式,”不是用铅笔,而是通过逻辑和关联来实现的。
过去,作为一名大型企业的机械工程师,我按照别人的“蓝图”行事。如今,那架飞机出了故障,而我却置身于自己的“荒漠”之中。
但我有我的工具、我的经验以及几年的延缓开发时间。我或许无法随叫随画出一只完美的羊,但我可以构建一个“盒子”。我能够将复杂的功能封装在像 tcp_connector.py 这样的简单脚本中。它并不华丽,也绝对称不上是传统意义上的杰作,但它确实能发挥作用,具有一定的适应性,最重要的是,它是属于我的。
“这就是我描绘自己未来的方式。”
个人发展的现实与期望:
传统观点认为,在编码之前完成设计以确保效率(即“前置加载”)是正确的做法。但在独自开发的情况下,实际情况往往需要理论与实践之间的相互交流。我认为在开发过程中修改自己的序列图并非规划不周的表现,而是在构建过程中获得更深刻理解的体现。我觉得这种灵活性可能是独立工程所独有的优势。
展望未来,我打算研究如何将这种实践经验融入到团队环境中,无论是在一个大型组织中,还是在一个小型、灵活的集体中。我致力于在有条理的规划与在实施过程中所发现的重要见解之间找到平衡,确保“在键盘和显示屏上找到的真相”从一开始就为项目的愿景提供指导并增强其力量。
经过无数次孤独的尝试与错误,我得出了一个结论:不仅要使用环境传感器,还要将这种实时的本地数据与全球开放的信息相结合。决策的代码就在这里。
我让这些汉尼瓦雕像的眼睛亮了起来。这就是结果。1. 对于那些想要了解颜色含义的人,他会耐心地告知他们这些园艺植物是否需要浇水。2. 对于那些不愿去尝试理解的人来说,它仿佛是一种恐惧的幻影,就像一个活跃的稻草人。我试图让这两种功能在单一操作中实现共存。难道你也这么认为吗?
这个概念很简单:通过将当地土壤湿度数据与天空天气预报进行交叉比对,云人工智能系统就能判断是否需要浇水。当其边缘人工智能的眼睛捕捉到“人”的身影时,哈尼瓦雕像的视线就会被激活。
在这一个动作中,我赋予了它两种不同的功能(灵魂):——对于我和我的家人而言,我们能够读懂它闪烁的色彩所传达的信息,它便成为了一盏指引我们如何照料花园的明灯。——而对于那些不了解其含义的闯入者来说,它则仅仅是一个奇怪的守护者,一种幽灵般的警告,能将他们驱离。
共享内存:“关键之处往往肉眼无法察觉。”
在初始调试阶段,我设置了 Telegram 通知以监测系统的运行情况。然而,我发现了一个严重的缺陷:从进入花园到手机收到警报之间有 7 秒的延迟,而即使回到室内之后,仍会有 5 秒的延迟。
如果这种延迟现象反映在哈尼瓦的眼睛中,那么一个快速移动的入侵者就能在“主动稻草人”还未启动之前穿过花园并进入房屋。我意识到了这个项目的一个“关键”要求:从检测到采取行动的时间间隔必须近乎瞬间完成。
最初,我的三个后端服务(DrWadachi、BirdWatcher 和 GardenGateway)是通过读取和写入共享的 JSON 文件来进行通信的。虽然这种方式简单,但文件输入输出(I/O)速度极其缓慢,还容易出现竞争条件,从而导致额外的数秒延迟。为了弥补这一缺陷,我决定通过共享内存来探索进程间通信(IPC)的方法。
要掌握这项技术需要一些技巧,但通过将共享内存引入到三个 Python 服务中,我构建了一条速度极快的数据通道。
通过将系统的状态(如天气警报、移动标志和土壤状况)直接映射到内存中的一个原始字节缓冲区中,延迟从秒级降低到了毫秒级。现在,当“观鸟者”发现阴影时,DrWadachi 就会根据内存中的变化做出浇水的决定,而 GardenGateway 会在入侵者迈出下一步之前通过 TCP 与 Haniwa 进行通信。
在这个系统中,“核心数据”(即信息)实际上是肉眼无法看见的,它深藏于硅片内部,但只要哈尼瓦的眼睛变成红色,其影响便会立刻显现出来。
代码
本文编译自hackster.io





