Aeronautics Tools

The TerraHawk’s aerodynamics come from a stack of open-source tools, each one quick where the next one is slow and blind where the next one can see. This page is the tour: what each tool is, what it does for this aircraft, and a sample of what it produces. The results themselves live on the wing aerodynamics, prop and wing interaction, propulsion, mission and CG envelope pages.

How the tools fit together

Tool	Kind of model	What it answers here	Time per case
XFOIL	2D panel method with a boundary layer	how each wing section lifts, drags and stalls	seconds
OpenVSP and VSPAERO	3D vortex lattice on thin surfaces	wing lift, trim, span loading, stability derivatives, shape studies	about a minute
DUST	vortex particles with rotor disks	how the lift rotors’ wash acts on the wing in transition	tens of minutes
OpenFOAM	3D Reynolds-averaged Navier-Stokes	the whole aircraft with its fuselage, VTOL pods and landing gear; separation and the stall; the wind in the hangar	1 to 2 hours
ArduPilot SITL	the real autopilot flying a model	how the aircraft actually flies: trim, turns, transitions, landings in wind	real time
JSBSim	table-driven flight dynamics	a fuller flight model built from all of the above, including the landing gear	real time

Each layer covers what the one before it cannot see. XFOIL knows the viscous flow round a section but not the planform. VSPAERO knows the planform but not the bodies or any separated flow. OpenFOAM knows both, and costs hours, so it checks and corrects the cheaper models rather than replacing them. The flight simulators come last and turn all of it into what the autopilot does with the aircraft. Most of the mistakes we found were at the boundaries between layers, which is why every number is carried through the whole stack when anything changes.

The geometry comes from the kit’s own STL files. A script slices them into sections for XFOIL and a planform for VSPAERO, and Blender assembles and exports the whole aircraft for OpenFOAM, so all three tools see the part that gets printed.

XFOIL: the wing sections

XFOIL (Mark Drela, MIT) solves the flow round a 2D aerofoil with a coupled boundary layer, which makes it good at the things a thin-surface model misses: skin friction, laminar-to-turbulent transition and the section’s own stall. We run it on the four sections sliced from the printed wing (centre body, root, outer panel and tip), each at the Reynolds numbers it actually flies at, and again on the same sections with the elevon deflected.

What it gives the other tools: the profile drag that VSPAERO adds strip by strip, and each section’s maximum lift, which sets where the wing first reaches its limit. Scripts: tools/wing_geometry.py (slicing), tools/section_polars.py (polars).

OpenVSP and VSPAERO: the wing

OpenVSP (NASA) builds the wing from the measured planform and sections; its solver VSPAERO models it as a vortex lattice, thin lifting surfaces with a wake. A full angle-of-attack sweep takes about a minute, so this is where the design questions get their first answer: the neutral point and CG envelope, the elevon trim, the span loading, and the stability derivatives that go into the flight simulator. It is also how the landing gear was chosen: dozens of stilt and keel shapes compared as fins in an afternoon.

What it cannot see: the fuselage and pods as bodies, and any flow that has separated. Scripts: tools/vsp_model.py, tools/vsp_analysis.py, tools/vsp_stilts.py, tools/aero_report.py.

DUST: the rotors and the wing together

DUST (Politecnico di Milano) is a mid-fidelity solver that follows the wake as vortex particles, so it can put the four lift rotors and the pusher in the same flow as the wing. That is the question for a quadplane’s transition: as the aircraft speeds up with the rotors still turning, how much does their wash change the wing’s lift and pitching moment? DUST found a nose-down moment the front rotors have to hold during the transition out, and that the pusher’s effect on the wing is small.

Scripts: tools/dust_case.py, tools/dust_matrix.py, tools/dust_report.py. Results on the prop and wing interaction page.

OpenFOAM: the whole aircraft

OpenFOAM solves the Reynolds-averaged Navier-Stokes equations round the complete aircraft: the wing, fuselage, VTOL pods with their parked props, the landing gear and the pusher, meshed with 2.9 to 5.3 million cells. It runs on a server in the workshop, a case at a time, about two hours each. It is the only tool here that sees the bodies and the stall, and it changed several answers: the fuselage and pods carry almost half the lift, the keels give about twice the yaw stability the vortex-lattice model credited, the wing’s first separation starts at the printed joints, and past the stall the nose drops rather than locking into a deep stall.

The same solver also models the hangar: a two-dimensional section of the box, its walls and the parked lid, to find how much the walls shelter the pad from the wind.

Jobs run through mcopenfoam, a job server built for this project, which queues the cases, stops each one when its forces have settled and reports as it goes. Scripts: tools/airframe_stl.py (geometry export from Blender), tools/cfd_case.py (cases), tools/cfd_report.py (forces, derivatives and separation maps), tools/cfd_results.py (the results table), tools/cfd_box2d.py (the hangar). The full log, with every case and every trap found on the way, is aero/cfd/NOTES.md. Flow pictures from ParaView are on the way.

ArduPilot SITL: flying it

ArduPilot’s software-in-the-loop simulator flies the real autopilot code against a flight model built from everything above: the lift and drag curves, the stability derivatives, the mass and inertia from the parts list, the lift rotors and a pusher model from the propeller data. A standard battery of test flights runs against every design change: trim and power sweeps, surveys, transitions both ways, turns, landings in the hangar in wind, and failure cases.

It found things the aerodynamics alone could not: the survey stalling in its turns, how far the keels make the autopilot work to hold a heading across the wind, and the energy the turns cost. Scripts: tools/sitl_model.py (the model, from the aero data), and the test battery under sim/. The model and its limits are on the SITL model page, and how the simulator is set up, patched and flown is on Flight Simulation Tools.

JSBSim: the next flight model

JSBSim is an open flight-dynamics engine that reads the aircraft as tables of forces and moments against angle of attack, sideslip and control deflection. It is set up to replace SITL’s simple built-in plane model, so that the simulator can use the CFD’s stall, each elevon’s own effect, and realistic gusts. It flies now: a bridge connects it to the autopilot, it models the keels as skids on the ground, and it matches SITL on trim and hover. The aerodynamic tables are being built from the data on this page. The whole story, with the touchdown on the keels, is on Flight Simulation Tools.

Propulsion and mission models

Two of our own models sit alongside the solvers. The propulsion model combines motor data from thrust-stand sheets with APC’s published propeller performance, to size the motors and propellers and give the power in hover and cruise. The mission model turns drag and power into energy for a survey, phase by phase, and into how much ground one battery maps.

Scripts: tools/propulsion.py, tools/mission.py. Results on the propulsion and mission pages.

What stays unmeasured

Every figure on this site comes from a model until the aircraft flies. The thrust stand will measure the motors and propellers, and the first flights will measure the trim, the stall and the energy. When they do, the models get corrected against them, and this page’s tools become the way to ask the next question rather than the source of the answers.

---

Source: docs/aero-tools.md in the repo. Edit it there; this page is generated.