Sensorless FOC estimator

[sahil-kale]

Currently, sensorless FOC estimator has not been developed. It would be possible to extend the BLDC rotor position sensor class to make a sensorless estimator that contains a reference to a bridge object.

[sahil-kale]

This has been updated in scope to now separate out the sensorless FOC estimator from the main estimator as a result of the requirement of making the code fault-tolerant if we can supply a flux observer such that a failure in the main estimator or loss of estimation validity can allow us to switch over to the sensorless estimation.

Need to put thought into how the BLDC control loop with decide how to switch over. Currently, invalid estimation would have caused the system to revert to open-loop control, but now we see that it is possible to want closed-loop control with the sensorless estimator rather than just open-loop.

The conditions to do this are thought of below:

• If either estimator reports it is valid, use closed loop control
• If both estimators report invalidity, revert to open-loop OR stop the rotor (this should really be feature flagged)

The BLDC control loop will have to register 2 separate estimators to support this, as it's possible to operate sensorlessly. This will be implemented as a 'primary' and 'secondary' estimator.

[sahil-kale]

Initial estimator merged! New control law needs to be made which supports the swapping of primary/secondary rotor sensors

[sahil-kale]

New control law exists but has yet to be validated. Sensorless estimator is decent as position tracking, but suffers from a pi/2 phase shift in the direction where the rotor is spinning. Suspected issue with the Valpha/beta feedforwards as these may be incorrectly set and leading to an incorrect deduction of the amount of flux driving voltage. Velocity estimation is messed up and requires attention with the following items

• Overflow handling (should be easy)
• Implementation of a PID filter for the velocity as per the paper.

Validaiton of the new control law should be done, as well as just using a sensorless algo entirely

[sahil-kale]

related issue: https://github.com/sahil-kale/basilisk-actuator-control-lib/issues/20

[sahil-kale]

https://github.com/sahil-kale/basilisk-actuator-control-lib/pull/28 addressed the sine PWM scaling which fixes the Valpha/Vbeta feedforwards and allows for the flux observer to track theta pretty nicely in simulation. Worth re-enabling sensorless estimation now and comparing the outputs of the simulink flux observer to the one implemented in the ortega observer

[sahil-kale]

chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://cas.mines-paristech.fr/~praly/Telechargement/Journaux/2010-IEEE_TPEL-Lee-Hong-Nam-Ortega-Praly-Astolfi.pdf

Link to the implemented observer

[sahil-kale]

tracking super well 👀

[sahil-kale]

Validated closed-loop control with the sensorless FOC estimator and it works as intended, except the control loop bandwidth needed to be reduced as an oscillating Valpha/Vbeta is an issue. Oscillating Valpha/Vbeta feedforwards causes instability to the estimator and reduces its ability to track a reference. This error is also observed with the sliding mode observers as well.

I tested out a SMO observer for funsies - it did track the rotor about as well, but took a little bit longer to converge to the rotor position in open loop.

It's also worth noting the open-loop implementation executes a full FOC algorithm and tries to track Iq to what it thinks the rotor is at. When we switch to sensorless FOC we suffer from a large current drop as we figure out where the rotor actually is. Worth figuring out why and optimizing