Abdo, M. M., Vali, A. R., Toloei, A. R., & Arvan, M. R. (2015). Improving two axes gimbal seeker performance using cascade control approach.Proc. IMechE Part G: Journal of Aerospace Engineering, 229(1), 38–55.
Abdo, M. M., Vali, A. R., Toloei, A. R., & Arvan, M. R. (2015). Improving two axes gimbal seeker performance using cascade control approach. Proc. IMechE Part G: Journal of Aerospace Engineering, 229(1), 38–55. DOI: 10.1177/0954410014525130
Abdo, M., Toloei, A. R., Vali, A. R., & Arvan, M. R. (2013). Cascade Control System for Two Axes Gimbal System with Mass Unbalance. 連結
Cascade servo control for LOS stabilization of opto-electronic tracking platform — design and self-tuning. 連結
Ekstrand, B. (2001). Equations of Motion for a Two-Axes Gimbal System. IEEE Transactions on Aerospace and Electronic Systems, 37(3), 1083–1091. 連結
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. (2008). Inertially Stabilized Platform Technology: Concepts and Principles. IEEE Control Systems Magazine, 28(1), 26–46.
This is the twenty-fifth post in the LocalPapa Notes dev-log series, and the eighth on gimbals.
Looking back over the previous seven, there is an obvious gap. Post 18 covered measurement, post 20 the mechanism, and posts 21 through 24 worked out "how big a motor" to five decimal places. But what happens once the motor is bolted on?
The symbol f_bw appears dozens of times across the series without any post ever saying which loop it belongs to, what other loops sit beside it, or why it can only be that order of magnitude. This post fills that in.
The literature
Cascade architecture is standard practice for gimbals and the literature is concentrated:
Abdo, M. M., Vali, A. R., Toloei, A. R., & Arvan, M. R. (2015). Improving two axes gimbal seeker performance using cascade control approach.Proc. IMechE Part G: Journal of Aerospace Engineering, 229(1), 38–55.
Same author group as the Abdo 2013 cited in post 24. It first identifies the stabilization loop's components, then defines a conventional single loop and a cascade loop to compare, concluding that cascade improves both transient and steady-state response. This is also that group's step from modeling into control architecture.
Cascade Control System for Two Axes Gimbal System with Mass Unbalance (2013). The same group's earlier conference paper, folding mass unbalance into the cascade.
Cascade servo control for LOS stabilization of opto-electronic tracking platform — design and self-tuning. Cascade servo design and self-tuning for an opto-electronic tracking platform.
These papers answer "why cascade beats a single loop." They say little about how to allocate bandwidth between layers — that is general servo practice, which section two covers, marked clearly as to what is a general rule and what is this series' own number.
1. What each layer does
Figure 1: the full three-loop cascade. The three feedback paths come from different sensors — current sense, gyro, and encoder or image. Disturbance enters at the plant, which is why the rate loop is the one that does the "stabilizing."
Inside out:
Current loop (FOC) — turns "how much torque I want" into three-phase voltage. It closes on current, and since T = Kt · I, controlling current is controlling torque. This layer is what lets the outer loops command torque without dealing with commutation, back-EMF, or inductance.
Rate loop (stabilization loop) — this is the layer that does the stabilizing in "stabilized platform." It feeds back the gyro's measurement of inertial angular rate and drives it to the commanded value. When the airframe moves, the gyro sees the LOS moving immediately and the rate loop pushes back. "The motor's job is to cancel, not to hold," from post 21 layer 1, describes this layer.
Position loop (track loop) — decides where to point. Feedback can be the encoder (hold a frame angle) or the image (keep the target centered). Its output is an angular rate command to the rate loop, not a direct motor command.
The division of labour fits in one sentence: current loop owns torque, rate loop owns stability, position loop owns pointing.
Disturbance enters at the plant, not at the command input. That is why the position loop barely helps against disturbance — it is far too slow; by the time it reacts the image has already smeared. Disturbance rejection is the rate loop's job, which is why f_bw is called the disturbance-rejection bandwidth.
2. Why the bandwidths must differ by five times
Figure 2: the bandwidth ladder. The middle three are linked — the mechanism's structural resonance caps the rate loop, and the rate loop caps the position loop. The current loop is not on that chain; it is set by PWM and digital delay.
Cascade only works if the inner loop is fast enough to look like a plain gain to the outer one. The general rule of thumb is that the inner loop should close at least 3–5× faster; any less and the inner dynamics eat into the outer loop's phase margin and the two fight each other.
Substituting the series' own numbers:
Rate loop f_bw = 12 Hz — the value this series has used since post 21.
Position loop ≤ 12 / 5 = 2.4 Hz — the separation rule's ceiling. Want faster tracking? Make the rate loop faster first.
Structural resonance f_res ≥ 12 × 5 = 60 Hz — another way of reading the f_res / f_bw ≥ 5 constraint from post 21 layer 6. The mechanism's first mode caps the rate loop.
The current loop is not on that chain. It is set by PWM switching frequency and digital delay; a 20 kHz switching frequency gives roughly a 1.7 kHz current loop — nearly thirty times faster than the separation rule would demand (5 × the rate loop = 60 Hz). Precisely because it is that much faster, the outer loops can safely treat it as a plain gain.
The most useful thing about this ladder is that it assigns blame. A slow position loop is usually not the position loop's fault. Trace back and the rate loop is too slow; trace back again and the mechanism's resonance is too low. If you want faster tracking response, the first thing to look at is the mechanism, not the PID.
3. Tuning has to go inside out
The order is not a preference, it's causal:
Lock the current loop first — compute PI gains from the motor's R and L, and check the step response for overshoot and ringing. If the current loop isn't right, the "torque command" the rate loop thinks it is issuing does not match actual torque, and everything you tune afterwards is compensating for the current loop's error.
Then the rate loop — this is where post 18's measurement comes in: sweep on a shaker table and read the 0 dB crossing of the disturbance-rejection response. Place the notch filter on f_res at the same time.
The position loop last — take the separation rule's ceiling as its bandwidth; usually P or PI is enough.
Compensators layered in between (all riding on the rate loop, not a separate layer):
Notch filter — suppresses f_res. The cost is that the notch drifts with temperature, payload, and wear (post 21 layer 6 notes this).
Friction compensation — LuGre feed-forward, literature surveyed in posts 19 and 22. Low-speed zero crossing is where a gimbal spends most of its time, so this one pays off directly.
Disturbance observer / ADRC — estimate the unmodeled part in real time and cancel it (post 22, clusters 1 and 2).
Gain scheduling — see section 5.
4. Does a gimbal need kinematics?
A question carried over from 6-axis robot arms, and it deserves its own section, because the answer is "yes, but only a small slice" — and you may have already computed that slice.
Figure 3: kinematics compared between a 6-axis arm and a two-axis gimbal. The arm's difficulty is inverse kinematics and pose; the gimbal's inverse kinematics is two atan2 calls, and all the difficulty concentrates in the Jacobian and the reference frame.
Forward and inverse kinematics: barely needed
An arm's forward kinematics is six link transforms multiplied together, and its inverse kinematics needs an analytic or numeric solve plus solution selection. A gimbal has none of that, because it does not move a position, it points a direction:
LOS = R_az(ψ) · R_el(θ) · x̂
One line, and the inverse is closed form: given a target unit vector [x, y, z],
ψ = atan2(y, x), θ = asin(z)
Two atan2-class operations, unique solution, nothing to choose between. There is no such thing as an "IK solver" for a gimbal.
The Jacobian: this is the part that matters, and you already compute it
An arm's 6×6 Jacobian is the core of velocity and force control. A gimbal's is 2×2, and its determinant is cos(el).
That means two things, both of which appeared in post 24:
Where the Jacobian loses rank is gimbal lock — the same mathematical phenomenon as an arm's wrist singularity.
The Jacobian's inverse is the yaw gain — ω_az = ω_LOS / cos(el)is inverting the Jacobian. Everything post 24 computed, said in arm language, is "the inverse Jacobian's entries blow up near the singularity."
The difference: a 6-axis arm can use a 7th axis's redundancy to dodge singularities; a two-axis gimbal doing a 2-DOF job has zero redundancy — so it cannot dodge, only draw a keep-out cone or change the mechanism.
Dynamics: a reduced form of the same equation
Every term in an arm's M(q)q̈ + C(q,q̇)q̇ + G(q) = τ has a gimbal counterpart:
M(q) → J_az(el), configuration-dependent inertia (post 24 computed it: 1.81× across full travel)
C(q,q̇)q̇ → cross-axis coupling terms (what Ekstrand 2001 derives, noting some can be removed by inertia symmetry conditions)
G(q) → gravity torque m·g·e·cos(el), the residual after balancing
So dynamics is not unnecessary — it has already been collapsed by Ekstrand into a few named terms, so you don't re-derive it each time.
The two places where the gimbal is actually harder
Everything above says "the gimbal is simpler." Two things are not:
First, the reference frame is inertial, not the base. An arm's base is fixed, everything is defined relative to it, and forward kinematics from encoders gives the true end-effector pose. **A gimbal's base is moving — that is the problem.** Encoders only tell you how far the frame turned relative to the airframe, and the airframe is moving, so encoders cannot give you the true LOS. That is why a gimbal needs a gyro and an arm does not. It's exactly the "direct versus indirect sensing" question in Kennedy & Kennedy 2003, cited in post 20.
Second, the dominant loop differs. The arm's core is the position loop, driven by kinematics. The gimbal's core is the rate loop, driven by disturbance rejection. The whole architecture's center of gravity is different — the arm's hard problem is computing accurately; the gimbal's is reacting quickly.
One-sentence answer: you need kinematics, but only the Jacobian slice, and that slice is the yaw gain. Forward and inverse are one line each, and the dynamics has been pre-collapsed by the literature. The real effort moves from kinematics to two problems the arm does not have: the inertial reference frame, and the rate loop's disturbance-rejection bandwidth.
5. Elevation dependence lands on two different layers
This section connects post 24's conclusion back to the control architecture. The azimuth axis has two elevation dependencies, they sit on different layers, and they need different fixes — the two are frequently conflated.
Figure 4: the two elevation dependencies. Top: the rate loop's loop gain varies as 1/J_az(el), only 1.81× across full travel. Bottom: the track loop's LOS mapping goes as cos(el), approaching zero.
Rate loop: the J_az(el) variation. The rate loop closes on the azimuth frame's gyro and sees a plant of "motor + J_az". Loop gain goes roughly as 1/J_az, and J_az varies only 1.81× over the whole travel — that magnitude usually sits inside the gain margin, so a fixed gain copes.
Track loop: the cos(el) variation. This layer converts "how much the LOS should move" into "how much azimuth should move," with cos(el) in between. It approaches zero — not a 1.81× problem. Uncompensated, the closer to straight down, the less azimuth command a given tracking error produces, until tracking authority disappears entirely.
So the fixes differ:
Rate loop → a fixed gain is fine (unless your J_az varies far more than 1.81×)
Track loop → the command side must multiply by 1/cos(el) — that is yaw gain compensation
And 1/cos(el) diverges near the singularity, so the compensation itself has a ceiling — and that ceiling is exactly the nadir keep-out cone computed in post 24. Where control cannot compensate, it is the motor's speed limit blocking you, not the algorithm.
The limits of this analysis
The per-layer bandwidth numbers are derived from this series' own f_bw = 12 Hz plus the separation rule, not from industry statistics. A different f_bw shifts the whole ladder.
The 3–5× separation rule is a rule of thumb, not a theorem. Real margin comes from the phase plot, not from a ratio.
The 1.7 kHz current loop is a rough estimate from 20 kHz PWM. The real value depends heavily on digital delay, current sampling timing, and motor inductance — use the drive's measured closed-loop frequency response.
This post covers single-axis loop structure only. Full treatment of cross-axis coupling (MIMO design) is out of scope; that goes back to Ekstrand's or Kane's full model.
How to work through this with me
To apply this to your gimbal, have these ready:
The motor's R, L, Kt (current loop gains come from these)
The drive's PWM frequency and current sampling scheme (sets the current loop's ceiling)
The mechanism's first resonance f_res (sets the rate loop's ceiling; post 18 covers measuring it)
The gyro's noise floor and bandwidth (sets the rate loop's signal quality floor)
Whether tracking comes from encoders or imagery, and the image latency (image latency is often the position loop's real bottleneck)
If something's missing, say it's missing — I won't guess a value and fill it in for you.
References
Abdo, M. M., Vali, A. R., Toloei, A. R., & Arvan, M. R. (2015). Improving two axes gimbal seeker performance using cascade control approach. Proc. IMechE Part G: Journal of Aerospace Engineering, 229(1), 38–55. DOI: 10.1177/0954410014525130
Abdo, M., Toloei, A. R., Vali, A. R., & Arvan, M. R. (2013). Cascade Control System for Two Axes Gimbal System with Mass Unbalance. Link
Cascade servo control for LOS stabilization of opto-electronic tracking platform — design and self-tuning. Link
Ekstrand, B. (2001). Equations of Motion for a Two-Axes Gimbal System. IEEE Transactions on Aerospace and Electronic Systems, 37(3), 1083–1091. Link
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. (2008). Inertially Stabilized Platform Technology: Concepts and Principles. IEEE Control Systems Magazine, 28(1), 26–46.