EST_STATE_ERROR Lab_02 with LAUNCHXL-F28027F and BOOSTXL-DRV8301

Max,

You must use lab2c, it includes special re-scaling of parameters for these large R/L motors.

Please attach the user.h you are using for this project, that is simplest for me to look for issues with your scaling.

Some quick items

#define USER_MOTOR_FLUX_EST_FREQ_Hz (20.0)

This is much too low. It should be ~10% of rated. Meaning 10% * Max RPM * poles / 120. So if you have a 15 KRPM 14 pole motor that is 10% of 1750 Hz = (175.0)

I am sure this is one primary issue of why your inductance test is not passing. 

Is this really only a 3A motor at maximum load? 
Does the (1.0) current allow it to spin during Ramp_up?

Chris,

Thanks for your input.  Responses below:

1) I had switched to lab 2c when I realized the motor is likely low inductance.  The behavior is the same as 2b though.

2) I've attached user.h after playing around with the MY_MOTOR parameters a little per your suggestions.5342.user.h

3) I had not appreciated the meaning and importance of that parameter for the purposes of this lab.  Your estimate of 15krpm max is about right so I changed the value to 175.  During the motor identification the motor spun much faster and longer, but I still ended up getting the same failure symptoms.  I tried bumping it up to 250 but I found that the motor would jerk periodically during flux estimation as if it was slipping a cycle and then fail.

4) The motor is probably good for around 10A (I don't have complete specs on it).  I changed that in the user parameters.  I didn't think it would be an issue because the thing is drawing no more than about 200 mA during the program.

5) The 1.0 current does allow it to spin during Ramp_up. I bumped it up just in case that would help but it didn't.

Any other thoughts?  Thanks again for your time!

Got it to finish - In addition to increasing USER_MOTOR_FLUX_EST_FREQ_Hz I had to increase USER_IQ_FULL_SCALE_FREQ_Hz to 1750.0 and USER_PWM_FREQ_kHz to 60.0.  I should have read through user.h more carefully before attempting.

I thought I was out of the woods after that but I am not having success with the very next step. After setting FLAG_Run_Identify to 1 again, the motor will jitter continuously, drawing about 500 mA and generating a bit of heat.  It may spin but at less than 1 RPM.  I tried changing target speed from the default of .099 kRPM to 1 kRPM but there was no apparent change in speed..  I have restarted and run motor identification several times and I have noticed that the results can vary significantly.  The first run gave me:

#define USER_MOTOR_Rs                   (6.755134e-05)
#define USER_MOTOR_Ls_d                 (7.803817e-09)
#define USER_MOTOR_Ls_q                 (7.803817e-09)
#define USER_MOTOR_RATED_FLUX           (0.1251475)

The second run gave me:

#define USER_MOTOR_Rs                   (0.03511877)
#define USER_MOTOR_Ls_d                 (1.560763e-08)
#define USER_MOTOR_Ls_q                 (1.560763e-08)
#define USER_MOTOR_RATED_FLUX           (0.1509135)

Rs values have varied from near zero to around .041.  Obviously the higher values make some sense.   Is this typical?  Why might the motor not attain the target speed?  Thank you.

When you increased PWM to 60 KHz did you change any of the other TICK rates?

On the 27F, it's about 30 MIPS (on a 60 MIPS machine) to run a 10 KHz control/estimator.

The default TICKs use PWM / 3, giving an effective rate of 20 KHz for the control/estimator.  This will overflow the interrupt.

It would be nice if we had a /4, /5, /6 option on our hardware PWM module, but we are stuck with a maximum of

USER_NUM_PWM_TICKS_PER_ISR_TICK (3)

so you then need to go to a software decimation using

USER_NUM_ISR_TICKS_PER_CTRL_TICK (2)

So for RUN-TIME I would recommend trying

#define USER_PWM_FREQ_kHz                (60.0)
#define USER_NUM_PWM_TICKS_PER_ISR_TICK        (3) // ADC DONE ISR at 20 KHz
#define USER_NUM_ISR_TICKS_PER_CTRL_TICK       (2) // CTRL at 10 KHz
#define USER_NUM_CTRL_TICKS_PER_CURRENT_TICK   (1) // CURRENT loops at 10 KHz
#define USER_NUM_CTRL_TICKS_PER_EST_TICK       (1) // FAST estimator at 10 KHz
#define USER_NUM_CTRL_TICKS_PER_SPEED_TICK  (10) // SPEED loop at 1 KHz 
#define USER_NUM_CTRL_TICKS_PER_TRAJ_TICK   (10) // TRAJECTORY loop at 1 KHz

I recommend trying to ID only using HW decimation (the PWM_TICKS_PER, always leavign ISR_TICKS_PER at (1) ).  Once you have the values (especially Ls) you can load from user.h and change the PWM / Clocking / Decimation as required.

