ENGINEER · PILOT · BUILDER

Aerospace & Flight · 2024

Drone Flight Control & Motor Mixing

Built a Crazyflie flight-control stack from measured airframe dynamics through motor mixing and firmware, then tested it in indoor mission flights.

Project type
Graduate aerospace controls project · modeling, firmware, and flight tests
Role
Individual modeling and mixer design; collaborative controller integration and mission testing
Maturity
Model + firmware + indoor flight demonstrations
Collaboration
Individual modeling and mixer work, followed by collaborative controller integration and mission testing
Vehicle dynamics
6-DOF
Hover control
LQR
Attitude estimation
Kalman
Motor mixing
Force → PWM
Read the motor-mixer report
01

What I built

I built an end-to-end flight-control stack for a 31.9 g Crazyflie 2.1, from physical measurements and a 12-state dynamics model to feedback control, motor allocation, firmware, and indoor flight testing. The goal was to carry force and moment commands beyond simulation and execute them on four real motors.

SYSTEM ARCHITECTURE

Measure and model

Airframe tests → physical parameters → 12-state hover model

A bifilar-pendulum experiment and propeller data supplied the mass, inertia, thrust, and torque parameters used in the six-degree-of-freedom model.

Control and estimate

References + sensor data → state estimate → cascaded feedback

The hover model was separated into practical control channels. LQR and frequency-domain analysis shaped the feedback loops, while a Kalman filter estimated roll and pitch from noisy measurements.

Allocate and execute

Lift + body moments → four motor commands → firmware

The mixer converted total lift and roll, pitch, and yaw moments into four rotor commands, mapped motor speed to PWM, and applied saturation before execution in the Crazyflie firmware.

Test in flight

Incremental tuning → hover → indoor mission runs

The integrated system was tuned and tested on hardware through hover, translation, mission, and airshow runs. Successful and failed attempts are both retained in the media gallery.

02

How it came together

  1. STAGE 01

    Characterize the airframe

    Measured the airframe with a bifilar pendulum and used propeller data to establish the physical parameters behind the model.

  2. STAGE 02

    Build the dynamics model

    Derived the nonlinear 12-state rigid-body dynamics and linearized them around hover for controller design.

  3. STAGE 03

    Design control and estimation

    Designed cascaded feedback loops and a roll/pitch Kalman filter, checking response and stability in simulation.

  4. STAGE 04

    Translate commands to motors

    Derived the four-rotor allocation, fitted the motor-speed-to-PWM relationship, and implemented the bounded mixer in C.

  5. STAGE 05

    Integrate and fly

    Integrated the controller and mixer on the Crazyflie, tuned incrementally, and recorded indoor mission and failure runs.

03

Key engineering decisions

Maintaining consistency from physics to firmware

The dynamics, controller, mixer, and embedded code all had to agree on units, axes, signs, and rotor numbering. A mismatch at any interface could reverse a control action on the real aircraft.

Turning control effort into feasible motor commands

A valid force-and-moment request is not automatically achievable by four motors. The mixer had to allocate the request, use the measured motor fit, and respect actuator limits.

Moving from simulation to flight

The model could not capture every sensor, actuator, battery, and aerodynamic effect. Conservative tuning and incremental hardware tests were essential before attempting full mission runs.

04

What worked

  • Completed the 12-state dynamics, hover-control, state-estimation, and motor-allocation analyses documented in the linked reports.
  • Implemented the force/torque mixer in the Crazyflie firmware using a measured motor fit and bounded commands.
  • Recorded successful indoor hover, translation, mission, and collaborative airshow runs on the physical aircraft.
  • Retained unsuccessful tests and a crash alongside the successful flights to show the real integration process.
05

What I took from it

Motor allocation and saturation belong in the control design, because a command matters only if the four motors can produce it.

Hardware testing exposed assumptions that simulation could not. Keeping the full path from measured parameters to firmware made those mistakes easier to find.

A successful flight demonstrates integration; repeated tests and telemetry are still needed to quantify robustness.

06

Reports and analysis

NEXT PROJECT / 02

CLF-CBF Safety Filter for an Autonomous UGV