Designing a multirotor that lifts four times its own weight, and checking it in a real autopilot
I wanted a multirotor that lifts four times its own bodyweight. That number drives every other choice: motor and propeller pairing, battery chemistry, frame mass, and how much structure you can afford before the structure itself eats the payload.
The pipeline has three stages that get progressively less forgiving. A closed-form screen rejects most of the design space cheaply. What survives goes into an NSGA-II architecture search over the remaining trade-offs. What survives that is verified in a numpy six degree-of-freedom simulation, and then flown in ArduPilot SITL, which is the real autopilot firmware rather than a model of one.
The search found a design reaching 4.62 to 1 in simulation. Nothing has been built. I would rather say that plainly than let a ratio imply hardware.
Simulating your own dynamics and calling it flightworthy is easy to do by accident. Running the actual autopilot removes a whole class of self-deception, because the firmware does not know it is being tested and will fight a badly conditioned airframe exactly as it would in the field.
The safety rule I work to is that hover throttle, not payload mass, tells you how close to the edge you are. Payload gets stepped on in a few increments and stops above eighty-eight percent throttle, because what remains above that is the margin the controller needs to reject a gust rather than headroom to spend.
The rate gains are tuned for a compact payload stack held close to the frame. A load that hangs and swings is a different plant entirely and wants gains around fifteen times higher, so the tune does not transfer. Autotune runs unloaded, never with the payload attached.
Partway through, I re-read the competition rules this was aimed at and found that three load-bearing assumptions were wrong. The mass cap applies empty rather than gross, the payload minimum is far higher than I had designed for, and the course is laps rather than a single transit. Every design the optimizer produced under the old reading would fail to qualify.
I left that correction at the top of the project's handoff instead of quietly re-running the numbers, because the interesting part is not the ratio. It is that a clean optimization over the wrong constraints produces a confident answer to a question nobody asked.