A problem that hall (and QEP sensors will face if implemented) sensors see when the velocity changes sign is the velocity estimate jumping up like crazy on a sector change back, even if the actual rotor velocity is small. Because the 'sector' signal is in-band, the velocity estimator currently shoots up on a sign change, with the problem ironically getting worse the less the rotor is changing and the closer it is to a sector.
Proposed resolutions
1) If we see the velocity sign change, stop interpolation until we exceed the num_hall_to_update and reset the estimation
2) Refactor the is_estimation_valid signal to be different from the is_ready_to_interpolate.
This is because is_estimation_valid is consumed by the higher level FOC algo and should always be valid because it is an absolute sensor. There is no reason we should be running in open loop if the absolute position is available
is_Ready_to_interpolate should contain logic surrounding num_hall_to_update before we start interpolating, as well as overrun detection and velocity sign change stuff as discussed above
A problem that hall (and QEP sensors will face if implemented) sensors see when the velocity changes sign is the velocity estimate jumping up like crazy on a sector change back, even if the actual rotor velocity is small. Because the 'sector' signal is in-band, the velocity estimator currently shoots up on a sign change, with the problem ironically getting worse the less the rotor is changing and the closer it is to a sector.
Proposed resolutions 1) If we see the velocity sign change, stop interpolation until we exceed the
num_hall_to_updateand reset the estimation 2) Refactor theis_estimation_validsignal to be different from theis_ready_to_interpolate.