uavformationsimuli
The problem
My PhD thesis question is multi-UAV formation control under an intermittent, stochastic communication channel — what a formation of drones can still do when the network between them isn’t reliable. That’s the research question, not what’s built yet, and I’d rather say so directly than let the thesis title imply more than the current artifact: what’s implemented and working today is a closed-loop trajectory-tracking controller for a single UAV, in simulation (CoppeliaSim, with ROS2 integration). Nothing has flown, and the multi-agent/formation/intermittent-communication parts of the thesis aren’t implemented yet.
What the current work actually demonstrates
Porting a controller from a published paper into a working simulation is not primarily a control-theory problem — it’s a bookkeeping problem, and most of it fails silently. The project’s own porting notes describe exactly where: state ordering has to match exactly across paper, Python reference implementation, and simulator; reference-trajectory derivatives have to be reproduced to whatever order the controller actually uses; frame conventions (body vs. world, sign of gravity, which way the body z-axis points) are the single most common source of a mathematically-correct controller that still doesn’t fly correctly; and the paper’s virtual control signal is not the same thing as a physical rotor thrust — an allocation layer has to bridge the two, correctly ordered and signed for the simulator’s own motor numbering.
The practical workflow was: reconstruct the paper’s equations and reference trajectory explicitly, build a Python reference implementation first and check it matches the paper qualitatively, only then port to CoppeliaSim’s discrete-time interface, add the saturation/wrapping/anti-windup guardrails a simulator needs that an ideal continuous-time model doesn’t, and validate by comparing position/attitude/thrust traces between the Python and CoppeliaSim runs.
Status, honestly
A single UAV tracks a time-varying reference trajectory in closed-loop simulation, with motor thrusts reacting in the expected coupled, nonlinear way and traces matching between the Python reference and the CoppeliaSim port — a real, working result, and the first-year foundation the formation-control and intermittent-communication work builds on next.