Case study · Edge AI + field systems

← All work

BarnHub

BarnHub began with a midnight question: could a change in ordinary behavior become visible before a problem becomes an emergency? Five years of field work turned that question from per-bucket sensors into a computer-vision system built to watch the horse instead of instrumenting the stall.

Barn monitoring and computer-vision system shown across stable, camera, and monitoring contexts
Computer vision only becomes useful when cameras, networks, edge compute, behavior logic, and the barn itself work as one system.
Status
BarnHub V1.0 Alpha · active field deployment
Deployment
Fireside Farms · center stall · 24/7 monitoring
Primary signal
Per-horse drinking behavior and change from individual normal
Evidence
In collection · operating history, detections, misses, false positives

Running 24/7 in a real barn. Now the work is proving it.

BarnHub V1.0 Alpha is operating continuously at Fireside Farms, monitoring the center stall under ordinary barn conditions. The architecture, training pipeline, and computer-vision system are no longer confined to development work; they are being exercised in the field.

Alpha does not mean finished. It means the core system is real enough to stay in the field while the evidence is still being built: where it succeeds, where it fails, and whether the resulting behavior record becomes dependable.

The next evidence set will come from the deployment itself: operating history, drinking/eating/resting captures, missed detections, false positives, camera limitations, model changes, and the failures that force the architecture to improve.

ProductV1.0 Alpha

Working field system under active development.

Deployment24/7

Fireside Farms · center stall.

EvidenceIn collection

No generalized reliability or medical-efficacy claim yet.

The signal may be ordinary. The problem is nobody can measure it continuously.

Water became the first hypothesis. A horse going off water may matter before anything looks obviously wrong, but shared troughs, topped-off buckets, changing schedules, and human observation make individual drinking difficult to measure consistently.

BarnHub is built around a narrower engineering question than diagnosis: can the system establish each horse's ordinary pattern, observe drinking day after day, and surface a meaningful change soon enough for a person to go look?

First instrument the water. Then remove the instrument.

The design changed because the field kept voting against unnecessary hardware.

01Measure the bucket

IoT water meters were installed per bucket to capture the signal directly.

02Meet the barn

Water, dust, temperature swings, power problems, mounting constraints, and animal contact turned every sensor into another maintenance point.

03Change the abstraction

If drinking can be seen reliably, the system can measure behavior without putting fragile instrumentation in the stall.

04Watch the horse

Computer vision became the primary path for drinking, eating, resting, presence, and related behavior.

Detection is the input. Behavior is the product.

A bounding box around a horse is not enough. BarnHub combines object detection with camera-specific regions, motion and geometry features, behavior rules, temporal smoothing, and persistent state so momentary poses do not become noisy events.

BarnHub realtime behavior architecture showing YOLOv8 detection, camera configuration, feature extraction, heuristic behavior logic, LSTM temporal aggregation, state persistence, and resting, eating, drinking, and transition states
Working behavior architecture. YOLOv8 detections feed feature extraction and camera-specific regions of interest; behavior logic and temporal aggregation are then stabilized through state persistence before event output. Thresholds and minimum-duration rules are engineering parameters, not medical criteria.
See

Detect the horse and head, then calculate motion and aspect-ratio features from the video stream.

Locate

Use per-camera regions of interest for places that give behavior meaning, including hay and water zones.

Interpret

Combine geometry, motion, and temporal context to classify eating, drinking, resting, or an uncertain transition.

Persist

Track state and duration so one frame does not become a behavioral conclusion. Minimum-duration rules and transition smoothing reduce churn.

The failures become the next training set.

The improvement system is designed around harvesting difficult real-world examples rather than pretending the first model is finished. Edge capture produces clips and metadata; candidate frames are reviewed and labeled; approved annotations flow back into retraining and validation.

BarnHub self-learning harvester automation flow showing Jetson capture, offline inference, artifact preparation, CVAT manual annotation review, and retraining pipeline
Training-loop architecture. The Jetson capture plane saves useful clips and metadata; offline inference exports training candidates; CVAT provides human label review and approval; approved labels feed dataset aggregation, retraining, validation, and model deployment. Human review remains part of the loop.
01

Harvest

Capture good clips and the metadata needed to understand why the model succeeded, failed, or became uncertain.

02

Filter

Offline inference and metrics identify useful training candidates instead of sending every frame into labeling.

03

Review

CVAT is the human-control point: annotations are reviewed and approved before becoming training truth.

04

Retrain

Approved labels aggregate into the dataset; new models are retrained, validated against metrics, and only then become deployment candidates.

The model is only one component of the measurement system.

Computer-vision concept situated in a working barn environment
The environment is part of the architecture: stable, cameras, edge devices, connectivity, and the application.

Connectivity is part of the product

Long runs, bridges, access points, camera networks, and edge devices become one system. A model is not useful when the video never arrives.

Visibility is imperfect

Animals move behind walls, gates, people, equipment, and one another. Lighting changes. Camera position matters. The input itself is uncertain.

