A single-file browser-based simulation for teaching manual control, PID control, feedforward compensation, and practical tuning of a simplified drone height-control system.
The app runs entirely in the browser as one HTML file and is suitable for hosting with GitHub Pages. The current public version is available at:
https://bobernhardsson.github.io/dronesimulation/
The simulation focuses on vertical motion only. The user can either:
- fly the drone manually by adjusting thrust, or
- tune a PID controller with feedforward to track changing height references.
The interface contains:
- a drone visualization,
- live plots of:
- height and reference,
- control signal,
- real-time controller sliders,
- score calculation based on staying within an allowed tracking corridor.
The drone is modeled as:
where:
x(t)= heightu(t)= thrust commandg = 9.81 m/s²k(t)= thrust effectivenessm(t)= drone mass
To make the control problem realistic, the plant changes during flight:
The gain k(t) slowly decreases over time.
This means the same control signal gives less lift later in the simulation.
At 45 seconds, the mass drops by 30%.
This creates a sudden plant change and tests controller robustness.
The user directly controls thrust.
This demonstrates:
- difficulty of manual tracking,
- need for hover thrust,
- effect of changing plant parameters.
Keyboard control is supported.
The controller is:
with
where:
r= reference heighty= measured heightb= proportional setpoint weightK= controller gainTi= integral timeTd= derivative timeŷdot= low-pass filtered vertical velocityu_ff= feedforward hover bias
The proportional term uses:
instead of:
This reduces overshoot after step changes.
Typical values:
b = 1.0→ normal proportional actionb = 0.5→ softer setpoint responseb = 0.0→ no proportional response to reference jumps
This is standard setpoint weighting.
The feedforward term supplies most of the thrust needed to hover:
Then PID only corrects:
- transients
- battery fade
- cargo drop
- modeling mismatch
The derivative part is based on measured motion, not reference error.
This avoids derivative kick when the reference changes suddenly.
A low-pass filter is used:
This gives smoother control signals.
The integral term uses conditional integration anti-windup.
If actuator saturation occurs:
- the integrator is frozen when it would worsen saturation
- it is allowed to move when it helps recover
This prevents runaway integral buildup.
The player can tune:
KTiTdbFF
Typical starting values:
K = 1Ti = 1Td = 1b = 1
Built-in references include:
- Steps
- Sine
- Challenge
The default game mode uses multiple step changes.
The score no longer penalizes control effort.
Instead, the drone must stay inside a tracking corridor around the reference.
To avoid unfair penalties:
- when reference increases, the lower boundary waits 1.5 seconds
- when reference decreases, the upper boundary waits 1.5 seconds
This rewards practical tracking rather than impossible instant jumps.
- Stay inside corridor → high score
- Leave corridor → penalty accumulates
- Fast but wild control gives no direct penalty
For this drone system (approximately a double integrator), some overshoot after step changes is natural when integral action is used.
This makes the simulator useful for discussing:
- transient design
- damping
- setpoint weighting
- tradeoff between speed and overshoot
Useful for teaching:
- manual vs automatic control
- PID tuning
- feedforward vs feedback
- anti-windup
- robustness
- setpoint weighting (
b) - actuator saturation
- double-integrator dynamics
Suggested exercise:
- Try manual mode
- Tune hover feedforward
- Add proportional action
- Add derivative damping
- Add integral correction
- Tune
bto reduce overshoot - Observe battery fade and cargo drop
Open index.html in any modern browser.
Host by placing index.html in the repository root and enabling GitHub Pages.
- wind disturbances
- measurement noise
- sensor delay
- leaderboard
- saved best scores
- auto-tuning challenge
- 2D drone motion
- Kalman filter mode