EL01: Why a drone hovers: forces, units, and your first design loop

Prerequisites and observable goals#

Level: Engineering Lab, Module 1 of 29. About 20 hours in nine sessions: two to three weeks at the track’s pace of about 9 hours a week. Python 3.14 plus four pinned packages, installed into the lab’s virtual environment in section 3.0. No purchases: the physical test uses your phone.

Warm-up: spaced review (10 minutes, closed book)#

If your error log has no reviews due, use these three, drawn from the friction points described in LM. All three come back in this module.

1. Rewrite $\dfrac{5}{x^3}$ and $\dfrac{1}{\sqrt{x}}$ as powers of $x$. (Notation disguises. Units use exactly this bookkeeping: section 2.2 writes m/s$^2$ as m s$^{-2}$.)
2. Differentiate $h(t)=4.9t^2+2t$, then differentiate the result. (Power rule. Section 2.4 reads these two derivatives as velocity and acceleration.)
3. Compute $1-\tfrac15$ and $1\big/\tfrac14$. (Fractions under pressure. Section 2.7 needs both: a hover fraction and its reciprocal.)

The answers are at the very end of this chapter’s solutions.

1. Quick summary#

A quadcopter hovering, seen from the side, so each propeller you see hides a second one behind it. Each propeller throws air downward (blue): the stream it pushes speeds up and narrows below the disc. The air pushes back up on the propeller, and that reaction is the thrust (orange). Gravity pulls down on the whole drone as if at one point, its centre of mass (the quartered disc). In a hover the four thrusts add up to exactly the weight, so the forces balance and nothing accelerates. Every number in this module is about keeping that balance, breaking it on purpose, and paying for it with a battery. EL03 derives the thrust from the air’s change of momentum.

Five ideas carry this module.

1. Every number is a quantity: a value times a unit. Unit algebra is exponent bookkeeping, the same bookkeeping as the power rule. An equation whose units do not match is wrong before you plug in a single number, and your hardware engine refuses to run it.
2. Mass is not weight. Mass is how much stuff there is; weight is the force gravity puts on it, $W=mg$. The “grams” of thrust in a motor’s data table are a force in disguise: gram-force.
3. Newton’s second law, $\sum F=ma$, drawn as a free-body diagram. A hover is balance, and any imbalance becomes acceleration. An accelerometer feels every force except gravity, so on a hovering drone it reads the thrust per unit mass: $+g$, not zero.
4. Thrust-to-weight is the control budget. A hover spends $1/(T/W)$ of the motors’ maximum thrust. What remains is everything the drone has for climbing, turning, and fighting gusts.
5. Energy is power times time, and mass feeds back. Flight time is usable battery energy divided by hover power. A bigger battery stores more energy but weighs more, which raises the hover power. That loop is the first design loop you will close.

What you will build. In your lab repository, your own copy of the companion code’s eng-lab folder, you write the physics core of a Python hardware engine: weight and Newton’s second law, the thrust-to-weight family, energy and flight time, a mass budget with growth allowances, your first parametric CAD part (a drone arm, checked against your own hand calculation), your first requirements, and the analysis for a real measurement you take with your phone. Eighty-two tests check them step by step. The companion code provides the rest of the engine around your code: the units system, the design-file loader, the report that reruns every analysis whenever you change the design, and the tinker command that logs your predictions next to the results. By the end of this module, changing one number in design/drone.toml changes the arm’s CAD mass, the thrust-to-weight ratio, the flight time, and every requirement’s pass or fail, in one report. The Hover Budget Explorer, on the companion website at bezhig.com/book/explorers/el01-hover-budget.html, runs the same model in your browser: drag the battery, payload, motor count, and arm thickness, and watch the thrust arrows, the flight time, the mass spiral, and the accelerometer’s reading move.

2. Deep explanation#

2.1. The question every drone design starts with#

Before anyone draws a part, a drone designer asks two questions: will it lift itself with room to spare, and for how long? Both answers depend on the mass, and the mass depends on the answers. A longer flight needs a bigger battery; a bigger battery is heavier; a heavier drone needs more thrust; more thrust takes more power; more power drains the battery faster. Engineers call this a design loop, and the first job of a design is to close it: to find numbers that agree with each other all the way around.

The loop this module closes. Each box is a section of this chapter and a stage of your hardware engine. Change any number and every box downstream changes; your report reruns the whole loop in seconds.

This module gives you every box at its simplest: forces along one vertical line, efficiency read from a manufacturer’s test table, and a single part in CAD. Later modules replace each box with a better model: EL02 adds moments and balance, EL03 derives hover power from how propellers move air, EL04 adds the electrical side, and EL05 turns the loop into a full trade study.

2.2. Quantities and units: unit algebra is exponent bookkeeping#

A physical number is never just a number. “The arm is 150” means nothing until you know 150 what: millimetres, metres, or grams. A quantity is a value times a unit, and the unit is part of the quantity: $150\ \text{mm}=0.15\ \text{m}$ is one length written two ways.

Base units. The International System of Units (SI) builds everything this module needs from four base units: the metre (m) for length, the kilogram (kg) for mass, the second (s) for time, and the ampere (A) for electric current. Every other unit is a product of powers of these. Here are the ones you will use, each with its exponents written out:

Unit algebra is the power rule’s cousin. Multiplying quantities multiplies their units, and multiplying powers of the same unit adds exponents. So acceleration times time is

a velocity, as it should be. Dividing subtracts exponents. This is the same slip that turns $-48x^{-4}$ into $-48x^4$ in a calculus answer: a dropped minus sign on an exponent. In units, a dropped sign turns seconds into per-second, and the answer is off by a factor of the time squared. Use the Parentheses Rewrite: write every unit as a product of powers before simplifying.

Converting is multiplying by 1. Since $1\ \text{h}=3600\ \text{s}$, the fraction $\dfrac{3600\ \text{s}}{1\ \text{h}}$ equals 1, and multiplying by it changes the units without changing the quantity. Chain as many of these “ones” as you need, and cancel units exactly like factors.

Worked example: the energy in a drone battery. A battery label says 6S (six cells in series) and 1300 mAh. A lithium-polymer (LiPo) cell has a nominal voltage of 3.7 V, so the pack’s nominal voltage is $6\times3.7\ \text{V}=22.2\ \text{V}$. The “mAh” is milliampere-hours: a charge, current times time. Convert it to coulombs, then multiply by the voltage:

Check the units of the product: C V $=$ (A s)(W/A) $=$ W s $=$ J. The amperes cancel, which is why charge times voltage is energy.

Your turn (faded). A 4S 5000 mAh pack. Pack voltage: $4\times3.7=\rule{1cm}{0.4pt}$ V. Charge: $5000\ \text{mA\,h}=\rule{1cm}{0.4pt}$ A h. Energy: W h. Check: 14.8 V, 5 A h, 74 W h. The drone simulator in the author’s FateMMO engine stores exactly this number, batteryCapacityWh = 74.0; EL01.10 audits it.

Dimensional homogeneity. You can only add, subtract, or compare quantities of the same dimension (length with length, force with force). Every term of a correct equation has the same units. And the input of $e^x$, $\ln x$, or $\sin x$ must be a pure number, with no units at all. That gives you a free test of any formula: check its units before trusting its numbers.

A units error that destroyed a spacecraft. NASA lost the Mars Climate Orbiter on 23 September 1999. One team’s ground software reported thruster impulse in pound-force seconds; the navigation software that used it expected newton-seconds, as the interface specification required. The navigation software therefore underestimated the effect of every small thruster firing on the trajectory by a factor of 4.45, the conversion from pound-force to newtons; the spacecraft reached Mars about 170 km lower than planned, and it was destroyed. No single line of code was “wrong”; the units at an interface did not match. The investigation report is listed at the end of this chapter.

