Building a Drone with 2 Propellers: ESP32 PID Control and Servo Mixing

A drone with 2 propellers, commonly known in robotics as a bicopter, is a twin-rotor aerial platform that achieves pitch and yaw control by physically tilting its motors via servos rather than relying solely on differential motor speeds. While a standard quadcopter simply spins two diagonal motors faster to induce yaw torque, a 2-propeller build forces your microcontroller to manage a hybrid mixing matrix, outputting both high-torque ESC signals and high-frequency servo PWM simultaneously. This fundamentally changes your embedded circuit architecture: you can no longer rely on a single power rail or a single timer peripheral, and you must allocate dedicated high-current BECs (Battery Eliminator Circuits) to prevent logic brownouts. Builders frequently confuse this configuration with a coaxial helicopter (two stacked props on a single shaft) or a twin-engine fixed-wing, but the bicopter is unique because its servos act as the primary flight control surfaces in hover.

The Mixing Matrix: Math Behind the Tilt

In a quadcopter, the mixing matrix maps PID outputs (Roll, Pitch, Yaw, Throttle) directly to four motor speeds. In a drone with 2 propellers, Yaw and Pitch are decoupled from motor RPM and mapped instead to servo angles. Roll is achieved by differential motor thrust, while Yaw is achieved by differential servo tilt.

Let us look at a worked numeric example using standard RC PWM microsecond (µs) pulse widths, where 1500µs is the center/neutral position.

If you are writing your own flight controller firmware on an ESP32 or Arduino, you must implement this matrix in your main control loop, ensuring the servo outputs are constrained to your mechanical limits (usually ±30 degrees, or roughly 1100µs to 1900µs) to prevent the servos from stalling against the frame.

Where You Meet This in Practice

When transitioning from theory to the workbench, a drone with 2 propellers introduces three major embedded systems constraints that do not exist on standard multirotors:

1. Timer Peripheral Conflicts: Standard analog servos require a 50Hz PWM signal (20ms period). Brushless ESCs running DShot600 or OneShot125 require much higher frequencies (e.g., 4kHz to 375kHz). On the ESP32-S3, you cannot easily run both from the same LEDC (LED Control) timer group without resolution loss. You must route servos to the LEDC peripheral and ESCs to the MCPWM (Motor Control PWM) peripheral.
2. Power Distribution Asymmetry: A 12g servo can draw 600mA to 1.2A at stall. If your flight controller's onboard 5V regulator is rated for 1A, commanding an aggressive yaw maneuver will stall both servos, pull 2.4A, and instantly sag the logic rail.
3. I2C Bus Vulnerability: Because the servos are physically mounted near the center of mass (and thus near the IMU), the high-current PWM switching and motor EMI can induce noise on the I2C SDA/SCL lines, causing the MPU6050 or BNO085 to drop off the bus mid-flight.

For deeper integration details on handling these peripheral conflicts, refer to the Espressif MCPWM API documentation and the ArduPilot Bicopter configuration guide.

Real-World Scenario Walkthrough: The Brownout Yaw Spin

To understand why power rail isolation is non-negotiable, consider this real-world bench test that went wrong during a prototype build.

The Setup: An ESP32-S3 DevKit mounted on a carbon fiber bicopter frame. Two 2205 2300KV motors driven by 30A ESCs. Two MG90S metal-gear servos for tilting. The IMU was an I2C MPU6050. The builder powered the ESP32 and both servos from a single 5V 3A UBEC wired directly to the microcontroller's 5V and GND pins.

The Numbers: The UBEC was rated for 3A continuous. The MG90S servos have a stall current of roughly 1.1A each. The ESP32-S3 draws about 250mA. Total theoretical max draw: 2.45A. This appeared to be safely within the 3A UBEC limit.

The Outcome: During a bench test with props off, the builder commanded a rapid, full-stick yaw sweep. The ESP32 output the correct 1100µs and 1900µs pulses. The servos snapped to their mechanical limits and stalled. Instantly, the ESP32 rebooted, and the motors spun up to 100% throttle (the default failsafe state of the ESCs when PWM is lost).

What Went Wrong: The 3A UBEC rating was a peak marketing spec, not a transient response spec. When both servos hit mechanical stall simultaneously, they drew a combined transient inrush of nearly 3.5A. The UBEC's output voltage sagged from 5.0V down to 3.6V for roughly 40 milliseconds. The ESP32-S3's internal brownout detector (BOD) tripped at 3.3V, resetting the chip. Furthermore, the I2C pull-up resistors lost their voltage potential, causing the IMU to throw a bus error right before the reset. The fix was straightforward: run a dedicated 5V 2A BEC exclusively for the servos, and power the ESP32 and IMU from a separate, clean 5V rail, joining only the ground planes.

ESP32-S3 Hardware Mapping and Refresh Rates

If you are wiring this up today, use the following pin mapping and peripheral allocation to ensure your PID loop runs cleanly without timer interrupts colliding.

By keeping the 50Hz analog servo signals on the LEDC peripheral and the high-speed digital ESC signals on the MCPWM peripheral, you prevent the ESP32's internal timer mux from dropping PWM pulses during high CPU load states.

Frequently Asked Questions