InstaSPIN-FOC with (mid-> large) hobby BLDC motors

Patrick,

I'd say about 25% of the posts on here are on this topic.  I know it's hard ro read through them all, but there is a lot of good information archived on this forum. 

You should read this blog post.

There is also a QSG that accidently got left out of the MotorWare release. It's attached and you can drop it into
C:\ti\motorware\motorware_1_01_00_11\docs\boards\kits\docs

The key things you need to know in regards to hobby motors

1. They typically have very high Isc (short circuit current). This is due to a very low Ls. Isc = Flux (webers) / Ls.  To deal with a high Isc you need to PWM faster. 45 kHz is typically minimum, and performance is improved at 60 kHz and many off-the shelf controllers (for hobby and other smal motors) use 72 kHz+.  These motors tend to have very high currents for full load conditions and accerleration capabiltiy, but VERY low currents for non-loaded running.

2. The motor ID for these motors is a bit different as the you are looking for very small flux and inductance values as well as dealing with the Isc during your ID period (which is pseudo open loop where stability is harder to maintain)

3. The hardware scaling on the EVMs is not designed ideally for these types of motors where you are running low bus voltage, looking for very small Bemf signals at lower speeds, and very small inductance measurements (smal current signals when running unloaded) on a larger current capability scaling (so low resolution).

4. FOC techniques in general haven't typically been used for these type of applications. Most of the ESCs for hobby type motors are running full duty cycle commutation and simply adjusting the bus voltage to regulate speed. That's why you see them spec'd in Kv (rpm/v). So for a 12V motor with 1200 Kv, it should spin 14,400 RPM.  When they want it to spin 7,700 they just reduce the bus voltage to 6V.  We have several hobby customers who have now done full designs with  with InstaSPIN-FOC though and they all claim 10-20% increases in efficiency = 10-20% increase in battery life / fligth time with InstaSPIN-FOC due to better current control, especially in high dynamics (which is always with things like helicopters).

So with all that said, here is how you go about getting the best performance.

• Optimize HW

• If you have a 12V motor, scale your Vbus and Vph readings for ~14-16V
• Create your HW filter pole to USER_IQ_FULL_SCALE_FREQ_Hz / 4; this FREQ should be just greater than the max Freq you want to run.
• Scale the currents for peak currents you need to read, this should be just over the max for full torque

• Update user.h for these HW settings
• Update user.h SW settings
  • Most critical for the low flux machines (as these typically are) is the formula for calculating the SMALLEST FLUX that can be measured =

    USER_IQ_FULL_SCALE_VOLTAGE_V / FAST_EST_Hz / 0.7
    
    but you also need to keep  USER_IQ_F_S_VOLT >= 0.5 * USER_ADC_FULL_SCALE_VOLTAGE_V
    
    Let's take the case where you set your ADC_VOLT  to something like 16V, so keep IQ_VOLT > 8
    . Let's choose 9V 

• 9V / EST_Hz / 0.7; where EST = 5 - 15 KHz typically.
  • So that sets a minimum flux value we can identify of
    • EST 5 kHz, min flux = 0.00257 V/Hz
    • EST 10 kHz, min flux = 0.001285 V/Hz
    • EST 15 kHz, min flux = 0.000857 V/Hz
  • Most hobby motors I've seen don't go lower than about 0.002 V/Hz, so in this case I'm probably ok with running my Estimator at about 10 kHz
• Note that on the existing
  • BOOSTXL-DRV8301 because the ADC_V = 26.3, you need to keep IQ_V to 14V minimum, this mean you really need to keep the EST 15 kHz to insure you have 0.0013 V/Hz minimum resolutions.
  • DRV8301 EVM because the ADC_V = 66.32, you need to keep IQ_V to 34V minimum, this means at 15 kHz your flux resolution is only 0.003 V/Hz, which is probably not small enough to get a good value for these very small flux motors