Units in code. In C++ you already use a units library without calling it one: std::chrono. You cannot add a std::chrono::seconds to a plain int without saying what the int means, and seconds(2) + milliseconds(500) converts automatically. The C++ library mp-units extends the same compile-time checking to every physical dimension. Your hardware engine uses pint, which does the same thing in Python at run time: every value carries its unit, conversions are automatic, and adding metres to seconds raises an error. Section 2.13 shows how.

Say it back: why does multiplying acceleration by time give a velocity? Answer in exponents.

2.3. Mass, weight, and the gram-force trap#

Mass $m$, in kilograms, is the amount of matter in an object and its resistance to being accelerated. It is the same on Earth, on Mars, and in orbit. Weight $W$ is a force: the pull of gravity on that mass,

where $g$ is the acceleration gravity would give the object if nothing else acted on it. Near Earth’s surface $g$ is about $9.81\ \text{m/s}^2$. For a definite number the world uses standard gravity, $g_0=9.80665\ \text{m/s}^2$ exactly, fixed by international agreement in 1901. Real local gravity varies by a few tenths of a percent, from about 9.780 m/s$^2$ at the equator to 9.832 m/s$^2$ at the poles. Weight is measured in newtons: a 1.5 kg drone weighs $1.5\ \text{kg}\times9.80665\ \text{m/s}^2=14.71\ \text{N}$.

On Mars, where $g=3.73\ \text{m/s}^2$ (NASA’s mean surface value), the same 1.5 kg weighs only 5.595 N. The mass did not change; the weight did. NASA’s Ingenuity helicopter used that to fly in an atmosphere about one percent as dense as Earth’s (EL01.14).

Scales measure force. A kitchen scale measures how hard the object pushes down on it, then divides by an assumed $g$ and displays grams. That is why hobby thrust tables are written in grams: a motor on a thrust stand pushes up on a scale, and the scale reports the “grams” that would push down equally hard. Those grams are gram-force (gf), the weight of one gram under standard gravity:

Two ways to make a scale read “1500 g”. On the left, a mass; on the right, a motor mounted upside down on a thrust stand, blowing air upward so that its thrust presses the stand down. Both push with 14.71 N. The display says grams in both cases, but only the left one is a mass; the right one is 1500 gram-force.

So a motor “making 1500 g of thrust” makes $1500\ \text{gf}=14.71\ \text{N}$. Hobbyists like gram-force for a good reason: to hover, the total thrust in gf equals the mass in grams, so a 650 g drone hovers at 650 gf. The trap is the moment you put gram-force into a physics formula that expects newtons, such as power $=$ force $\times$ speed (section 2.9): the answer comes out 9.8 times too small, with no error message. The hardware engine’s units system is what stops that.

Check yourself: a motor table lists 2.1 kg of thrust. In newtons? (20.6 N.)

2.4. Motion as derivatives (Module 12, just in time)#

Let $h(t)$ be the drone’s height above the ground, in metres, at time $t$ in seconds. Three quantities describe its motion, and each is the derivative of the one before:

The units follow from the derivative: $dh/dt$ is a small change in height (metres) divided by a small change in time (seconds), so velocity is in m/s, and acceleration is in (m/s)/s $=$ m s$^{-2}$. Positive velocity means rising; positive acceleration means the upward velocity is growing (or a downward velocity is shrinking). Throughout this module, up is positive.

Constant acceleration from rest. Suppose the drone starts at rest at $h=0$ and accelerates upward at a constant $a$. Which function has derivative $a$? The function $v(t)=at$. Which function has derivative $at$? Try $h(t)=\tfrac12at^2$: its derivative is $\tfrac12a\cdot2t=at$. It works, and both start at zero. So

Finding a function from its derivative is antidifferentiation, the subject of Module 16. For now, guessing and checking with the power rule is enough.

Worked example. A drone with $T/W=2$ (section 2.7) climbs from rest with $a=9.81\ \text{m/s}^2$ for 1.0 s. Then $v=9.81\times1.0=9.81$ m/s and $h=\tfrac12\times9.81\times1.0^2=4.9$ m. One second of full thrust, and it is climbing at 35 km/h. (Real drones meet air drag long before this, which EL19 adds.)

Walking the chain backwards with a computer. Your phone’s accelerometer gives you $a$ at hundreds of instants a second, not a formula. To recover $v$ and $h$, add up the small changes: over a short step $\Delta t$, velocity changes by about $a\,\Delta t$, and height by about $v\,\Delta t$. That is exactly the update loop a game engine runs every frame, here in the grenade code of ZeroVector, the author’s tactical shooter:

grenade.velocity.y -= 9.81f * dt;                  // gravity changes the velocity
const vec3 displacement = grenade.velocity * dt;   // the velocity changes the position

Averaging the acceleration at the start and end of each step, instead of using only the start, is called the trapezoid rule, and it is far more accurate for the same step size. Lab step 8 builds it; Module 23 proves how accurate it is.

A 2-second climb that speeds up and then slows to a stop 3 m higher (the shape your phone test will have). Top: height. Middle: velocity, the slope of height. Bottom: acceleration, the slope of velocity: positive while speeding up, negative while slowing down, and zero at the instant of fastest climb, where the height curve is steepest. Reading the chain upward is differentiation; reading it downward is integration.

Say it back: at the instant the climb is fastest, what is the acceleration, and why?

2.5. Newton’s second law and the free-body diagram#

Newton’s second law. The net force on a body equals its mass times its acceleration:

Read it as a statement about cause and effect. Forces that cancel produce no acceleration; whatever does not cancel, the net force, accelerates the body, and the heavier the body, the less it accelerates for the same net force. Force and acceleration have directions, so the law is a vector equation. In this module everything happens along one vertical line, so a sign carries the direction.

The free-body diagram: a four-step method.

1. Isolate the body. Draw only the drone, cut free from everything else.
2. Draw every external force where it acts: each thrust at its motor, the weight at the centre of mass, drag opposing any motion through the air, a push from the ground if the drone is sitting on it. Forces the drone’s parts exert on each other (a motor on its arm) are internal and are not drawn.
3. Choose axes and a sign convention. Up is positive.
4. Sum the forces and apply $\sum F=ma$.

Worked example: hover. Four motors with thrusts $T_1,\dots,T_4$ (up), weight $mg$ (down), no drag while still:

In a hover, $a=0$, so $T_1+T_2+T_3+T_4=mg$. For a 1.5 kg drone, the four thrusts must total $14.71$ N, or 3.68 N (375 gf) each if they share it equally.

Worked example: climbing. A 1.2 kg drone runs all four motors at 5.0 N each. Net force: $4\times5.0-1.2\times9.80665=20.0-11.77=8.23$ N upward. Acceleration: $a=8.23/1.2=6.86$ m/s$^2$ upward.

Your turn (faded). A 0.80 kg drone; each motor makes 1.5 N. Net force: $4\times1.5-\rule{1.2cm}{0.4pt}=\rule{1.2cm}{0.4pt}$ N. Acceleration: m/s$^2$. Is it climbing? Check: $6.0-7.85=-1.85$ N; $a=-2.31$ m/s$^2$. It accelerates downward: the thrust does not cover the weight. Whether it is moving up or down depends on its velocity, which the forces alone do not tell you.

This is the same equation as F01’s altitude model, $mz''=T-mg-cz'$, with drag added. F01’s lab drone has $T_{\max}=2mg$; section 2.7 explains that choice.

Say it back: a drone rises at a constant 2 m/s. Draw its free-body diagram and say which force is larger.

2.6. What an accelerometer measures#

Your drone’s flight controller, and your phone, contain a MEMS accelerometer (micro-electro-mechanical system): a speck of silicon with a tiny proof mass held between springs. The chip measures how far the springs are stretched, which tells it the force the springs are exerting on the proof mass.

