Hardware — reference designs, open-sourced

We don't sell hardware.
We build it to keep ourselves honest.

Mimirly is a software platform. But claims about a device abstraction layer mean nothing until they're tested against a real machine with real constraints — RC signal lag, sensor noise, GPS-denied canopy, battery limits. So this team builds small reference endpoints, proves the Commander can run Observe-Decide-Act-Verify against them, and open-sources what it learns. No product line, no hardware business model — the reference designs exist to keep the software honest and to give operators without a ground or air asset already a way in.

Why we touch hardware at all

BYOD is still the default.

Most operators already have usable hardware. A DJI drone in the ute. An RC-based platform in the shed. A virtual fence system on the herd. Bringing your own hardware is the default path into Mimirly, and it stays that way.

Building reference hardware isn't a departure from that. It's how the team proves the abstraction layer actually works before asking a farmer, a mine site or a construction operator to trust it with the gear they already rely on.

If the Commander can drive a small tracked rover we built in a workshop, and a companion app on someone else's DJI drone, through the same endpoint contract — the contract is real.

Reference architecture

An endpoint, not an island.

Every reference design is built against the same four-layer contract the Commander uses for third-party drones, rovers, sensors and telemetry.

01
Commander

The coordination layer. Runs Observe → Decide → Act → Verify across every connected endpoint on a site.

02
Endpoint adapter

A thin, standard interface. Any endpoint, whether an operator's existing unit or a Mimirly reference design, talks to the Commander through the same contract.

03
Endpoint on-board

Navigation, payload control and local buffering. Enough intelligence to be useful when the link is bad, not so much it drifts from the plan.

04
Payload / capability bus

Power, data and mounting standard on the deck or frame. Payloads and sensors are discoverable — the Commander knows what's on site.

Reference designs

What the team is building right now.

Two working reference endpoints — one on the ground, one in the air. Both exist to prove the loop end-to-end against a real machine.

Open, not proprietary

Meant to be built on, not bought.

The reference designs are meant to be built on, not bought. Over time this includes published BOMs, wiring diagrams, firmware, and a Commander device manifest — so technical users, maker communities, and agricultural or engineering colleges can build their own endpoints rather than needing ours.

This is in-progress, not fully live yet. Leave an email and we'll get in touch when the first designs publish.

Talk to us about hardware

Bring your own hardware, or start with a reference design.

If your operation already runs a ground or air platform, we want it on the endpoint contract. If it doesn't, the Rover and Mimirly Flight are ways to prove the loop without a hardware project of your own.