• PWM Frequency, you will need 45 KHz minimum. I like to start with this at least for ID because then I can use the PWM_TICKS = 3 (maximum value) to get 15 KHz at the controller and estimator.  If you increase the PWM frequency higher you have to add in software decimation with ISR ticks. This is ok for run-tim, but the ID process uses more MIPS overhead and I don't want to risk overflowing my interrupt.
• Control Frequency
  • General rule of thumb is you need to be updating your current control frequency at least as fast as the MAX_HZ * 7. For your motor that's 720 * 7 = 5+ kHz minimum, so I would make sure I'm at 7.5 kHz or higher....so I'd just start with 10 kHz. But since your flux may be so low that you use 15 KHz for estimator, you might as well keep them in sync both at 15 kHz.
• USER_R_OVER_L_EST_FREQ_Hz (300)
  • This is now default of (300) in the DRV83x based inverters once we say how many people were using high speed motors. At the previous (100) the inital RoverL was not giving good enough values
• USER_VOLTAGE_FILTER_POLE_Hz  (335.648)
  • The values we choose for this pole (which is matched in HW) are too low for the very high speed motors.  A value we would recommend is MAX_HZ + buffer / 4. 
  • Your motor is actually only 720 Hz @ 12V, so this will work fine.  I would then set your full scale to 4 * the HW/SW FILTER_POLE
    #define USER_IQ_FULL_SCALE_FREQ_Hz        (1343.0)
• USER_MAX_ACCEL_EST_Hzps           (20.0)         // 5.0 Default, don't change
  • This controls how fast you accelerate during motor ID state RampUp. There is a time-out during this process so you need to insure you can hit the target speed in time. For your motor the defautl is fine, but for 1-2KHz motors we set this to (10) or (20) to make sure the speed is reached
• #define USER_MOTOR_RES_EST_CURRENT      (1.0)
  • 10% of rated current minimum.  Increase if needed to make sure motor starts spinning during Motor ID state RampUp         
• #define USER_MOTOR_IND_EST_CURRENT      (-1.0) 
  • -10% of rated current. If you increase RES_EST per above, you can also increase (negative) this value, but I tend to do so at about half the rate so the control doesn't become unstable during the Ls testing      
• #define USER_MOTOR_MAX_CURRENT          (3.82)    
  • Insure this is the largest Iq_A command you ever want coming from your speed controller output. It must be enough to insure you reach your RampUp speed target    
• #define USER_MOTOR_FLUX_EST_FREQ_Hz     (20.0)         

• This is your RampUp speed target. Make sure this is 10% of your rated, so 72 Hz for your motor

Trying to answer some of your other questions in the next post.

"*The controller loses stability at about 10k RPM, which the motor and controller should easily do - I am putting it down to poor identification?"

Many things.

• Ls becomes critical (Rs less critical) at higher speeds, so yes it needs to be reasonable.
• Mis-settings on Max Hz, USER_MOTOR settings, etc. Make sure they are correct.
• Did you check the default tuning of the current controllers using a step response? Typically they are good to do basic operations, however at higher speeds / dynamics we recommend setting the IqId_Kp back to the full bandwidth (multiply the default value by 4)
• Speed loop tuning: The gains we default to are not tuned, they are nearly arbitrary to enable the motor to spin at moderate speeds. You need to tune for your system. This is documented in multiple areas.
• Any control issues are usually tied to the speed controller. You can run lab5a which removes the speed controller from the loop. If this is stable to maximum speeds you need to tune the speed controller
• Recall your modulation. The default is 1.0 which isn't "full speed" from a Kv specification. You will need to increase your modulation in lab09 to get more voltage to the motor

"*Is there a simple way to find the inductance with bench equipment and break it up into direct and quadrature components - accurately?"

• There are inductance meters
• Recall that our Ls variable is Line-Neutral, you will measure Line-Line with a meter, so adjust accordingly.
• Inductance isn't a single value. It changes with frequency and can change with load, although these hobby motors have essentially no saliency, their direct and quadrature can be treated as equal

