What was built and what it did. The Boom-eyes field unit is an ESP32-CAM that runs image classification on the device itself: a roughly 4 MB int8-quantized YOLO model, fine-tuned on custom classes, classifying captures locally. In bench testing it classified its owner live ("label=Rob"), stored captures to the on-board SD card, and sent detection events over LTE to a Raspberry Pi server, where a native console displayed them with device status.

Close-up of Roberto Vega’s physical camera prototype mounted in a temporary bench fixture, with the camera lens and ribbon cable visible.
My ESP32-CAM bench prototype, with the camera lens, ribbon cable, and temporary mounting visible.

Local classification, remote visibility

I fine-tuned the image classifier for custom classes, exported it for integer inference, and integrated the exported model into the camera firmware. The field unit captures an image, prepares it for the model, runs inference, and returns the selected class and score.

This is image classification: the output names the class of the capture. Bounding-box detection adds object locations inside the image. Ultralytics documents classification as its own task.

Quantization gives the model a numerical representation suited to the embedded device. The deployment work connects that representation to the firmware’s input preparation, output interpretation, and label lookup.

Boom-eyes / system overview

From a captured image
to an observer’s decision.

  1. 01Camera + local AICapture an image; classify on the field unit.
  2. 02Cellular modemSend the event through the wired modem and wireless LTE uplink.
  3. 03Remote gatewayAuthenticate and forward the event.
  4. 04Event serverStore telemetry and evaluate notification rules.
  5. 05Observer consoleShow received events and operating status.
The five-stage path I built, from local classification to the observer’s console.

What the device actually sends

What the unit sends per event: a class label and score, an event ID, device identity, a reference to the image kept on the device, and operating status. The image itself stays on the device; the event is the telemetry. That distinction matters for anyone building a monitoring interface on top of it.

The modem is wired to the field unit and carries events over LTE. The phone screenshot below shows the camera’s local setup and capture interface. Image classification runs on the ESP32-CAM.

Phone screenshot of the ESP32-CAM local interface showing a captured image, capture-and-classify controls, a returned Rob label and score, and device readiness information.
The local camera interface classified my live capture as Rob with a score of 0.953125. The controls handle capture, streaming, sleep settings, and device status.

The server is part of the sensing system

A useful remote observation must survive the handoff from embedded code to network transport to storage. The server implementation authenticates incoming events, records telemetry, and creates notification work according to configured rules. Event identifiers let it recognize repeated submissions rather than treating every arrival as a new observation.

I track receipt, storage, and notification delivery as separate states. The event record and notification state show where an observation has reached in the workflow.

The custom native console reads service status and telemetry from the server’s local API. Its implementation includes recent observations and paged event details. The operator needs to distinguish a newly received observation from an old one, and a classification result from a device-readiness report. The console’s job is to make those differences visible for review.

Why this matters beyond a camera

The useful pattern is sensing near the source, moving a structured observation across an unreliable boundary, and presenting it with enough context for a person to decide what comes next. The same engineering discipline applies to instrumentation, robotics, and AI-assisted business workflows.

My text-classification experiment explores a related idea: extracting predefined, useful signals. The flood-forecasting case study looks at the evaluation demands of models connected to physical systems. Different inputs, but the same obligation to connect model behavior to a defensible decision.

I connect sensing and embedded connectivity to the work an observer needs to do next. AI-Rey’s services apply the same approach to recurring business tasks and the information behind them.

Scope, stated plainly. This is a working bench prototype, not a deployed product. Battery life, field accuracy across lighting and scenes, and end-to-end latency have not been measured yet. What is demonstrated is the full path: capture, on-device classification, cellular event delivery, server ingestion, observer console.

Sources and further reading

  • Project evidence: the original hardware photographs and device-interface screenshot supplied from the private Boom-eyes project, alongside inspection of its firmware, model-export tooling, telemetry server, and native-console implementation.
  • Ultralytics image-classification documentation explains the distinction between an image category and an object location.
  • Google’s microcontroller inference overview describes the embedded inference runtime family used by this implementation.

Explore AI-Rey services · Book a free fit call