ESP32 Bicycle Robot Dynamics: PID Tuning and Sensor Fusion Theory

A bicycle robot is a two-wheeled autonomous platform with wheels aligned in a single longitudinal line that maintains dynamic upright balance by actively steering the front wheel or shifting a reaction mass based on IMU feedback. Unlike simpler balancing platforms, this inline configuration demands continuous, high-speed computational correction across multiple axes to prevent lateral collapse.

The Core Physics: Inline vs. Side-by-Side Balance

The most common mistake hobbyists make is confusing a true bicycle robot with a differential-drive self-balancing robot (like a Segway). A differential-drive robot features two wheels mounted side-by-side on a single axle. It only needs to correct pitch (falling forward or backward) by varying the speed of the left and right motors.

A bicycle robot, with its wheels mounted front-and-back, operates as a dual-axis inverted pendulum. Correcting pitch (fore/aft balance) requires accelerating or decelerating the main drive wheel. However, correcting roll (falling left or right) cannot be solved by wheel speed alone. It requires active steering of the front wheel to drive the contact patch back under the center of gravity, or the use of a high-RPM reaction wheel to generate a counter-torque.

Sensor Fusion and the PID Control Loop

To keep the chassis upright, the microcontroller must know its exact angle relative to gravity. We use an Inertial Measurement Unit (IMU) like the MPU6050, which combines a 3-axis accelerometer and a 3-axis gyroscope. The accelerometer is accurate at rest but noisy under vibration; the gyroscope is precise during motion but suffers from integration drift. Sensor fusion (typically via a Madgwick or Mahony filter) blends these into a stable pitch/roll estimate.

The Proportional-Integral-Derivative (PID) controller takes this fused angle and calculates the motor output. Here is a worked numeric example of a single PID loop iteration for the pitch controller:

• Target Angle (Setpoint): 0.0° (perfectly vertical)
• Measured Angle (Process Variable): 4.2° (leaning forward)
• Error (e): 0.0 - 4.2 = -4.2°
• Previous Error: -3.8°
• Loop Time (dt): 0.01 seconds (100Hz loop)

Assuming tuned constants of Kp = 35.0, Ki = 12.5, and Kd = 1.8:

1. P-Term (Proportional): Reacts to current error. 35.0 * -4.2 = -147.0
2. I-Term (Integral): Accumulates past error to eliminate steady-state offset. Assuming previous I-sum was -10.5, new I-term is 12.5 * (-10.5 + (-4.2 * 0.01)) = -132.5
3. D-Term (Derivative): Reacts to the rate of change to dampen oscillation. 1.8 * ((-4.2 - (-3.8)) / 0.01) = -72.0

Total PID Output: -147.0 + (-132.5) + (-72.0) = -351.5. This negative value commands the drive motor to spin backward, driving the wheels under the falling chassis to catch the balance.

Where You Meet This in Practice

You will encounter inline two-wheeled dynamics in several modern applications beyond hobbyist workbenches. In warehouse logistics, narrow-aisle automated guided vehicles (AGVs) use bicycle-style steering to navigate tight racks. In cinematography, 2-axis and 3-axis motorized camera gimbals use the exact same IMU fusion and PID math to keep a lens level while the operator walks. For the DIY engineer, building a bicycle robot with an ESP32 is the ultimate stress-test of your ability to manage I2C bus timing, interrupt service routines (ISRs), and power rail isolation.

Real-World Scenario Walkthrough: Tuning the Pitch Controller

Theory is clean; the bench is messy. Here is a real-world scenario demonstrating how power dynamics destroy control theory if ignored.

The Setup: An ESP32 DevKit v1 reading an MPU6050 via I2C at 400kHz. The steering mechanism is a 25kg-cm digital servo (MG996R) powered directly from a 6V UBEC tied to the same ground plane as the ESP32. The PID loop runs at 10ms intervals.

The Numbers: The robot is held at a 5-degree lean. The P-term is aggressively tuned to Kp = 250 to ensure a snappy recovery. The steering servo is commanded to turn 15 degrees to catch the roll.

The Outcome: As the servo engages, it draws a 2.2A peak current spike. The robot violently oscillates, the ESP32 throws an I2C timeout error, and the chassis crashes to the bench.

What Went Wrong: The 2.2A servo spike caused ground bounce. Because the servo and the MPU6050 shared a thin breadboard ground wire, the localized ground potential at the IMU spiked by nearly 0.4V for a few microseconds. The MPU6050 misinterpreted this voltage shift on the SDA line as a corrupted data packet, returning a NaN (Not a Number) or a wild 180-degree spike for the pitch angle. The D-term in the PID controller multiplied this massive, fake rate-of-change, sending a 100% PWM spike to the drive motor.

Hardware Selection and Wiring Topology

Selecting the right components dictates whether your control loop can physically execute fast enough. The ESP32's dual-core architecture allows you to run the Wi-Fi stack on Core 0 and the 100Hz PID/IMU loop on Core 1, preventing network interrupts from stalling the balance algorithm.

For deeper reading on inverted pendulum state-space modeling and PID limitations, refer to the University of Michigan Control Tutorials and the official TDK InvenSense MPU-6000 Register Map for configuring the digital low-pass filter (DLPF) registers.

FAQ: Troubleshooting the Wobble