An accelerometer is a proof mass (blue) on springs inside a case. Gravity pulls the proof mass and the case equally, so gravity alone never stretches the springs: in free fall they relax and the reading is 0. The springs deflect only when another force (the table, the thrust) pushes the case, and the springs must pass that push on to the proof mass. The reading is that non-gravitational force per unit mass.

Why gravity is invisible to it. Gravity pulls on every gram of the phone equally, the case and the proof mass alike, so it accelerates them together and the springs never need to push. Only the other forces (the table, a hand, the thrust) act on the case alone, and the springs must pass them on to the proof mass. So an accelerometer measures the non-gravitational force per unit mass, called the specific force $f$. From Newton’s second law along the vertical, with up positive: the non-gravitational forces are $ma+mg$ (whatever is needed, beyond gravity, to produce the acceleration $a$), so

• On a table: $a=0$, so $f=+g=9.81$ m/s$^2$ upward. The phone reads “one $g$ up” while sitting still, because the table pushes it up.
• In free fall: $a=-g$, so $f=0$. A dropped phone reads zero, even though it is accelerating as hard as gravity can make it.
• A drone: the only non-gravitational force is the thrust (plus drag), so $f=T/m$. In a hover it reads $g$; climbing with acceleration $a$ it reads $g+a$.

That last line is worth a pause: a drone’s accelerometer measures its thrust per unit mass. Divide the reading by $g$ and you have the drone’s instantaneous thrust-to-weight ratio. The drone controller in the author’s FateMMO engine uses exactly this relation in reverse: it computes the thrust it needs as (accelerationSetpoint + gravity) * mass, which is $T=m(a+g)=mf$. And PX4, the open-source autopilot your drone will run, estimates its own hover throttle from this equation while it flies; the code-reading drill (section 4.2) walks through it.

Say it back: in one sentence each, why an accelerometer reads $+g$ on a table and 0 in free fall.

2.7. Thrust-to-weight: the control budget#

Let $n$ be the number of motors and $T_{\max}$ the most thrust one motor can make. The thrust-to-weight ratio compares the drone’s total maximum thrust with its weight:

It is a ratio of two forces, so it is a pure number with no units. Three quantities follow from it directly.

• Hover thrust fraction $\phi$ (the Greek letter phi): the share of the maximum thrust a hover uses, $\phi=\dfrac{mg}{nT_{\max}}=\dfrac{1}{T/W}$.
• What is left over, $1-\phi$: the headroom for everything that is not hovering.
• Maximum climb acceleration: with every motor at full thrust, section 2.5 gives $a_{\max}=\dfrac{nT_{\max}-mg}{m}=g\left(\dfrac TW-1\right)$. At $T/W=2$ the drone can accelerate upward at exactly $1g$. At $T/W<1$ it cannot leave the ground.

Worked example: the drone in your design file. Its motor is a T-Motor AIR2216 II swinging a 10-inch propeller. The manufacturer’s bench test (the thrust table, below) gives $T_{\max}=1332$ gf at full throttle. Section 2.8 finds the predicted mass, $m=1158.6$ g, which weighs 1158.6 gf. So

A hover uses 21.7% of the available thrust; 78% is left for manoeuvring.

Why designers ask for $T/W\ge2$. A multicopter steers by making some motors push harder than others: to pitch forward, the back motors speed up and the front ones slow down. If the hover already demands most of the maximum, the motors that need to speed up cannot, the controller saturates, and the drone stops obeying. Three more demands eat into the same headroom:

• Tilting to move. A drone flies sideways by tilting. Its thrust then points partly sideways, and only the vertical part holds it up. Section 2.5’s balance at a tilt angle $\theta$ needs a total thrust of $mg/\cos\theta$: 15% more than a hover at $30^\circ$. EL01.13 shows that the steepest tilt that still holds altitude is $\arccos\bigl(1/(T/W)\bigr)$, which is $60^\circ$ at $T/W=2$.
• Climbing and gusts, which need $a>0$ and therefore thrust above $mg$.
• A sagging battery. The thrust table was measured with a bench power supply holding exactly 16 V. A real four-cell pack starts near 16.8 V and falls as it drains, and the motors’ maximum thrust falls with it. EL04 measures how much; until then, the margin covers it.

The usual answer to all four is a designers’ rule of thumb, not a law of physics: $T/W\ge2$, a hover at no more than half of maximum thrust. Your requirement SYS-001 states exactly that, and section 2.11 turns it into a mass limit.

Masses: T-Motor’s recommended take-off weights for the first two motors; section 2.8 for yours; the simulator’s parameters for FateMMO (EL01.10); PX4’s model files for its x500, at the commit PX4 v1.17.0 uses (x500_base: a 2.0 kg body plus four 16 g rotors; x500: the motor constant and top speed). Maximum thrusts: the makers’ thrust tables; FateMMO’s $9.1\times10^{-6}\,\text{N/(rad/s)}^2\times(900\ \text{rad/s})^2$; PX4’s $8.549\times10^{-6}\,\text{N/(rad/s)}^2\times(1000\ \text{rad/s})^2$. Sources at the end of the chapter.

Racing and freestyle quads carry huge thrust surpluses because they are flown aggressively; camera and mapping drones sit near 2 to 3 because every gram of motor is a gram of battery they cannot carry. The PX4 simulation model is surprisingly heavy for its motors, which is worth remembering when you compare your simulator with it in EL23.

Reading a thrust table. A motor maker mounts the motor and propeller on a test stand, holds the voltage fixed, steps the throttle, and records thrust, current, electrical power, and efficiency:

The AIR2216 II with a 10-inch propeller at a fixed 16 V, from the manufacturer’s table (the dots are its rows; lines join them). Left: thrust grows faster than throttle, so half throttle gives only 34% of full thrust. Right: efficiency, thrust per watt, is best at low thrust and falls as thrust rises. Your drone hovers at 289.6 gf per motor (orange): about 38% throttle, but only 21.7% of full thrust, at 8.54 gf/W.

Two lessons hide in that figure. First, throttle is not thrust. A propeller’s thrust grows roughly with the square of its speed (EL03 derives why), so the throttle setting that hovers is much larger than the hover thrust fraction $\phi$. FateMMO’s drone simulator shows the same thing in its own terms: its hoverThrottle() (listed in EL01.10) returns the hover motor speed as a fraction of maximum, 0.706, while the hover thrust fraction is 0.499; and $\sqrt{0.499}=0.706$. Second, efficiency depends on where you read it. The table’s best number, 9.12 gf/W, is at 30% throttle; at full throttle it is 5.13 gf/W. Hover power must use the efficiency at the hover thrust, which the engine interpolates from the table.

Say it back: what is $1-\phi$, and name two things the drone spends it on.

2.8. The mass budget#

A mass budget lists every component with its mass, grouped into subsystems, and adds them up. Two ideas turn that list into an engineering tool.

Numbers grow as a design matures. An early estimate forgets things: screws, wire, glue, a heavier connector than planned. Aerospace programs therefore add a mass growth allowance to each item according to how mature its number is. The standard most programs follow, ANSI/AIAA S-120A, gives ranges: roughly 10–35% for an estimate (up to 50–100% for estimated wiring harnesses), 3–25% for a preliminary design, and 1–5% for an item bought from a catalog. A measured part carries only its measurement uncertainty. Your design file uses 20% for estimates, 10% for CAD parts, 5% for catalog parts, and 1% for weighed parts:

where $m_i$ is the item’s mass and $a_i$ its allowance as a fraction.

Worked example: your design file’s budget.

The allowances add 85.6 g, 8% of the basic mass. The battery alone is 38% of the predicted mass, which is why section 2.10 exists.

