Designing a VTOL testbed: constraints first

Our first flight platform is a VTOL — vertical take-off and landing combined with fixed-wing cruise. This post explains why we chose the harder configuration, and what "constraints first" means for how the testbed is being built.

Why VTOL at all

Multirotors are simple and hover beautifully, but their endurance physics are unforgiving: every minute aloft is fought for with thrust. Fixed-wing aircraft cruise efficiently but need runways or launchers — operationally disqualifying for the field work we care about (survey, inspection, response in places without infrastructure).

The hybrid takes the useful half of each: lift off vertically from anywhere, transition to wing-borne flight, cover real distance, return, land on a point. The price is the transition — the regime between hover and cruise where the aircraft is briefly neither, and control authority is at its most ambiguous. That price is exactly why we want it: a team that has mastered transition has mastered most of what makes small aircraft hard.

Constraints before features

The design conversation for the testbed starts from budgets, not capabilities:

• Power. Hover is the tyrant. The powertrain must survive worst-case hover draw with margin, while the cruise regime wants a completely different operating point. Sizing propulsion across both regimes — and knowing the battery reserve rule before the first flight — is the first design gate.
• Mass. Every gram is paid for twice: once in hover thrust, once in wing loading. Instrumentation, compute, and repairability all fight for the same mass budget, and the testbed's job is to lose that fight gracefully.
• Control. Transition logic in the flight controller is where firmware meets aerodynamics. We treat it as safety-critical code: staged, simulated, and flight-tested incrementally rather than tuned live.

Features — payloads, endurance targets, autonomy behaviours — get admitted only after the budgets close.

A testbed's job is to be crashed

We are explicit about what this aircraft is for. It is not a product prototype; it is an instrument for producing knowledge. That changes the design values:

• Instrumentation over polish. Every flight must produce logs worth analysing — attitude, power, control outputs, transitions. An un-instrumented flight is a wasted flight.
• Repairability over elegance. Field-replaceable arms, sacrificial components, and a spares discipline, because the fastest way to learn is to fly again tomorrow.
• A failure catalogue as a first-class artifact. Each incident gets a written entry: what happened, what the logs show, what changed. This catalogue is the real output of the programme — it is what the Prototype phase of our roadmap will be built on.

Where this goes

The testbed thread converges with our multi-agent coordination stack: the endgame is not one aircraft flying well, it is several coordinating. But sequencing matters — coordination logic riding on an unreliable platform teaches you nothing except which crash was whose fault.

One honest aircraft first. Then two.