PID Drone Controller

I built a PID flight controller for a simulated quadcopter using CoppeliaSim as the plant and MATLAB for control logic and analysis. The goal was to fly commanded paths and then use plots — trajectories plus step responses — to see how well the gains held position, velocity, and angular rate.

CoppeliaSim ran the drone model (motors, body dynamics, sensors). MATLAB closed the loop: read state, run PID, command motor speeds / setpoints, and log data for plotting.

Signals in the loop included: - Position (x, y, z) - Linear velocity - Angular velocity / yaw rate - Motor speed commands

I flew simple missions in sim — climb, hold altitude, orbit, and planar paths — then exported the logs into MATLAB figures.

Separate (or cascaded) PID terms handled altitude, vertical velocity, and yaw rate, with gains tuned until the actual curves met the desired setpoints without wild overshoot.

The response plots compare actual vs desired for: - z position (pz) - z velocity (vz) - angular velocity about z (ωz)

Rise time, overshoot, and steady-state error were the usual checks while tweaking P, I, and D.

Three views of the flown path: - 3D orbit — takeoff, then a circular hold - XYZ path — full spatial maneuver - XZ plane — side view where corner overshoot shows the controller catching new setpoints

The sim produced stable flights and clean tracking plots: altitude and velocity settled on the commanded lines, and the orbit / XZ paths matched the intended geometry closely enough to trust the gain set for classroom / lab use.

Simulation makes it safe to push gains hard, but you still need the plots — a path that “looks fine” in the 3D view can hide overshoot or slow settle that only shows up in the time-series.