Person-Gated Inference: Running Pose and Audio Models Concurrently on a Sub-$700 Edge Box

I'm building a passive safety-alerting system for elderly parents living alone: an edge-AI box that watches indoor common-area cameras for a person on the floor and not moving, or acute distress sounds, and escalates through a human contact tree until someone acknowledges. It deliberately never contacts emergency services directly — escalation stops at a person, always. That's a design constraint that shapes the whole system, not an afterthought bolted on at the end. This is the technical validation work behind it: the two real risks that had to be proven on real hardware before anything else got built.

Why inference has to happen on the box

A cloud-dependent system that goes blind the moment a home's internet drops is not a safety system, so the pose and audio inference has to run entirely on local hardware, continuously, with no round trip required to detect an event. That constraint rules out a lot of otherwise-reasonable architectures and points directly at a small edge box with a dedicated AI accelerator rather than a general-purpose GPU: a 26-TOPS M.2 accelerator card draws a fraction of a GPU's power and cost while still handling the actual workload — pose estimation and audio classification running concurrently, continuously, on a box that sits quietly in someone's house.

Person-gating: the trick that makes one accelerator cover six cameras

Running a full 17-keypoint pose model on every frame of every camera, all the time, is wasteful — most of the time, most rooms are empty. The actual architecture gates the expensive model behind a cheap one: an always-on, low-cost person-detector runs continuously and costs almost nothing, and the full pose-estimation model only spins up when a person is actually present in frame. Run that alongside a concurrent lightweight audio classifier listening for glass breaking, screaming, or shouting, and one accelerator card covers six to eight camera feeds instead of one. The pattern is the same shape as routing a request to a cheap classifier before an expensive model — don't run the expensive thing until something cheap has confirmed it's actually needed.

The first real risk: does the accelerator even work on this hardware?

AI accelerator cards built around this class of chip are validated primarily against ARM single-board computers, not standard x86 mini-PCs, and the driver stack's default configuration has a known page-size mismatch that's the single most common reason this hardware fails to initialize cleanly on x86 Linux. Rather than assume it would work and build the rest of the system on top of that assumption, the validation plan treats it as a hard, sequential gate: confirm the device physically enumerates on the PCIe bus, confirm the driver loads without the page-size error, and only then confirm that a real model actually executes and reports frames per second on the chip. Enumerating is not the same as working — a device can show up on the bus and still never successfully run inference, and the plan explicitly calls that distinction out as a checkpoint of its own, not something to assume once the earlier step passes.

The second real risk: does a cheap camera hold a stream on real Wi-Fi?

The consumer-installable version of this system depends on plug-in Wi-Fi cameras rather than wired PoE cameras, which is a real reliability-for-installation-economics tradeoff, not a free win. Continuous detection needs a continuous stream, which immediately rules out battery-powered cameras: manufacturers disable continuous streaming on battery models specifically to conserve power, so the "must be plug-in, wall-powered" hardware requirement falls directly out of the inference requirement rather than being a preference. The remaining open question is whether a plug-in Wi-Fi camera holds a stable low-resolution substream continuously, for days, on an ordinary home network rather than a clean lab network — and whether stream loss itself is detectable and alertable, since a fall-detector that goes silently blind is a worse failure mode than one that never worked at all.

The safety net has to heal itself, and you have to watch it happen

Because these are unattended boxes inside someone's home, a software update that breaks the device can't be fixed with a phone call. The recovery architecture keeps two bootable operating-system partitions; an update boots into the currently unused one, and it only becomes permanent if a scripted health check passes afterward — accelerator present, inference pipeline actually detecting, heartbeat agent alive. If that check fails, the device automatically falls back to the last known-good partition with zero human action required. The validation plan doesn't treat a clean update as proof this works. It requires deliberately shipping a broken update and watching the box roll itself back before the mechanism is trusted at all — "I shipped something broken and it healed itself" is the actual bar, not "a normal update went fine."

The discipline that matters here

The tempting sequence is to build the full provisioning and deployment pipeline first, because that work feels productive and concrete. The sequence I'm actually following is the opposite: prove the two riskiest unknowns — the accelerator actually working on this exact hardware, and a cheap camera holding a stable stream on a real home network — before investing in any tooling that assumes they're solved. If either one fails, that's the signal to change the hardware or the architecture, and it's far cheaper to learn that from one validation pass than after a provisioning pipeline has been built around an assumption that turned out to be wrong.

I'm Jesse Myers — Marine veteran, 32 years in enterprise IT, now building production AI systems. This site is where I write about what I've actually built, technically, in my own words.