[Editor’s note] Model Predictive Control (MPC) can handle dynamics, control constraints and safety boundaries simultaneously during flight, but its computational cost has long limited its use in large-scale training and onboard deployment. The research team behind WarpMPC solves thousands of MPC problems in batch on a single GPU, reaching up to about 250,000 SQP iterations per second, and uses roughly four minutes of data generation and training to produce a neural network controller deployable on a micro quadrotor. What is genuinely worth watching is not that the drone flew stably, but that MPC is beginning to look like a “control data factory.”
Figure 1: Sparse KKT matrix structures for cart-pole, quadrotor and humanoid problems in WarpMPC.
Key Takeaways
- WarpMPC runs many MPC problems in batch on one GPU, reaching ~8,000 to 250,000 SQP iterations per second.
- End-to-end throughput improves roughly 3× to 25× over baselines such as OSQP, MPAX, TurboMPC and NVIDIA cuDSS.
- In the drone experiment, ~20 million state–action pairs were generated in about two minutes, then a small 3×32 network trained in about 1.7 minutes.
- The deployed artifact is a lightweight learned policy; the heavy GPU work is offline data generation and training, not onboard flight.
- It is not a complete autonomous flight system — it validates dynamics control and attitude stabilization, not perception, mapping or obstacle avoidance.
MPC Is Powerful, but “Mass-Producing Control Data” Is Too Slow
The advantages of MPC are not hard to understand.
Rather than mapping the current observation directly to an action, it uses a dynamics model to predict future states over a horizon and, subject to thrust, attitude, velocity and safety-boundary constraints, searches for an optimal set of control inputs.
For drones this mechanism is especially valuable. Aircraft dynamics change quickly, actuators have hard limits, and a control mistake can mean a crash. Compared with relying entirely on a black-box neural network, MPC naturally folds physical models and safety constraints into the control process.
The problem is that traditional MPC is usually solved one problem at a time on the CPU.
Running a single MPC problem online on a single drone is acceptable, but if researchers want to generate tens of millions of “state–optimal action” pairs to train imitation-learning policies, reinforcement-learning policies or neural network approximation controllers, the computation can take days or even weeks. That is exactly the step WarpMPC targets: it does not simply move a single MPC solve onto the GPU, but redesigns the computation for large batches of control problems with the same sparse structure.
In other words, the core goal is not to let a drone fly next to a GPU server, but to let the GPU “produce” large numbers of high-quality control trajectories at once, then compress those trajectories into a small neural network that can run on an onboard chip.
How It Moves MPC onto the GPU
WarpMPC is built on Sequential Quadratic Programming (SQP) and an ADMM solver framework similar to OSQP. The team observed that although many MPC problems have different input states, the nonzero positions of their internal matrices usually stay the same.
As long as the sparsity structure does not change, there is no need to re-analyze the matrix structure on every computation.
The team therefore split the pipeline into two stages:
First, an offline stage analyzes the computational graph and sparsity structure and generates fixed factorization and back-substitution operations. In the online batch-solving stage, the GPU only needs to run those already-unrolled computational steps for different numerical values.
The key technique is unrolling the LDLᵗ factorization of the sparse KKT matrix, and partitioning matrix columns by symbolic operation count to reduce load imbalance between GPU threads. The triangular back-substitution is then layered according to variable dependencies, so mutually independent operations can execute in parallel.
Figure 2: Column segmentation based on symbolic operation count reduces fill-in and load waste in GPU batching.
Figure 3: Sparse triangular back-substitution scheduled by dependency level, solving multiple variables in parallel.
The limitation of this method is also clear: WarpMPC is best suited to problems with large batch size and a fixed sparsity pattern. If the problem structure changes frequently, or only one very small control problem is solved, its GPU parallel advantage weakens markedly.
Up to 250,000 Iterations per Second, 3× to 25× Overall Speedup
The paper tests three classes of nonlinear systems — cart-pole, quadrotor and humanoid robot — and compares against OSQP, MPAX, TurboMPC and NVIDIA cuDSS.
In large-batch scenarios, WarpMPC achieves about 8,000 to 250,000 SQP iterations per second. Depending on the model, prediction horizon and batch size, end-to-end throughput improves by roughly 3× to 25× over existing schemes.
Figure 4: WarpMPC versus GPU and CPU baselines on matrix factorization and back-substitution throughput.
Figure 5: Quadratic program solving and sensitivity computation performance at different batch sizes.
One easy misreading needs to be avoided here.
The paper used high-performance GPUs, including the NVIDIA H100, for the large-scale benchmarks. So “250,000 iterations per second” describes batch compute capability on a server GPU; it does not mean that a drone’s onboard flight controller needs an H100, nor that a drone in flight runs 250,000 MPC solves per second.
The value of WarpMPC lies mainly in offline data generation, controller training, parameter search and simulation evaluation. What is actually deployed on the drone is the lightweight policy trained from that data.
20 Million Control Data Points, Generated in Two Minutes
In the drone experiment, the team chose the Crazyflie nano quadrotor.
They first used WarpMPC to generate about 20 million state–action pairs in batch, taking about two minutes. They then trained a small network with three hidden layers of 32 neurons each, with a training time of about 1.7 minutes.
In other words, from generating MPC expert data to finishing neural network policy training, the actual compute stage takes under four minutes in total. The paper also reports roughly 11 minutes of first-compilation overhead, but that part can be cached and does not need to be repeated for every training run.
Figure 6: Overall speedup across different nonlinear control tasks.
The trained neural network, approximating the MPC controller, was deployed on Crazyflie hardware and outputs thrust commands for the four motors directly. The paper shows several real flight tests in which the aircraft maintains stable control while respecting state and input constraints.
Figure 7: Real flight experiments of the neural-network MPC approximation controller on a Crazyflie nano quadrotor.
The Real Change Is How Controllers Are Manufactured
The most notable aspect of this work is not that a Crazyflie flew stably again.
Quadrotors of similar size have long been able to run traditional PID, geometric controllers, MPC or learned control policies. What WarpMPC changes is turning the GPU into a high-speed control data production line.
Previously, training a policy that approximates MPC often forced a choice between two options:
One was to reduce training data and state coverage, and accept the risk that the policy fails under edge conditions; the other was to spend a great deal of CPU time generating enough expert trajectories offline.
WarpMPC tries to lower the cost of the second option. Researchers can solve MPC in batch over a larger initial state space, disturbance range and constraint set to obtain denser expert data, then use imitation learning or policy distillation to compress the complex optimization process into a low-latency network.
For end-to-end flight control, reinforcement learning, flight world models and vision-language-action models, this capability matters equally. Learning systems need not only more data but also high-quality action labels that embody dynamics constraints and safety boundaries. MPC can play exactly the role of a “physics teacher.”
This Is Not a Complete Autonomous Drone Flight System
Despite the headline and the numbers, WarpMPC cannot yet be described as an end-to-end autonomous drone flight solution.
The paper mainly validates dynamics control and attitude stabilization; it does not cover visual perception, object recognition, mapping of unknown environments, dynamic obstacle avoidance, semantic navigation or multi-drone coordination. The Crazyflie experiments are also not high-speed autonomous flight in complex outdoor environments.
Its speed advantage also depends on several preconditions:
First, the batch must be large enough. The GPU needs to process many problems simultaneously to realize its throughput advantage.
Second, problems must share a fixed sparse structure. If the control model or constraint structure keeps changing, the offline unrolled computational graph must be regenerated.
Third, the code is still at an early stage. As of this review, the official GitHub repository has published core modules, examples and installation instructions, but commit records are few, no stable release has been issued, and some baseline implementations from the paper have not been merged into the main repository. Its cross-hardware reproducibility still needs verification by more research teams.
Drone Control May Form a New Three-Layer Architecture
From an industry perspective, WarpMPC demonstrates a technical route worth tracking:
On servers or simulation clusters, use the GPU to run high-accuracy MPC in batch, covering different payloads, wind disturbances, faults and actuator constraints; then distill the generated data into a small policy suited to onboard compute; and during real flight, use a safety monitor or low-frequency MPC to constrain and correct the learned policy.
This could form a new three-layer structure:
The top layer is a GPU control data factory, the middle layer is a lightweight learned policy, and the bottom layer is a deterministic safety flight controller.
For logistics drones, inspection drones and industrial work drones, the commercial value of this architecture is the chance to combine the interpretability of model-based control with the low latency of neural network inference.
When a drone’s platform model, payload configuration or motor parameters change, a company can regenerate control data in batch rather than relying entirely on manual tuning and real-flight collection. For manufacturers and operators with many different airframes, this may be more valuable than a one-off flight performance gain.
However, what decides whether WarpMPC truly enters engineering practice is not the peak throughput in the paper, but whether it can later demonstrate stability under complex aerodynamic models, actuator faults, strong wind disturbances, GNSS-denied environments and real closed-loop perception.
For now, it looks more like promising GPU control infrastructure than a finished, productized autonomous flight brain.
If you have any questions about this topic, feel free to contact us at [email protected]
FAQ
Q: Does WarpMPC mean I need an H100 on my drone?
No. The H100-class GPU is used for offline batch computation and benchmarking. What runs onboard the drone is a small neural network policy distilled from the generated data.
Q: Can WarpMPC replace classical MPC on the flight controller?
It is better understood as an accelerator for generating and training controllers. Online flight can still use a lightweight policy plus a safety monitor or low-frequency MPC for correction.
Q: When does the GPU advantage disappear?
When the batch size is small, or when the problem’s sparsity structure changes frequently so the offline unrolled graph must be regenerated, the GPU parallelism advantage weakens significantly.
Q: What did the drone experiment actually prove?
It proved that roughly 20 million expert state–action pairs plus a small 3×32 network can be produced in under four minutes of compute, and that the resulting policy can fly a Crazyflie stably while respecting constraints. It did not prove end-to-end autonomy.
Q: What is the commercial takeaway for drone makers?
For fleets with many airframe variants, being able to regenerate control data in batch when platform, payload or motor parameters change could replace much of the slow manual tuning and real-flight collection — the kind of efficiency Aomway follows closely in UAV hardware.
Have questions about this article? Feel free to contact us at [email protected] — we’re happy to help!
