RotorLabRotorLab is a rotorcraft performance engine your students can see all the way through: actuator-disc momentum theory, a real power-required curve, a wing model with a stall boundary, an electrical system with regulated rails — every governing equation written out, re-derived live in the browser, and then tested against a real aircraft on the bench. The derivation belongs on the whiteboard. The four hundred recalculations that follow it do not.
This is not software with a physics flavor. It is the coursework itself: each unit below is a topic your syllabus already carries, taught with the equation in one hand and a live aircraft model in the other.
Momentum theory, disc loading, and the atmosphere. Students learn why a larger prop hovers cheaper and why a hot day at altitude punishes every rotorcraft, and they watch both effects move the numbers exactly as the equation says they must.
Packs, parallel packs, named buses, and regulated BEC rails. Every rail is checked against its regulator, every pack against its C-rating. The electrical system stops being an afterthought and becomes an engineering artifact with limits and headroom.
The power-required curve across airspeed. Best-endurance speed is the minimum of a curve the student built; best-range speed is a tangent, not a vocabulary word. Top speed comes out thrust-limited or power-limited, and the tool says which bound.
A wing with area, aspect ratio, and span efficiency; a stall speed the aircraft must exceed before the wing will carry it; and a transition-feasibility check — can the thrust-borne phase accelerate past stall at all? Stall is a boundary, not a footnote.
The calibration lab. Students predict hover current from the model, hover the real aircraft, and invert the measurement into a figure of merit. The gap between predicted and measured is the lesson, and the software is built around exactly that comparison.
Trade studies sweep one variable and re-analyze everything at each point. The endurance-versus-capacity curve flattens because the bigger pack weighs more, and students discover that from the curve before the instructor says it out loud.
These are the governing relations the engine computes, exactly as the Math & Validation page writes them out and re-checks them. Nothing below is simplified for marketing.
Induced power per disc from the thrust it carries, air density, and disc area, summed across rotors and divided by the figure of merit (default 0.65) for real power. Coaxial layouts stack two motors on one disc location and carry a ×1.20 power penalty.
Air density from the standard-atmosphere model at the entered altitude, then corrected to the real temperature. Hot-and-high is the worst case for any rotorcraft, and the endurance and thrust penalty appears directly in the readout.
Induced power falls with speed, profile power holds roughly constant, and parasite power rises as the cube of speed through the flat-plate drag area f. Best-endurance speed is the curve's minimum; best-range speed maximizes distance per unit energy; top speed is limited by the smaller of available thrust and available power.
The wing is the airfoil arms: area from arm count, length, and chord. Induced drag comes from aspect ratio and span efficiency. The tool reports stall speed, wing loading, cruise speeds and range, and whether the thrust-borne phase can accelerate past stall at all.
With no measured thrust, the engine estimates from a pitch- and blade-aware static thrust coefficient and flags every dependent figure [est]. Enter a thrust-stand value and the flags clear. Students learn to read the difference between an estimate and a measurement, because the software refuses to blur it.
Free-space path loss (Friis), the line-of-sight horizon from both antenna heights, first Fresnel-zone clearance, and the two-ray ground-reflection model. An aircraft must close every link it carries, and its usable range is the shortest of them.
Every component placed on the airframe moves the CG by its mass moment. On winged aircraft the CG reads as a percentage of mean chord, the standard aviation measure. Mass is conserved by construction: the placed items sum exactly to the all-up weight the analyzer reports.
A steady hover fixes the real figure of merit from measured voltage and current. A bench wide-open-throttle burst adds an assumption-free max thrust from the power ratio, because induced power scales as thrust to the 3/2. Applying the result turns estimated figures into measured ones.
The Math & Validation page writes out every governing equation, derived and referenced, then re-evaluates each one independently in the browser and checks it against the engine's own code path. A green badge means the printed equation and the software agree to within 0.1%. A red badge would mean they diverge. Change any input and every number, and every check, recomputes — no internet, no external math library.
And the model states its own limits, on the page, because teaching what a model does not capture is part of the engineering:
The lab exercise the whole tool is built around, runnable with one aircraft, one battery, and one bench.
Students model the lab aircraft in the Builder and commit to numbers: hover current, hover throttle, endurance. On paper, in advance, from theory.
Hover the real aircraft. Live Telemetry reads the flight controller in the browser over USB, the LAN, or the cloud relay — nothing to install on lab machines.
Live Calibration averages the steady hover and inverts it: the measured figure of merit and max thrust fall out of the same equations the students derived.
Predicted versus measured, side by side, with percentage deltas. Why is the figure of merit 0.55 and not the 0.65 the model assumed? That discussion is the course.
Nothing here replaces deriving momentum theory by hand; the first problem set is the same one it has always been. What changes is everything after it. On paper, one aircraft configuration is an evening of arithmetic, and a single transcription slip quietly poisons every number downstream. In RotorLab the configuration is described once, and every dependent figure — hover, endurance, rail loads, stall margin, link budget — recomputes on every keystroke.
No design office sizes an aircraft by spreadsheet-and-calculator anymore, and pretending otherwise in the classroom teaches a workflow the industry has already left. Teach the derivation, then teach the judgment — on the class of tool the job actually uses.
Invite the class from the Admin Console, organize sections into groups, reset a forgotten password in one click, and read the activity log when something needs explaining.
Students keep private build libraries and publish chosen builds to the organization, where the whole class can open, compare, and critique them.
Every saved revision keeps its dated note: what changed, why, and what it did to the numbers. Build history reads like the notebook you wish students kept on paper.
One click exports a self-contained HTML report of any build: the assumptions, the figures, the charts. The deliverable is the analysis itself, and it opens anywhere.
The Log Analyzer reads any ArduPilot, MAVLink, or PX4 flight log free, and the Math & Validation page is public. Students can start the week before the department buys anything.
Every tool runs in the browser, on the machines the lab already has. Live telemetry reaches a flight controller over USB from the browser itself.
Students who learn performance analysis here graduate into UAS programs, public-safety flight operations, and design teams already fluent in the tool those operations run on — from the first momentum-theory problem set to the fleet records their future employer keeps. That is why we price for classrooms instead of counting seats like an enterprise: your lab section should never be a procurement negotiation.
Flight physics, fleet operations and what shipped — written for people who fly. No spam, unsubscribe in one click.