The last post ended with a real hover and a clear next step: stop proving the airframe can fly, and start proving the software can fly it. Phase Three closed with a human on the sticks and a drone that finally behaved like a quadrotor instead of a configuration problem. Phase Four is about handing the sticks over.
This week, that handoff happened. A Holybro S500 armed, took off, hovered, and returned to launch on commands sent through droneserver’s MCP interface. This post covers how I got from “one careful manual hover” to that point, and what the two demo flights below actually prove.
Where Phase Three Left Off
The corrected v6 baseline gave me a real, repeatable hover, but only a narrow one. At the end of that post the list of “not yet proven” items was long: a broader manual envelope, real-world Return To Launch, and software-led control of the hardware at all. Closing that list meant adding capability one gate at a time instead of jumping straight to “let the LLM fly it.”
That turned out to be the right call. Every gate below went smoothly and we were able to step our way to what I have been working towards for many months now.
Gate One: Hover Until It’s Boring
Before trusting anything new, I went back and repeated the exact same hover from Phase Three, unchanged, several times in a row. Seven clean takeoff, hover, and landing cycles on the same v6 baseline, including light manual repositioning mid-hover. No drama, no surprises, no parameter changes.
That mattered because a single good flight can be luck. Seven identical ones in a row is a baseline. Once the hover stopped being interesting to watch, I trusted it enough to build the next gate on top of it.
Gate Two: Return To Launch, By Hand First
The next unproven item on the list was RTL. Before letting software anywhere near it, I validated it the same way I validated the hover: manually, with the RC transmitter, using the RTL switch.
Two clean real-site passes, both ending in an automatic landing and automatic disarm with no kill switch and no manual bailout. That told me the failsafe chain — RTL trigger, return-to-home navigation, descent, landing detection, disarm — worked end to end on real hardware, independent of who or what was triggering it. It also really showed off what the onboard PX4 is capable of. I’m thankful this flight software has been developed over the years.
Gate Three: Handing Telemetry to droneserver
The remaining open question was less about flight mechanics and more about plumbing: would GPS lock and home-position state survive switching the active control session from QGroundControl to droneserver’s MCP link? If closing QGC reset anything, software-led commands would be flying blind on home position.
I ran that handoff twice. Both times, GPS lock and home state carried over cleanly from QGroundControl to MCP-only operation. That cleared the last piece of plumbing standing between “manually validated failsafes” and “software issuing the same commands.”
The v7 Baseline
Two parameters changed going into the live software-led test, and they changed for the same reason: trusting an LLM-issued command on a real aircraft needed a stricter failure posture than trusting my own thumb on a switch.
| Parameter | v6 | v7 | Why |
|---|---|---|---|
NAV_DLL_ACT |
1 (Hold) |
2 (Return) |
If the data link drops mid-flight, the aircraft now flies itself home instead of just holding in place and waiting. |
RTL_RETURN_ALT |
4.572 m (15 ft) |
6.096 m (20 ft) |
Raised return altitude for more obstacle clearance during an automatic return. |
The full exported parameter file carries other minor drift beyond these two lines, so v7 is saved and treated as a complete baseline rather than a two-line patch on top of v6. It’s the current source of truth.
First Software-Led Flight
With all three gates cleared and v7 loaded, the test itself was almost anticlimactic, which is exactly what four gates of preparation are supposed to buy you.
The sequence, called entirely through MCP tools with the RC transmitter live but untouched:
arm_drone() -> armed
takeoff(5.0m) -> climbed to ~4.5m AGL, held hover
return_to_launch() -> RTL engaged
get_drone_activity() -> confirmed RTL mode, aircraft airborne
get_drone_activity() -> confirmed ON_GROUND, HOLD
Arm, takeoff, hover, RTL, landing, disarm — the full lifecycle, with no manual stick input. The evidence trail for this is the MCP server logs, the tool-call transcript, and corroborating flight footage itself.
The Footage
The two clips below are the demo cuts from the first and second software-led flights. The first is the full sequence; the second picks up partway through to focus on expanding the flight complexity with the exact same setup. What changed in the second video was simply asking to fly a more complicated mission.
What This Milestone Proves
What’s proven now, on top of everything from Phase Three:
- a repeatable hover, validated across seven consecutive cycles on an unchanged baseline
- manual Return To Launch, validated twice on real hardware with automatic landing and disarm
- telemetry and home-position state surviving the handoff from QGroundControl to MCP-only control
- a full arm, takeoff, hover, flight, return-to-launch, and landing sequence driven entirely by natural-language MCP tool calls, with no manual flight input
What’s still not proven:
- longer, more complex flight paths with obstacles to avoid
- any perception-driven behavior on real hardware
- anything resembling unattended autonomy
What This Phase Actually Closes
Up to now, most sessions were about firmware and hardware debug — chasing down a prop convention, a switch mapping, a failsafe value that didn’t match what I thought was live on the aircraft. That work is done. The proof boundary is established, the footage is captured, and v7 is documented as the baseline I’m building forward from, not iterating on.
The system architecture held up again here: the MCP surface and MAVSDK path that worked in simulation, then on a manually-flown real aircraft, now also works for software-issued commands on that same real aircraft. The work this whole time has been about earning the right to trust that surface in increasingly unforgiving contexts. Moving from the computer screen to real-life robotics is a world of difference and has given me a newfound respect.
To keep this post focused on engineering I will expand on what this milestone proves from a product perspective in a separate post. :D
What Comes Next
With the evidence phase closed, the near-term work shifts off the airframe and onto everything around it:
- widen the mission vocabulary
- start carrying perception work from simulation onto the real aircraft
- shift remaining effort toward publication, outreach, and demo assembly rather than further baseline changes
My first GitHub commit was on Feb 20, 2026. Fast forward to now, that is 4 months of engineering work that I am very proud of. I have learned so much in so many areas, such as: software development, AWS infrastructure, how to publish myself on the global internet, Claude Code, Codex, agentic coding best practices, drone hardware, and agentic robotics. There has never been a better time to shift to being a builder, regardless of background, perceived skillset, resume, work experience, and any other thing holding you back.
-Jake