All blade counts the tool tried
| Blades | Thrust (gf) | vs target | gf/W | In band |
|---|
How it works
Four stages. The third is what makes it a design tool rather than a regression: the model proposes, the physics decides.
-
1
Requirement
Thrust, diameter and rpm (from motor Kv × battery voltage), plus an optional blade count. These become two dimensionless inputs: a thrust coefficient and a Reynolds number.
-
2
Model
A linear regression predicts chord and twist at 18 radial stations for each blade count from 2 to 6. It was trained on the efficient frontier (29,639 blades) of 200,000 synthetic propellers.
-
3
BEMT check
Each candidate is simulated with blade-element momentum theory. The most efficient one landing between 0% and +20% of the thrust target wins.
-
4
CAD
CadQuery lofts cambered NACA sections (14% thick at the root, 7% at the tip) along the blade, patterns the blades around a hub, and exports STEP and STL.
Example designs
Six requirements that span the range, generated ahead of time by
src/export_showcase.py with the same code the local web app runs.
Two sit outside the validated diameter range and one misses the thrust band,
and the tool flags all three.
Loading designs…
Validation
1. The physics solver against 119 real propellers
Before trusting simulated training data, the BEMT solver was run on all 119 propellers in the UIUC database (2,121 operating points) and compared against wind-tunnel measurements.
−12.6%median thrust (CT) error. The solver under-predicts.
−11.5%median power (CP) error
17.1%spread between propellers (sd of per-prop median CT error)
4.3%spread within one propeller across its rpm sweep
The small within-propeller spread means the solver tracks each blade consistently. The large between-propeller spread comes mostly from unknown airfoil sections: the solver assumes one airfoil for every blade, and the database doesn't say which each one uses. That is a floor to report, not a bug to tune away. Because the bias runs low, a real blade built to a design that simulates exactly on target would likely make more thrust than predicted.
2. The model
The deployed model is a plain linear regression. XGBoost was benchmarked against it on the same data and tied, so the simpler, smoother model shipped. Every one of the 119 real propellers is held out from training, because training uses synthetic blades only.
3. Closed-loop test: does the designed blade do the job?
For 15 real operating points, the tool designed a propeller for the same thrust, diameter and rpm. That design was compared with the best real propeller meeting the same requirement. Both sides are simulated in the same solver, so its bias cancels and the comparison measures design quality. It is not a test against measured data.
Result in the 6–11 in range: 8 of 10 cases were no more than 15% less
efficient than the best real reference. The two failures are both 11 in cases,
ma_11x4 and grcp_11x4. For those, auto-select picked
5 blades where the real propellers use 2, and the designs came out 38–42% worse.
Outside 6–11 in, the model extrapolates below its training Reynolds range and does
markedly worse, which is why the tool warns there.
Phase 3 closed-loop results (CSV). “vs best real” compares thrust per shaft watt; positive means the design beats the reference. Pass means no more than 15% worse.
| Case | Dia. (in) | Target (gf) | Thrust err. | Blades (tool / real) | Design gf/W | Best real gf/W | vs best real | Verdict |
|---|---|---|---|---|---|---|---|---|
| Loading… | ||||||||
Large positive values like +77% (mi_5x3.5) don't mean the tool beats real
propellers by that much. They sit outside the validated range, and they mostly show that the
nearest real reference was built for a different operating point.
Limitations
- Validated for 6–11 in only. Outside it, the model extrapolates below its training Reynolds range.
- Blade-count selection is weak for lightly loaded rotors. It picks 5 blades where real designs use 2, as in the two Phase 3 failures. The 12 in and 15 in examples above show the same behaviour.
- All performance is simulated. The solver under-predicts thrust by a median 12.6%, with 17% scatter between propellers. No designed blade has been built and tested yet.
- Shaft power, not battery power. Motor and ESC losses aren't modelled, and rpm is taken as given rather than solved from a motor model.
- One design point. Efficiency is judged at hover only, not across a throttle sweep or in forward flight.
- Plain round bore. The hub has a simple 6 mm round hole. A D-flat mount and clamp collar were tried and reverted, so a printed part needs its own way of fixing to the shaft.
- Unverified structure. There's no stress or flutter analysis. Don't spin a printed prop near people.
About
This rebuilds my high-school AIAA paper, Using Machine Learning to Expedite Production of Aircraft Propellers. The original trained a model on labels that already contained a fixed efficiency assumption, so it mostly relearned that assumption. This version generates its training data with a physics solver that was first validated against wind-tunnel data, and it retargets the problem from piston aircraft to small electric hover rotors (2–30 in).
The full tool is a local Flask app. It isn't hosted here because its CAD stack needs about 2 GB of dependencies and about 760 MB of memory per design. The examples above were generated offline with the same code. Measured data comes from the UIUC Propeller Data Site.