Most drone software demonstrations are run on the aircraft the software company sells. That is understandable, and it tells you very little.
Last week we did the opposite. We took IDI Fly into a field with a third party MAVLink based VTOL fixed wing aircraft that we did not design, did not build and do not sell, and we flew it. With us were the University of Southampton UAV team, who have been working with us on the integration, and the NPCC drone team, who are evaluating the airframe for drone as first responder work.
This is a field note rather than a product announcement. The evaluation is ongoing and nothing here is a delivered capability. But the day was useful enough to write up honestly, including the part that did not pass.
The test card
We agreed the objectives in advance and flew against them in sequence:
Automated take off
Transition from vertical lift to forward flight
Orbit on task
Geofence behaviour
Manual control
Return and land on the take off point
That list is deliberately unglamorous. It is also the sequence that has to be boring and repeatable before anyone should discuss deploying an aircraft to a live incident.
What happened
90% of the test card passed clean. Take off, transition, orbit, geofence and the return to land all behaved as expected.
The 10% was manual control. Partway through that phase a faulty USB connection dropped the link to the manual controller. The aircraft did not wobble, did not hesitate and did not do anything dramatic. It handed control straight back to the dashboard and continued under IDI Fly. No safety event, no loss of the aircraft, no drama on the ground.
The fix is a hardware one, not a code one. A connector, not a control law.
Why we are publishing the 10%
There is a reasonable argument for leaving that paragraph out. A cleaner write-up would say the aircraft flew the profile and leave it there.
We are including it because failure behaviour is the only part of a flight test that tells you anything about a bad day. Any competent stack can fly a good day. What a policing customer actually needs to know is what the system does when a component fails mid-flight, and whether the degradation is graceful or sudden. In this case a physical connector failed and control reverted to the dashboard without the operator having to intervene. That is the behaviour you want, and we only know it works because something broke.
If you are evaluating any drone platform, that is a better question to ask than the range figure. Ask what happens when the link drops. Ask what the aircraft does, what the operator sees, and how long the transition takes. Ask to be shown it, not told it.
Why fixed wing VTOL matters for DFR
Drone as first responder in the UK has been built almost entirely on multirotors, and for good reason. They launch from a small footprint, they hold station over an incident, and they suit dense urban geography where the next call is rarely far away.
The limitation shows up when you move away from that geography. A multirotor's endurance and speed set a radius around the launch point, and outside that radius the response time argument stops working. For a rural force, or for a force covering a large area with a small number of launch sites, the coverage maths is unforgiving.
A fixed wing VTOL changes the shape of the problem. It launches vertically, so it does not need a runway or a catapult, then transitions to wing borne flight and covers ground far more efficiently than a rotor can. One launch point serves a much larger area.
That is why the NPCC VTOL and fixed wing team are evaluating this class of aircraft, and why we wanted IDI Fly tested against one properly rather than on paper. If DFR is going to reach beyond a handful of urban footprints and serve rural forces and the wider emergency services, this capability has to be in the mix alongside multirotors, not instead of them.
The software layer has to be airframe agnostic
Here is the part that matters most to us as a software company.
A force that commits to DFR is not buying one aircraft. Over a decade it will run multirotors on docks, it will probably run fixed wing VTOL for reach, and it will run whatever comes next. If each of those arrives with its own ground control software, its own operator training and its own evidential record, the force ends up operating three systems and defending three sets of data.
Our position is that the control layer should not care what you bolt it to. One dashboard, one operator experience, one evidential record, whether that is a multirotor on a dock or a third party fixed wing VTOL flying a MAVLink stack. Last week was a test of exactly that claim, on hardware we had no control over.
It is worth being precise about what that took. Airframe agnostic does not mean plug and play. Getting IDI Fly talking properly to this aircraft took real integration work, and the Southampton team have been excellent to work with on it. The point is not that no work is required. The point is that the work happens once, in the software layer, rather than landing on the operator every time the fleet changes.
What happens next
The evaluation continues. There are hardware tweaks to make on the manual control side, more of the test card to extend, and more flying to do before anyone draws conclusions.
We will keep publishing what we find, including the parts that do not pass first time. If you are a force weighing up where fixed wing fits alongside your multirotor fleet, or you want to understand what an airframe agnostic control layer would mean for your operation, talk to us.
FAQs
Which aircraft did you fly?
A third party MAVLink based VTOL fixed wing aircraft being evaluated by the NPCC. We are not naming the manufacturer while the evaluation is in progress.
Does this mean IDI Fly supports any MAVLink aircraft?
Not automatically. MAVLink is a common protocol rather than a guarantee of compatibility, and integrating this airframe took genuine engineering work with the University of Southampton UAV team. What the test demonstrates is that the platform is not tied to our own hardware.
Is this a live DFR capability?
No. This is an evaluation in progress. Nothing described here is deployed or in service, and no operational authorisation is claimed or implied.
What was the failure, exactly?
A faulty USB connection dropped the link to the manual controller during the manual control phase. Control reverted automatically to the IDI Fly dashboard. It was a hardware fault in the test kit, not a software fault, and there was no safety event.
Does fixed wing replace multirotors for DFR?
No. They solve different problems. Multirotors suit dense urban coverage and holding station over an incident. Fixed wing VTOL extends the radius a single launch point can serve, which matters most for rural and large area forces.
