The error between the estimated position Angle with Luenberger observer and the actual position Angle

[董培董]

hello!!!

When the Lombergo observer is used, the Angle estimated by the observer differs from the real Angle by 180 ° sometimes,In this case,The closed loop will fail.I modeled and simulated the algorithm with simulink,It still happens.I think the algorithm has two stable points of 0° and 180°,but how to identify and use them,I hope to get your help,Thank you very much!!!

[lucabarbiero]

Hi Dong,

I found a solution to this problem and I am going to share it here. The problem I saw in my setup is that when the algorithm is activated and the motor just starts turning (typically using an open loop control strategy), the error angle (which is the arctan of the ratio between back-EMF in the gamma and delta axis) is really unreliable because the back-EMF on the delta axis is still approximately null (and it is at the denominator of the back-EMF ratio!). This leads to an error angle that saturates randomly. Since this is the input to the angle tracking observer, the PI controller therein integrates a spurious estimated speed in the first 50 ms let's say. As a consequence the downstream integrator that outputs the estimate angle also provides a spurious angle. When then the back-EMF on the delta axis increases and the angle error becomes meaningful, it is too late.. the whole algorithm (back-EMF observer + ATO) is gone to a wrong stable state, with an estimated angle shifted by 180 deg.

See from this screenshot what happens:

So my solution was, to force the error angle to zero as long as the magnitude of the back-EMF on delta axis is lower than some threshold (in my case a threshold of 750mV works fine), in order to avoid the spurious behaviour that you can see during the first 50 ms of the recording I took using FreeMASTER.

I can't say why engineers at NXP did not have this sort of problem with this algorithm. Maybe there is a cleaner solution to this, perhaps in the way the algorithm is used? But I could not find it in their reference projects. So this is my workaround. An even simpler solution would be to just activate the back-EMF observer after a delay of 50 ms in my case. This algorithm should not be executed if the motor is stationary, which is basically the case for this initial short time elapse.

dumitrupopa‌ marekmusak‌ MatejPacha do you think my workaround makes sense? Did you ever had this problem?

Luca

[董培董]

Hi Luca

your solution is great, and I found a solution,I think the reason for the Angle error is that the error Angle is 180+ error angle,and Compensation is made by judging the positive and negative of  back-EMF in the  delta axis,If If it's positive,That means the Angle is right,If If it's negative,That means the Angle is right,That means the Angle need to compensate for 180 degrees.and I verified the feasibility of the method by simulink simulation.

Dong

[lucabarbiero]

Hi Dong,

Your workaround also works, well done. However I think that mine is really at the source of the problem. I mean when the sign of the back-EMF on delta axis goes wrong, is because of what happens in the very beginning as I showed. You are letting this to happen, and then fix downstream. The problem I see is that this will not work if you try to spin the motor in the opposite direction, but maybe this is not a concern in your application.

Luca

[董培董]

Hi Luca 

when I used the module of the function AMCLIB_BemfObsrvDQ, I have some question about parameter settings

 is the Imax equal to the Iscale, and the Umax is also,

if the Imax is not  equal to the Iscale ,the parameters is wrong,beacuse  the normalization uses Iscal,

so ,Ineed your help ,thank you very much!!!

[lucabarbiero]

Hello,

The Max quantities are in practice the scaling factors, so for me Imax = Iscale and same for Umax. You need to use values that you know will never be exceeded. They could be the maximum inverter or motor current as described, but normally I use the maximum values which are measurable by the sensors. That's the real max in practice. If the sensors range is too wide, you may have a poor FRAC32 resolution. So choose whatever max values makes sense, but make sure you never exceed that, or you will have FRAC32 overflows!

Luca

[董培董]

yes, thank you very much

I think  Imax = Iscale and same for Umax, if Ichoose the max current ,then the current should be normalized according to the maximum value ,not the scal current,(Imax<=Iscal),so,I think it's the best to use the scale current.

Dong

[lucabarbiero]

Hello, I noticed the same problem actually.

I work with the MPC5777C and I have implemented the observer myself for the eTPU, based on the algorithm description provided in AMMCLIB and the motor control workshop create by dumitru-daniel.popa‌ (by the way, thank you for that PMSM FOC workshop, I learned a lot from it!).

My implementation seems to work, the observer successfully estimates rotor speed (always) and position (sometimes, otherwise there is a constant error). My suspect is that this error in rotor position estimation could be due to incorrect motor electrical and/or mechanical parameters used to characterise the motor model inside the observer. What do you think?

Regards,

Luca

[董培董]

Hello,

I think you are right ,

My suspect is If the error Angle is close to 180°, then the system will be stable, and the estimated Angle should be 180° different from the actual Angle.

So,Can we deal with the Angle of error to avoid this situation?

Best Regards,

Dong

[Daniel_Popa]

Hi MatejPacha‌ marekmusak‌,

Can one of you comment of this one ?

Thank you!

Daniel

[nxf45548]

To provide you better support, can you please let us know the part number that you are using? 

[董培董]

The chip model is S912ZVML64，The reference manual is MC9S12ZVMMCLUG