Home Blog Bear or Rabbit? On-Device AI Garden Monitoring wit...

Bear or Rabbit? On-Device AI Garden Monitoring with Raspberry Pi and Soracom

Director of Customer Reliability Engineering

How It Works

The flow is a short local loop:

Ultrasonic sensor detects something approaching
  → Camera captures a single still image
  → On-device AI (TensorFlow Lite) classifies it as bear / rabbit / background
  → A per-animal buzzer pattern plays
  → The captured image is uploaded to Soracom Harvest FilesCode language: JavaScript (javascript)

An ultrasonic sensor watches for foreign objects closer than a configurable threshold. When something crosses it, a Raspberry Pi Camera takes a photo, and a TensorFlow Lite model running on the Raspberry Pi decides what it’s looking at. Based on that result, the device plays a buzzer pattern (loud for a bear, or a short, gentle chirp for a rabbit), and uploads the image to the cloud so you can review detections later and reuse them for training.

The Key Decision: Run the AI on the Edge

The most important architecture choice in this build was whether to run the AI on the device (edge) or in the cloud. In IoT, this single decision shapes latency, offline behavior, and operating cost, so it’s worth being explicit about it.

For a predator deterrent, response time is the whole point. A warning that arrives a couple of seconds after the fact is a warning that arrives too late. If we shipped each image to a cloud AI and waited for the verdict, that round trip would sit directly between the “animal detected” and “buzzer sounds” events, pushing the timeline and rendering the alert pointless. But if we run inference locally: capture-to-decision takes about 0.6 seconds with a resident process and an always-on camera, and also keeps working if connectivity briefly drops, meaning detection and the buzzer don’t depend on the network being up.

As a rule of thumb: choose edge AI when you need immediate reactions or offline operation, and cloud AI when you need heavy compute or aggregated analysis across many sites. This trade-off is evident in Soracom’s own recent inventory monitoring demo, which sends images to a cloud model via Soracom Flux – ideal for when periodic, richer analysis matters more than millisecond latency. Each demonstration utilizes the same building blocks with opposing placement driven by the requirements of each project.

Putting the AI on the edge does create a new wrinkle, however: once the device is in the field, how do you update it? Models drift, thresholds need tuning, and driving out to the site creates both time and financial costs. Our answer:

The model and settings are updatable over the network, and
detection images accumulate in the cloud, ready to become training data for the next model.

Both of those rely on Soracom, which I’ll cover below.

The Conception – and the “Rabbit Problem”

This prototype started at a Soracom team offsite. A teammate described how rabbits wander into their backyard, and how they look forward to photographing them each year. The problem was that rabbits sometimes fall prey to coyotes and other predators. The goal became keeping predators away, for the sake of both the rabbits and the household’s peace of mind.

At first I thought: “we only need to sound the alarm for dangerous intruders like bears and coyotes, rabbits are cute, so why not let them visit?” So, of course, I trained a bear-only model that ignores rabbits entirely.

Then I reconsidered. Rabbits eat the garden vegetables, and a rabbit that stays wary of humans and keeps its distance is arguably safer for it. Maybe everyone is happier if they simply stay out of the garden. So I trained a second model that also detects rabbits, and made the active model switchable from the dashboard. There’s no single correct answer here, and being able to express that ambiguity as a runtime toggle was one of the more satisfying parts of the build.

Building the Model

Materials

IoT devices: Raspberry Pi 3 Model B, Raspberry Pi Camera Module 2, HC-SR04 ultrasonic sensor, an active buzzer (driven by an S8050 NPN transistor), and a Soracom Onyx LTE™ USB Modem as a backup connectivity path
Soracom services: Soracom Arc, Soracom Harvest Files, Soracom Remote Command

The model is a transfer-learning classifier built on MobileNetV2, with a 160×160 input, exported to TensorFlow Lite with float16 quantization (about 4.4 MB — small enough to push over the network). It has three classes: bear, rabbit, and background (“other”).

That background class is not optional, and I learned this the hard way. With only two classes, an empty scene still gets forced into one of them — at one point an empty table was classified as a bear with high confidence, and the buzzer went off. Feeding real “nothing here” shots in as a background class fixed it, and a minimum-confidence threshold drops anything below it back to “other” as a final guard.

The per-animal behavior lives in a small config that the device reads at runtime; an active buzzer only does on/off timing, so a pattern is just a rhythm:

{
  "buzzer": {
    "animal_patterns": { "bear": "pupupu", "rabbit": "triple_chirp" }
  },
  "detection_threshold_cm": 45.0,
  "model_path": "models/model-bear-rabbit.tflite"
}Code language: JSON / JSON with Comments (json)

Remote Fleet Management with Soracom

This is where the “deploy once, keep improving remotely” story comes together. Everything below happens without physically touching the device.

Soracom Arc connects the Raspberry Pi to the Soracom platform over a secure WireGuard tunnel, even on plain Wi-Fi.
Settings (detection threshold, buzzer volume, per-animal patterns, active model, camera rotation) are stored on a SIM tag and pushed to the device with Soracom Remote Command. The monitor process hot-reloads them; no restart, no downtime.
New models are uploaded to Soracom Harvest Files, then pulled down by the device and swapped in, over-the-air model updates for an edge AI.
Detection images land in Harvest Files, labeled by animal, so you can review them and reuse the mistakes as training data for the next round.

All of this is driven from a small web dashboard I call “Garden Monitor” (running on AWS Lambda behind a Function URL). From the browser you can tune thresholds, start/stop monitoring, browse detections, and upload a new model.

Retraining at the Venue

Image models tend to pick up on their training environment. Our booth had a distinctive backdrop (a brick-pattern wall and a Soracom-logo cloth) so after setting up on site, I captured 152 fresh photos in the venue’s actual background and lighting to retrain the model using a small burst-capture script while nudging the subjects between shots. Verified against every venue photo, the retrained model classified them correctly.

Conference networks rarely put your laptop and device on the same LAN. When that happened, I reached the Raspberry Pi with Soracom Napter (on-demand remote access) and applied config and model changes through Remote Command exactly as before. Being able to go from “retrain on my laptop” to “swap the model on the show floor” with minimal on-site fuss is precisely the payoff of building in remote management from the start.

Built Almost Entirely by a Coding Agent

There’s one more thing worth calling out, and it fits this year’s Discovery theme: “As AI evolves, IoT moves to its next stage.”

The dashboard UI, the backend that calls the Soracom APIs, and the monitoring application on the Raspberry Pi were all written largely by a coding agent (Claude Code). The software came together in roughly a day. My contribution was the physical part: wiring the breadboard, adjusting the camera angle, and taking the photos for model training.

That shifts what a proof of concept costs. When an agent can produce the glue code, the dashboard, and the device app, the distance between “I have an idea” and “there’s a working thing on the table” gets dramatically shorter – which is exactly what a prototyping booth is meant to show.

Conclusion

This garden monitor is a small build, but it captures a decision every IoT project faces: where the intelligence lives. Placing the AI at the edge gave us the sub-second response a deterrent needs and resilience to network hiccups; wiring the device to Soracom Arc, Harvest Files, and Remote Command gave us the ability to tune settings, ship new models, and collect training data long after deployment. Edge for speed, cloud for management and improvement – and, increasingly, an AI coding agent to build the software in between.

Got a question about Soracom? Whether you’re an existing customer, interested in learning more about our products and services, or want to learn about our Partner program — we’d love to hear from you!