for another year or so. But rather than sit on it until it's "finished," I've decided to publish parts of it early, partly to document my own progress and keep myself honest about where things stand.

Why This Project

As probably no one needs telling, bees are struggling. Rising temperatures and pollution are part of the picture, but one additional factor is the Varroa mite — a parasite that attaches to bees from the pupal stage onward, usually latching onto a gland on the thorax. Left unchecked, it can debilitate individual bees and cause hive collapse. The good news is that there's a relatively simple treatment: dusting with icing sugar causes the mites to detach.

The catch is that monitoring hives is hard. Treatment options exist, but any time spent monitoring adds to the cost of beekeeping — even when the treatment itself, like sugar, is cheap.

There are already serious efforts underway to breed mite-resistant bees that can detect and remove the parasites themselves, alongside other pest-control approaches. This project isn't trying to compete with that — it's aiming for something cheap and pitched somewhere in the middle: automated enough to be useful, simple enough to be affordable.

Project Outline

The project breaks down into a few distinct phases:

1. Basic hardware integration and testing — collecting a test set of bee images over time from a local hive.
2. Training and synthetic data generation, if the real-world data proves insufficient on its own.
3. Testing of the monitoring system in the field.

The project was originally put on hold for a while, largely because compute costs went vertical. I'd intended to build around Google's Coral AI chip, but given Google's decision to more or less abandon support for it around 2022, building a project on a deprecated chip — however efficient it is at inference — started to feel pointless. Recently, though, Google has been shifting priorities, announcing plans to sell its own larger chips (the same ones powering Gemini). After a decade of the industry sitting on the fence about it, AI workloads are still fundamentally the same calculations TPUs handle efficiently — without the von Neumann architecture bottleneck GPUs carry. So I'm hopeful Coral won't stay ignored forever.

Hardware

• Raspberry Pi Zero W (v1 — the v2 is out of stock until 2027)
• UPS — a simple 18650 battery UPS board
• Solar panel with built-in voltage regulation
• Coral USB Accelerator
• Camera — two options being tested: a standard OV5640 module and a USB scope/probe camera
• 3D-printed case — designed and post-processed to be watertight
• 
  

Architecture of the Current Software

The software side of the project is made up of six scripts that each handle one job, all living together on the Pi under /home/pi/hive/scripts/. I'm awaiting the Coral hardware accelerator to be able to test the full hardware in real time before approaching a local beekeeper for their assistance. capture.py, counter.py, logger.py, sleep_manager.py, wifi_server.py, and main.py, and all now pass their own self-tests in a dev environment without Pi hardware (camera, GPIO, and the hotspot tools all fail gracefully when unavailable, which made it possible to build and test most of this off-Pi before ever touching real hardware).

sleep_manager.py runs a simple ACTIVE / IDLE / SLEEPING state machine so the Pi isn't burning battery and solar charge monitoring an empty hive entrance overnight. To keep power draw down without missing real activity, waking from sleep draws on three methods in combination, weighted depending on the time of day: an ambient light sensor over I2C to confirm daylight hours, a small vibration/accelerometer sensor mounted on the hive body to pick up the low hum of bee traffic directly, and a lightweight low-resolution camera frame-diff check as a final trigger before the full detection pipeline spins up. It only stays active during a configurable daylight window — 06:00–20:00 by default, dropping to idle after a period with no activity detected. A force_active() method exists purely for manual testing and setup, letting you override the state machine while wiring things up. If it's running somewhere without real hardware attached, it fails soft: sensors default to an inactive reading — enough to let the rest of the pipeline be tested without any hardware attached.

logger.py handles persistence. It writes counts and sessions to a local SQLite database, supports CSV export, and keeps an eye on free disk space, writing a row to a storage_log table on every check without ever raising an error that could take down the main loop. It also accepts an optional database path, so tests (and the web UI, when it wants a scratch copy) don't have to touch the live database.

