Devlog #5
I moved from fixed-duration legs to distance-based dynamic timing, replacing the flat 5-second-per-leg assumption from Devlog #4 with per-leg durations computed from waypoint spacing and a target cruise speed.

I added a speed constant (2 m/s) and used it to compute t_segment as an array instead of a scalar. Each leg’s duration is now distance / speed between its start and end waypoints, so longer legs take proportionally longer instead of every leg getting the same fixed window.
I also updated the interior-waypoint velocity estimate to divide by the sum of the adjacent leg durations (t_segment(i-1) + t_segment(i)) instead of 2 * t_segment, since that shortcut only made sense when every leg was the same length.
I dropped mass to 0.5 kg to better match a real small-quadrotor class, and lowered Kp/Kd as a starting point since neither the old gains nor the old fixed timing apply anymore.

---

Bugs
I didn’t hit any major bugs during this section.

---

Where it stands now
Leg duration now reflects actual waypoint spacing instead of an arbitrary constant, which should reduce the unnatural sameness of a drone crawling across a short hop and sprinting across a long one in the same 5 seconds.

---

Next up
Re-tune Kp/Kd/Kr/Kw against the new mass and dynamic timing before drawing conclusions from the plots. I will also look into MATLAB’s UAV Toolbox with a built-in quadrotor animation/scene viewer that can consume my state trajectory directly.