This is the twenty-first post in the LocalPapa Notes dev-log series. Post 18 covered measuring LOS jitter, post 19 covered tuning the control loop afterward, and post 20 covered designing the mechanism itself. All three share an assumption: the reader already speaks inertially stabilized platform.
This post fills that gap. Built around the methodology in Hilkert, J. M. (2008). Inertially Stabilized Platform Technology: Concepts and Principles. IEEE Control Systems Magazine, 28(1), 26–46, it starts from the most basic concepts and layers upward, with numbers you can verify yourself at every level.
How to use this handbook
Seven layers, shallow to deep. Each reads standalone, but the order is deliberate — every layer uses conclusions from the ones before it.
- Layer 1: What are you stabilizing? (concepts)
- Layer 2: Where does the sensor go? (the earliest, hardest-to-reverse decision)
- Layer 3: How much torque does one axis need? (the core, with a fully worked example)
- Layer 4: From torque to an actual motor
- Layer 5: From one axis to three (nesting, coupling)
- Layer 6: Where the control bandwidth ceiling is
- Layer 7: How to verify what you built actually meets the target
The last section lists exactly what numbers you need on hand for us to work through a sizing problem together.
Layer 1: What are you stabilizing?
Line of sight is not the gimbal's attitude
This is the first concept people conflate. LOS is the line the sensor's optical axis points along in inertial space — not the angle of the gimbal frame relative to the airframe.
Why does that matter? Picture a drone in flight when the airframe rolls 1°. If the gimbal's encoder reading does not change at all (the frame has not moved relative to the airframe), the LOS has just moved 1° — because the whole gimbal was carried along with the airframe. The encoder faithfully reports "the frame did not move," and the image smears anyway.
A stabilized platform suppresses LOS jitter in inertial space, not the frame angle relative to the airframe. That is why the field is called inertially stabilized platforms.
So "stabilizing" is not locking the gimbal down
The intuitive move is: clamp the motors, do not let anything move, and it will be stable. The opposite is true.
When the airframe rolls 1°, a perfectly rigid gimbal (equivalent to locked) carries the LOS along with it for the full 1°. To hold the LOS still, the gimbal frame has to rotate 1° the other way relative to the airframe — it has to actively move, as fast and as accurately as the disturbance.
This is the most counter-intuitive point, and everything downstream follows once it clicks: the motor's job is cancellation, not fixation.
Why you need a gyro, and encoders are not enough
An encoder measures how far the frame turned relative to the airframe — a relative quantity. A gyro measures how fast something is rotating in inertial space — an absolute quantity.
To stabilize LOS you need to know the LOS motion in inertial space, and only a gyro provides that. Encoders have their own roles (knowing where the frame points, closing a position loop, travel-limit protection), but they cannot achieve inertial stabilization on their own.
Where the disturbances come from
Naming the adversaries makes the torque budget meaningful. Four main categories:
- Carrier motion: airframe attitude changes transmitted straight through the mechanism. The largest contributor.
- Aerodynamic forces: torque from relative airflow hitting the payload in flight. On airborne gimbals with exposed payloads this is usually the largest steady-state load (Layer 3 proves it with numbers).
- Mechanical friction and cable drag: bearing stiction, slip-ring drag, wiring-harness spring-back. Hard to model precisely; in practice estimated as an empirical fraction.
- Mass unbalance: when the center of gravity is off the rotation axis, gravity produces an attitude-dependent torque. This term does not appear in the torque budget formulas — the methodology assumes you have already balanced it out (Layer 5 covers this in depth).
Layer 2: Where does the sensor go?
This is the earliest and hardest-to-reverse decision in the whole design flow — changing it means changing the mechanical layout, the cable routing, and the slip-ring channel count.
Per Kennedy, P. J., & Kennedy, R. L. (2003). Direct versus Indirect Line of Sight (LOS) Stabilization. IEEE Transactions on Control Systems Technology, 11(1), 3–15:
- Direct sensing: the gyro mounts on the payload, so what it measures is the LOS. Every mechanical error (flexure, backlash, compliance) is enclosed inside the control loop — the controller sees it, so the controller can cancel it.
- Indirect sensing: the gyro mounts on the gimbal frame (or the airframe), and LOS is inferred from encoder readings plus kinematics. In that inference, any flexure or backlash between the encoder and the payload becomes an invisible error — the controller does not know it exists, so it cannot compensate for it.
Direct sensing has the higher precision ceiling, at the cost of putting a gyro inside the rotating payload pod (adding inertia to that axis, requiring more slip-ring channels). Indirect sensing keeps the mechanism simple, but your precision ceiling is locked to your structural stiffness.
There is no universally right answer here — but you must know which one you picked and what it costs you.
Layer 3: How much torque does one axis need?
This is the core of Hilkert's methodology, and the formula chain implemented in the motor sizing calculator.
Four torque sources
What the motor fights breaks into four terms, estimated separately and summed:
T_wind: torque from aerodynamic drag (steady-state; the motor holds against it continuously)T_inertia: acceleration torque needed to actively correct disturbances (dynamic; a short-duration peak)T_friction: friction and cable drag (empirical fraction)- Multiplied by a safety factor
SF covering all the unmodeled uncertainty
The fully worked example
Here is one pass through the Pitch axis using the calculator's default values. Open the calculator alongside and the numbers will match exactly.
Given: air density ρ = 1.225 kg/m³, flight speed v = 18 m/s, gust factor 1.4, drag coefficient Cd = 0.45, frontal area A = 0.025 m², moment arm L_arm = 0.050 m, moment of inertia J = 0.0012 kg·m², stabilization bandwidth f_bw = 10 Hz, target angular deviation θ_max = 1 mrad, friction fraction 15%, safety factor SF = 2.5, torque constant Kt = 0.18 Nm/A.
Step 1 — design airspeed. The 18 m/s you typed in is not the number that goes into the formula; it gets multiplied by the gust factor first:
v_design = 18 × 1.4 = 25.2 m/s
The gust factor scales "sustained cruise speed" up to "design speed including instantaneous gusts." It has a different job from the safety factor SF applied later — this is not double-counting.
Step 2 — aerodynamic drag:
F_drag = ½ × 1.225 × 25.2² × 0.45 × 0.025 = 4.3758 N
Step 3 — wind torque. Drag is not torque; multiply by the moment arm to the rotation axis:
T_wind = 4.3758 × 0.050 = 0.21879 N·m
Step 4 — peak angular acceleration. This step asks: "to hold angular deviation under 1 mrad within a 10 Hz bandwidth, how much acceleration reserve is needed?" It uses the simple-harmonic peak-acceleration formula:
α = (2π × 10)² × 0.001 = 3.9478 rad/s²
Step 5 — inertial torque (Newton's second law, rotational form):
T_inertia = 0.0012 × 3.9478 = 0.00474 N·m
Step 6 — friction torque (an empirical fraction of the first two combined):
T_friction = (0.21879 + 0.00474) × 15% = 0.03353 N·m
Step 7 — total required torque:
T_required = (0.21879 + 0.00474 + 0.03353) × 2.5 = 0.64264 N·m
Step 8 — convert to current:
I_cont = 0.21879 / 0.18 = 1.2155 A (matches steady wind drag — what the motor carries continuously)
I_peak = 0.64264 / 0.18 = 3.5702 A (matches total demand — the instantaneous value during maneuvers)
Three intuitions from these numbers
First: drag dominates. With these parameters the split is T_wind 85.1%, T_friction 13.0%, T_inertia just 1.8%.
That explains the calculator's hint that "being off by 2× on J usually changes the result by under 5%." Test it: double J from 0.0012 to 0.0024 and T_required goes from 0.64264 to only 0.65626 — a 2.1% difference. On a drag-dominated airborne gimbal, precision on the inertia estimate matters far less than getting the moment arm L_arm right.
Second: airspeed enters squared. Double the design airspeed (25.2 → 50.4 m/s) and T_wind goes from 0.21879 to 0.87516 — exactly four times. T_required becomes 3.94× (slightly under four, because T_inertia did not change).
Third: bandwidth is also squared, but its impact depends on the share. Double f_bw from 10 Hz to 20 Hz and α goes from 3.95 to 15.79 (4×), pushing T_inertia from 0.00474 to 0.01895. But since the inertial term only held 1.8% to begin with, T_required rises only 6.4%.
The same formula chain has completely different sensitivities on different designs. Large domes and fast airframes → drag-dominated. Heavy payloads, high bandwidth, low-speed or indoor applications → inertia-dominated. Read the breakdown table first to find out which one you are, then decide where to spend your measurement effort.
Layer 4: From torque to an actual motor
Getting T_required still leaves a stretch of road before "which motor should I buy."
Torque and current: Kt
I = T / Kt
This is not an engineering approximation — it is a physical property of the motor. An ideal brushless motor's output torque is exactly proportional to current, and Kt is that constant of proportionality, in Nm/A.
Kt and KV: two units for the same thing
The problem is that vendor datasheets mostly publish KV (rpm per volt) rather than Kt. The two are the same thing expressed differently:
Kt = 60 / (2π × KV) ≈ 9.5493 / KV
Substituting gives a genuinely useful relationship:
I = T × KV / 9.5493
For the same torque demand, a higher KV means a larger current draw. That is why gimbal motors run low KV (in the 20–300 range, an order of magnitude below drone propulsion motors) — a gimbal wants lots of torque from little current, and speed is irrelevant.
One practical trap
The constant in that conversion shifts by a factor of 2/√3 ≈ 1.155 depending on the KV definition convention (phase vs line-to-line voltage), and 8.27/KV is also commonly seen. Nobody's arithmetic is wrong — the conventions differ. When a KV you derived from Kt does not match the vendor's stated KV, check this before suspecting the data is bad.
Continuous and peak current must be compared separately
This is where sizing margins get misjudged most often:
- Continuous current matches
T_wind — steady drag is what the motor carries indefinitely, and it determines whether it overheats
- Peak current matches
T_required — including inertia, friction, and safety factor; the instantaneous demand during a short maneuver
Comparing peak current against a motor's continuous rating understates the motor; comparing continuous current against a peak rating overstates it. Walk both paths independently and take the stricter conclusion.
Layer 5: From one axis to three
Everything so far has been single-axis. A three-axis gimbal is not "run the single-axis calculation three times."
First, an important disclosure: this layer is not in Hilkert's paper
Hilkert 2008 defines a torque budget for a balanced axis treated in isolation. How to measure mass properties on a nested axis set, and how to handle cross-axis coupling, are a different level of problem — requiring standard rigid-body mechanics, and (for precision) multibody dynamics. This section is a procedure this site adds on top of that methodology, not content from the paper.
Nesting: outer axes carry inner ones
The axes of a three-axis gimbal are nested. Taking the common Yaw ⊃ Roll ⊃ Pitch arrangement:
- Pitch (innermost) drives only the payload pod
- Roll (middle) drives the payload pod plus the Roll mechanism
- Yaw (outermost) drives the payload pod plus the Roll mechanism plus the Yaw mechanism
The determination method is concrete: grab the moving half of that axis, turn it by hand, and every part that comes along counts; every part that stays still does not.
But you cannot add the three J values together
This is the most common and most insidious error. Two independent reasons:
- Double counting:
J_roll already contains the entire payload pod, and so does J_pitch. Adding them counts the payload twice. The scopes are Russian dolls, not three puzzle pieces.
- The three axes are not parallel: the complete description of rotational inertia is a tensor
I, and the scalar J you want is its projection onto a direction, J = n̂ᵀ·I·n̂. Three mutually perpendicular directions; adding the three projections is like adding a force vector's Fx, Fy and Fz to get "how big the force is" — the units work, the physics does not.
The correct approach: perform an independent measurement for each axis, with the selection scope expanding axis by axis, and each time set the measurement reference axis to that axis's actual line in space. Your CAD mass-properties tool handles the parallel-axis theorem for you.
Another trap: the outer axis does not necessarily have larger J
Intuition says the outer axis carries more, so its J must be bigger. Not necessarily. The Yaw axis is usually vertical with the whole gimbal stacked along it, so mass sits close to the axis line; the Roll axis is horizontal with the payload possibly hanging several centimeters below it. The square of the distance matters far more than the mass, so Roll's J exceeding Yaw's is entirely common.
Attitude dependence: J is not a constant
Here is something that does not exist in the single-axis world: an outer axis's J changes with the inner axes' angles. When Roll swings to 90°, the payload pod moves from "directly below" to "out to the side," and the Yaw axis sees a completely different moment arm — a 2× difference in J is entirely normal.
Size for the worst-case attitude, not the neutral one. At minimum, measure once at each travel limit.
Balancing: why it is a prerequisite, not an option
The torque budget formula chain has no gravity term. That is not an omission — it is the methodology's premise: the payload's center of gravity already sits on the rotation axis.
Skipping it causes two problems:
First, torque gets badly underestimated. A 400 g payload whose CG sits 1 cm off-axis produces a gravity torque of 0.4 × 9.81 × 0.01 ≈ 39 mN·m — larger than the entire peak demand of a small gimbal, and unlike a peak it is a static load the motor holds continuously, generating heat the whole time.
Second, the equations of motion for two axes stop being decoupled. The shared conclusion across the literature is that when a gimbal is properly balanced, the azimuth and elevation equations of motion decouple — each axis's angular rate depends only on the net torque applied to that axis. Without balancing, cross-coupling terms appear, meaning tuning the Pitch controller inadvertently affects Yaw behavior, and the two axes can no longer be designed or tuned independently.
Balancing is not merely a labor-saving trick for reducing gravity torque. It is the mathematical premise that lets three axes be treated as three independent systems. That is why it sits before motor sizing in the design flow.
Beyond static balance: dynamic unbalance
Driving the combined CG onto the rotation axis only gets you halfway. That is static balance (Σ m·u = 0): it will not tip one way when standing still.
But if the counterweight sits fore or aft of the payload along the rotation axis, the pair forms a couple as soon as it spins — that is dynamic unbalance, mathematically a non-zero product of inertia P_uw = Σ m·u·w. A non-zero product of inertia means the principal axes of inertia are not aligned with the rotation axis, so rotation itself generates a cross-coupling torque pulling the payload sideways — and static balancing gives you no visibility into it at all.
Substituting the static-balance condition gives a very clean result:
P_uw = m_p · u_p · (w_p − w_c)
In other words, once statically balanced, dynamic balance asks for only one more thing: the counterweight and the payload must lie in the same plane perpendicular to the rotation axis. However far apart they sit along the axis is how much dynamic unbalance you get — a linear relationship, unlike the square law governing ΔJ. In practice this means the counterweight should not stick out behind on the end of an arm.
The balance visualizer computes both layers live.
Layer 6: The control bandwidth ceiling
f_bw is the only parameter in the torque budget that you choose, which is exactly why it is the easiest one to fill in with a number the mechanism cannot actually deliver.
f_bw is not a free parameter
The step α = (2π·f_bw)² × θ_max is squared-sensitive to f_bw. Entering 10 Hz versus 25 Hz changes the inertial torque by 6.25×. But the more serious problem is: enter a bandwidth the structure cannot support and the calculator will still hand you a confident answer.
The ceiling is set by the mechanism, not by you
The control bandwidth ceiling is determined by the first structural resonance frequency. The servo rule of thumb:
f_res / f_bw ≥ 5: comfortablef_res / f_bw ≥ 3: tight but workable, with caref_res / f_bw < 3: beyond what the mechanism can do
Note that this is a rule of thumb, not a hard requirement from any specific paper.
A notch filter can push the bandwidth up somewhat, but the notch frequency drifts with temperature, payload and wear — with thin design margin, that is a fragile solution.
Pick the lowest frequency, not the largest amplitude
A measured frequency response typically shows several resonant peaks. The one that constrains bandwidth is the lowest-frequency mode, not the highest-amplitude one. This is easy to get backwards.
The calculator's f_res field deliberately has no default value — this number can only come from measurement or modal analysis, and guessing one would make the check meaningless. Fill it in and it checks; leave it blank and it says plainly that it cannot check, rather than pretending it did.
Layer 7: Verifying what you built actually meets the target
Hilkert 2008 provides a demand-side estimate, and that paper is itself explicit when discussing stabilization-loop design: whether what you built is actually good enough has to be verified with a measured frequency response. The follow-up paper by Hilkert and Pautler (Reduced-Order Disturbance Observer Applied to Inertially Stabilized Line-of-Sight Control, Proc. SPIE 8052, 2011) develops this further.
In other words:
The calculator answers "roughly how much torque do you need." Measurement answers "does what you built actually meet the target." You need both, and the second cannot be substituted by the first.
The standard approach mounts the gimbal on a rate table, excites the base with a known angular-rate profile, records LOS error simultaneously, and uses system identification to derive the closed-loop disturbance rejection frequency response — which is where the f_bw input field should, in principle, have come from in the first place.
One definition that is easy to get wrong: disturbance rejection bandwidth is taken at the 0 dB crossing, not −3 dB. The disturbance transfer function should sit well below 0 dB at low frequency (disturbance suppressed); crossing 0 dB is where the controller has stopped keeping up.
Measurement results feed back into the earlier design targets — measured θ_max, f_bw and structural resonance all backfill into the calculator in one click. This is a loop, not a one-way street.
Where this methodology stops
Marking the boundary honestly matters as much as explaining the method.
Hilkert 2008's methodology covers: torque and bandwidth demand estimation for a balanced axis treated in isolation. That is precisely the answer to "how big a motor."
Not covered, but you will eventually need it:
- Precise cross-axis coupling torque. The formula chain treats the three axes as independent systems. If balancing falls short, or the inertia tensor's principal axes are not aligned with the rotation axes, real coupling terms appear — computing them precisely means Kane's method, Lagrangian mechanics, or multibody dynamics software.
- How to tune the controller optimally. That is an entire separate field; recent literature clusters heavily around Active Disturbance Rejection Control (ADRC) and disturbance observers.
- Optical-system-level architecture design. That is what the companion paper in the same journal issue answers: Masten, M. K. (2008). Inertially Stabilized Platforms for Optical Imaging Systems. IEEE Control Systems Magazine, 28(1), 47–64. The two together are the actual complete ISP primer.
One more: the calculator uses a simplified simple-harmonic peak-acceleration estimate, not a full dynamic model. It is a design-stage estimating tool that gives order-of-magnitude-correct answers, not exact solutions.
How to work through this with me
If you want help sizing a specific gimbal, here is what you need on hand. Say so plainly if something is missing — I will not guess a value and fill it in, because a guessed number makes the whole result meaningless.
Environment (shared across all three axes)
- The target airframe's actual flight speed (do not use a "wind resistance rating" — that measures the airframe's thrust against headwind while hovering, not the relative airflow the gimbal sees)
- Altitude or air density (use the sea-level standard 1.225 if unsure)
Per axis (one set for each of the three)
- Moment of inertia J (kg·m²) — from CAD mass properties; remeasure per axis with expanding scope, and take the worst-case attitude value
- Frontal projected area A (m²) — the projection of that axis's rotating group perpendicular to the airflow direction
- Moment arm L_arm (m) — the perpendicular distance from the center of pressure to that axis's line, not the housing dimension
- Drag coefficient Cd — pick the conservative value (boxy 1.0) if unsure
- Stabilization bandwidth f_bw (Hz) — your mission requirement; if you have measured the structural resonance, send that too
- Target angular deviation θ_max (mrad) — your precision requirement
Balance state
- Balanced or not. If not, send the payload mass and CG offset per axis and we run the balance check before sizing.
Drive side (if you already have candidates)
- The driver's continuous and peak current limits
- Candidate motors' Kt or KV, rated and peak torque, rated and peak current
If you have a CAD/STEP model but have not extracted these numbers yet, say so — the measurement procedure can be broken into a step-by-step checklist first.
References
- Hilkert, J. M. (2008). Inertially Stabilized Platform Technology: Concepts and Principles. IEEE Control Systems Magazine, 28(1), 26–46.
- Masten, M. K. (2008). Inertially Stabilized Platforms for Optical Imaging Systems. IEEE Control Systems Magazine, 28(1), 47–64.
- Kennedy, P. J., & Kennedy, R. L. (2003). Direct versus Indirect Line of Sight (LOS) Stabilization. IEEE Transactions on Control Systems Technology, 11(1), 3–15.
- Hilkert, J. M., & Pautler, D. (2011). Reduced-Order Disturbance Observer Applied to Inertially Stabilized Line-of-Sight Control. Proc. SPIE 8052, Acquisition, Tracking, Pointing, and Laser Systems Technologies XXV.
Related tools: Gimbal Motor Sizing Calculator · Gimbal Balance Visualizer