Your Rs values should be consistent if you use a current setting in user.h of about 10%.  With low inductance motors it's very easy to heat up the windings though if you aren't controlling the current or applying too much.  However, the Rs value has a very large impact on the FAST estimation at low speeds and very little at higher speeds.  You won't (and can't) run these hobby motors at low speed anyways, so your primary concern will be on getting the Ls value correct. 

The Ls is till ID'ing too low. For hobby motors you should find values in the 3uH to 30uH range.

When I increased to 60 kHz I changed USER_NUM_CTRL_TICKS_PER_SPEED_TICK to 20 and USER_NUM_CTRL_TICKS_PER_TRAJ_TICK to 20 for 1 kHz loops.  I see that 20 kHz was perhaps too ambitious for the 27F.  I entered your values and the behavior was near identical to what I had running before (where ISR_TICKS_PER was 1).  It completes the identification giving these values:

#define USER_MOTOR_Rs                   (0.06358504)
#define USER_MOTOR_Ls_d                 (1.560763e-08)
#define USER_MOTOR_Ls_q                 (1.560763e-08)
#define USER_MOTOR_RATED_FLUX           (0.512)

Then when it tries to run, it spins very slowly and does not respond to updated speed targets.  I will keep playing with the ticks and PWM frequency.

I will add that the first time I ran it and also just now, when starting up the current pegged and the motor squealed horribly.  I had to kill power.  The second time, it ran OK, and then just now, the third time, it squealed again. Not sure why that happens.

Look at the other hobby motors listed in the user.h file and notice they all have Ls values of 2.5 - 30 uH

If you just want to get it spinning try setting your Ls values to 0.000003 (3uH) and just load from user.h (disable RsRecal but enable OffsetCalc unless you have stored them in your user.h as well)

and then increment up  to 30 uH to see if you can find something that works well.  This motor should perform well in the 500 RPM - 15 kRPM range.  These types of motors aren't really meant for low speed operation and count on higher speeds for self cooling. At low speeds they will heat up rather quickly.

Your 0.06 ohm Rs value is reasonable (although most of the small hobby motors are more like 0.01 to 0.03 ohm), but it would be nice if it was consistent.  That's the only part that has be a bit concerned.

I'll try just spinning the motor but I would like to see the algorithm correctly identify parameters (I think that's really the purpose of the lab) and I don't really understand why that's not happening.  Is this little motor a poor example for InstaSPIN?  It's surprising that it's having trouble because it spins beautifully during some stages of the identification process.  I just ran it again and it estimated 80 mOhms Rs (which is at least in the ballpark) and ~.080 for Ls which is crazy high. At the end of its inductance identification it sang and pegged current briefly but still completed.  Maybe I need to get a hold of a more typical motor because I'd like to understand how the process normally works.

Correct, these types of motors were not the target when we created InstaSPIN-FOC.

These very low inductance (sometimes low flux), high speed motors are more challenging to control with PWM techniques due to the very high short circuit current / current ripple.  There's several posts on this topic, but many of the controllers for these types of motors today are just doing near 100% duty cycle block commutation and varying speed just by regulating the voltage bus.  The more complex ones add some current-limiting control (not full closed loop current control).

The complication with the identifcation stage has several factors

1. The ID process takes more MIPS than the run-time control, so it limits the capability to increase the PWM frequency as high as we would like (70-100 KHz).

2. Quality of the voltage and current signals - and the resolution of those signals in HW and in SW - becomes more important.  With the BoosterPack at least your scale is from 0-26V and 0-14A, but if you are only looking at 12V and 0.5A signals you aren't using much of the resolution.  It always helps to get best resolution possible. One of the problems with these motors is that they can use HUGE current if loaded, but unloaded (when doing ID testing) it is very small. 

3. Because the inductance is so low, you are trying to measure a current signal that is non-linear during the transition event when you sample.  It is extremely challenging to do this with shunt based sampling.  On larger systems they would measure the phases in-line where you get continuous samples and could do some averaging of the current.

4. Inductance isn't a static term. It changes with frequency and current.  For most applications the Ls doesn't change too much, and when it does it's a small amount.  With these motors I believe it changes more, and the overheating from the current switching makes it much worse.

With all this said, we've still been able to ID almost everything.  I still have trouble getting 100% reproducable results on the very smallest ~2-5uH, but they do ID.

More disturbing is that in your screenshots you are showing VERY dramatic differences in Rs and Flux. This is a red flag that something else must be wrong.  Rs and Flux are very straight forward and should be reproduceable.

Thank you for the detailed explanation.  

What else do you think might be wrong?  I suppose it's possible that the motor might be a piece of junk but I'm surprised it runs so well when it gets some speed up.  The driving hardware is brand new from TI and the software is straight out of motorware.  As I said, I'll try to get a hold of another motor for experimentation.

