A drone you actually own.
An open platform — airframe, electronics, firmware and ground software, designed together. No cloud account, no remote kill switch, no no-fly zones imposed from somewhere else. Repairable, extendable, and still flying in ten years.
One platform, and a payload bay that isn't sealed shut.
A multirotor built as a whole system: airframe, flight controller, motor controllers, flight firmware and the software you use on the ground. All of it open — schematics, board files, source, documentation.
The payload is the part that changes. A camera and gimbal for most people, thermal for inspection work, and a documented mechanical and electrical interface for whatever you want to put there instead. That flexibility is deliberate: it is exactly what closed consumer drones refuse to give you.
Open drone tech is built by tinkerers, for tinkerers.
The open stack is technically mature and genuinely impressive. It is also, without exception, optimised for configurability rather than for working. Betaflight and iNav are hard to tame even for experienced pilots. Of OpenIPC — the open answer to DJI's video link — the current state of the art says:
“Best suited to tinkerers and developers, not pilots who need plug-and-play reliability.”
The other side of the market has the opposite problem. The polished drones work beautifully and belong to someone else: firmware updates you cannot decline, geofencing you cannot inspect, an account you must keep, a product line where swapping the camera is simply not offered.
Nobody has taken the open stack and made it genuinely pleasant to use.That gap is the entire reason this project exists.
- PrecedentExpressLRS displaced the proprietary radio links it competed with and is now the de facto standard, with hundreds of manufacturers building compatible hardware.
- PrecedentAM32 took over as the leading 32-bit ESC firmware after BLHeli_32 was discontinued.
- SoIn this exact market, open has already beaten proprietary twice. The model isn't a hope. It has a track record.
Simplicity comes from integration.
Betaflight isn't badly built. It is hardware-agnostic. It has to run on thousands of combinations of frames, motors and sensors, so it has to expose every parameter. And a large share of those parameters exist only to compensate in software for mechanical problems: vibration, gyro noise, resonance.
A DJI drone is easy to fly because the airframe, sensors, motors and firmware were designed together. The configuration didn't get smarter. The causes were engineered out.
We fix complexity at the cause, not at the surface.
Build it where integration pays. Adopt it where the standard already won.
Reinventing a solved problem is not a virtue. AM32 is excellent, open and actively maintained, so we use it and contribute back. The layers we build ourselves are the ones where owning the whole chain is the only way to deliver the simplicity above. Two layers are genuinely undecided, and they say so.
Ground software
OursWhere the usability win becomes visible
Setup, calibration, flight logs, firmware updates. Every integration decision further down shows up here as a step you no longer have to take — or it was not worth making.
Video link
UndecidedThe widest gap between open and closed drone tech
The live picture from the aircraft, and the layer where we are least ready to promise anything. Adopt OpenIPC, build our own, or defer it to a later phase — all three are still on the table.
RC link
UndecidedThe control radio
ExpressLRS won this category outright and hundreds of manufacturers build compatible hardware. Adopting it keeps every transmitter people already own; building our own gives that up for a small integration gain.
Flight firmware
OursOurs from the first commit
Written for one airframe and one board instead of thousands of combinations. That is the only way the parameter count actually comes down rather than being hidden behind a friendlier interface.
Flight controller
OursMeasured by how many setup steps it removes
Receiver and redundant IMUs on the board, processing headroom for self-calibration, connectors instead of solder pads. Every one of those costs parts and removes work for the owner.
ESC firmware
AdoptedAdopted, not rebuilt
AM32 — open, actively maintained, and the successor to BLHeli_32 since it was discontinued in 2024. It has already won; rebuilding it would be burned time.
ESC hardware
OursPart of the integration
Four motor controllers designed as part of the aircraft rather than bought in: telemetry the firmware can act on, connectors, and thermal behaviour matched to our own airflow.
Airframe
OursWhere configuration complexity is created or removed
Vibration, gyro noise and resonance are mechanical problems. A frame we did not design leaves all of them for the firmware to filter out — which is exactly the parameter surface we are trying to eliminate.
- Built by us
- Open standard adopted
- Still undecided
Board fabrication and assembly are bought in. Manufacturing depth is a result of volume, never a route to it — Prusa builds in Prague today, but started with sourced parts and hand assembly.
Twelve months to an aircraft that flies.
All four layers built rather than sourced: airframe, flight controller, motor controllers, and the firmware on both boards. Months are relative, not calendar dates — a date would be a promise, and this is a build.
- 01Month 1–2
Definition and benchWe are here
Weight class and EU class path decided, parts selected, test rig built. Firmware skeleton on a dev board: sensors read, attitude estimated, control loop closed.
- 02Month 3–4
First boards
Flight controller and ESC, revision A — schematic, layout, fabrication, assembly. Bring-up on the bench: power, USB, sensors, and motors turning under our own firmware.
- 03Month 5–6
First hover
Mixing, arming, failsafe, rate and attitude control. Tethered hover on the rig — and logs good enough to explain what went wrong without guessing.
- 04Month 7–8
Airframe, first free flight
Frame, arms and motor mounts, with the flight controller decoupled structurally rather than by filter cascade. First flight outdoors, off the tether.
- 05Month 9–10
Revision B
What the first flights taught, fed back into both boards and the firmware. Auto-tuning and self-calibration, telemetry and logging that stand on their own.
- 06Month 11–12
Prototype
Five minutes of stable flight, and someone who has never seen it can fly it without a briefing. That is the moment this build stops being quiet.
Hardware moves at the speed of flying, crashing and reading logs — not at the speed of writing code. Twelve months is the target the work is planned against, not a guarantee.
The build is quiet until it flies. Then it is open.
There is no repository, no channel and no progress feed yet — deliberately. A running commentary on a machine that does not yet fly costs attention the build needs, and it asks people to follow something they cannot see. So the first twelve months happen in a workshop, not on a timeline.
The prototype is the moment that changes. When the aircraft flies for five minutes and someone who has never seen it can take the controls, the footage, the schematics, the board files and the source go out together — and everything after that is built in the open.
What will be needed then: firmware work, board review, mechanical design, test flying in conditions we don't have, and documentation written by someone who wasn't in the room when the decision was made.