A dragon is a bad airframe.

I want to try to use LLMs to make something physical, and something that I haven’t seen done before. What I decided on was a remote-control dragon that takes off under its own power and flies. Not a quadcopter with a dragon ‘costume’, but a thing shaped like a dragon that gets itself into the air and can fly. The catch is that everything that reads as dragon is aerodynamically wrong. The deep chest, the long neck and tail, the legs hanging down, wings held out mostly for the silhouette. Long, heavy, draggy, and unstable.

This is a work in progress. Currently it’s a software-in-the-loop simulation. What I’m actually trying to work out before I spend anything is whether this is buildable at all. Everything below is where that’s gotten to, not a report from a finished aircraft.

Hide the lift where the shape will tolerate it

What I settled on is a heavier-than-air lift-plus-cruise VTOL. The whole design is about putting propulsion where a dragon can carry it without looking like a drone.

Two fans live in the chest, one forward and one aft, ultimately with baffles so you can’t see them except from directly underneath/above. They do the hovering, pitch, and maybe some yaw if I can get a clockwise and counterclockwise version. Four small fans sit in the feet on legs that fold from standing up to tucked under the body. There’s a propulsor in the mouth that exhausts through side ducts in the neck flares. That’s mostly what pushes it forward. The wings are planned to be real. Hybrid rigid-and-membrane, set at 4° incidence, and if possible to get enough airspeed they carry the whole aircraft with chest fans mostly off. A stretch goal is to get teh wings to do some cosmetic flapping, with loss of lift supported by the VTOL fans.

Hover thrust beats weight by about 1.6 to 1, it stalls around 6.6 m/s, and it cruises near 11. In simulation, it flies.

The loop

I did almost none of this by hand. I ran the project as a loop of different models doing different jobs, and spent my own time on judgment and direction.

One model built the first physics model, the center-of-gravity table and the component masses, from a couple of reference images and a description of where the fans go. Opus put together the software-in-the-loop rig: a physics simulation on one side, the actual ArduPilot flight code on the other, talking over a UDP socket the same way the autopilot would talk to real hardware. When I needed a structure to hang the masses on, I handed that to Hermes using a mixture of models (but mostly Opus 5). Its first model wasn’t what I wanted, so I had Fable produce clean orthographic renderings and dimension them, then had Sol turn those dimensions into a better solid I could check weights and clearances against.

Side elevation, dimensioned. Station coordinates run aft-positive from the nose.

Top view. The chest fans sit symmetric about the CG; the tail is deliberately long.

The parametric structural model. Point masses are the source of truth; the geometry only supplies what a point can’t: envelope, volume, and clearance.

Three things I got wrong first

My first instinct with the foot fans was to keep them pointing straight down no matter what the legs were doing, and to cant all four the same way. Both were wrong. A foot fan sitting out to the side makes a roll moment and a yaw moment at the same time, and the ratio between the two is set entirely by the cant angle. If all four feet cant identically, they all produce the same ratio, which means roll and yaw stop aren’t individually controllable. In the sim I watched one motor pin wide open, another fall near idle, and the pitch swing twenty degrees back and forth. The fix is that the front legs and the rear legs have to cant in opposite directions (sort of like a dog’s legs sit when laying down upright). Opposing the front and back feet propulsion allows better control.

Second, the center of gravity has to sit exactly between the two chest fans. The plan is for thefans counter-rotate, so their reaction torque cancels, but only when they’re spinning at the same thrust. Put the CG off-center and they have to run at different thrusts to hold level, which leaves a standing yaw bias, which eats yaw authority in one direction. The symptom is that it turns beautifully one way and fights the other. So the CG has to stay centered between the fans. The battery is about a fifth of the total weight, so wherever the battery goes, the CG follows. The fans have to sit either side of the CG. And the fan ducts, as it happens, land right where the battery wants to be. What worked was to split the battery into two smaller packs and drop them into the dead gaps either side of where the two fan shrouds meet.

The last one is the one I’m actually pleased about, because it’s where the dragon geometry actually helped. The legs can serve as a transition mechanism. Legs down for hovering: the feet straddle the CG, the fans point nearly straight down, full roll authority. Then as the aircraft picks up speed the legs tuck, and as they tuck the foot fans rotate from pointing down to pointing away from CoG. They turn into steering control when the wings start carrying the weight. If a leg jams, the failure is gentle: stuck-down legs just means draggier cruise.

Status

Stable hover holds in the simulator against real ArduPilot, not just against the original physics sim stand-in controller: chest fans and feet close to balanced, altitude holding, nothing near saturation. The model and the autopilot agree to within a few percent. It’s still all in software, though. Nothing has hovered in a room.

The hover-to-wing handoff is the part I trust least. It’s flaky even in sim. Which, for a bad airframe, is further than I expected to get. Some of this I can’t settle in software at all. Duct losses, the membrane wing flexing, whether a printed frame survives its own fans.

Plan

• See how far/accurate CFD analysis can get.
• Model the cosmetic airframe in 3D
• Model support structure inside the airframe
• Run load calcs to see how much flex is likely
• Actually buy material

