Thomas McKee Design Engineering Book a call →
Case study · Engineering analysis

A water rocket, flown thousands of times in software first.

A first-principles model of a water-powered rocket, built from thermodynamics, compressible flow and flight dynamics, checked against real launches, then used to optimise the design. I was designer and performance lead, owning the mathematical model, its MATLAB implementation, the experimental validation, the optimisation, and the structural analysis of the pressure vessel.

Start your project → See the process
>300 m
with the heaviest payload the launcher could carry
±5%
of experiment across fill, pressure and firing angle
4
additions to the published models
1
launcher built, thousands of designs tested in simulation
The design process

How the project ran, end to end

Building and flying hundreds of rockets would have been slow, hard to repeat and constantly thrown off by the wind. So I built the rocket in maths first and let the model do the searching. It's the same method I later used on the Volt 2 elements and firmware, against a production deadline.

  1. Define the goal and the ground rules

    Carry the heaviest payload as far as possible, safely. Before writing a single equation I set out every assumption and the theory behind it, because a model is only worth having if its limits are clear.

    Problem definition · stating assumptions

  2. Research the published models

    I built on the existing literature and looked for where it fell short, which is where my four additions came from.

    Literature review · critical analysis

  3. Derive the model from first principles

    Newton's second law for a body losing mass, Bernoulli for the water jet, polytropic gas expansion, compressible nozzle flow and quadratic drag, in three derivations.

    Thermodynamics · compressible flow · dynamics

  4. Implement and solve it

    I coded the model in MATLAB and solved it with a fourth and fifth order Runge-Kutta method.

    MATLAB · numerical methods

  5. Validate it against real launches

    I tested the model against my own launches and against published experimental data.

    Experimental testing · validation

  6. Couple the parameters and optimise

    Every design variable was linked to the others, so the search only ever tried designs that could actually be built.

    Parametric modelling · optimisation

  7. Make it safe, then build it

    Hoop stress analysis set the allowable pressure with a safety factor, so the design met the relevant standards before it was ever pressurised.

    Structural analysis · pressure vessel design · design to standards
Skills used

What this project called on

Engineering
Mathematical modellingNumerical methodsParameter optimisationStructural analysisPressure vessel designExperimental validationDesign to safety standards
Theory
Variable-mass dynamicsBernoulli's equationPolytropic expansionIsentropic nozzle flowChoked flowQuadratic dragHoop stress
Tools
MATLABRunge-Kutta (4,5), Dormand-PrinceHand derivationLaunch testing
Case study 4.1 · Mathematical model

Mathematically modelling the flight path from first principles, so thousands of parameters could be tested without thousands of launches

Problem

The launcher had to deliver the heaviest payload it could, as far as it could, and stay safe. There are a lot of variables in play: vessel radius and length, wall thickness, water fill, pressure, nozzle size and firing angle, and they all affect each other. Testing them physically would have meant hundreds of builds and launches, each one affected by the wind on the day.

A simulation was the answer, but only one I could trust. That meant deriving it properly, stating its assumptions openly, and proving it against real launches.

Assumptions declared up front: quasi-steady inviscid flow through the nozzle · water inertia and thrust concentration neglected, as the two largely cancel · polytropic expansion with γ from published data · constant ambient pressure, temperature and gravity · constant drag coefficient from wind-tunnel results · no wind, the largest divergence from reality.
Fig. 71, Flight phases and the free body diagram, reproduced from sketch
Fig. 72, Experiment against the literature models and my model
Process

Three derivations, a validation, and a coupled optimisation

  1. 01Derivation I, the water thrust phase. Newton's second law on the vehicle, resolved along its flight path, with thrust, drag, weight and mass all changing over time. Bernoulli through the nozzle gives the jet velocity, and the thrust becomes a function of pressure alone. This is where I departed from the published model: the air expands polytropically rather than isothermally, and the vehicle mass includes the air still inside the bottle. The result is one first-order equation in pressure, which makes the whole water phase almost free to solve, and that's what makes sweeping thousands of designs practical.
  2. 02Derivation II, the air thrust phase. Once the water has gone, the bottle is a fixed volume of compressed air. While the pressure is high the nozzle is choked at Mach one and pressure thrust has to be counted; below the critical ratio it unchokes. Most published models treat the whole air phase as unchoked, which throws away the pressure thrust exactly where thrust is highest, so splitting the two regimes was my third addition.
  3. 03Solve it accurately. The literature uses a first-order method. I used a fourth and fifth order Runge-Kutta pair in MATLAB, which removes that source of error, my fourth addition.
  4. 04Validate against more than my own data. I tested the model against my launches and against Barrio-Perotti et al.'s experimental results, since a model tuned only to its author's data proves very little. It held to within about 5% across water fill, pressure and firing angle, and predicted more closely than their model.
  5. 05Let the structure set the pressure. The vessel is a thin-walled cylinder, so hoop stress governs: Pall = 2tσy / (r·SF). Setting wall thickness as a fraction of radius, t = βr, collapses that to Pall = 2βσy / SF, which doesn't depend on radius at all. Radius is then free to be optimised for volume and drag, and the cost of a bigger vessel shows up in mass. A wall of 5 to 6% of the radius was the first point where the allowable pressure beat the cartridge pressure, so that became the design point.
  6. 06Couple the parameters so only legal designs are tried. Changing the radius changes the wall thickness, which changes the mass, which changes the trajectory, and the allowable pressure caps what fill pressure can be tried. Written as functions in the code, an illegal combination simply can't be evaluated.
  7. 07Turn the firing angle into a function. The best angle falls as pressure rises, and sweeping it inside every loop would have squared the run time. I ran angle against pressure once, fitted the ridge of the response, θopt(P) = θ∞ + (θ0 − θ∞)e−P/P*, and tested every design at its own best angle so the comparisons stayed fair.
Fig. 73, Range against pressure and firing angle
Fig. 74, Radius against mass, allowable pressure and volume
Fig. 75, Wall thickness study: where the vessel first survives the cartridge
Results

Over 300 metres with the heaviest payload

>300 mheaviest payload
±5%of experiment
1launcher built

The launcher was optimised, made safe, and carried the heaviest payload it could over 300 metres. The structural analysis set the allowable pressure with a safety factor, so the design already met the relevant standards before it was ever pressurised.

The method matters more than the number. A model validated against measurement let me test thousands of parameter combinations, where the alternative was building hundreds of prototypes and testing them one at a time. Establish the physics, validate it against reality, then let the model do the searching: it's the same approach I used on the Volt 2 five years later.

Fig. 76, Trajectory families for vessel radius at 4% wall thickness
Fig. 77, Optimised design, firing over 200 metres on test
How I could help you

The same process, on your product

When physical testing is slow, expensive or unrepeatable, a model you can trust saves both time and money. Building and validating that kind of model is a big part of a Feasibility Study and Design Verification.

Let's talk

Too many variables to test by hand?

Book a free intro call and tell me about the problem. I'll tell you honestly whether a model would help and what it would take.

Book a free intro call → See more work