Devlog #1

I’ve built a drone sim before, such as a Python project with Plotly animations, PD control, motor lag, drag, the works. It looked good, but it had a problem where the “drone” was really just a point that could apply force in any direction, instantly. Real quadrotors can’t do that, because they only push one way (straight up from their own frame) and have to physically rotate to redirect that push.

I’m now pushing myself to build a research-style quadrotor simulator in MATLAB.

The plan:
Start with a 9-state model: position, velocity, and orientation (roll/pitch/yaw).
Verify a hover with a basic PID controller first.
Later, move to trajectory planning using differential flatness (generating smooth polynomial paths and computing the forces needed to fly them)
Eventually stress-test trajectories by speeding them up / slowing them down and watching what that does to the required forces.

In this devlog, I covered:
Milestone 1: 1D hover
Before touching 3D, I built the simplest possible version, a single point that can only move up and down, controlled by:
thrust = massgravity + Kperror - Kd*velocity

Using MATLAB’s ode45 to integrate [z; vz] forward in time. I learned what an ODE solver does.

Milestone 2: 3D
Next step: extend to a full 3D position [x,y,z,vx,vy,vz], but still letting the controller output force in any direction. This is the same “free vector” simplification my old Python sim used, kept on purpose this time as an isolated stepping stone. The goal was to prove the PID math generalizes to 3D before adding the complexity of real attitude dynamics on top.

In my first test, the drone was pointed at a single fixed target. It gave a perfectly straight line, and it took me a second to realize that wasn’t a bug: since x, y, and z all use identical gains and start at rest, they move in lockstep, always in the same ratio to the target.

Milestone 3: chasing waypoints
I added a list of waypoints instead of one static target, with the controller switching to the next point once it gets within a 0.5 m of the current one. This needed a persistent variable inside the dynamics function to track which waypoint index it’s on, since ode45 calls that function many times per step and nothing about waypoint progress lives in the physical state vector itself.

This gave path that actually bends at each waypoint instead of a straight shot. The corners are sharp however, instead of being smooth.

Next up
I’m going to be adding adding real orientation states (φ, θ, ψ) and constraining thrust to act along a single body axis, the way an actual quadrotor works. That’s the point where this stops being a point-mass simulation and starts being a quadrotor simulation.