Arduino as Flight Controller: DIY Quadcopter PID Build & Debugging

Can you use an Arduino as a flight controller? Yes, but with strict expectations. An ATmega328P-based board lacks the processing headroom and hardware timers to run modern sensor-fusion algorithms (like ArduPilot or Betaflight) or handle high-speed DShot ESC protocols. However, building a bare-metal PID stabilization loop on an Arduino is the ultimate bench project for understanding gyroscopic feedback, I2C sensor polling, and motor mixing. You will not be doing FPV acrobatics with this, but you will learn exactly how a quadcopter stays level.

This guide targets the Arduino Nano V3.0 (ATmega328P, 16MHz) paired with an MPU-6050 6-axis IMU and standard 50Hz PWM ESCs. We will cover the exact hardware mapping, provide a fully compilable C++ PID control loop, and break down the specific I2C and motor failures that plague first-time drone builders.

Project Spec Sheet & Parts List

Do not substitute the IMU. The MPU-6050 has a built-in Digital Motion Processor (DMP) and predictable noise floors that make bare-metal math manageable. Cheaper alternatives like the MPU-9250 clones often have misaligned magnetometers that will ruin your yaw axis.

Hardware Pin Mapping & Wiring

The Arduino Nano uses Timer1 and Timer2 for its standard PWM outputs. The Servo.h library hijacks Timer1, which disables analogWrite() on pins 9 and 10, but perfectly generates the 50Hz pulse train required by standard ESCs. We map the motors in a standard 'Quad X' configuration.

Power Note: Do not power the Arduino Nano via the USB port while flying. Use the 5V BEC (Battery Eliminator Circuit) from one of your ESCs wired to the Nano's 5V pin, or use a dedicated 5V step-down buck converter rated for at least 2A.

The PID Control Loop (Compilable Code)

This code implements a basic rate-mode stabilization loop. It reads the raw gyroscope data, calculates the error against a level setpoint (0°), applies a discrete PID algorithm, and mixes the outputs to the four ESCs. It includes explicit I2C error handling to prevent the drone from arming if the sensor bus hangs.

#include <Wire.h>
#include <Servo.h>

// --- PIN DEFINITIONS ---
const uint8_t PIN_MOTOR_FR = 3;  // Front Right
const uint8_t PIN_MOTOR_RR = 9;  // Rear Right
const uint8_t PIN_MOTOR_RL = 10; // Rear Left
const uint8_t PIN_MOTOR_FL = 11; // Front Left

// --- GLOBAL VARIABLES ---
Servo escFR, escRR, escRL, escFL;
float gyroX, gyroY, gyroZ;
float errorX, errorY, lastErrorX, lastErrorY;
float integralX = 0, integralY = 0;
float pidOutputX, pidOutputY;

// PID Tuning Constants (Requires bench tuning)
float Kp = 1.2, Ki = 0.02, Kd = 15.0; 
int baseThrottle = 1200; // Baseline hover PWM (µs)

unsigned long lastTime = 0;
float dt = 0.004; // Target 4ms loop time (250Hz)

void setup() {
  Serial.begin(115200);
  Wire.begin();
  Wire.setClock(400000); // Fast I2C mode
  
  // Initialize MPU6050
  Wire.beginTransmission(0x68);
  Wire.write(0x6B); // PWR_MGMT_1 register
  Wire.write(0);    // Wake up
  uint8_t i2cStatus = Wire.endTransmission();
  
  // ERROR HANDLING: Check I2C bus status
  if (i2cStatus != 0) {
    Serial.print("I2C Error: NACK on address (Code ");
    Serial.print(i2cStatus);
    Serial.println("). Check SDA/SCL wiring.");
    while(1); // Halt execution to prevent flyaway
  }

  // Configure Gyro (250 deg/s full scale range)
  Wire.beginTransmission(0x68);
  Wire.write(0x1B); // GYRO_CONFIG
  Wire.write(0x00); // FS_SEL = 0 (250 deg/s)
  Wire.endTransmission();

  // Configure DLPF (Digital Low Pass Filter) to 44Hz bandwidth
  Wire.beginTransmission(0x68);
  Wire.write(0x1A); // CONFIG register
  Wire.write(0x03); // DLPF_CFG = 3
  Wire.endTransmission();

  // Attach ESCs (1000 to 2000 microsecond limits)
  escFR.attach(PIN_MOTOR_FR, 1000, 2000);
  escRR.attach(PIN_MOTOR_RR, 1000, 2000);
  escRL.attach(PIN_MOTOR_RL, 1000, 2000);
  escFL.attach(PIN_MOTOR_FL, 1000, 2000);
  
  // Send minimum throttle to arm ESCs
  escFR.writeMicroseconds(1000);
  escRR.writeMicroseconds(1000);
  escRL.writeMicroseconds(1000);
  escFL.writeMicroseconds(1000);
  
  Serial.println("System Armed. Waiting 3 seconds for ESC initialization...");
  delay(3000); 
  lastTime = micros();
}

