The default Gazebo motor model is a stock LiftDragPlugin that produces snappy, idealized response curves — instant thrust on PWM command, no spin-up dynamics, no efficiency falloff at high RPM. For an outdoor scale drone with large rotors, that’s a fine approximation. For our small indoor quad with 1404 brushed motors and 3-inch props, it’s wrong enough that sim-to-real transfer would degrade noticeably.
Our custom plugin replaces it with a more honest model:
- Spin-up time constant — motors don’t reach commanded RPM instantly; there’s a ~50 ms first-order response.
- Propeller efficiency curve — thrust is not linear in RPM at the extremes; we model the rolloff above ~80% throttle.
- Battery sag — sustained high current pulls voltage down, which reduces available thrust; we model a linear sag for now (nonlinear is on the backlog).
Why it matters for RL
The RL policy implicitly learns motor dynamics through the trajectory it experiences during training. A policy trained against the default LiftDragPlugin learns that motors respond instantly; transferred to a real drone, that policy will overshoot every setpoint because the real motors have a lag the policy doesn’t expect. Even a rough but-directionally-correct motor model in sim closes 80% of the transfer gap.
Implementation note
The plugin source lives in simulation/src/drone_sim/plugins/motor_physics/. Calibration parameters (time constant, efficiency coefficients, sag slope) are loaded from a YAML file so they can be tuned without recompiling. The match against the planned BOM (brushed 1404 motors, ~600 g all-up, 4S LiPo) is currently best-guess and will need empirical refinement once we have the real drone — that’s on the H2 2026 roadmap.
Where to go next
- Gazebo realtime factor < 1.0 — when expensive plugins hurt sim performance
- Week 3 May — Gazebo physics tuning — the dev-log entry covering this work
- Plugins hub — sibling plugin pages