Multirotor Recovery Dynamics
A Crazyflie recovery study starting with dynamics replay against public flight recordings.
Result. Crazyflie platform selected and propulsion inputs sourced. The first reproducible flight-data replay is the next deliverable.
The historical model's recovery outcome changed substantially when both motor allocation and controller behavior changed. That sensitivity motivates checking the new model against recorded flights first. NanoBench provides motor commands, motion-capture state and onboard telemetry from an instrumented Crazyflie. The selected 2.1+ purchase candidate is a separate configuration. The V995 fixture is retired.
| Category | Robotics & Controls |
|---|---|
| Timeline | Jun. 2026 - Present |
| Status | In Progress |
| Evidence | Documented Crazyflie inputs; flight-data replay pending |
| Role | Dynamics modeling, motor allocation, parameter sourcing, and recovery-study design |
| Tools | Python, NumPy, SciPy, CadQuery |
| Links | RepositoryRoadmapParameter register |
problem
My contribution. Built the rigid-body recovery simulation, motor-allocation model and parameter sweeps; assembled sourced Crazyflie inputs and defined the replay, identification and firmware-comparison sequence.
How much height does a tumbling quadrotor need to regain controlled flight, and how do actuator limits, sensing, delay and mass distribution change that prediction?
constraints
- No hardware purchase before the final owner decision.
- NanoBench contains ordinary flight; recovery and design-variant results remain predictions until tested in flight.
- Training, development and final evaluation use separate whole flights. Previously inspected flights belong to development.
- Firmware thrust-command limits are distinct from measured physical thrust limits.
design evolution
Iterations, issues, and fixes, recorded in the order they happened.
| Revision | Failure mode | Design change | Result |
|---|---|---|---|
| Historical model audit | Recovery predictions depended strongly on assumed actuation and controller behavior. | Recorded the model limitations and preserved the original outputs for reproduction. | Historical plots remain labeled with their original aircraft. |
| Crazyflie inputs | Published vehicle models and firmware defaults describe different configurations. | Separated dataset mass, hardware specifications and firmware thrust curves in a sourced register. | Platform decision and documented inputs are committed. |
| Flight replay, next | Frame, timing or motor-command mistakes can resemble an incorrect thrust model. | The replay will check signal meaning before parameter fitting and reserve whole flights for final evaluation. | No Crazyflie prediction-error result released yet. |
results
Existing tests exercise the historical analysis and synthetic bench-capture software. They do not evaluate Crazyflie recovery.
The next result will report baseline errors by flight and axis, followed by short open-loop predictions and training-only identification.
Scope note. No Crazyflie recovery trial or held-out replay result has been released. The figures below use the historical estimated aircraft. NanoBench observations were collected by the dataset authors.
lessons
- Agreement on ordinary flight has a limited operating range; tumble recovery requires separate evidence.
- Motor torque and inertia can be difficult to identify separately from the same angular motion.
- A firmware comparison must use the intended sensor inputs and preserve an independent disarm path.
gallery
