Self Balancing Robot Theory: PID Tuning and IMU Sensor Fusion

A self-balancing robot is an inverted pendulum system that uses an inertial measurement unit (IMU) and a PID control loop to continuously adjust motor torque and maintain its center of gravity directly over its wheel axis. Building one fundamentally changes your microcontroller circuit from a simple sequential logic executor into a high-speed, real-time closed-loop feedback controller, demanding strict hardware timing, interrupt management, and specialized motor drivers. The most common mistake hobbyists make when approaching this build is confusing raw accelerometer data with the true tilt angle, ignoring gyroscope drift and the absolute necessity of sensor fusion.

The Physics and the Feedback Loop

Think of balancing a broomstick on the palm of your hand. If the stick leans forward, you must move your hand forward to catch the center of mass before gravity accelerates the stick out of your reach. A two-wheeled robot does exactly this, but it uses motors to drive the "hand" (the wheel base) under the falling mass.

Because the robot's center of mass is intentionally placed above the wheel axle, it exists in a state of unstable equilibrium. Gravity exerts a rotational torque that increases non-linearly as the tilt angle increases. To counteract this, the microcontroller must read the tilt angle, calculate the required corrective torque, and apply it to the motors. To maintain stability, this read-calculate-actuate loop must execute between 100Hz and 250Hz (every 4ms to 10ms). If the loop jitters or drops below 50Hz, the derivative calculations fail, and the robot will violently oscillate and fall.

Sensor Fusion: Why Raw Data Fails

To know its tilt angle, the robot relies on a 6-axis IMU, typically the ubiquitous TDK InvenSense MPU-6050. This chip contains a 3-axis accelerometer and a 3-axis gyroscope. Neither sensor can do the job alone.

• The Accelerometer: Measures proper acceleration. When stationary, it measures gravity, allowing you to calculate the tilt angle using trigonometry (atan2). However, the moment the robot's motors vibrate or the chassis accelerates linearly, the accelerometer reads those forces as false tilt, resulting in incredibly noisy data.
• The Gyroscope: Measures angular velocity (degrees per second). By integrating this velocity over time, you get the tilt angle. It is immune to linear vibrations, but integration introduces cumulative floating-point errors, causing the calculated angle to "drift" away from zero over time.

To solve this, we use a Complementary Filter (or a Kalman filter) to fuse the data. The filter trusts the gyroscope for high-frequency, short-term movements, and trusts the accelerometer for low-frequency, long-term baseline correction.

Worked Numeric Example:
Assume a loop time (dt) of 0.01 seconds. The previous fused angle was 2.0°. The gyroscope reads an angular velocity of 15°/s. The accelerometer calculates a raw angle of 2.8°.
Using a standard complementary filter with a 0.98 weighting for the gyro:
Fused_Angle = 0.98 * (Previous_Angle + (Gyro * dt)) + 0.02 * Accel_Angle
Fused_Angle = 0.98 * (2.0 + (15 * 0.01)) + 0.02 * 2.8
Fused_Angle = 0.98 * (2.15) + 0.056 = 2.107 + 0.056 = 2.163°
The robot now confidently knows it is leaning forward at 2.163°, ignoring the high-frequency noise from the accelerometer.

The PID Controller: A Worked Numeric Example

Once you have a clean angle, you need to translate that error into motor power. This is handled by a Proportional-Integral-Derivative (PID) controller. According to National Instruments' control theory primers, PID calculates an output based on three distinct terms:

1. Proportional (P): Reacts to the current error. The further it leans, the harder the motors push.
2. Integral (I): Reacts to the accumulated past error. Think of the I-term like a water tank filling up; even if the flow stops (error reaches zero), the tank remains full, providing the baseline continuous power needed to hold the robot upright against gravity without oscillating around the setpoint.
3. Derivative (D): Reacts to the rate of change of the error. It acts as a damper, predicting where the angle is going and applying brakes to prevent overshooting.

Where You Meet This in Practice

The inverted pendulum control loop is not just a parlor trick for Arduino hobbyists; it is a foundational control system in modern engineering. You meet this exact mathematical framework in:

• Personal Transporters: Segways and modern electric unicycles use multi-axis IMUs and heavy-duty PID loops to manage rider weight shifts.
• Aerospace: SpaceX’s Falcon 9 booster landing sequence relies on thrust-vectoring PID loops reacting to 3-axis IMU data to balance a 14-story cylinder on a column of fire.
• Cinematography: Brushless camera gimbals use high-frequency PID loops to isolate the camera from the operator's walking vibrations, keeping the horizon perfectly level.

Real-World Scenario Walkthrough: The I2C Bottleneck

Theory is clean; the workbench is not. Here is a classic failure mode when building a self balancing robot with off-the-shelf maker parts.

The Setup: An Arduino Nano, an MPU-6050 breakout board, an L298N motor driver, and two 6V N20 gear motors powered by a 2S (7.4V) LiPo battery. The code uses the standard Arduino Wire.h library to poll the IMU and a simple delay(20) to maintain a 50Hz loop.

The Numbers: 7.4V nominal battery voltage, 50Hz target loop rate (20ms per cycle), 6V rated motors.

The Outcome: Upon powering up, the robot emits a loud, high-pitched audible whine from the motors. It oscillates violently back and forth by about 15 degrees before immediately falling over. The serial monitor shows loop times jittering between 18ms and 35ms.

What Went Wrong: Two distinct hardware and software failures combined to kill the project.

1. The Motor Driver Voltage Drop: The L298N uses older bipolar junction transistors (BJTs), which inherently drop about 2V to 3V across the H-bridge. Your 7.4V LiPo is only delivering ~4.5V to the motors. When the PID loop demands a low PWM value to make a micro-correction, the voltage drops below the motor's stall threshold. The motors don't move, the error accumulates, and the I-term winds up until it violently jerks the robot.
2. The I2C Blocking Jitter: The standard Wire.requestFrom() function in Arduino is blocking. While the Nano waits for the 14 bytes of IMU data over I2C, hardware interrupts are paused. If a motor PWM timer interrupt fires during this wait, it gets delayed. This introduces massive jitter into your dt (loop time) variable. Because the Derivative (D) term divides by dt, a jittery dt causes the D-term to output massive, erratic spikes, shaking the robot apart.

The Fix: Swap the L298N for a MOSFET-based driver like the TB6612FNG, which has a voltage drop of only ~0.5V, delivering proper torque at low PWM. Next, configure the MPU-6050's internal Digital Motion Processor (DMP) to calculate the fused angle on the chip itself, push it to its hardware FIFO buffer, and trigger an interrupt pin on the Arduino when data is ready. This guarantees a rock-solid, jitter-free loop time.