Max,

Your Flux numbers sure are varying alot, and they are alot larger than I would expect for a helicopter motor.  Most of the highspeed hobby motors have very low flux of < 0.01 V/Hz. 

If you have a large V/Hz this creates a large Bemf V at higher Hz. For example, even with the 0.125 V/Hz you measured first, at 1750 Hz you would be producing 218.75V of Bemf.  This doesn't make sense for a low voltage motor used in Hobby applications.  If you assume 24V and solve for Hz you would find that you have a maximum speed of 192 Hz.

Are you sure this is a low voltage three phase motor?  Is it possible this is a motor wound for high voltage operation?

The parameters just aren't making sense.

If you would like to get a low voltage motor, we include a 24V motor in our DRV8312-69M-KIT.  You can buy this motor by itself from AnaheimAutomation.com for ~$50.  We also sell a nice motor that is rated for up to 60V and works well at 24V with the Launch+Booster: LVSERVOMTR

There are many, many motors available on the market from all sorts of suppliers. I would recommend trying to find one that isn't super high speed or high current so you don't have to worry about the low inductance effect.

If you need something cheaper and want to stay with these style of motors you can buy a new hobby motor in the <24V range on-line at very low cost. I've purchsed from HobbyKing.com and recommend Eflite or Walkera.

Thanks again.  It's actually an rc plane motor I happened to have lying around - here's a link http://www.rc-base.com/engine/rctimer/rctimer-cf2805-14-2840kv-outrunner-brushless-motor.  Definitely a very high speed unit and supposedly 2840 kv so the BEMF should be very low.  I think the parameters just aren't being identified correctly given the exceptionally high kv.  I'll pick something else up to play around with.

Max,

We never have any issues with very low flux though, that is always identified correctly (at ID and as soon as the motor is spinning)

It makes me suspect that either there is a HW issue or we are missing something simple.

Considering we are seeing strange and inconsistent Rs and Flux my feeling is maybe the hardware is damaged.

BTW - I want to mention something.  My comments above regarding these hobby motors came across kind of negative. InstaSPIN-FOC does work VERY well for these motors once you get everything sorted out, it just may not be as "instant" as with higher inductance motors. I just got a note that a cusotmer (who has helicopters in the market) just did testing on their systems and InstaSPIN-FOC gave a 10% gain in efficiency / battery life.  I have another customer (who does very large flying systems) that has a 15% efficiency gain.  This is a big advantage for motors that run on batteries!

Max,

Looking at your link

1. Are you ensuring you only run the Vbus at 7.4V ?  Running at higher voltages will damage these small motors. Trust me, I have done it :)

Max RPM = 21 krpm = 7.4V * 2840 RPM/v

These small motors are usually 3 pole pairs so
Max 1050 Hz 
If you are sure it's 4 pairs that is 1400 Hz

Flux for this machine should be < 0.01 V/Hz, in fact it should be less than 0.007 to operate at full speed (7.4V / 1050 Hz) w/o weakening the field. If it's 4 pole pairs that puts the flux at 0.005 V/Hz

Rs = 0.073 ohm on website, which is usually line to line. For InstaSPIN you /2 to get line to neutral should be about 0.035

It has a continuious current of about 16A according to it's wattage number, and they recommend a 30A inverter to handle some peaks.

Isc = flux / 2pi / Ls.  If we make some assumptions that flux is 0.006, and Isc is over designed (typical for these motors) by 4x rated and 2x peaks, that gives an Ls of 15uH.

So you should be looking for something in this range

Rs = 0.035
Ls = 0.000015
Flux= 0.006

And PWM'ing at 60 kHz is a good idea.

You should lower this value to something like

#define USER_IQ_FULL_SCALE_VOLTAGE_V      (10.0)

this will probably help with the motor ID.

If you want to cange some of the hardware scaling, updating the voltage sense to increase resolution will help quite a bit for such a low voltage motor.

#define USER_ADC_FULL_SCALE_VOLTAGE_V       (13.157)

Thanks for going through the numbers a little bit there - the examples are very useful to me.

1.  I was running at 7.4V initially but I did bump up the voltage to 16 later on when I was getting errors under the assumption that for some reason it wasn't able to drive adequate current into the BEMF.  Perhaps the motor has been damaged by that but I don't really understand the mechanism since I'm current limiting the supply at 10A and the coil wire should have enough insulation to withstand more than 16V.   Certainly a possible source of failure though if you've experienced it. 

I did just drop the USER_IQ_FULL_SCALE_VOLTAGE_V to 10 and ran it again with a 7.4V supply but got pretty similar numbers to some of the previous attempts.