From a requirement to a mass limit. Requirement SYS-001 says $T/W\ge2$. Solve the $T/W$ definition for the mass: $m_{\text{allow}}=\dfrac{nT_{\max}}{g\,(T/W)_{\min}}=\dfrac{4\times1332\ \text{gf}}{2}=2664$ g. The mass margin is the share of the allowable mass not yet spent:

A large margin this early is comfortable: it can pay for a camera, a bigger battery, or a heavier but stronger arm later.

2.9. Energy, power, and flight time#

Work and power. A force $F$ that pushes something through a distance $d$ along its line does work $E=Fd$ (joules, N m). Power is work per unit time. If the force is constant while the distance changes, $P=\dfrac{dE}{dt}=F\dfrac{dd}{dt}=Fv$: force times speed. (This is where the units trap of section 2.3 bites: put gram-force into $P=Fv$ and the power comes out 9.8 times too small.) Energy is power accumulated over time; at constant power, $E=Pt$.

Battery energy is charge times voltage (section 2.2): your pack stores $5\ \text{A\,h}\times14.8\ \text{V}=74\ \text{W\,h}$. You should not use all of it. Makers recommend stopping at about 3.5 V per cell under load and never going below 3.0 V, where damage begins; and the last part of the charge comes out at a sagging voltage. So flight-time estimates use a usable fraction $f_u$ of the stored energy; 0.8 is a common choice and your design file’s default.

Hover power from the thrust table. Each motor must make $289.6$ gf in a hover (section 2.7). The table’s efficiency at that thrust is $\eta_T=8.54$ gf/W: every watt of electrical power buys 8.54 gram-force of thrust. So each motor draws $289.6/8.54=33.9$ W, and the four draw 135.7 W. The flight controller, GPS, and receiver add about 4 W, for a total of $P=139.7$ W.

Flight time at constant power is usable energy over power:

Two second opinions, and only one of them is independent. First, the hover current is $I=P/V=139.7\ \text{W}/14.8\ \text{V}=9.44$ A; the usable charge is $0.8\times5\ \text{A\,h}=4$ A h, and $4\ \text{A\,h}/9.44\ \text{A}=0.424$ h. Same answer, but it had to be: the current came from the same power, so charge over current is energy over power in disguise. That catches an arithmetic slip, never a wrong model. Second, a route that really is different: the thrust table also records the current each motor drew, measured rather than computed. Read at the hover thrust, it is 2.13 A per motor; with 0.27 A for the electronics the total is 8.78 A, and $4\ \text{A\,h}/8.78\ \text{A}=27.3$ min. The two disagree by about 2 minutes, and the disagreement is information. The table was measured at 16 V, your pack sits near 14.8 V, and at the same thrust a motor needs about the same power, so it draws about $16/14.8=1.08$ times the table’s current. Energy over power accounts for that; the table’s current does not. Your report shows both checks, labelled by kind (section 2.14).

Your turn (faded). Add a 200 g camera. New predicted mass: $1158.6+200\times1.2=\rule{1.2cm}{0.4pt}$ g. Hover thrust per motor: gf. Reading the table between its 309 gf and 373 gf rows, efficiency near that thrust is about 8.3 gf/W, so motor power is $4\times\rule{1.2cm}{0.4pt}\big/8.3=\rule{1.2cm}{0.4pt}$ W; add 4 W. Flight time: min. Check: 1398.6 g; 349.6 gf; $4\times349.6/8.3=168.5$ W, plus 4 W is 172.5 W; $0.8\times74/172.5$ h $=20.6$ min. The engine interpolates the efficiency exactly (8.26 gf/W) and reports 20.5 min; run python -m hwe tinker "payload.mass=200 g" --predict "..." to see.

2.10. The mass spiral: why a bigger battery helps less and less#

A bigger battery stores more energy, but it also adds mass, and more mass raises the hover power. Where does that end?

A first model. Suppose efficiency did not depend on thrust. Let $m_b$ be the battery’s mass and $m_0$ the mass of everything else, $e_b$ the battery’s specific energy (energy per unit mass: your pack’s is $74\ \text{W\,h}/0.421\ \text{kg}=175.8$ W h/kg), and $\eta_T$ the thrust efficiency. Hover power is the total weight divided by the efficiency, so

The fraction $\dfrac{m_b}{m_0+m_b}$ is the battery’s share of the whole drone. It grows when $m_b$ grows, but it can never reach 1, so the flight time creeps toward a ceiling $K$ and never passes it. Each added gram of battery buys less flight time than the one before: diminishing returns. For your drone, $K\approx72$ minutes, which only an all-battery drone could reach.

With the real propeller, the curve turns over. Real efficiency falls as thrust rises (the thrust table’s right panel), so a heavier drone pays more watts for every gram. The engine sweeps the battery capacity from a quarter to eight times the design’s, holding the pack’s specific energy fixed, and reads the table’s efficiency at every new hover thrust:

Flight time against battery capacity for your design file’s drone, from the engine. Doubling the battery from 5000 to 10,000 mAh buys 37% more flight time, not 100%. The longest flight, 40.4 minutes, needs a 25,000 mAh pack weighing 2.1 kg, three times the rest of the drone, and by then $T/W$ has fallen to 1.82 (shaded: fails SYS-001). The largest battery that still meets $T/W\ge2$ is about 22,000 mAh.

That figure is the design loop of section 2.1, drawn. Engineering is choosing a point on it: the best flight time is not the best design, because it fails the control budget. EL03 derives the shape of this curve from how a propeller accelerates air, and uses Module 14’s optimization to find the peak with a pencil: for an ideal rotor, the best battery weighs twice everything else.

2.11. Requirements that can be verified#

A requirement states what the system shall do. The word matters: in engineering documents “shall” marks a binding requirement, “should” a goal, and “will” a statement of fact. A good requirement is one sentence, about one thing, with a number and a unit, that someone can check. Compare:

• Bad: “The drone should fly for a long time.” (No number; “should”; how long is long?)
• Good: “The drone shall hover for at least 12.0 minutes at sea level from a full charge to a resting voltage of 3.5 V per cell.” (One quantity, a unit, and the conditions under which it is measured.)

Every requirement names how it will be verified. NASA’s Systems Engineering Handbook, like most aerospace programs, uses four methods:

• Inspection: look, weigh, or measure the thing itself (weigh the drone on a scale).
• Analysis: calculations and models (the engine’s $T/W$).
• Demonstration: operate it and observe a result, without detailed measurement (it hovers).
• Test: operate it under controlled conditions with instruments, and record data (a timed hover with a logged voltage).

Derived requirements and margins. Requirements form a tree: a top-level need (a flight time) produces derived requirements (a battery energy, a mass limit) that each part must meet. Section 2.8 derived the allowable mass, 2664 g, from SYS-001. A parent field records that link so that a change can be traced to everything it affects. The margin records how comfortably the design meets each requirement, and your report prints it for every one.

Regulations are requirements too. Your drone’s mass decides which rules apply to it. United States federal rules (14 CFR 48.15) require a drone flown only for recreation to be registered with the FAA if it weighs more than 0.55 pounds, about 249.5 g, at take-off, counting everything on board; once registered, it must broadcast Remote ID, and a home-built drone does that with an FAA-accepted broadcast module. A drone flown under Part 107, the rules for non-recreational flying, must be registered whatever it weighs, and flights that produce material for a professional portfolio are safest treated as Part 107. Your worked example weighs 1159 g, so it must be registered either way; a sub-250 g design would avoid registration only for purely recreational flying. EL06 covers these rules in full, with their sources, before you build or fly anything.

2.12. Your first part in code: build123d#

