Devlog #4
I moved from simple point-to-point waypoint chasing to smooth polynomial trajectory generation between waypoints, replacing the threshold-based switching from Devlog #3 with time-based tracking of a continuously moving target.

New machinery
I built cubicTrajectory.m, which solves a 4x4 system of equations for the coefficients of a cubic polynomial connecting a start point to an end point over a fixed duration, with velocity constrained to zero at both ends of each leg.
I also built evalCubic.m, which evaluates that polynomial’s position and velocity at any given time.
I tested both standalone before touching the main dynamics. I stored all the coefficients in one array, coeffs_all, indexed by [coefficient, axis, leg], and built a loop that chains legs together so each leg starts exactly where the previous one ended.

Bugs

1. The very first version of the leg/local-time lookup accidentally dropped global time from the local-time calculation entirely, leaving the “current time within this leg” frozen at a constant for the whole leg instead of counting up. This meant the drone’s target wasn’t moving during a leg at all, it only jumped once per leg, which produced a single sharp overshoot spike instead of a tracked path.
2. The simulation’s total time span hadn’t been updated to match the total trajectory duration, cutting the run short by a full leg.

Where it stands now
With both fixed, the drone tracks a moving position and velocity target through all four waypoints instead of chasing a static point. Spin rate and attitude plots show a clean repeating pattern, a spike at each leg transition that damps out before the next one, rather than instability or runaway spiraling.

Next up
Because every leg currently forces velocity to zero at both ends, the drone still fully stops at every intermediate waypoint before accelerating into the next leg, which is what’s producing the repeating spikes rather than a truly smooth flight. Next is allowing interior waypoints to have nonzero passthrough velocity (estimated from neighboring waypoints), plus adding acceleration feedforward into the force calculation so the controller anticipates the trajectory instead of only reacting to error. After that, the plan is still to move toward true minimum-snap trajectories.