gMotorVars.Rs_Ohm float 0.07210001 0x00000064@Data 
gMotorVars.Lsd_H float 6.503181e-09 0x00000068@Data 
gMotorVars.Lsq_H float 6.503181e-09 0x0000006A@Data 
gMotorVars.Flux_VpHz float 0.1244552 0x0000006C@Data

It's just as likely that this motor was poorly assembled from its inception or damaged while it has been sitting around in a box of junk.  I think my best strategy is to try out a motor that is less of a question mark.  I'll pick something up and report back with my results.  Thanks again for your patience.  

Max,

No, thank you for YOUR patience and willingness to continue to investigate our solution. I understand the expectations that we are setting with our InstaSPIN claims, and in your case the expecation was not met (regardless of the validity of the reasons).

I know you will be pleased with the outcome as you continue to investigate.  Look forward to seeing your successful report!

Hi Chris,

I finally got back to trying this again with a new motor.  I ended up going with something outside of your recommendations (perhaps at my own peril) but I was looking for a sensored 2-pole and this one fit the bill.  It is another hobby-type motor, 1900 kV.  The results are similar to the first motor.  Estimated resistance is all over the map, inductance seems low, and flux is nonsensical.  

[actually the part about the motor not spinning may have been my eyes playing tricks on me]. After the estimation sequence completes and I set gMotorVars.Flag_Run_Identify to 1, the motor turns slowly (probably about 10 rpm) but does not change speed when I change target speed.

It has been a few weeks since I looked at this so maybe I'm forgetting some obvious configuration parameter?  I have attached my current user.h file.  

2502.user.h

Success!

I implemented all of the changes you mentioned except for #define My_Motor and it worked beautifully this time.  With regard to the commented out "My_Motor" definition, you should note that there is an uncommented line a few lines down where "MY_MOTOR' is defined.  The reason for this is that the motorware version I downloaded basically had all of the steps of Lab 2 done already and I wanted to undo the steps that had been done and write them all completely myself.  So that part was working as it should.

Here are the new parameters:

The Flux_VpHz estimate does not quite align with the specified 1900 kV of the motor but I'm going to play around and see if I can get more agreement there.  Thanks again for your patience, I'll probably have more questions soon.  Can I mark your post as the correct answer somehow?

V/Hz and kV are not equivalent,

0.02 V/Hz is the Bemf produced. This means that you may be able to run this up to the Bus voltage and get a corresponding Hz for speed.  It is typically your Bemf that limits your maximum speed.

0.02 V / Hz = 50 Hz / V

So if this is as 12V machine that would be 50 * 12 = 600 Hz  @ 2 poles = 36 kRPM

Manufacturer claims this is a 1900 kV motor, which means 1900 RPM per Volt, so at 12 V = 22.8 kRPM

I guess you could say that

1 / [kV * poles / 120]  equivalent  V/Hz

1 / [1900 * 2 / 120] = 0.032 V/Hz

I think the kV number produced by the manufacturers of these hobby motors are typicaly reduced to guarantee full torque ratings at these speeds with the typical ESCs used for control.

0.02 V/Hz converts to a  3000 kV value.

I'll be interested to see which kV "line" the speed of this motor produces at a given voltage and full modulation.

Hi Chris,

I'm aware that V/hz and kV are not directly equivalent, but they are both related to BEMF and the numbers (as you explained in your post) do not work out to be identical.  No need to get into the discussion right now, I just would have expected kV of the motor to be much closer to the BEMF-predicted value.  I adjusted the Flux Est Hz up from 60 to 100 and saw that the BEMF estimate was the same so that 0.02 V/Hz does appear to be correct.

Wow, you got a quick additional response in before I could.  Your second post addressed the question perfectly.  Thanks again!

Here are some other Hobby motors and their equivalents

EFLITE 420, 6 poles
V/Hz = 0.0034 equivalent to  5882 kV
kV = 3800 kV

EFLITE700, 12 poles
V/Hz = 0.018 equivalent to  555 kV
kV = 500

EMAX Custom, 12 poles (?)
V/Hz = 0.008  equivalent to  1250kV
custom sticker says 650 kV but originally an 1100 kV off the shelf...or I'm off on the poles

Hmmmm. That doesn't tell us much, except that these small motors have a very small flux, so there is probably more error, especially with hardware scaling not being ideal.  But we are measuring LESS flux than what the kV suggests, so I don't think it's a resolution issue.

I have heard that these really small motors may do something in their design caled "consequence poles" which may effect the kV but not the flux you are measuring during ID.  I'm curious to run some more now and see if the flux does increase at higher speeds.

Interesting datapoints.

I had been thinking they reduce the rated kV of the motor such that at a given bus voltage you can achieve the speed indicated by the kV (overcoming the BEMF) and still build adequate current across the winding resistance to achieve the rated torque.  However, the discrepancy is too big to be accounted for just by that, even if some losses were factored in as well.