CAD (computer-aided design) programs build exact 3D models of parts. Most engineers use a graphical program such as Siemens NX, CATIA, SolidWorks, or Creo: sketch a profile with the mouse, constrain its dimensions, extrude it into a solid, cut holes, and the program records every step in a feature history. Code-CAD writes the same steps as a program. You will use build123d, a Python library on top of OpenCASCADE, an open-source geometry kernel. The model is a boundary representation: a solid is stored as its exact bounding surfaces, so a circle stays a true circle rather than becoming a polygon. That is why the volume build123d reports agrees with a hand formula to about sixteen significant digits, the limit of a double-precision number: your report shows a difference near $10^{-16}$.

Why code, when industry works in NX? Three reasons that matter for this project. A part written as a function of its dimensions is parametric: change one argument and the whole part regenerates, so your report can re-run the CAD whenever the design changes. Code can be tested, diffed, and reviewed like any other code. And every feature in a graphical CAD program has a counterpart in code, so what you learn here transfers: EL11 rebuilds this arm in NX and maps each click to a line of build123d.

The arm. Your first part is a flat arm like those cut from carbon-fibre plate for small quadcopters: a bar from the frame to the motor, a square pad under the motor with four screw holes and a centre hole, and two bolt holes where it clamps into the frame.

The arm from above, with the ten parameters its function takes: length $L$, bar width $w$, pad size $a$, motor-hole spacing $s$, the frame holes’ inset and pitch, the three hole diameters, and the thickness $t$. The pad is centred on the motor. Drawn to scale for your design file’s arm ($L=190$, $w=16$, $a=32$, $s=19$, $t=5$, in mm); the worked example below uses the lab tests’ smaller arm. Every dimension is a knob: EL07 will use this same function to find the thinnest arm that survives a crash load.

The same arm in an isometric view, drawn by the engine from the CAD solid: visible edges solid, hidden edges dashed, the way engineering drawings show a part. build123d projects every edge and removes the hidden ones; hwe/cad/drawing.py only draws the result.

The units boundary. build123d, like most CAD kernels, takes plain numbers and assumes millimetres. The engine never uses a plain number. So there is exactly one border crossing, the function mm() in hwe/cad/boundary.py, which turns a length quantity into a bare number of millimetres. Hand build123d a length in metres (0.15) where it expects millimetres (150), and the part comes out 1000 times too small in every direction, with a volume $10^9$ times too small, and no error anywhere. Converting at one named boundary is how real systems keep that from happening; the Mars Climate Orbiter’s interface had no such guard.

Mass from geometry. For a part made of one material of uniform density $\rho$ (mass per unit volume), mass is density times volume, $m=\rho V$. The volume is where CAD earns its keep on complicated parts. For this flat arm you can also get it by hand, which is the point: the top-view area is the bar plus the pad, minus the rectangle where they overlap, minus the seven holes, and the volume is that area times the thickness $t$:

where $L$ is the length, $w$ the bar width, $a$ the pad size, and $d_m$, $d_c$, $d_f$ the motor-hole, centre-hole, and frame-hole diameters. (The overlap is $\frac a2$ long because the pad is centred on the motor, so half of it lies over the bar.) For the arm the lab tests use, with $L=100$, $w=12$, $t=5$, $a=28$, $d_m=3.2$, $d_c=8$, and $d_f=3.2$ (all in mm):

build123d reports $8587.398\ \text{mm}^3$ for the same part. Two independent methods, one answer. At the density of a typical carbon-fibre plate, about $1.55\ \text{g/cm}^3$ (one maker lists 1.44 to 1.61 g/cm$^3$ across its solid plates; see the chapter’s sources), one arm is $8.587\ \text{cm}^3\times1.55\ \text{g/cm}^3\approx13.3$ g. Your design file’s longer, wider arm (190 by 16 mm, section 2.8) comes out at 18,547 mm$^3$ and 28.75 g.

2.13. The hardware engine, and the Python this lab adds#

The hardware engine is a pipeline. Each stage reads the design files and the stages before it, and the report shows every result with its cross-check.

The EL01 slice of the engine. Every arrow carries quantities with units. A stage whose core code you have not written yet shows “not written” in the report instead of disappearing; a stage a later module adds shows “locked” with the module that unlocks it.

The Python this lab adds, with C++ comparisons.

The commands (run from your eng-lab folder with the virtual environment’s Python): python -m hwe report runs every unlocked stage and writes out/report/index.html; python -m hwe watch reruns it whenever you save a design, data, or code file; python -m hwe tinker KEY=VALUE --predict "..." changes knobs without editing the design file, compares against the baseline, and logs your prediction beside the result; python -m hwe explain N "..." adds your explanation to entry $N$.

2.14. Cross-checks: how independent is the second opinion?#

An engineer who reports one number with one method is asking to be trusted. An engineer who reports it three ways is showing why they should be. The three kinds of evidence, in rising order of authority:

1. A hand calculation from first principles, on paper: the arm’s volume from its geometry, the flight time from energy over power.
2. An independent model: a different method, program, or data set that shares as little as possible with the first: build123d’s exact solid against your hand formula; flight time from the thrust table’s measured current against energy over power from its efficiency (section 2.9).
3. A measurement: the kitchen scale, the thrust stand, the flight log. Only measurement tells you whether your model matches reality.

Not every second calculation counts, so your report labels each check by kind:

• Independent: a different method or different data. Only this kind can catch a wrong model.
• Recomputed: the same formula and inputs worked a second way, like $T/W$ in plain gram-force arithmetic. It catches slips in code.
• Identity: two results that must agree by algebra, like hover fraction times $T/W$, or charge over a current computed from the same power. It catches arithmetic slips only.
• Assumption: a check that an input suits the model, like the pack’s voltage against the thrust table’s test voltage.

Engineers split this into verification (did we solve the equations right?) and validation (did we solve the right equations?). Hand calculation against CAD is verification: both assume a solid, uniform arm, so they can agree perfectly and both be wrong about a 3D-printed part. Only weighing the part validates the model. Your report’s cross-check table shows each pair side by side with its relative difference, and flags any pair that disagrees beyond its tolerance.

Two cautions. Independence matters: two methods that read the same wrong input will agree on the wrong answer. The current-column check shares its bench test with the efficiency column, so it can expose a table that was misread or misapplied (the field guide’s U7), but not a table that is wrong; only your own thrust stand in EL15 can do that. And the tolerance must match the method: CAD against exact geometry should agree to about $10^{-6}$; two models built on different assumptions, like the table’s 16 V and your pack’s 14.8 V, agree only as well as those assumptions allow; a model against a measurement agrees to a few percent at best. That disagreement is information, not failure.

2.15. Design trade-offs: why this engine looks the way it does#

• Units at run time, not compile time. pint checks units while the program runs, which costs time and catches errors only on paths you execute. Measured on one desktop PC: multiplying two plain Python floats took about 11 ns, multiplying two pint quantities about 4.3 $\mu$s, a few hundred times slower (between 340 and 420 times across three runs). C++ libraries such as mp-units check at compile time for free, but Python has no compiler to do it. For design analysis the cost is invisible; for a flight controller running a thousand times a second it would not be, which is why EL19’s C++ simulator uses plain doubles with units in the names and tests instead.
• A text design file, not a GUI. Every knob lives in drone.toml, so a design change is a one-line diff your Git history records, reviewable like code. A GUI is faster to poke at but leaves no reviewable trail.
• The report is rebuilt from scratch every run. No number is typed into the report by hand, so it can never disagree with the design: the same reason continuous integration beats a hand-updated spreadsheet. The price is that every analysis must be automated, including the ones you would rather eyeball.
• Data tables versus physics models. The thrust table is measured, so it is accurate inside its tested range and silent outside it (the engine refuses to extrapolate it). Momentum theory (EL03) extrapolates anywhere but must be validated against tables and tests. Real engineering uses both and watches where they disagree.
• Code-CAD versus industry CAD. Code is parametric, testable, and diffable, but slower for sculpting organic shapes and rarer in industry job postings: of the 45 postings in EL00, SolidWorks and CATIA appear in six each and NX in five. You learn the concepts here and the industry tool in EL11.

