why closed loop speed control?
Typical drone electronic speed controllers (ESCs) are not actually speed controllers - rather, they handle commutation: switching of the applied current between the (usually 3) phases of the motor. This is done by a dedicated microcontroller that can sense the zero-crossing of the back-EMF in the undriven coil, informing when to commutate. That said, ESCs do pass through an input command range to an output range: for protocols such as PWM and all of the *Shot variants on commodity hardware, the input signal is translated into an output PWM duty cycle, usually with a linear mapping.
In a typical multirotor control scheme, there are multiple nested control loops, and having better tracking at the motor speed command level means that commanded thrust and moments are more closely tracked. Without motor speed control, errors in actual applied thrust and moment act as disturbances to the attitude and position control loops.
ID the open-loop mapping
The first step to good closed-loop motor speed control performance is determining the open-loop model, and identifying its coefficients. Because the thrust generated by the propeller increases with the square of rotational speed, the load placed on the motor due to propeller drag, and therefore the required PWM duty cycle, also goes up with speed squared. Due to friction, minimum smooth commutation speed, and other effects, the open-loop fit between PWM and RPM can be improved by adding linear and constant terms.
Once the open-loop fit has been determined, closed loop feedback control can be added. In my experience, proportional control is sufficient to compensate for unmodeled effects during flight near hover. Especially because there are more control loops closed above the motor speed (e.g. attitude and position), integral control terms are best added at those levels.
The open-loop mapping between PWM duty cycle in the motor coils and motor speed is simple when the air around the propeller is static and undisturbed. During periods of heavy loading, such as fast flight under wind resistance, or rapid acceleration/deceleration, additional aerodynamic effects come into play, but those effects can be compensated for by feedforward terms calculated above the motor control level, using information from state estimation and even perception/mapping.
close the loop - hardware options
To apply feedback control, you need a speed signal from the ESC, or you need to be running code inside the motor controller. Typical protocols are unidirectional and so can't return this information, and many commodity ESCs run closed-source firmware. These restrictions led me to investigate the following options:
1) SimonK tgy firmware on Atmel-based ESCs. Running on Snapdragon Flight with SDREF/HEXREF and BLIMPREF. This solution keeps only the code for commutation and interfacing in the motor control firmware. Everything else, including the open-loop mapping and the feedback control, live in higher-level code. This makes modification of the logic and coefficients much easier. The biggest difficulty is hardware availability - most Atmel ESCs are discontinued, although we fabbed the open-source Blue ESC and tested with some success.
2) CAN bus ESCs, such as the UAVCAN or KDECAN-capable ESCs. Work in progress - will be supported on the TI TMS570 with R5REF. Many ESCs in this category run Field Oriented Control (FOC) algorithms, which dramatically improve efficiency. Most have higher voltage and current ratings than the Atmel ESCs, and most close the speed control loop onboard. Any telemetry back from the ESC in this case is for health/status monitoring.
3) Close the attitude rate loop instead, using PX4 or Betaflight. If you’re building a typical multirotor aerial vehicle (something that can be controlled effectively by PX4 or Betaflight), it may make sense to close the attitude rate loop in commodity hardware, running one of those autopilots. This does make it more difficult to do research on mixing from commanded thrust and moment to commanded rotor velocities, or to implement fancy feedforward compensation terms at the motor control level, but the ease of use for research in the lab is excellent. I opened a PR against Betaflight for a MAVLink angular rate setpoint receiver but haven’t had time to clean it up for approval. PX4 supports receiving these commands out of the box, and QUEST has an interface to send them from HEXREF.
4) Modify Betaflight code to close the motor control loop, using Bidirectional DShot. This is notional, but with the RPM feedback in Betaflight, it would be pretty easy to add a closed-loop motor control mode (or make a fork dedicated to this, stripping down the existing functionality). The hardware support is excellent, and these protocols seem to be the standard in high-performance racing drones. If anyone is interested in looking into this, let me know in the comments!