Overmodulation and other questions

Hello Dr. Proton,

We get asked about the power question a lot.  In fact, we are considering adding a feature in Motorware to do this.

As Chris pointed out, we are only concerned with MOTOR voltages and currents from a control perspective.  Since we don't measure bus current, we cannot directly calculate bus power.  But we CAN calculate motor input power.  The easiest way to do this is with synchronous frame variables.  Since we are using the amplitude invariant form of the Clarke transform, motor power can be calculated as follows:

Motor input power =  1.5 * (Vsd * Isd + Vsq * Isq)

Also, battery power = Motor input power + inverter loss power.

To determine you inverter losses under different load conditions, you could run some tests.  Use a DC voltmeter and ammeter to measure battery power, and then subtract motor power from the equation above.  The answer should then be your inverter losses.  So you could characterize your inverter losses over different conditions and even build a LUT in code to characterize inverter losses as a function of motor power.  From then on, you could add motor power to your inverter power to get battery power.  If you want, you could even use your calculated bus power and divide it by your measurement of battery voltage to get bus current.

Please keep in mind that InstaSPIN-FOC is not guaranteed to work at zero speed, or a stall condition.  Usually it works for just a little while before giving up, but since your inductances are so low, I doubt if you can use it at all for velocity information when it is stalled, since the angle lock will be lost.  Let me think about this a little more to see what options you might have...

Regards,

Dave

I just redid the tests with unedited motorware 115 labs.  My results:

Lab 10a - USER_MAX_VS_MAG = 2/3

Overmodulation=0.67, ~3850rpm

Overmodulation=0.5, ~3130rpm

Lab 11 - remember, not modified with overmodulation
USER_MAX_VS_MAG =2/3, ~3930rpm

USER_MAX_VS_MAG=0.5, ~3890rpm

Lab 11a

USER_MAX_VS_MAG=2/3, ~4000rpm

USER_MAX_VS_MAG=0.5, ~3980rpm

The only changes I made were to add my motor to user.h, and change the speed PI gains to 0.15 and 0.001 (same gains used for all labs).  Why are labs 11 and 11a so close, but lab 10 so different?  In this case the motor does not have a load connected.  I don't really care about the slight variations in upper RPM, I want to know why I got the 3100 rpm result.

The motor I am testing with in this case is:

#define USER_MOTOR_TYPE                 MOTOR_Type_Pm
#define USER_MOTOR_NUM_POLE_PAIRS       (12)
#define USER_MOTOR_Rr                   (NULL)
#define USER_MOTOR_Rs                   (0.412260681390762)
#define USER_MOTOR_Ls_d                 (.00021836803352925926)
#define USER_MOTOR_Ls_q                 (.00021836803352925926)
#define USER_MOTOR_RATED_FLUX           (0.0094)
#define USER_MOTOR_MAGNETIZING_CURRENT  (NULL)
#define USER_MOTOR_RES_EST_CURRENT      (0.5)
#define USER_MOTOR_IND_EST_CURRENT      (-0.5)
#define USER_MOTOR_MAX_CURRENT          (4.0)
#define USER_MOTOR_FLUX_EST_FREQ_Hz     (80.0)

I don't need very accurate power measurements, just accurate enough to tell if something has gone horribly wrong.  I think ignoring inverter loss will be just fine for me.

I don't really need velocity information when stalled, I just need to know that it is stalled.  My technique seems to work okay, but I can't help but feel that there is a better way.

P.S.

Dave, your videos on motor control I found on youtube are excellent.  The concepts are very well explained and easy to understand, thank you for creating them.
Would you be kind enough to send me a link to your blog post about different integrator clamping techniques?

Dr. Proton,

I am glad that my videos were helpful.  The best way to get to all of my blogs on PI controllers is to just google "teaching your pi controller to behave".  Part 7 in particular deals with integrator clamping.

I agree that you don't need an accurate estimation of the velocity signal to determine whether you have stalled or not.  My concern however is that under a stalled condition, if angle lock is lost, we cannot guarantee anything about the velocity signal.  It could report 0 rpm, 1k rpm, or even 10k rpm.  In fact, I am surprised that it holds steady to a constant value when you stall.  Without understanding how that is happening, I can't guarantee that it will always work like that.

I'm still thinking about the problem of stall detection.  I have an idea, but I want to bounce it off the other guys on our motor control team.  Stand by...

Thanks,

Dave

I checked with the other individuals on our motor control team, and unfortunately we don't have a recommended solution for stall detection.  The problem is that when the speed is zero, we cannot say anything about the accuracy of the flux angle estimate.  And since the speed estimate is related to the angle estimate, we also cannot say anything about its accuracy.  If the speed were ramping down, I would simply suggest that you monitor speed, and if it drops below a value where you know the angle guess is still good, you simply turn off the motor.  But in a stall (which could be caused by an immediate stop of the propeller), you may not have enough time to do this.

