Three flat-pack drone kits arrived at the workshop in early April. A bag of cable ties, a calibration weight, an unopened bottle of Loctite, three folded carbon-fibre arms still wrapped in factory plastic. An afternoon of solderless assembly later, three Holybro X500 V2 quadcopters were wired up on the workbench. By the weekend they were doing manual flights in a field outside Brussels. By the Monday after, they were crashing into things on purpose. By the Friday of that week, we were writing what would eventually become SAR.
This is how A Drone Company started: not with a polished pitch, not with a dressed-up prototype, but with three €350 development kits, a workbench, and a question we couldn't put down. Total hardware cost of the first fleet: around €1,780. Everything else — the autonomy software, the ground station, the mission logic, the integration with Drone One that came a year later — grew out of those three drones and the things they taught us in the air.
Three-part company narrative. Part 1 (this post): Our First Fleet — how three X500 V2 kits in a Belgium workshop turned into a software-and-hardware company. Part 2: Why we built SAR — what was missing in existing ground stations, and why we built the whole stack. Part 3: Why We Built Drone One — why the software company added hardware.
The question that put us in the workshop
The short version: we'd watched enough SAR teams — coastguards, fire brigades, mountain-rescue volunteers — try to use general-purpose drones for search-and-rescue missions to be sure that the gap was real. The drones were good. The pilots were skilled. The software they were running on was built for someone else's mission profile, and the friction between "I want to find a missing person" and "the ground station expects me to drop forty waypoints" was eating the critical first hour of every callout.
The honest answer to "why did you start" is that we couldn't stop thinking about that gap. The deep dive into the software thesis is Part 2 of this story. What matters here is what we did about it: we ordered three drone kits, cleared a workbench, and started flying.
Why X500 V2, specifically
The Holybro X500 V2 is the reference airframe for PX4 development. Folding arms, 500 mm wheelbase, ~1.8 kg MTOW. Solderless assembly — motors connect via bullet connectors, ESCs are pre-soldered to the power distribution board. Plug, calibrate, fly. The development kit ships with a Pixhawk 6C flight controller, an M9N multi-constellation GPS, BLHeli_S 4-in-1 ESCs, and 10-inch propellers. It's the airframe the PX4 community effectively standardises on, which means every SITL test, every online tutorial, every troubleshooting forum post references it.
That standardisation matters more than it sounds. Running hardware that matches the simulator means the gap between "works in SITL, fails on real drone" and "works in SITL, works on real drone" closes to almost nothing. We could iterate on multi-drone relay logic in PX4 SITL on a laptop, then validate against three real airframes the same afternoon, with confidence the simulator's behaviour wasn't lying. That feedback loop is what made the whole development cadence work.
What X500 V2 isn't: weatherproof, long-endurance, payload-flexible, or productised. It's a minimal platform. Which is exactly why it was the right choice for the workshop bench, and why we never tried to sell it as a customer drone.
The first sortie, and what it taught us
The first flight was a 90-second hover. The second was a 200-metre out-and-back. By the third afternoon we were running our first autonomous mission — a four-waypoint grid with a 50-metre side length — and watching the first prototype of what would become the SAR Ground Station follow the drone on a laptop screen.
Some of what we learned from those first weeks:
- Real wind is louder than simulator wind. The 6 m/s gust that PX4 SITL handles politely became a real gust that pushed the drone two metres off track and made the relay handoff logic re-trigger. Wind-aware relay parameters became a feature, not a nice-to-have.
- Battery curves are not flat. The simulator assumed linear battery drain. Real LiPos sag at low state of charge. Our first cycle of fleet-sufficiency math was wrong by 8%, which compounded across an eight-hour patrol into a missed handoff. We rebuilt the drain model against telemetry from the real fleet.
- GPS dropouts are common. The bench was 200 metres from a building that masked half the sky. The first time the drone flew behind the building, we got a GPS dropout we didn't expect. VIO continuity moved up the priority list that week.
- Three drones in the same airspace require thinking we hadn't done. The first multi-drone test put two drones near each other for a few seconds during a handoff. Nothing dangerous, but enough to push us to design the altitude-stagger and runtime collision-avoidance system properly rather than ad-hoc.
- Manual override has to be muscle memory. The day we put a motor in the ground was the day the three-layer safety architecture stopped being a design document and started being a drill. Every operator carries the RC transmitter; every operator throws the kill switch on demand without thinking; every test session starts with the throw rehearsal.
None of these were surprises in retrospect. All of them were things you learn by flying real drones rather than by reading other people's documentation about flying real drones. The workshop fleet was, in retrospect, the cheapest tuition we could have paid.
What was on the bench: the spec
| Item | Qty | Unit | Total |
|---|---|---|---|
| Holybro X500 V2 Development Kit | 3 | €350 | €1,050 |
| Zeee 4S 5200 mAh 120C LiPo | 8 | €45 | €360 |
| ESP32 WiFi telemetry module | 3 | €15 | €45 |
| ISDT D2 Mark 2 charger | 2 | €100 | €200 |
| RadioMaster Pocket transmitter | 1 | €80 | €80 |
| Spare props, cable ties, velcro | 1 | €45 | €45 |
| Total | ~€1,780 | ||
Some specifics that mattered for the development cadence:
Eight batteries for three drones. The minimum for continuous 24/7 patrol on the workshop fleet. Each sortie is ~18 minutes of flight (20-minute spec minus safety margin). Battery cool-down + swap + recharge is ~60 minutes at the conservative 1C charge rate. At any moment there are three batteries in drones, four on chargers, one in reserve. With fewer batteries the rotation breaks; with more, you carry dead weight. Eight is the pragmatic minimum.
ESP32 over WiFi instead of SiK telemetry. X500 kits ship with SiK 433 MHz radios for QGroundControl. We swapped them for ESP32 WiFi modules so a single laptop — the MacBook running its built-in WiFi hotspot — could be the ground-station network. All three drones forward MAVLink to UDP port 14550, the SAR MAVLink bridge multiplexes by system ID, and one laptop drives three fleet cards in the UI. SiK stays as fallback when the hotspot is jammed or out of range.
RadioMaster Pocket for manual override. One ELRS transmitter on 2.4 GHz, bound to all three drones. This is layer 3 of the three-layer safety architecture — the hardware kill switch that works regardless of what the ground station or the autopilot are doing. ~€80, lighter than a fleet battery, no excuse for not carrying it.
What the workshop fleet taught us about the software
By the time we'd put two months of flight hours on the X500 fleet, the architecture of SAR had crystallised:
- The orchestrator's 200 ms tick loop — the heartbeat of fleet relay — was tuned against real airframes, not simulated ones. Tick latency too high, handoffs miss; too low, the loop saturates. 200 ms held up across all three workshop drones with margin.
- Battery-aware handoff needed pre-launch dispatch with relay overlap. We discovered that by watching coverage gaps appear during the first multi-drone tests; the fix was to dispatch the standby before the active drone hit the swap threshold, not after. The full story is its own post.
- Exception-only alerting — the principle that the operator should only see what they need to act on — came out of the realisation that watching three telemetry streams simultaneously while debugging was already too much. A 12-hour shift on a patrol with five drones would be unworkable. The whole alerting model is shaped around that constraint.
- Three-layer safety got drilled until the operator-throw-the-RC-kill reflex was muscle memory. We crashed drones, we recovered drones, we triggered the failsafe, we triggered the GS kill, we triggered the RC kill. Every layer got tested separately and in combination.
You can't develop this kind of system on a simulator alone. You also can't develop it on industrial €25,000 airframes you can't afford to crash. The workshop fleet was the only point in the design space where the cost of a destructive failure was low enough that we could iterate honestly.
What the workshop fleet taught us about the hardware
Halfway through the development cadence, a pattern was forming. The X500 V2 chassis kept showing up as the right answer.
It was repairable in the workshop with parts available worldwide. It was open MAVLink end-to-end. It was the same airframe PX4's documentation, simulator, and community standardise on, which meant every troubleshooting question had been asked before. It crashed cheaply. It flew well in 8–10 m/s wind without complaint. The thermal envelope on the motors was generous. The flight controller and ESC stack was the open-source de facto standard.
And we kept hearing the same thing from the customers we were starting to talk to: regional fire brigades, inland public-safety units, training departments, search-and-rescue charities. They wanted autonomous SAR. They couldn't afford €25,000-per-drone industrial airframes. The DJI options they could afford ran a closed flight stack that locked our software out. None of the existing €10–15k options had thermal in the bundle. The customer segment we'd built the software for couldn't buy the hardware to run it on.
Which led to the conversation we had on a Friday evening some time in mid-summer 2026. "What if we just productised the chassis we already trust?" Add a hardened airframe build, integrate a dual EO/IR thermal gimbal, add an AI companion computer for onboard detection, add a proper long-range datalink, ship it with the SAR Ground Station and 2-day on-site training. Price it where the segment can actually buy it.
That conversation is what became Drone One, and the chassis lineage from the workshop bench to the productised drone is direct — same airframe family, hardened and bundled. The full story is Part 3.
Why this fleet still exists
The workshop fleet is still on the bench. It's now the test platform every new feature passes through before it ships. New relay logic, new sector partitioning, new GPS-denied behaviour, new alerting rules — all get flown on the X500 fleet first, often the same day they get committed. The discipline of test-platform / deployment-platform separation means we ship to customers what we already validated on hardware, not what we hoped would work.
The fleet has also kept us honest about cost. We break drones. That is the work. A new relay path lands, we fly it, and occasionally an edge case puts a motor into the ground. On an X500 that's a €150 ESC and an evening in the workshop. On an industrial frame that's a weeks-long RMA cycle. The €1,780 test fleet recovers in hours; an equivalent industrial rig would cost €75,000+ and crush iteration cadence. That ratio is what makes multi-drone relay development tractable at the pace we need.
And the fleet still validates against the production demo. The simulator at demo.adrone.company runs a 24-hour Curacao coastal patrol compressed to ~120 seconds of real time. The same software running against the simulator runs against the workshop fleet, which runs against operational Drone One bundles, which runs against compatible MAVLink airframes (Astro Max, Trinity Pro, any other supported PX4 / ArduPilot drone). MAVLink parity means we validate on the cheap fleet and ship on whichever airframe the customer needs.
What this all became
An €1,780 workshop bench, three X500 V2 quadcopters, a few months of flying and crashing and rebuilding, and the question we couldn't stop asking. Out of that came:
- SAR — a complete ground station for autonomous search-and-rescue and 24/7 multi-drone patrol, software-portable across MAVLink airframes. The story of the software is Part 2.
- Drone One — the productised airframe whose chassis lineage starts at this same workshop bench, sold as a complete bundle from €11,000 per drone with thermal included. The story of the hardware is Part 3.
- The compatible-airframes lineup — SAR runs on Drone One, on Freefly Astro Max for NDAA / Blue UAS customers, on Quantum Systems Trinity Pro for EU sovereignty and long-endurance VTOL coverage, and on any other PX4 / ArduPilot industrial drone that fits the customer's procurement.
If you want to see what this looks like as a working product, run the demo. If you want to talk through whether SAR fits your operation, get in touch.
For the rest of the founding story, read on:
- Part 1: Our First Fleet (this post)
- Part 2: Why We Built SAR — what was missing in existing ground stations, and why we built the whole stack
- Part 3: Why We Built Drone One — why the software company added hardware