void loop() {
  unsigned long currentTime = micros();
  dt = (currentTime - lastTime) / 1000000.0; // Calculate actual delta time
  
  if (dt >= 0.004) { // Enforce ~250Hz loop rate
    lastTime = currentTime;
    
    // Read Gyro Data (Registers 0x43 to 0x48)
    Wire.beginTransmission(0x68);
    Wire.write(0x43);
    Wire.endTransmission(false);
    Wire.requestFrom(0x68, 6, true);
    
    if(Wire.available() == 6) {
      int16_t rawX = Wire.read() << 8 | Wire.read();
      int16_t rawY = Wire.read() << 8 | Wire.read();
      int16_t rawZ = Wire.read() << 8 | Wire.read();
      
      // Convert to deg/s (131 LSB = 1 deg/s for 250dps range)
      gyroX = rawX / 131.0;
      gyroY = rawY / 131.0;
      gyroZ = rawZ / 131.0;
    }

    // Setpoint is 0 (level hover)
    errorX = 0 - gyroX; // Roll error
    errorY = 0 - gyroY; // Pitch error

    // PID Calculations
    integralX += errorX * dt;
    integralY += errorY * dt;
    
    // Anti-windup clamp for integral term
    integralX = constrain(integralX, -400, 400);
    integralY = constrain(integralY, -400, 400);

    float derivativeX = (errorX - lastErrorX) / dt;
    float derivativeY = (errorY - lastErrorY) / dt;

    pidOutputX = (Kp * errorX) + (Ki * integralX) + (Kd * derivativeX);
    pidOutputY = (Kp * errorY) + (Ki * integralY) + (Kd * derivativeY);
    
    lastErrorX = errorX;
    lastErrorY = errorY;

    // Motor Mixing (Quad X configuration)
    int mFR = baseThrottle - pidOutputX - pidOutputY + gyroZ;
    int mRR = baseThrottle - pidOutputX + pidOutputY - gyroZ;
    int mRL = baseThrottle + pidOutputX + pidOutputY + gyroZ;
    int mFL = baseThrottle + pidOutputX - pidOutputY - gyroZ;

    // Constrain and write to ESCs
    escFR.writeMicroseconds(constrain(mFR, 1000, 2000));
    escRR.writeMicroseconds(constrain(mRR, 1000, 2000));
    escRL.writeMicroseconds(constrain(mRL, 1000, 2000));
    escFL.writeMicroseconds(constrain(mFL, 1000, 2000));
  }
}

Debugging: First Three Things to Check When It Fails

When a DIY flight controller fails to stabilize or refuses to arm, the issue is almost always physical wiring or ESC protocol mismatch, not the math. If your serial monitor outputs I2C Error: NACK on address (Code 2), or your motors just twitch and stop, check these three things in order.