"*The BLDC motor is particularly bad at low RPMS (<500), the magnets in it are very strong and I doubt that a hobby ESC would spin it at these speeds (this low)?"

FAST is based on Bemf/Flux calculations. Think about how small your Bemf is when operating at 500 RPM (25 Hz for your motor).  25 Hz * 0.002 V/Hz (as an example) = 0.05 V.  This is TINY!  Most "regular" motors have flux values that enable excellent feedback at very low Hz levels....but not these hobby motors.

This is why sensorless observer tracking is difficult at low speed. Just think, some observers don't even use Vph, so they are trying to extract this only from the current information or reconstruct from the Vbus. Impossible!  If you REALLY need to run slower here are the options

1. Maximize the scaling / resolution. Look at using a programmable gain amplifier, so when at low speeds you can dynamicaly scale the voltage to increase resolution.  Eventually we will show an exmaple of doing this, but most people probably won't use it I suspect.

2. Build a better motor with more flux.  These hobby motors are TERRIBLY designed for the speed, torque, and acceleration they need to produce.  I understand the flux is low because they want to minimize magnet costs, but there are things they could do to improve the overall performance of the motor. I've ranted about his in multiple places.

3. Use a different technique than FAST at low speeds. There are various injection techniques that could potentially be used to get a better estimate at low speed than FAST can provide.

The GUI is a "fixed" demo. You'll notice you can't change any of the PWM or Scaling variables from my previous post, so no wonder it doesn't work for hobby motors.

*I'm thinking that current sense is probably going to be the hardest thing to get right with my custom hardware."

• Noise at high speed (high duty cycle) will be your main current sense issue. Voltage feedback at low speed is your other challenge.

"I've read people sampling all three phases but I couldn't really see the point in this, presumably things don't get much more balanced than a 3-ph motor? any real advantages to this? "

• FOC requires the knowledge of all three currents. How you get them is a design choice.

• If you use direct phase measurements it's easy, just take all three. Or take 2 and calculate 3rd. by sum = 0. You will always be able to read those 2 ph directly.
• If you use a single bus current measurement you have to use techniques to reconstruct all three phases.  You have to sample at multiple points in the PWM cycle and continuously move PWM modulation in accordance with your sampling to get enough values to reconstruct all three currents. This gets extremely challenging at very low and very high modulation
• If you use shunt currents this gets easier, and most try to just use two. The problem here is that at higher modulation you will always have cases where 1 of our 2 signals does not have a enough on-time for the lower FET/shunt to get a 2nd good reading, so you would fall into trying to reconstruct with a single leg shunt value.  The easiest way to allow these higher duty cycles is to use all three current legs and set up some logic to use the correct "best 2 of 3" at any given sample. This is built into InstaSPIN-FOC, see the final labs9 and 10

"Would be pointless with trapezoidal commutation but since foc is sinusoidal I am not sure?"

In Trapezoidal commutation you don't need the phase currents, you are getting the commutation/angle information from the off-leg, typically through a Bemf event.  You run current control through a total bus current scheme.

"Seems like the DRV8301 is one of the better gate drive ICs out at the moment - pretty much decided to use it. Are SO1 & SO2 usable for current sense"

Yes, our controlSUITE version of software for the DRV8301-HC-C2-KIT uses the on-DRV8301 PGAs only. For DRV8301 EVM we wanted to first insure we could get all three currents as best as possible so we wanted to match all three OPA.

With the BOOSTXL-DRV8301 we attempted to use the two on-chip PGAs and a single off-chip OPA. With good layout this worked out really well.

"Are the identified parameters only used to tune the PI loops?"

No, the parameters are used for

• FAST tracking; if the paramters are wrong or drift to much the estimates will be as well
• Control loop tuning: uses R, L. control frequency, MAX_HZ and all the V/I scaling to get things in per-unit