Shared resources hide individual behavior

Knowing that a trough level changed is not the same thing as knowing which horse drank. The useful unit of analysis is the individual horse over time.

Existing cameras are a harder, better test

Real-world tolerance matters more than a perfect demonstration. Footage evaluation deliberately asks barns not to re-aim or upgrade cameras before testing.

Observe change. Do not pretend observation is diagnosis.

BarnHub V1.0 Alpha is working field software. The useful claim is bounded: monitor behavior continuously, establish patterns, and tell a person when something deserves attention.

Behavior

Eating · drinking · resting · presence

The system is being developed around ordinary, repeated behaviors that can be compared over time.

Baseline

One horse compared with itself

The target is change from that horse's own normal pattern, not a population-average definition of a “normal horse.”

Attention

Surface the change sooner

The system is intended to narrow the gap between when a pattern changes and when a human notices.

Boundary

Not a medical device

BarnHub does not diagnose colic or replace staff, owners, or veterinarians. It tells you something changed so you can look sooner.

Send ordinary footage. Do not optimize it for the model.

The next evidence problem is generalization: how well does BarnHub hold up against cameras, angles, lighting, compression, layouts, and horses it was not developed around?

What is useful

  • Continuous footage when available, including overnight
  • A stall or run with the water source visible
  • The resolution and camera placement already in use
  • Clips are fine when the camera system does not export continuous video

What comes back

  • Which horses the model could track and where it lost them
  • Whether drinking was visible from the existing camera angles
  • Whether failures look like camera-placement problems or model problems
  • An assessment of whether the current setup can support useful analysis at all

Data handling

  • Submitted footage is used for the requested analysis and is not shared with others
  • Retention for model improvement requires a separate, explicit opt-in
  • Staff, boarders, farriers, and others visible in the footage should be informed before it is sent
  • Participation is an evaluation, not a sales funnel

The public installed-system local-versus-cloud boundary remains intentionally unspecified until that deployment architecture is finalized and verified.

The model is not an oracle.

Behavior inference from video remains probabilistic. Occlusion, lighting, shared resources, individual baselines, and incomplete views can all make an apparently simple question difficult to answer with confidence.

Alpha means it will get things wrong. Those misses are not embarrassing edge cases to hide; they are the evidence needed to decide whether the product can become dependable.

The Night Shift No One Sees

The technical project began with a personal observation. The voice changes here deliberately: this is Christopher Wolff's account of the problem that started BarnHub.

Colic doesn't start as an emergency. It starts as a change in pattern that nobody is around to notice.

Ours announced itself at midnight. A horse in clear distress, a fast call to the vet, and the long wait every barn hopes to avoid.

We were lucky. Not everyone is.

I should say up front that I am not a horse person. Horses are my wife's life. I'm the one who ends up in the barn anyway, and what I do there is what I do everywhere: count things and notice what nobody is counting.

What stayed with me that night wasn't the chaos. It was the timing.

This didn't begin at midnight. It began hours earlier, maybe longer, and it began quietly, in a barn where people were paying attention.

So I started asking which signal came first. Not as a horseman. As someone who has spent a career looking for the measurement everyone skipped.

My best guess is water.

A horse going off water may be telling you something well before anything looks wrong. It's also one of the hardest things in a barn to see.

Buckets get topped off. Troughs are shared. You can tell the water level went down. You can't tell which horse drank it, when, or how much less than yesterday.

That isn't a failure of care. Nobody can watch a barn around the clock, and nobody who did could count gallons per horse.

It's a structural blind spot, the kind that shows up in any system where the thing that matters most is the thing no one is positioned to measure.

That's the part I couldn't let go of.

Whatever we missed wasn't subtle, hidden, or mysterious.

It was a number sitting in plain sight that nobody was in a position to collect.

That was five years ago.

Most of that time I spent noodling. Theorizing. Wiring up IoT water sensors that did not survive contact with an actual barn.

What changed is computer vision. It finally got good enough to watch the horse instead of instrumenting the bucket, which means I can finally test whether the hunch holds up.

That's BarnHub. I'm still not a horse person. But I'd like to hand this community something useful, and I'd like to find out whether I'm right.

Expanding the team.

As BarnHub moves from Alpha into broader field use, it is the right time to add a commercial owner.

We are looking for a hands-on business development / commercialization lead who can help expand the pilot program, recruit barns, build customer relationships, and turn field evidence into adoption.

If that sounds like you — or someone you know — we would like to talk.

BarnHub is the proof behind the headline.

"Evidence before capability claims" only means something if the failures are visible too. BarnHub shows the difference between understanding computer vision and making an AI system survive cameras, networks, weather, uncertainty, privacy, labeling, retraining, and daily operations.

That is the standard carried into client work: observe first, diagnose the real constraint, change the design when the evidence disagrees, and do not call it finished until it works outside the presentation.

The point is not that nothing fails.

The point is that the failures become information, and the system gets better because they were measured instead of hidden.

Return to selected work →