wifi_server.py is the field-access layer. Rather than needing a permanent network connection, the Pi periodically broadcasts its own hotspot — HiveMonitor — for a short window during daylight hours, and serves a small Flask-based web page over it. That page (a single self-contained HTML template, no external assets, so it works even with no upstream internet) shows the day's counts and current storage status, and offers downloads of the database or a CSV export. It pulls its stats by importing logger.py directly, and falls back to a bare filesystem check if that import fails for any reason.

main.py is the orchestrator — it runs the main capture loop and ties the sleep manager, logger, and camera pipeline together. One deliberate design choice: the cv2 (OpenCV) import happens lazily, inside the frame-processing loop rather than at the top of the file, so the whole system's wiring and state-machine logic can be validated in --test mode even on a machine without a working camera or OpenCV/picamera2 stack installed.

capture.py and counter.py round out the pipeline: capture.py grabs bursts of frames from whichever camera is attached, and counter.py does the actual computer vision — tracking blobs across a configurable counting line to tally bees moving in and out, with an HSV colour range for flagging likely mite presence, and an optional path through the Coral accelerator when USE_CORAL is enabled (falling back to CPU otherwise).

Every script shares the same conventions: constants declared at the top, pathlib.Path used throughout, logging to both file and stdout, and a --test mode that writes results to logs/test_<module>.log. setup.sh ties it all together — installing dependencies, enabling the camera interface, installing the systemd services, and running all six self-tests automatically on first setup.

Where It's Headed Next

The basic setup is close to field-ready, pending the Coral accelerator arriving so the full hardware can be tested end-to-end before approaching a beekeeper. Data collection itself doesn't need a permanent connection — the Pi acts as its own server for a short window each hour during active daylight periods, and a device with the right credentials within about 30 metres can connect to pull files and logs down. There are a few hives I pass daily on the way to my workshop, and I'm hopeful their keepers will be happy to have the project nearby and to help keep local storage from filling up between visits.

In its basic form, with the accelerator attached, the goal is for the system to monitor drone health and spot parasites before they become a real problem for the hive. Beyond that, it should also be useful for simpler tasks like estimating hive population — not every bee travels in and out each day (that varies by bee type and age), but keeping a running tally of in/out movement still gives a useful proxy for colony size.

The Longer-Term Goal

The final goal — still a long way off — is to isolate and treat individual mite-carrying bees as they come and go from the hive, most likely by focusing on returning bees, since that's the more tractable direction to monitor.

Bee movement in and out of a hive follows well-documented patterns, which suggests it should be possible to guide bees through a narrow physical channel on the way in — a kind of "airlock" — and briefly dust any mite-carrying bee with powdered sugar as it passes through.

Any mechanism to briefly slow a bee down would obviously need to be safe — something like soft brushes, or cilia modelled loosely on a Venus flytrap, not to restrain the bee but simply to obstruct forward and backward movement for a moment. In the bee-sized channel, a grate would move back and forth to lightly dust the bee, while a second grate below — sized to let mites fall through but too fine to trouble the bee — would catch and remove the dislodged, now-suffocating mites. Once dusting is done, the cilia barriers would retract, letting the cleaned bee carry on into the hive.

This stage would likely need a second board, or at least an additional camera dedicated to monitoring the isolated bee as it moves through the dusting channel, with some way to switch between systems, since the general monitoring software is already pushing the limits of what the little Pi Zero can comfortably do. The overall power draw isn't large, though — power consumption monitoring will be part of the initial field testing, to make sure the solar panel is sized correctly. Since hives are largely inactive overnight, monitoring only needs to run during daylight hours anyway, which is exactly what the sleep cycle built into the software is there for.

The actual next steps are to combine the hardware and begin testing to make sure the system runs as expected, then start collecting test data. I'll post an update soon with results from the test setup, along with images of the prototype case both in progress and post-assembly.

Getting the image focused and clear, with no distortion, will also matter — that'll involve some tests to build a distortion matrix, borrowing the method from Tadj Cazaubons' undergraduate thesis project.

Once real data has been collected, I'll make the training set available for anyone else who has a use for it or is interested.