Details

Initial LLM Code

I had LLMs develop the initial physics model, center of gravities, and masses. The prompt:

Please develop a center of gravity component table for a 1.2m long version of the attached images, with legs moveable from standing to near straight back under the body. Two vertical fans should be hidden in the torso, one lognitudinal fan in the mouth with side ducts out neck flares, one fan at bottom of each foot. Include the required structure in the CoF table too. Then develop the config files we would need to simulate a control scheme and physics for this 1.2m model. If you can run the simulation, do so. Then give me all the config files, output that is available (if available), and setup instructions for immutable Linux.

Physics Setup

With help from Opus, this was the software-in-the-loop setup to test physics and controllability.

Setup container:

distrobox create --name ardupilot --image ubuntu:22.04

Enter container:

distrobox enter ardupilot

Setup numpy for sim:

sudo apt update && sudo apt install -y python3-pip
pip3 install numpy matplotlib
cd ~/dragon-sim

Test the simulator:

python3 mass_properties.py                      # CG table
python3 dragon_sim.py --standalone              # mission scenario
python3 dragon_sim.py --standalone --scenario yaw

Controller / ArduPilot Setup

Download ArduPilot and compile it:

sudo apt install -y git
git clone --recurse-submodules --shallow-submodules --depth 1 \ https://github.com/ArduPilot/ardupilot.git
cd ardupilot
Tools/environment_install/install-prereqs-ubuntu.sh -y
. ~/.profile          # required — puts waf and MAVProxy on PATH

This takes a long time. It is a lot to clone, and then a lot to compile. This is the actual controller code that would normally be on the drone.

Start Sim

Terminal 1 (Physics):

cd "/home/jwbatey/Documents/agent_workspace/flight/"
distrobox enter ardupilot

python3 dragon_sim.py --json        # listens UDP 9002

Terminal 2 (Controller):

cd "/home/jwbatey/Documents/agent_workspace/flight/ardupilot"
distrobox enter ardupilot

Tools/autotest/sim_vehicle.py -v ArduPlane -f JSON:127.0.0.1 --console --map

Wait a bit for compiling. Then in Terminal 2:

param load /home/jwbatey/Documents/agent_workspace/flight/dragon.param
# wait until params saved
param set ARSPD_TYPE 100
param set SIM_BATT_VOLTAGE 25.2
param set Q_FRAME_TYPE 0
param fetch

Copy the matrix in a separate terminal

cp dragon_matrix.lua ardupilot/scripts/dragon_matrix.lua

Reboot SITL

reboot

Test

param show Q_FRAME_CLASS     # want 15
param show Q_ASSIST_SPEED    # want 8.5
param show SERVO5_FUNCTION   # want 33

If errors

param set Q_ENABLE 1
param set SCR_ENABLE 1
reboot
param load /home/jwbatey/Documents/agent_workspace/flight/dragon.param
# wait until params saved
param set ARSPD_TYPE 100
param fetch

Then in terminal B, try to throttle it:

mode QLOITER
arm throttle
rc 3 1600

Testing

At this point I immediately found some issues. My fore lifting motor was saturated, but the vehicle still pitched down. I moved the fan further forward to increase the moment.

Hovering, with legs down seemed to be fine. However, putting the legs back into cruise mode caused pitch instability and therefor loss of yaw control (since from fan had to derate). Ended up having to have front feet face forward when folded, and rear feet face back. (It’s the pose most dogs are in when laying upright on the ground)

Looping

At this point I started up Hermes and directed it to:

I don't have any of the hardware material bought for the project under 'flight/' yet. I want a 3D model of the dragon that I can use to design the structure, validate weights/CoGs, and simulate that    
arrangement.

That model wasn’t quite what I wanted, so I had Fable produce renderings and then dimension them:

1) Create a top down view of this dragon in this pose. A view I can use in a 3D rendered, orthographic.
2) Same sort of orthographic view, but from the side please. same body pose.
3) Assuming a head to tail of 1.2m, please get X/Y/Z coordinates for: tip of head, tip of tail, 'shoulder' rotation point of each leg, 'knee' point of each leg when tucked in, 'foot' tip of each leg when tucked in, main wing to body attachment point, wing joint location, 4 point locations for each wing (1 forward and 3 rear, where the claws are), bounding box of core torso
4) Output those points, then overlay them on the images. If the points aren't in the right place, try again. If needed, you can stretch/scale the images a bit.

Then I had it make a separate 3D model of that dragon:

Please create an STL file based on these dimensions. Wings should only be the support structure/bones. Head, neck, torso, tail, legs should be tapered/sliced cylinders. You can use compound cylinders where needed, but avoid overlapping meshes/cylinders.

That wasn’t quite what I wanted, so I loaded in a 3D model from online. I used this one, straightened out, symmetric, with a tail fin added: https://www.printables.com/model/14875-bronze-dragon-flying#preview.file.Zrv8

I had Sol dimension this in images in order to make a better model.