Introducing Project Volley — a small platform for big swarm ideas
Swarm flight has been one of the long-term goals for Project Quiver for a while now. But testing swarm behavior directly on full-scale Quiver vehicles would be expensive, slow, and risky.
That is exactly why Project Volley exists.
Volley is a compact, low-cost, fast-build demonstrator platform designed to let us test swarm ideas early, safely, and repeatedly — before transferring them to larger Quiver-class aircraft.
The idea is simple:
Instead of waiting until we have multiple full-size aircraft ready, we build a smaller physical platform that can validate the same core ideas:
• multi-vehicle coordination
• ground control workflows
• telemetry architecture
• ArduPilot-based autonomy
• simulation-to-flight transfer
• swarm behavior in real-world conditions
• operational lessons before scaling up
Volley is intentionally based on a 5-inch ArduPilot-capable frame, which we see as the smallest practical frame size that can still transfer meaningfully toward Quiver. Going smaller would make the build cheaper, but it would also create problems for companion computer integration, power budget, payload space, and future autonomy hardware.
So Volley is not just “a tiny drone.”
It is a minimum viable swarm test aircraft.
I have already built the first demonstrator out of pocket to prove the concept and start moving from theory to physical testing. The current demonstrator is a 5-inch ArduPilot quad with ELRS control, GPS, Wi-Fi telemetry, and a full flight-controller/ESC stack suitable for autonomous development.
Current demonstrator status:
airframe selected and assembled
flight controller and ESC stack installed
motors installed and tested
ELRS receiver working
GPS working
Wi-Fi telemetry working
ArduPilot configured
vehicle can arm
motor directions verified
propeller installation
final calibrations
first hover and tuning
swarm-oriented test workflow
The first build cost is currently around 450-500 USD for the drone itself, excluding reusable items like the radio controller, charger, tools, and bench equipment. If someone is starting completely from zero, including radio, charger, batteries, tools, and safety equipment, the entry cost is higher — but those items can be reused across future builds.
The repeatable build time for future units should be much shorter than the first one. The first demonstrator involved firmware flashing, wiring decisions, debugging, telemetry setup, and configuration work. Once the build is frozen, the goal is to make each Volley aircraft something that can be assembled and configured in a few focused build sessions rather than weeks of custom work.
Technical Approach and Phased Roadmap
Guiding Principles
Three principles govern the technical approach:
Simulation before flight. Every swarm behavior is validated in ArduPilot Software-in-the-Loop (SITL) simulation at fleet scale before it is flown on hardware. Flight testing is reserved for confirming that simulated behavior survives real-world sensing, communication latency, and disturbance — not for discovering whether an algorithm works.
Architectural parity with Project Quiver. Every element of the Volley stack — ArduPilot firmware, MAVLink/MAVROS middleware, STM32H7-class flight controllers, Raspberry Pi companion computers, and the ground control topology — mirrors the Quiver architecture. Each phase therefore concludes with a defined transfer package to Project Quiver, so that value accrues to the primary program continuously rather than only at project completion.
Capability-matched architecture. The coordination architecture is selected per fleet size rather than fixed in advance. Centralized ground-station coordination is used where it is sufficient (3–5 vehicles); decentralized onboard coordination is introduced only at the fleet scale that requires it (approximately 10 vehicles). To make this transition low-risk, all formation and coordination logic is developed as a self-contained software library that executes identically on the ground station or on the vehicle companion computer.
Algorithm Portfolio
The program distinguishes between algorithms validated at scale in simulation and behaviors qualified for real flight. The simulation portfolio comprises Hungarian-method optimal assignment, Reynolds flocking, consensus-based formation control, Optimal Reciprocal Collision Avoidance (ORCA), and heartbeat-based failure detection with leader re-election. The flight-qualified subset — introduced progressively across Phases 2–4 — comprises leader–follower control with fixed offsets, virtual-structure formation control, Hungarian-assigned formation transitions, artificial-potential-field separation assurance, and a geofence and broadcast-abort safety framework. Algorithms remain simulation-only until the sensing and communication infrastructure they depend on has been demonstrated in flight.
Phase 0 — Platform Bring-Up and Simulation Baseline
Status: substantially complete.
Objective. Establish a flight-worthy single-vehicle demonstrator and a validated multi-vehicle simulation environment.
Scope. Assembly and ground qualification of the v0.1 demonstrator (5-inch airframe, STM32H743 flight controller, ArduPilot Copter, ELRS control link, M10 GNSS/compass, WiFi MAVLink telemetry to QGroundControl); bring-up of the ArduPilot SITL toolchain with verified multi-vehicle launch (3 instances with automatic system-ID assignment demonstrated).
Exit criteria (Gate 0).
- Stable manual hover of the v0.1 demonstrator with full telemetry.
- Repeatable 3-vehicle SITL launch with per-vehicle command addressing.
Transfer to Quiver. Validated ArduPilot H7 bring-up procedure, ELRS integration and DShot configuration findings, and a documented multi-vehicle SITL workflow directly applicable to Quiver mission rehearsal.
Phase 1 — Swarm Algorithm Validation in Simulation
Objective. Validate the full algorithm portfolio in SITL at up to 10 vehicles, and select the flight-qualification subset on evidence rather than assumption.
Scope. Implementation of the coordination library (Python, MAVSDK/MAVROS-compatible) exercising: Hungarian assignment for slot allocation and formation transitions; virtual-structure and consensus-based formation control; Reynolds flocking; ORCA and artificial-potential-field collision avoidance; heartbeat-based failure detection with leader re-election. Quantitative comparison under injected communication latency and packet loss representative of the real WiFi link.
Exit criteria (Gate 1).
- 10-vehicle formation demonstration in SITL, including a scripted transition into the Arrow logo formation (program announcement asset).
- Documented latency/robustness envelope for each algorithm, and a justified selection of the Phase 2–4 flight set.
Transfer to Quiver. The coordination library itself, architected to run unmodified on Quiver’s Raspberry Pi companion computer, together with the SITL test harness for regression testing.
Phase 2 — Two-Vehicle Flight Qualification (Leader–Follower)
Objective. Demonstrate the first real-world coordinated flight and qualify the complete multi-vehicle infrastructure: per-vehicle MAVLink routing, companion-computer guided control, and the safety framework.
Scope. Construction of demonstrator #2; integration of the Raspberry Pi Zero 2 W companion computer on both vehicles; bench radio-frequency coexistence test of the 2.4 GHz ELRS control links against companion-computer WiFi telemetry (entry criterion for flight testing); implementation of the geofence and broadcast-abort framework with the ELRS link retained as an independent emergency kill channel; outdoor leader–follower flight with fixed position offsets.
Exit criteria (Gate 2).
- Sustained two-vehicle leader–follower flight within a defined geofence.
- Demonstrated broadcast abort terminating coordinated flight on command.
- RF coexistence characterized and mitigations documented.
- Fleet hardware decision point: procurement of remaining fleet hardware is authorized at this gate, contingent on results.
Transfer to Quiver. The MAVLink routing configuration and per-system-ID network topology, the guided-mode companion control stack, and the geofence/abort safety framework — all directly required by Quiver’s autonomy roadmap.
Phase 3 — Three-Vehicle Formation Flight (Virtual Structure)
Objective. Advance from following a physical leader to tracking a virtual reference, eliminating the single point of failure and establishing rigid, repeatable formation geometry.
Scope. Construction of demonstrator #3 to complete the baseline fleet; virtual-structure formation control with ground-station trajectory generation; artificial-potential-field separation assurance layered onto formation targets; formation-hold and formation-translation flight sequences (line, triangle, column).
Exit criteria (Gate 3).
- Three-vehicle formation hold and translation along a commanded trajectory.
- Demonstrated automatic separation response to a deliberately induced convergence.
- Safety framework revalidated at three vehicles.
Transfer to Quiver. Flight-validated virtual-structure controller and separation-assurance layer; multi-vehicle operations procedures (pre-flight, arming sequence, abort drill) forming the basis of Quiver multi-ship operations documentation.
Phase 4 — Formation Transitions and Fleet Scale-Up
Objective. Demonstrate dynamic formation reconfiguration — the externally visible signature capability of the program — and validate scaling behavior from three to five vehicles.
Scope. Hungarian-assigned formation transitions (minimum-cost slot reassignment with crossing avoidance) flown first at three vehicles, then at five following construction of demonstrators #4 and #5; measurement of communication load, ground-station loop latency, and formation accuracy as functions of fleet size; migration of the offset-tracking control loop onto the vehicle companion computers while retaining centralized coordination, as the transitional step toward decentralization.
Exit criteria (Gate 4).
- Five-vehicle formation transition sequence executed outdoors.
- Scaling analysis quantifying communication and latency margins at 5 vehicles and projecting them to 10.
- Recommendation and costed plan for Phase 5, or a recommendation to conclude at the five-vehicle capability level.
Transfer to Quiver. The formation-transition capability as a library feature; empirical scaling data informing Quiver multi-ship communication architecture; onboard control-loop deployment pattern for the Raspberry Pi companion computer.
Phase 5 — Decentralized Coordination at Fleet Scale (Conditional)
Objective. Where justified by Gate 4 findings and program objectives, transition to decentralized onboard coordination and demonstrate operation at approximately ten vehicles.
Scope. Inter-vehicle state broadcast between companion computers; onboard execution of the coordination library; heartbeat-based failure detection with leader re-election, promoting these from simulation to flight; tolerance demonstration of a deliberate single-vehicle dropout during formation flight.
Exit criteria (Gate 5).
- Ten-vehicle coordinated flight with no single point of failure in the coordination layer.
- Demonstrated graceful degradation on induced vehicle loss.
Transfer to Quiver. The decentralized coordination architecture in full — the definitive deliverable for Quiver multi-ship autonomy.
Roadmap Summary
| Phase | Capability Demonstrated | Fleet Size | Gate Decision |
|---|---|---|---|
| 0 | Single-vehicle flight; multi-vehicle SITL | 1 (real), 3 (sim) | Proceed to algorithm validation |
| 1 | Full algorithm portfolio in simulation; Arrow logo asset | 10 (sim) | Select flight algorithm set |
| 2 | First coordinated flight; safety framework | 2 | Authorize fleet hardware |
| 3 | Virtual-structure formation flight | 3 | Confirm scale-up |
| 4 | Formation transitions; scaling analysis | 5 | Authorize or conclude before Phase 5 |
| 5 | Decentralized coordination (conditional) | ~10 | Program completion |
Project Volley v0.1 Demonstrator BOM
The airframe is excluded from the cost calculation because it will be 3D printed.
| Component | Quantity | Unit Price | Unit Price (USD) | Total (TRY) | Total (USD) |
|---|---|---|---|---|---|
| GEPRC TAKER H743 BT flight controller + 50A 4-in-1 ESC stack | 1 | 7,355.40 TRY | $156.86 | 7,355.40 TRY | $156.86 |
| T-Motor P2207 V3 1950KV motor | 4 | 1,555.95 TRY | $33.18 | 6,223.80 TRY | $132.72 |
| Gemfan Yuki 5129 5-inch propeller | 4 | 95.48 TRY | $2.04 | 381.92 TRY | $8.14 |
| Tattu R-Line V5 1550 mAh 4S XT60 battery | 1 | 2,299.00 TRY | $49.03 | 2,299.00 TRY | $49.03 |
| RadioMaster RP4TD ELRS 2.4 GHz receiver | 1 | 1,697.40 TRY | $36.20 | 1,697.40 TRY | $36.20 |
| GEPRC GEP-M10-DI M10 GPS + compass | 1 | 1,949.00 TRY | $41.56 | 1,949.00 TRY | $41.56 |
| Wi-Fi MAVLink telemetry module | 1 | 1,342.21 TRY | $28.62 | 1,342.21 TRY | $28.62 |
| Raspberry Pi Zero 2 W | 1 | 703.39 TRY | $15.00 | 703.39 TRY | $15.00 |
| Total | 21,952.12 TRY | $468.13 |
Estimated Cost per Unit
The estimated core electronics and propulsion cost of the Project Volley v0.1 demonstrator is approximately:
- 21,952 TRY
- 468 USD
This total excludes the 3D-printed frame material, printing cost, microSD card, voltage regulator/BEC, wiring, connectors, fasteners, battery straps, mounts, and other small integration hardware.
Long-Term Vision
Long term, Volley can become more than an internal swarm demonstrator. Because it is cheap, accessible, ArduPilot-based, and standalone, it could also evolve into a general-purpose small drone platform for FPV, autonomy education, research, and rapid flight testing.
Project Volley is our way of making swarm development practical now — not someday.
Small aircraft.
Fast iteration.
Real flights.
A direct path toward Quiver swarm capability. 
Can’t wait to hear your thoughts and suggestions!