Perhaps you could monitor the speed variable at every sample point, and if for any reason you see an unexpected change in its value beyond a certain threshold, you declare a stall condition and shut it down.  I think this would work because whether the speed estimate is accurate or inaccurate when you stall, the chances that it will remain the same value as before the stall are very remote.

Regards,

Dave

Hi DrProton,

Sorry for my tardy response.

Knowing if the BEMF is zero is at the core of the problem.  Even if you brought out the back-EMF signals from the FAST observer, you can't trust that the signals will be correct if the speed is below FAST's ability to track them.

I will be interested in hearing what you find out from my suggestion.  I think you could still detect a slow stall condition if you also compare the speed value to the commanded speed.  If current is high while the actual speed continues to depart from the commanded speed, that should also indicate a slow stall.

I will need to check with the author of the lab to see how overmodulation could be added.

-Dave

Yes, once you have lost angle lock, the current will probably go nuts too.  I suspect that when angle lock is lost, all of the controlled parameters (speed and currents) will no longer equal their commanded values.  I hope this can be used to give an indication that something is wrong.

With MotorWare15, we changed our voltage scaling by a factor of 2.  This may be what you are seeing.  Also, have you tried lab 11b?  This has a new and improved overmodulation algorithm which allows you to go all the way up to 4/3 overmodulation without loss of control.  At mod index of 1.333, the waveforms are no longer sinewaves, but trapezoidal.  The space vector plot is no longer a circle, but a hexagon.

-Dave

Hi,

I tested lab 10a and compared vs. lab 11a, and also made modifications to lab 11 so that it does overmodulation. The results are the same for all three. Here are my test results:

Modified lab 11:

Lab 10a:

There is a slightly higher speed reached with lab 10a (0.5%), which is negligible in my opinion. Not sure where the 20% came from on your tests. One thing to note though is that in labs 11 and 11a, there is only one parameter to change in user.h to limit the Vs vector (USER_MAX_VS_MAG_PU), but in lab 10a, you need to actually change a global variable (gMotorVars.OverModulation).

-Jorge

If I use the original lab 11, and if I limit the output vector Vs to 0.5, then I get this:

Although the current is noisy, and the speed varies quite a bit. Then if I change the limit to 2.0/3.0 and I try to go beyond 5000 RPM, the current controller becomes unstable, which causes the speed controller to go unstable, and generates an overvoltage, dropping the JTAG communication and resetting the device. This is expected though, since the current samples are not correct due to the narrow sampling window available, that's why the overmodulation changes are needed.

-Jorge

Hi Dr. Proton,

FAST is the observer that is used by InstaSPIN (Flux, Angle, Speed, Torque).  And it works great above a minimum speed and speed reversal through zero speed.  Stall conditions can be identified with the stall defined in your system's minimum speed.  Please take a look at the InstaSPIN User's Guide for a comprehensive overview:  .  

Below is a snippet form the UG:

Jeff

FAST features from iS UG.tiff

Not sure what is causing the difference. Could you please send screen captures of the values of Vs and Speed just like the ones I sent out?

Also, you might want to set the PI gains on the speed controller to the same values for 10a and 11 or 11a.

I think the user's guide post was an oversight. Sorry about that.

-Jorge

I ran the tests again.

Lab 11 - unmodified, I only changed speed PID values

Lab 10 - again unmodified

I confirmed the curent PI values are the same for both labs.  One odd thing I noticed is that in lab 11 at ~3100 rpm I get this:

That is interesting. Could you capture the same for lab 11a? Are you using MW15?

-Jorge

Results with lab11a

Hope this helps.  The motor in this case has 12 pole pairs, could there be some issue with high rpm?

Could you please run at lower speeds, so it doesn't go into saturation, to see if it is the same scaling? So for example, run labs 11a and 10a, at 1000 RPM and 2000 RPM, and capture both speeds and Vs for both labs. They should use a similar Vs for the same speed.

-Jorge

Seems pretty consistent.  My results:

lab10a:

lab 11:

lab 11a

Where do I go from here?

your results for lab10 are using twice as much voltage as the results in labs11

there is scaling factor of 2 off in something you've done

can you verify the USER_MOTOR_NUM_POLE_PAIRS being used for each active motor in user.h?

Lab 10a:

Lab 11:

Lab 11a:

Same results with all three labs. This is using a fresh install of MW15, and an DRV8312 kit, with 28069F and an Anaheim motor. I don't know what is the difference with your system, but I can't replicate your results. Could you try a fresh MW15 install with a standard TI kit?

Thanks,

-Jorge

DrProton.piz