2.16. Beginner mistakes: a field guide#

These are the mistakes people really make in a first sizing calculation. Each has a symptom you can recognize and a way to catch it. For all but U7, a test in your lab catches it: that test was run against a copy of the code with the mistake planted in it, and the copy fails. U7 lives in the engine’s own code, so the report guards against it instead.

3. The lab: build the first slice yourself#

3.0. Setup and ground rules#

Everything lives in your own copy of the companion code’s eng-lab folder; put it under Git, because it is designed to become your public repository. If you do not have Python 3.14 yet, install it from python.org. Then, in PowerShell, go to that folder, create the virtual environment .venv once, install the four packages pinned in pyproject.toml (pint 0.26.1, numpy 2.5.3, matplotlib 3.11.2, and build123d 0.13.0), and run the first check:

cd path\to\eng-lab
py -3.14 -m venv .venv
.venv\Scripts\python.exe -m pip install -e .
.venv\Scripts\python.exe labs\el01_hover\check.py 1

On macOS or Linux the same steps are python3.14 -m venv .venv, .venv/bin/pip install -e ., and .venv/bin/python labs/el01_hover/check.py 1; this chapter writes the Windows forms. Four of step 1’s five tests stop at NotImplementedError: Step 1: weight, and the summary reports step 1 as “not written yet”. That is the starting line. The fifth, test_bare_number_is_refused, already passes: the decorator refuses a bare number before your function even runs. To type plain python instead of the long path, activate the environment first with .venv\Scripts\Activate.ps1; if PowerShell’s execution policy blocks the script, keep using the full path, which always works.

• Your files are the five in hwe/core/ that say “YOU WRITE THIS FILE” (each starts as docstrings only), plus design/requirements.toml, labs/el01_hover/predictions.toml, your phone data, and your tinker log. The tests in labs/el01_hover/tests/ and everything else in hwe/ were written for you; read them freely, but don’t edit the tests.
• Type the code yourself. Don’t paste from the book. Typing is how your hands learn the patterns.
• Predict before every run, in writing. The orange boxes say what to predict.
• When a test fails, read the test before your code. Each test’s comment shows the arithmetic it expected.
• Stuck? Climb that step’s hint ladder (after the practice set) one rung at a time.
• The tests are the judge. A step is done when check.py reports it passing on your own code. After an honest attempt, compare your code with the step’s worked listing or its hint ladder’s skeleton, and with the usual first failures in EL01.16’s solution; find your first incorrect step before you change anything.

3.1. Step 1: quantities, and mass is not weight (worked example)#

First, meet pint in the Python prompt. Start it with .venv\Scripts\python.exe, then type:

from hwe.units import Q_, G0
m = Q_(1.5, "kg")
w = m * G0
print(w)                               # 14.709975, in kg times m/s^2: correct, not yet simplified
print(w.to("N"))                       # 14.709975 N
print(Q_(1500, "gf").to("N"))          # a thrust table's "1500 g"
print(Q_(1300, "mA*h").to("C"))        # charge, not energy
Q_(1, "m") + Q_(1, "s")                # DimensionalityError

Now open hwe/core/hover.py and replace the body of weight with one line:

@quantities(mass="[mass]", g="[acceleration]", returns="[force]")
def weight(mass, g=G0):
    """The weight of a mass: W = m g, the force gravity exerts on it. ..."""
    return (mass * g).to("N")

Line by line: the decorator line (already in the file) states the contract: mass must be a mass, g an acceleration, and the result a force; it checks all three on every call. g=G0 makes standard gravity the default while letting a caller pass Mars gravity. mass * g multiplies the magnitudes and adds the unit exponents (kg times m s$^{-2}$); .to("N") expresses the result in newtons. Leave the docstring in place.

Run .venv\Scripts\python.exe labs\el01_hover\check.py 1.

3.2. Step 2: Newton’s second law (partly filled)#

Goal. net_force, acceleration, and accelerometer_reading. Here are the first two with their key pieces left blank; fill them from section 2.5:

def net_force(thrusts, mass, g=G0):
    total = sum(thrusts, ____)            # a start value WITH units: zero newtons
    return ____ - weight(mass, g)

def acceleration(thrusts, mass, g=G0):
    return (____ / mass).to("m/s^2")      # Newton's second law, solved for a

Why give sum a start value? Unless told otherwise it begins from the plain integer 0. pint makes a special exception for adding or subtracting 0, so here the arithmetic would still work. But where sum’s result is returned directly, as in step 5’s mass budget, an empty list would hand back the bare int 0, a number with no unit, and the caller’s next .to("g") would fail. Writing the start as zero newtons states the unit and makes every case, even the empty one, a force: a habit worth keeping. Now write accelerometer_reading on your own from section 2.6: one line.

Run check.py 2.

3.3. Step 3: the thrust-to-weight family (on your own)#

Goal. thrust_to_weight, hover_thrust_per_motor, hover_thrust_fraction, and max_climb_acceleration, from section 2.7 and their docstrings. No code shown this time. Reuse weight; each function is one or two lines.

Run check.py 3.

3.4. Step 4: energy, power, and flight time (on your own)#

Goal. battery_energy, propulsion_power, and flight_time in hwe/core/energy.py, from section 2.9. flight_time must refuse nonsense: a usable fraction outside $0<f_u\le1$, or a power that is not positive, raises ValueError (Python’s raise ValueError("...")).

Run check.py 4.

3.5. Step 5: the mass budget (on your own)#

Goal. The five functions in hwe/core/massbudget.py, from section 2.8. Read the module docstring first: it names the Item fields and the one Python trap in this file.

Run check.py 5.

3.6. Step 6: the arm in build123d, and its hand check (worked, then on your own)#

Goal. arm() builds the part in section 2.12’s plan view; arm_volume_by_hand() computes its volume from geometry alone. Type arm() from this listing:

def arm(length, width, thickness, pad_size, motor_hole_spacing, motor_hole_diameter,
        center_hole_diameter, frame_hole_diameter, frame_hole_inset, frame_hole_pitch):
    from build123d import (BuildPart, BuildSketch, Circle, GridLocations, Locations,
                           Mode, Rectangle, extrude)
    L, w, t, a = mm(length), mm(width), mm(thickness), mm(pad_size)      # the units boundary
    s, dm, dc = mm(motor_hole_spacing), mm(motor_hole_diameter), mm(center_hole_diameter)
    df, x1, p = mm(frame_hole_diameter), mm(frame_hole_inset), mm(frame_hole_pitch)
    with BuildPart() as part:
        with BuildSketch():                                  # a flat profile on the XY plane
            with Locations((L / 2, 0)):
                Rectangle(L, w)                              # the bar, centred at L/2
            with Locations((L, 0)):
                Rectangle(a, a)                              # the pad, centred on the motor
            with Locations((L, 0)):
                with GridLocations(s, s, 2, 2):              # a 2 x 2 grid, s apart
                    Circle(dm / 2, mode=Mode.SUBTRACT)       # motor screw holes
                Circle(dc / 2, mode=Mode.SUBTRACT)           # centre clearance hole
            with Locations((x1, 0), (x1 + p, 0)):
                Circle(df / 2, mode=Mode.SUBTRACT)           # frame bolt holes
        extrude(amount=t)                                    # the profile, t thick, upward
    return part.part

