Geometry-Aware Autonomous FPV Drone
A cheap FPV camera drone, a companion Android app, and nothing else. The goal: a policy that perceives depth from onboard cameras and flies the drone end to end, trained in simulation and transferred to the real hardware.
How it came apart.
Every step was a guess, tested on hardware, then confirmed in source. Nothing here came from documentation, because there wasn't any.
- Capture the handshakemacOS Wireless Diagnostics into pcap, read with tcpdump and scapy. Found the gateway and a UDP registration handshake.packet capture
- Guess the movement packetReconstructed a candidate layout from a related OEM drone hack.hypothesis
- Confirm it in sourceDecompiled the Android app with jadx. Roll, pitch, throttle, yaw in bytes 6 to 9, plus XOR checksum.jadx
- Lift offReplayed the arm-then-launch gesture over WiFi.first flight
- Fix the videoOne deliberately wrong byte per frame, traced to an undocumented XOR step in the app.main.py
- Find the second cameraA downward-facing camera, switched by a 7-byte UDP command.hidden hardware
- Train PPO in simulationPhysical parameters and measured flight response mapped into the sim in place of telemetry.next
The plan was to read IMU data over WiFi. The drone never sends any. That's a result, not a gap: camera perception is the only real-world state this hardware has, and the whole sim-to-real strategy is built around it.
What it sees next.
Height from optical flow
Ground distance during takeoff and landing, from the hidden second camera.
Lightweight obstacle detection
A geometry-aware state built entirely from vision.
PPO over SAC
Chosen for its sim-to-real record on quadrotors under heavy domain randomisation.