1. I2C Bus Pull-Up Resistors (The Code 2 NACK Error): The exact error string I2C Error: NACK on address (Code 2) means the Arduino sent the MPU-6050 address (0x68) but received no acknowledgment. The ATmega328P internal pull-ups are too weak for the capacitance of drone wiring. Verify your GY-521 breakout board has 4.7kΩ physical pull-up resistors on the SDA and SCL lines. If it doesn't, solder two 4.7kΩ resistors between the SDA/SCL lines and the 5V rail. Furthermore, ensure your SDA/SCL jumper wires are under 10cm long; longer wires act as antennas for ESC switching noise, causing intermittent I2C hangs.
2. ESC Throttle Range Calibration: If the motors beep continuously and refuse to spin, the ESCs do not recognize the Arduino's 1000µs low-throttle signal. ESCs have a safety lockout if the minimum throttle is too high. You must calibrate them: Upload a sketch that outputs exactly 2000µs to all motors. Power on the ESCs (they will beep a high-low tone). Then change the sketch to output 1000µs and power them on again (they will beep a confirmation tone). Only after this will they accept the arming sequence in the flight code.
3. Gyro Axis Orientation (Software vs. Physical): If the drone flips violently on takeoff, your PID loop is fighting the wrong axis. The MPU-6050 silicon die orientation on cheap GY-521 clones varies. If you tilt the drone forward (pitch), but the serial monitor shows a spike in the X-axis (roll) data, your physical board is rotated 90° relative to your software mapping. Either rotate the physical IMU on the frame so the X/Y silkscreen matches the drone's forward/right vectors, or swap the rawX and rawY variable assignments in the C++ code.

Extending and Simplifying the Build

How to Simplify: If bare-metal C++ PID math is overwhelming and you just want to fly, abandon the custom code and flash the legacy MultiWii 2.4 firmware onto the Arduino Nano. MultiWii was specifically designed for the ATmega328P and MPU-6050 combination. You can configure it using the MultiWiiConf GUI via a serial Bluetooth (HC-06) module, bypassing the need to write your own sensor fusion or motor mixing logic.

How to Extend: To make this a functional RC aircraft, you need a receiver. The Nano lacks the UART bandwidth and processing speed to handle SBUS or CRSF protocols while maintaining a 250Hz PID loop. Extend the build by adding an NRF24L01+ PA/LNA module (wired via SPI to pins 13, 12, 11, and a CE/CSN on pins 7 and 8) to receive custom 2.4GHz telemetry from a second Arduino acting as a ground transmitter. Alternatively, upgrade the brain to an ESP32-WROOM-32 or an STM32F405 (like the SpeedyBee F405 V4), which natively supports hardware UARTs for SBUS receivers and DMA-driven DShot600 ESC protocols.

Frequently Asked Questions

Can an Arduino Uno be used as a drone flight controller?

Yes, the Arduino Uno shares the exact same ATmega328P microcontroller as the Nano, meaning the code and I2C logic are identical. However, the Uno's physical footprint (68.6 x 53.4mm) and heavy DC barrel jack make it impractical for anything larger than a micro-drone. The weight penalty will severely reduce your 3S LiPo flight time. If you only have an Uno, use it for bench-testing the PID loop and sensor fusion before migrating the chip or code to a Nano or Pro Mini for the actual airframe.

Why is my Arduino flight controller drifting during hover?

Drift in a bare-metal gyro-only setup is caused by gyro bias and temperature variance. The MPU-6050 gyroscope has a zero-rate offset that changes as the silicon heats up. Because the code above uses 'Rate Mode' (stabilizing angular velocity, not absolute angle), any tiny DC offset in the gyro reading is integrated over time by the PID loop, causing the drone to slowly drift. Commercial controllers like Betaflight solve this by fusing the gyroscope with an accelerometer (Complementary or Kalman filter) to establish an absolute level horizon. To fix drift on the Arduino, you must implement an accelerometer reading routine and apply a complementary filter to calculate absolute roll/pitch angles.

Is Arduino as flight controller better than Betaflight for FPV?

No. An Arduino running a bare-metal loop is strictly an educational tool. Betaflight runs on 32-bit ARM Cortex-M4/M7 processors (STM32 F4/F7/H7) clocked at 168MHz to 480MHz, utilizing hardware DMA to send DShot1200 telemetry to ESCs at 32kHz PID loop rates. An Arduino Nano runs at 16MHz, uses 50Hz analog PWM, and lacks the memory to run complex Kalman filters or GPS waypoint navigation. For FPV freestyle or racing, always use a dedicated STM32-based flight controller; for learning control theory and embedded C++, the Arduino is unmatched.