Line by line: every length crosses the units boundary once, at the top, into plain millimetres. BuildPart opens a solid under construction and BuildSketch a flat profile inside it; a shape created inside a Locations block is centred at each listed point. Shapes add to the profile by default; mode=Mode.SUBTRACT cuts them out instead. Circle takes a radius, so every diameter is halved. extrude sweeps the finished profile upward into a solid, and part.part is that solid.

Now write arm_volume_by_hand() on your own from section 2.12’s formula. Keep the units: your function receives quantities and returns a volume.

Run check.py 6. These tests build real CAD, so the first run takes several seconds while build123d loads its geometry kernel.

3.7. Step 7: your first requirements, and your first report (on your own)#

Goal. At least four more requirements in design/requirements.toml, beside the worked SYS-001, following section 2.11 and the file’s own comments. Between them, use the verification methods Analysis, Test, and Inspection; derive at least one from another (its parent); give every threshold a unit when its result has one; and write a one-sentence rationale for each. A requirement the current design fails is fine: that is information, not a mistake.

Then run the whole engine for the first time and open the result in your browser:

.venv\Scripts\python.exe -m hwe report --open

Run check.py 7.

3.8. Step 8: the phone test (predict, measure, integrate)#

This is your first physical test, and it follows the rule every test in this track follows: the prediction is written, and saved, before the measurement is taken. check.py compares the files’ timestamps and reports whether your prediction came first.

(a) The prediction. Open labs/el01_hover/predictions.toml and fill in every value its comments ask for (you may have done this in session 3): the reading at rest, whether it rises or falls while you lift and while you stop, the height your double integration will report compared with the tape measure, and an honest error band.

(b) The measurement. Install phyphox, a free physics app from RWTH Aachen University, on your phone. Use its “Acceleration with g” experiment, which records the raw accelerometer, gravity included.

1. Lay the phone screen up on a thick book on a table, next to a wall with a tape measure or ruler taped vertically. Start the recording and keep everything still for 2 seconds.
2. Lift the book and phone smoothly straight up by about 30 cm, taking about a second, and hold it steady at the top for 2 seconds. Stop the recording. Read the lift height off the tape measure to the nearest half centimetre.
3. Export the data as CSV (comma separator, decimal point), copy it to your computer, and save it as data/tests/el01_phone/lift.csv. Its columns are Time (s) and Acceleration x (m/s^2) through Absolute acceleration (m/s^2), so the engine reads the units straight from the header.
4. Check the sign: look at the first second of Acceleration z. If it reads about $-9.8$ instead of $+9.8$, your phone reports the opposite convention; set sign = -1 under [tests.phone] in design/drone.toml.

(c) The analysis code. Write cumulative_trapezoid, remove_bias, and velocity_and_height in hwe/core/kinematics.py on your own, from section 2.4 and the docstrings. The tests use synthetic lifts with a known answer, including one with random sensor noise and one that ends while still moving. Run check.py 8.

(d) Predicted versus measured. Run python -m hwe report and open the phone section: your raw reading, the velocity and height you integrated, and the final height.

3.9. Step 9: the tinker loop (three knobs)#

Every concept in this track comes with a knob. The loop: predict what changing it will do, run it, then explain the result, especially when your prediction was wrong. The engine enforces the order: tinker refuses to run without a written prediction.

.venv\Scripts\python.exe -m hwe tinker "battery.capacity=8000 mA*h" --predict "flight time up, but less than the 60 percent the capacity grew: the pack gets heavier. T/W down"
.venv\Scripts\python.exe -m hwe explain 1 "..."

Turn at least three different knobs, one at a time. Good first choices, each tied to a section:

Each entry lands in logs/tinker.csv and in your report. Run check.py 9.

3.10. Read and change the engine#

The engine is yours to read and change, line by line. Three short tasks, in order:

1. Read hwe/units.py (about 150 lines). Explain in writing what require does when it receives a bare float, and how the @quantities decorator finds the argument named mass among positional arguments. (Hint: inspect.signature(func).bind.)
2. Read stage_hover and stage_energy in hwe/pipeline.py. For each cross-check they record, say what the two methods are and whether they are truly independent (section 2.14). Then compare your answers with the Kind column of your report’s cross-check table.
3. Change the report: add “Hover current” (the result energy.hover_current, in amperes) to the tiles at the top of hwe/report/html.py. One line in KEY_RESULTS does it. Run python -m hwe watch in a second terminal first, and watch the report rebuild when you save.

When check.py reports all nine steps passing, you have the first slice of a hardware engine whose physics you wrote. Copy the summary line into your development log (section 5).

4. Practice, code reading, and the gate#

4.1. Practice set#

F = foundation; C = standard; T = transfer; S = optional stretch; L = lab; R = code reading; G = mastery gate. Follow the session plan in section 1. Attempt each problem completely before opening its solution, carry units through every line, and log every miss in your error log with its friction family (LM shows the columns).

// Physical description of a quad-X airframe. Defaults describe a 1.5 kg,
// 450 mm (motor-to-motor) quad on 10-inch propellers and a 4S 5000 mAh LiPo,
// with a thrust-to-weight ratio of about 2.
struct VehicleParams {
    double mass = 1.5;
    double armLength = 0.225;                 // centre to motor axis
    Vec3 inertia{0.015, 0.015, 0.027};        // principal moments about the body axes
    double thrustCoefficient = 9.1e-6;        // N per (rad/s)^2
    double torqueCoefficient = 1.5e-7;        // N m per (rad/s)^2
    double motorTimeConstant = 0.03;          // first-order rotor speed lag, s
    double maxMotorSpeed = 900.0;             // rad/s at command 1
    double minMotorSpeed = 150.0;             // idle speed the controller holds while armed, rad/s
    double linearDragCoefficient = 0.15;      // N per (m/s) of air-relative velocity
    double quadraticDragCoefficient = 0.02;   // N per (m/s)^2
    double angularDragCoefficient = 0.003;    // N m per (rad/s)
    double batteryCapacityWh = 74.0;
    int batteryCells = 4;
    double batteryInternalResistance = 0.03;  // whole pack, ohm
    double powertrainEfficiency = 0.8;        // rotor shaft power / electrical power
    double avionicsPower = 3.0;               // constant electrical load, W
    // ... member functions
};

double VehicleParams::hoverThrottle(double gravity) const {
    // ... input checks
    const double hoverSpeed = std::sqrt(mass * gravity / (4.0 * thrustCoefficient));
    return std::clamp(hoverSpeed / maxMotorSpeed, 0.0, 1.0);
}

// ... in the battery telemetry
const double usedWh = std::max(0.0, params.batteryCapacityWh - s.batteryEnergyWh);
m.currentBattery = saturate<std::int16_t>(s.batteryCurrent * 100.0);
m.currentConsumed = saturate<std::int32_t>(usedWh / (kNominalCellVoltage * params.batteryCells) * 1000.0);
m.energyConsumed = saturate<std::int32_t>(usedWh * 36.0);

4.2. Code-reading drill: PX4 estimates its own hover thrust#

PX4, the open-source autopilot your drone will run, learns its hover throttle in flight. It watches the vertical acceleration and the thrust it is commanding, and fits the one number that makes Newton’s second law agree with them. The code is C++ written by other people, and reading someone else’s code is a skill of its own; its physics is exactly this module’s. Read these three files at this pinned commit (tag v1.17.0); the line numbers below refer to it:

Protocol. Read the header comment of the .hpp (lines 34–62) and the whole .cpp once, top to bottom, without stopping. Words you have not met yet (Kalman gain, covariance, innovation variance) belong to EL22; for now, treat them as machinery that adjusts one number. Then write your explanation for each question before opening its solution.

4.3. Mastery gate#

# (a)
def thrust_to_weight(max_thrust_per_motor, motor_count, mass, g=G0):
    return max_thrust_per_motor / (mass * g)

