The idea
SkySpar explores whether a reused Android phone can provide useful video, telemetry and higher-level computing on a small fixed-wing aircraft. V1 is a conventional manually recoverable model with a phone payload. The approximately 1.3 m span is a starting concept, not a validated airframe specification. Solar endurance, autonomous visual navigation and beyond-visual-line-of-sight operation are separate research tracks.
The connection
The connection is between an everyday computer and a purpose-built aircraft: reuse the phone's rich capabilities while keeping flight control independent.
How it could work
Keep flight stabilization, primary navigation and failsafes on the autopilot. Treat the phone as a companion whose crash, overheating or network loss must not remove basic aircraft control. Use a documented MAVLink link, an independent RC receiver, a measured power distribution design and a physically secure, ventilated phone mount. Start with read-only telemetry before allowing any phone-originated commands.
An established lightweight trainer airframe is the fastest integration baseline. A fully printed airframe adds mass, joining and stiffness uncertainty; validate those separately before combining them with the phone experiment. Weigh every component and calculate centre of gravity from measured masses and arm lengths: CG = sum(mass × position) / total mass. Compare it to the airframe designer's permitted range.
What would prove it
First use the ArduPilot simulator to exercise phone disconnect, delayed telemetry and an unavailable ground station. Then run the actual autopilot, receiver and phone on a bench with the propeller removed. Log controller voltage, phone temperature, telemetry age and failsafe transitions for 30 minutes; interrupt the phone application, USB link and network separately. Confirm recovery requires deliberate action where appropriate.
Proposed acceptance gate: every injected fault produces the documented response; there are no autopilot resets; primary RC control remains available; stale telemetry is visibly marked; no command is replayed after reconnection. Attach parameter exports, timestamped logs and wiring photographs. These tests have not been run for APX.
The path to a complete build
- Freeze the operating envelope, airframe and mass budget; obtain a pilot review of the design.
- Demonstrate the simulator and propeller-off bench tests with a read-only phone link.
- Build and balance the airframe; verify control direction, structural joints and power margin.
- Plan initial flights with a competent model-aircraft pilot in an appropriate location under the applicable CAA rules. Establish ordinary flight behaviour before adding higher-level phone commands.
- Publish measured flight logs, faults and revisions before calling this a demonstrated prototype.
Open the engineering notebook
Components, interfaces and calculations
Autopilot: supported Plane controller with power monitoring, independent GNSS and enough serial interfaces. Propulsion: matched motor, ESC, propeller and battery selected for the measured airframe mass. Payload: known Android handset, supported USB/serial interface or network bridge, separate regulated supply and strain-relieved harness. Ground equipment: RC transmitter, telemetry viewer, scales and current logger. Exact part numbers remain dependent on the airframe and phone inventory.
Record battery capacity in Wh, measured average power in W and an explicit usable-energy reserve. Estimated endurance in minutes = 60 × usable Wh / measured average W. A bench estimate does not include launch, climbing, wind or manoeuvring losses and cannot establish flight endurance.
Scope and development questions
Planning allowance: 6–10 workshop sessions for integration after the baseline aircraft is available; flight training and weather are additional. Cost the airframe, flight electronics, propulsion, independent radio, phone interface, spare parts and test instruments separately. Do not purchase a custom airframe until phone mass, power and thermal behaviour are known. Key unknowns are the handset model, existing hardware, airframe limits and the intended useful payload task.