sahil-kale / basilisk-actuator-control-lib Goto Github PK

HFI might be cool to support sensorless FOC if the HW can make it happen.

The BLDC control loop (and all control loops should, bridge permitting give an equivalent DC link current draw

Right now (pretty stupidly...) the warnings/errors are 1:1 and are not multiple (it is possible to have multiple errors/warnings active)

Hi sir im interesting with ypur project, i want to ask ypu, that is suport with step/dir interface??

Right now, the phase command has 2 fields

• duty cycle high side
• invert_low_side
  The first part makes sense since the phase command is assumed to implement a complementary PWM signal, but the latter makes no sense (since it implies we can short both high and low). Right now we're using it as an enable anyways, so might as well communicate that intent with renaming the field

Recommended by a motor control mentor - we can probably leverage pytest to provide SIL 'hooks' and model inverters/stepper motors/brushed motors to provide deeper coverage.

Will need to investigate a few things, notably

• python/c++ interop
• motor modelling and dynamics
• hardware modelling

The SW stack itself should not require modification.

I had originally made the decision to split up the commutation strategy of the motor into 2 separate classes, FOC and TRAP. At some point I wanted to harmonize the control loops and ended up putting all the logic back together.

At some other indeterminate time, I started splitting it back up to provide better regression coverage. The advantages of run time parameterization of the commutation strategy can still be achieved in other ways (or just giving the user the option to control), but mixing these 2 together is, in retrospect, a mistake due to the bloat introduced and the paradigms introduced by forcing the control loop to care about a commutation strategy it might not employ.

TLDR split up 6 step and FOC control loops.

Reflecting on it, there really isn't much in common, except perhaps the open loop control law, which is negligible...

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

• Capture state machine transitions
• Key flow charts for trapezoidal
• Warning/Error Generation

https://ir.nctu.edu.tw/bitstream/11536/25734/1/000224811200082.pdf

Currently, there are 2 separate control loops for BLDC motor driving. These should be consolidated into one that can then employ FOC or 6 step drive as a run-time configuration to enable run-time parameterization

An idea is that we should classify the rotor sector sensor as an absolute rotor sensor and be able to share the hall estimator code with other absolute sensors (since they will all suffer from some quantization error and the code itself doesn't actually change, just the resolution of the quantization).

This might also open up a few possibilities to decouple the interpolation code if required for relative sensors if we want to interpolate between those as well and define a generic phase-locked loop class for the estimators. However, perhaps this is left for later as a relative encoder will likely have high resolution and not require interpolation

Add a gains class/struct that will hold the kp/ki/kd values and can be used to instantiate a PID class.

This should only be enabled if we enable interpolation, otherwise this makes no sense??

As titled, would like to re-review

When validating the phase inductance estimator in simulation, the phase inductor estimate strictly works as intended in reporting the phase inductance, Ls, given a balanced 3 phase motor with no saliency.
The following LTSpice model was also used to verify the voltage/current outputs manually:

The phase inductance estimation law is able to deduce the phase inductance value given these measurements.

However, it was noted that the sensorless rotor observer paper defines the motor inductance for a non-salient motor as L = 3/2 * L_s, and defines L as equal to L_d and L_q. An NXP app note app note, however, claims that L_d is simply the phase inductance, as does the MATLAB documentation for PMSM drive parameterization. When the 3/2 term is removed from the observer, it works with the estimator values, equating L_d as L_s.

I'm more inclined to think the paper parameterization may be referring to something else given that it does not describe the motor model directly, but this might be completely wrong...

For now I will remove the 3/2 term, but this is something to look into and make sure is correct.

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.

A popular encoder type is a relative encoder - these typically output pulses in QEP form which allow them to offer relative motor positions. These can be helpful in commutation purposes as they can offer improved precision in reporting the rotor angle.

Work that needs to be done

• Add support for a base sensor relativeAngleSensor
• Add an estimator that takes the base sensor and performs relevant filtering and potential velocity/accel compensation (perhaps not required? maybe just add in, should be duplicate outta the hall sensor one)
• Add in API for all rotor sensors that allow calibration (not the rotor sensor) to be reset
• Add flag for the control loop to calibrate itself on startup and then call the above api

#IF 0'ed for now

The control loop should have a base requests function that will allow higher-level code to request the control loop of something. The specific motivation is being able to implement a calibration request to figure out phase resistance and inductance for a bridge. Motivates an issue for a base control loop state

The sensorless rotor sector sensor is still taking in a bridge object... this should be smited and instead, use the params available and have the control loop pass these values in.

Per matlab and wikipedia's documentation, the inverse clarke transform is implemented correctly. https://en.wikipedia.org/wiki/Alpha%E2%80%93beta_transformation

However, when checking the results of the voltage vector produced by the sine PWM, it was noted that the output of the duty cycles and by extension, output of the voltage vectors, were off by a factor of 1.5

I am not fully sure why the multiplication of the voltages produced by the inverse clarke are required, but that is the case so far.

Understanding this would be good.

• Should autogenerate a release on a merge to main
• Shuold capture the library artifact

Comments are already using doxygen styling, so this shouldn't be too hard

The build environment for development requires a bit of setup but fortunately is trivial on a plain ubuntu machine. The CI does not use docker, but doing so would afford more flexibility in development

Phase and Resistance Estimation is required for estimating the PI gains used by FOC.

• Control loops should report generic errors
• Specific control loops can report type-specific issues to diagnose why something failed

might be useful to add something to the base class for profiling the control loop

if the phase inductance is not set we can't determine kp and ki. we'll also get a div0 error... oops