# (b)
def battery_energy(capacity, cells, cell_voltage=Q_(3.7, "V")):
    return (capacity * cell_voltage).to("W*h")

# (c)
def velocity_and_height(t, accel, still_until):
    v = cumulative_trapezoid(t, accel)
    return v, cumulative_trapezoid(t, v)

4.4. Next steps#

• Record the module. Add an EL01 row to your progress record, a spreadsheet with one row per module (first attempt, gate score, teach-back, tests passing, first error, next review in seven days), and log every miss in your error log.
• The calculus modules. Module 12 is section 2.4 with more examples; Module 14’s optimization is EL01.15; Module 16’s antiderivatives and Module 23’s trapezoid rule are lab step 8.
• EL02 turns the vertical line into a plane: moments, the centre of mass, why unequal thrusts tip the drone, and the matrix that turns “roll, pitch, yaw, thrust” into four motor commands. Your arm gains a place on a frame.

5. Development log entry#

Keep a running DEVLOG.md at the top of your eng-lab repository. It becomes public evidence of what you built, so write every claim so that a stranger could check it. For this module, one entry:

6. Stretch (optional)#

• S1. The best battery. EL01.15, after Module 14: the calculus behind section 2.10’s curve.
• S2. Drag in a climb. Add quadratic drag, $D=kv^2$, to section 2.5’s climb and find the steady climb speed at full thrust for $k=0.02$ N s$^2$/m$^2$ (the value FateMMO’s drone simulator uses, EL01.10). EL19 builds the full model.
• S3. Units at compile time, in C++23 (portfolio). Write a tiny Quantity<M, L, T> template whose exponents are template parameters, so that mass * accel has type Quantity<1, 1, -2> and adding it to a length does not compile. Port weight and thrust_to_weight to it, then compare your design with mp-units. It is exactly the tool the VehicleParams struct of EL01.10 is missing.
• S4. Your first open-source contribution. EL01.22 finds unit comments in PX4 that are dimensionally inconsistent, still present on the main branch as of 26 September 2026. Check the current main branch first; if they are still there, read PX4’s contribution guide and open a one-line pull request that corrects them. A merged fix, however small, is public evidence of careful reading.
• S5. How good is your phone’s accelerometer? Record 60 seconds with the phone perfectly still. Compute the mean and standard deviation of the vertical reading. Predict the height error after 10 seconds of double integration from a bias error of one standard deviation divided by the square root of the number of still samples, then measure it by integrating the still record itself. This is the first step toward EL16 (sensor noise) and EL22 (Kalman filtering).

Frontier connections: where this module’s ideas show up at scale#

Sources for this chapter (checked 26 September 2026)#

Hint ladders for the lab#

Climb one rung at a time, and try again after each one. Rung 1 is a question, rung 2 points to the idea, rung 3 is a skeleton with the key parts left for you.

L1. Step 1: weight#

Rung 1. Which two quantities multiply to give a weight, and which unit should the answer be expressed in?

Rung 2. Section 2.3, $W=mg$; section 3.1’s pint tour for .to().

Rung 3. return (____ * ____).to("N")

L2. Step 2: Newton’s second law#

Rung 1. In section 2.5’s free-body diagram, which forces point up and which point down? Which of them does thrusts hold?

Rung 2. Section 2.5 for the net force and $a=F_{\text{net}}/m$; section 2.6 for the reading, $f=a+g$; section 2.13’s table for sum with a start value.

Rung 3.

    total = sum(thrusts, Q_(0, "N"))
    return total - ____                     # net_force
    return (net_force(____, ____, g) / ____).to("m/s^2")      # acceleration
    return (____ + g).to("m/s^2")           # accelerometer_reading

L3. Step 3: thrust-to-weight#

Rung 1. How much thrust can all the motors make together? How much does the drone weigh? Which of those is on top?

Rung 2. Section 2.7: $T/W$, $\phi=1/(T/W)$, and $a_{\max}=g(T/W-1)$. Reuse weight.

Rung 3.

    return motor_count * ____ / weight(____, g)          # thrust_to_weight
    return weight(mass, g) / ____                        # hover_thrust_per_motor
    return 1 / thrust_to_weight(____)                    # hover_thrust_fraction
    return g * (thrust_to_weight(____) - ____)           # max_climb_acceleration

L4. Step 4: energy and flight time#

Rung 1. What is the pack’s voltage when cells cells of cell_voltage each sit in series? What is charge times voltage?

Rung 2. Section 2.2’s worked example and section 2.9’s hover power and flight time. raise ValueError("...") rejects bad inputs.

Rung 3.

    return (capacity * cells * ____).to("W*h")             # battery_energy
    return motor_count * (____ / ____)                     # propulsion_power
    if not (0 < usable_fraction <= 1): raise ValueError("usable_fraction must be in (0, 1]")
    if power <= Q_(0, "W"): raise ValueError("power must be positive")
    return (____ * ____ / ____).to("min")                  # flight_time

L5. Step 5: the mass budget#

Rung 1. For one item, what is its predicted mass? How do you look up its allowance?

Rung 2. Section 2.8, $m_{\text{predicted}}=\sum m_i(1+a_i)$; the module docstring’s Python traps.

Rung 3.

    return sum((item.mass * (1 + allowances[____]) for item in items), Q_(0, "g")).to("g")
    split = {}
    for item in items:
        split[item.subsystem] = split.get(item.subsystem, Q_(0, "g")) + ____

For allowable_mass, solve $n\,T_{\max}/(mg)=(T/W)_{\min}$ for $m$ on paper first.

L6. Step 6: the arm and its hand check#

Rung 1. (For arm_volume_by_hand.) Sketch the top view. Which rectangles add, which rectangle is counted twice, and which circles come out?

Rung 2. Section 2.12’s formula. Circles take radii in build123d but your formula uses diameters: $\pi d^2/4$.

Rung 3.

    area = length * width + pad_size**2 - (pad_size / 2) * ____
    holes = math.pi / 4 * (4 * ____**2 + ____**2 + 2 * ____**2)
    return ((area - holes) * ____).to("mm^3")

L7. Step 7: requirements#

Rung 1. For each requirement: could someone who has never met you check it, and how? Does it name one quantity, with a unit?

Rung 2. Section 2.11 and the file’s comments; the list of results in tests/test_requirements.py.

Rung 3. A derived requirement in the file’s format: id = "SYS-002", text “The drone’s predicted take-off mass shall not exceed 2664 g.”, verification = "Analysis", result = "mass.predicted", op = "<=", threshold = "2664 g", parent = "SYS-001". Now write one of your own that is verified by Test and one by Inspection.

L8. Step 8: integrating the phone data#

Rung 1. If you know the acceleration at two instants $\Delta t$ apart, by how much did the velocity change between them? Where does the running total start?

Rung 2. Section 2.4’s trapezoid rule and section 3.8’s bias warning. A boolean mask, t < still_until, selects the still samples.

Rung 3.

    total = 0 * y[0] * t[0]                    # zero, already in y's unit times t's unit
    values = [total]
    for k in range(1, len(t)):
        dt = t[k] - t[k - 1]
        total = total + ____                   # one trapezoid: the average of its ends, times dt
        values.append(total)
    return Q_.from_list(values)                # one Quantity array; the units never left

    still = accel[t < still_until]
    return accel - ____                        # remove_bias

L9. Step 9: the tinker loop#

Rung 1. Which section does each knob belong to, and what does that section’s equation say will happen?

Rung 2. Section 3.9’s knob list; write the prediction as a number with a direction (“flight time up about 30%”), not a feeling.

Rung 3. After each run, answer in the explanation: which equation explains the result, and where did your prediction differ, and why?

Complete solutions: EL01#

Open a solution only after you have written your own attempt. Compare at the first step where your work differs. A corrected answer is not yet an independent success.

Open every solution