Autonomous Drone Buildout: Phase Three — Real Hardware — Jake DeCamp

← Engineering

In the last two posts I got the drone stack flying in simulation, then added missions and vision. That work mattered, but it still left a fair question hanging over the whole project: could the same control model survive contact with real hardware? If the software can safely and successfully fly real hardware, I would consider that a minimum viable product. Getting there meant putting together a real PX4 drone.

Over the last week and a half I moved the project onto a real airframe: a Holybro S500 with a Pixhawk 6X, GPS, PX4, a Holybro SiK telemetry radio, and a standard RC link as the human safety path. The outcome was not “full autonomy” or even “broad flight readiness.” It was something narrower and more useful: the first real-hardware hover, reached through a sequence of bench bring-up, safety hardening, a failed hover attempt, a prop and motor convention diagnosis, and a corrected retest.

That is the milestone in this post. Not that the drone flew once, but that the stack now has a real hardware baseline I trust enough to build on and test against.

The Hardware Stack

The real aircraft path is built around a straightforward PX4 quadrotor:

Layer<br>Hardware<br>Role

Airframe<br>Holybro S500 V2<br>Physical quadrotor frame, power distribution, motors, props

Flight controller<br>Pixhawk 6X<br>Runs PX4 autopilot firmware

Positioning<br>Holybro M10 GPS + compass<br>GNSS and heading for position modes and RTL

Telemetry<br>Holybro SiK Telemetry Radio V3<br>MAVLink link for QGroundControl and droneserver

Operator safety<br>RC transmitter + receiver<br>Manual arm/disarm, kill, return, and mode selection

Software layer<br>droneserver MCP server + MAVSDK<br>Natural-language tool surface, telemetry, and future mission runtime

User layer<br>Codex, Claude, or an open-source LLM with local MCP access<br>Operator-facing prompt surface and supervised command entry point

At a glance, this is a pretty standard PX4 quadrotor stack. The difference is that once the aircraft is real, small mismatches stop being minor details and start becoming flight-critical facts. Motor direction, prop placement, RC switch semantics, and home-position truth all had to be taken out of the realm of assumption and turned into something directly verified.

Before getting into the field gates, here is the buildout arc in photos, from unopened kit to the first fully wired airframe:

Expand

What Counted As Progress

After soldering the remote-control antenna, I was excited to finally try a flight now that the controller could talk to the drone. I screwed on the propellers, carried it into the backyard, connected the battery, and armed it. It booted and armed, but the moment I raised the throttle, two props flew off and the drone tipped onto its side with the other two still spinning. The kill switch on the remote was not mapped correctly, so instead of shutting it down from the transmitter I had to run over and physically yank the battery to stop the motors. After that failed experiment, it was obvious I needed much stricter pre-flight safety.

That meant defining new pre-flight requirements:

droneserver had to talk to the aircraft locally over the SiK telemetry radio and return real telemetry.

QGroundControl had to show a coherent RC safety layout: arm/disarm, kill, return, and an actually trusted flight-mode switch.

PX4 had to be configured conservatively enough that GPS quality and home position were real gates, not paper settings.

A restrained props-on test had to look stable even under increased throttle.

Only then could a tiny hover be accepted, and only if it stayed within a narrow manual envelope.

After that first crash, I slowed down so I didn’t destroy my newly built drone.

Bench Bring-Up First

The first real hardware milestone after completing physical assembly, which was not as easy as I expected, was connecting my software to the onboard flight controller. This was link integrity.

I brought droneserver up locally against the bench PX4 setup over the Holybro SiK telemetry radio on /dev/cu.usbserial-DU0EFM6C at 57600 baud. That established the basic end-to-end chain:

Codex / MCP client<br>-> local droneserver MCP server<br>-> MAVSDK<br>-> MAVLink over SiK telemetry<br>-> PX4 on Pixhawk 6X

That was intentionally a read-only phase. The question was whether the software I had built in simulation could interrogate a real vehicle cleanly before I let it command anything interesting.

The answer was yes. Telemetry, health, and status reads worked. That mattered because it turned the project from “MCP works on a simulator” into “the same control surface can see a real aircraft.”

Safety Hardening Before Flight

The next milestone was not lift. It was operator safety.

I spent most of the real-hardware bench work getting the RC layout, PX4 parameters, and QGroundControl evidence into a state I could trust. The important choices were as follows:

SE / CH5 became the arm and disarm switch.

SF...