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. Link
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.
Ekstrand, B. (2001). Equations of Motion for a Two-Axes Gimbal System. IEEE Transactions on Aerospace and Electronic Systems, 37(3), 1083–1091. Link
All of that is about how to compute. None of it is about how to assemble.
Someone asked me a very basic question: the gimbal, the IMU, the encoder, the STM32 — how do these four actually fit together? And what is BaseCam's role, at what point should it enter? This post answers that.
The one-sentence version
The IMU and the encoder do not measure the same thing.
The IMU is referenced to inertial space; the encoder to the mechanism itself. With the base still, the two readings agree. The moment the base moves they diverge — and that divergence is the reason the gimbal exists.
Get that sentence, and the division of labour among the four parts falls out on its own.
1. Which layer each part sits on
Figure 1: the three loops from outside in, each piece of hardware on its own layer, and two feedback paths of entirely different character.
Part
Layer
Update rate
What it measures / does
STM32
all three
—
FOC commutation, rate loop and position loop all run on it
IMU (gyro)
rate-loop feedback
about 1 kHz
LOS angular rate in inertial space
Encoder
position-loop feedback + FOC commutation
about 10 kHz
joint angle and rotor angle of the mechanism
Motor + mechanism
plant
—
where disturbance enters
The bandwidth plan is post 25's: position loop 2.4 Hz, rate loop 12 Hz, current loop about 1.7 kHz, PWM 20 kHz.
Worth noting: the middle layer is the gimbal. The position loop decides where to point, which is a mission-layer concern. The current loop decides how to produce torque, which is a drive-layer concern. The thing actually fighting airframe motion — the thing that determines whether this gimbal is any good — is the rate loop, and its only source of feedback is that gyro.
So if you can only get one thing right: mount the gyro in the right place and tune the rate loop.
2. One encoder, two entirely different requirements
The encoder has two independent uses, and they get conflated constantly.
Use one: FOC commutation. It wants the rotor's electrical angle. The requirement is speed — it has to keep up with PWM, on the order of 10 kHz — but it need not be absolutely accurate, because commutation only cares where the rotor is relative to the stator, and a fixed offset can be absorbed by a startup alignment.
Use two: position-loop feedback. It wants the joint's mechanical angle. The requirement is absolute accuracy — a 2.4 Hz loop asks nothing of speed, but if the reading carries a 0.5° absolute offset, your gimbal will point 0.5° wrong very stably, with no way to notice from the inside.
The two requirements point in different directions, so "we have an encoder" does not mean both are solved. Concretely:
Incremental encoders (ABZ) do not know where they are at power-up; they need an index pulse or an alignment routine. Commutation can live with that (one twitch at startup and it is aligned). The position loop cannot — you do not want the gimbal to sweep itself every time it boots.
Absolute encoders (SPI magnetic, the AS5048 class) know the angle at power-up and can serve both. This is why gimbals almost always use absolute encoders.
With gearing, does the encoder go on the load side or the motor side? Motor side favours commutation (the electrical angle is directly available); load side favours the position loop (backlash does not enter the error). This is a side benefit of post 29's "direct drive" conclusion: with direct drive the two sides are the same place, and the trade-off disappears.
3. Physical placement matters more than the wiring diagram
Figure 2: a section view of a two-axis gimbal, plus where each part goes, why it goes there, and how fast it runs.
However correct the wiring diagram, a misplaced part will still not stabilize. Three rules.
The IMU must be on the inner frame, on the same rigid body as the camera. What you need is the camera's rate in inertial space, not something else's. Mount it on the base and you measure the airframe's motion — the rate loop will stabilize the base, while the camera hangs off the far side of two joints whose angular motion this gyro cannot see at all.
This is not an implementation detail, it is an architectural fork. Kennedy & Kennedy (2003) splits it into two routes:
Direct: the gyro sits on the stabilized body (the inner frame) and measures the LOS directly.
Indirect: the gyro sits on the base, and the LOS is computed from encoder readings.
The indirect path accumulates every bit of compliance and backlash in the mechanism — and post 29 worked out that a harmonic drive's backlash alone is 2.9 to 8.7 times θ_max = 0.1 mrad. So indirect measurement is basically not viable for a high-precision gimbal unless the mechanism is stiff enough for the error to be negligible.
The encoder straddles the joint. It measures a relative angle, not an absolute attitude. The azimuth one measures the yoke relative to the base; the elevation one measures the inner frame relative to the yoke.
The STM32 can stay on the base or the azimuth yoke — it does not have to ride the elevation axis. All three loops run on it, but it does not need to share a body with the thing being stabilized. Making it ride along only adds a cable bundle crossing a joint — and cables crossing joints are themselves one source of post 23's friction term.
On the update rates: encoder and current sampling are tied to commutation, making them the two fastest links in the system (10 kHz, 20 kHz). The gyro is around 1 kHz. The position loop is 2.4 Hz — three orders of magnitude slower. The same encoder feeds both the fastest and the slowest end.
4. Where BaseCam actually helps
Figure 3: what an off-the-shelf controller covers, drawn on the same design chain as post 28's literature coverage. The two blanks overlap on one cell.
Stage
BaseCam-class off-the-shelf controller
Architecture (axis count / direct or geared / frame or mirror)
No. This is on you
Torque budget, motor sizing
No (post 28: the literature does not do it either)
Comparing drive capability
Starts to matter — its driver tier sets the available current
Implementing the three loops (FOC, rate, position)
All of it
Tuning
All of it, via the GUI
Custom control law (DOB / ADRC / friction feedforward)
Out of scope again — you write firmware
In one line: BaseCam is most valuable in the stretch after you have chosen the motor and before you need a custom control law.
Figure 3 puts it on the same design chain as post 28's literature map. The top bar is the union of the eight gimbal-literature clusters; the bottom bar is what the off-the-shelf controller covers — and both are computed from data, not drawn by me. The result: the two blanks overlap on one cell, motor sizing.
That overlap is worth pausing on. The literature misses that cell because "how big a motor" depends on your payload, airspeed and bandwidth spec, which does not make a paper with general validity — post 22 went and borrowed aerospace mechanism standards precisely because nothing else was there. The product misses that cell because it is a controller, not a mechanism design tool. Different causes, same landing spot.
5. The reverse constraint: the board reaches back and pins the motor
One row above says "starts to matter", and it deserves unpacking, because it runs against intuition.
The assumed order is: pick the motor, then pick a board that can drive it. In practice the board's driver tier reaches back to set the motor's Kt floor, and through it the nadir keep-out:
`` driver tier → available current I per axis → Kt ≥ T_required / I → keep-out = asin(ω_LOS·Kt / (0.7·V_bus)) ``
Running that with post 24's constants (elevation axis T_required = 0.1807 N·m, V_bus = 24 V, ω_LOS = 90°/s):
Driver tier
Current per axis
Kt floor
Nadir keep-out
Standard onboard (1.5 A across 3 axes)
0.75 A
0.2410 Nm/A
1.29°
I2C_Drv custom
3.00 A
0.0602 Nm/A
0.32°
Larger custom driver
6.00 A
0.0301 Nm/A
0.16°
BaseCamBGC Pro (13 A per axis)
13.00 A
0.0139 Nm/A
0.07°
Picking the standard onboard driver is picking a 1.29° nadir keep-out. Nobody describes the decision that way — when you buy the board you are thinking "is it enough to drive it", not "how big a patch straight below can I not track". But they are two ends of the same equation.
In ratios: 0.75 A to 13 A is 17.3× the current, buying 1.29° down to 0.07° of keep-out — also about 17×, since at small angles the keep-out is nearly linear in Kt. The relationship is straight; there is no knee to exploit.
This reverse chain is a third way of writing post 24's "squeezed from both sides": torque demand pushes Kt up from below, keep-out tolerance presses it down from above, and the driver tier decides how high that lower bound sits. Undersize the board and the floor rises, eating the feasible window from underneath.
6. A minimum viable build order
Stringing the previous posts together, the order looks roughly like this — note that the first four steps never touch firmware:
Fix the spec: θ_max (stabilization accuracy), f_bw (rejection bandwidth), acceptable nadir keep-out, whether image derotation is needed.
Fix the architecture (post 29): axis count → direct or geared → coarse-fine or not → frame or mirror.
Compute torque (posts 23 and 24): wind + inertia + friction, times the safety factor; for two axes, sweep elevation as well.
Pick the motor and the board: the Kt floor (torque) and the Kt ceiling (keep-out) bracket a feasible window, and the board's available current sets the floor.
Assemble: gyro on the inner frame, encoders across the joints, STM32 on the base. Get this wrong and everything after it is wasted.
Tune inside out (post 25): lock the current loop, then the rate loop, then the position loop. This is where BaseCam's GUI takes over.
Identify the parameters (post 27): measure J, B and T_c off the machine and check step 3's assumptions.
Measure performance (post 20): LOS jitter and the disturbance-rejection transfer function, to check whether step 1's spec was met.
Steps 7 and 8 will send you back to revise step 3. That is normal, not failure. The real failure is getting step 5 wrong without knowing it — it will not make your loops diverge, it will just make the spec unreachable no matter how you tune, and then you will blame the control law.
The limits of this post
BaseCam's specifics were not verified item by item. The current figures in the table (1.5 A across three axes for the standard board, 13 A per axis for the Pro) come from this site's existing source material for the calculator, not from a fresh check with the vendor for this post. Board generations and firmware versions differ meaningfully; use the datasheet for the board in your hand. The same caveat applies to questions like "is this particular encoder supported".
Cabling, slip rings and EMC are not covered. Cables crossing joints are a real source of friction and of reliability problems, and a continuously rotating axis needs a slip ring. Separate topics.
Only the gyro half of the IMU is discussed. The accelerometer is mainly used for a gravity reference and long-term drift correction, which pulls in attitude fusion (complementary filter or EKF) — a post of its own.
"One STM32 runs all three layers" is a simplification. In practice the current loop is often pushed down into a dedicated driver chip or a second MCU, especially in multi-axis systems. Where the work sits changes; the layering does not.
The update rates are orders of magnitude, not specifications. 1 kHz / 10 kHz / 20 kHz are typical for this class of system, used here to make the point that they are three orders apart.
How to work through this with me
To help judge a build, I need to know:
Where the gyro is going (if the answer is "the base", we need to talk about that first)
Whether the encoder is absolute or incremental, and whether it sits on the load side or the motor side
Whether the board is off-the-shelf or custom, and how much current it can supply
Whether you intend to write your own control law, or use the existing tuning GUI
How many of step 1's four specs are actually fixed
If something's missing, say it's missing — I won't guess a value and fill it in for you.
References
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. Link
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.
Ekstrand, B. (2001). Equations of Motion for a Two-Axes Gimbal System. IEEE Transactions on Aerospace and Electronic Systems, 37(3), 1083–1091. Link
The driver-tier current figures come from this site's existing "BaseCam gimbal stabilization research notes", the same source that backs the gimbal motor sizing calculator.