IPM Motor Simulation and FOC Software

[Pete9008]

@johu - can either IIRFILTER of IIRFILTERF be used on s32fp types or is it just in and floats?

[Pete9008]

Tried the improved scheme. First plot with the limiter just aiming the trajectory at Icrit:

And next one that tried to adjust the trajectory to limit the amount of Iq reduced if there is plenty of margin on ud:

The second one, which should be slightly better, is slightly worse. What is happening is that the mod causes a bit of instability in the limiter control loop (seen in the disturbances on the Id and Iq traces) and this instability does more harm than the improved trajectory does good. Now this is for Icrit of 550A, it's quite possible that for motors with lower Icrit (but still outside the current limit circle) it may offer more benefits but I don't think it is worth it so am going to bin it for now.

[Pete9008]

Reasonably happy with the way the code is running in the simulator now so have just pushed it onto github.

It is in the "experimental" branch which is named that because:

• It has only been run in the simulator.
• It has NOT been tested on real hardware.
• It is a significant change from the previous version in the way it does field weakening.
• It reuses the redundant fwcurmax parameter index for icrit, the values are very different and so this WILL need manually changing.
• There are a few other changes in the param file that should be reviewed.
• If using this code I suggest that you review the source code and only try using it if you are comfortable with the changes.
• The controllers seem pretty stable in simulation but that doesn't mean that they will be in real life, be careful!

The code includes the SD card logging features but unless used with the ESP32 they should be inactive.

The new parameter icrit is the critical current for the motor. It is equal to flux linkage/Ld. For a high inductance motor set it to around -75A, for a low inductance motor set it to around -550A.

The fwki and fwkp parameters are redundant but haven't been removed yet.

There are two param_prj files in the include folder that give the controller gains that I have found to work in simulation for low L and high L motors.

If the simulation is anywhere close to reality this should provide improvements for both low and high L motors. The biggest gains are hopefully on high L motors at higher speeds.

Fingers crossed!

Edit - @johu - forgot to put the uq limit change with frq code in on this.

Edit2 - just noticed that the ifw parameter is not set to a sensible value in terms of logging, doesn't affect operation but just makes plotting a bit pointless. It is actually plotting idMtpa
.
Edit3 - there is an error in the param_prj_highL file, this:

Code: Select all

PARAM_ENTRY(CAT_MOTOR,   ld,          "mH",      0,      1000,   3,      144 ) \

should read this:

Code: Select all

PARAM_ENTRY(CAT_MOTOR,   icrit,       "A",       -1000,  0,      -75,  144 ) \

[Pete9008]

Just noticed in the latest firmware that ProcessCurrents() which calls the Park/Clarke transforms is called before SetAngle(). Is this right, what am I missing?

@johi - did you have a chance to look at this? I would have expected ProcessCurrents() to be called after SetAngle() as otherwise it is using whatever value was last calculated for sin and cos rather than the up to date values when it does the Park/Clarke.

I've just simulated calling is both before and after SetAngle() and it does make around 10% difference to the amplitude of iq and about 1% difference to id but apart from that virtually nothing in the simulation changes, which is not what I was expecting at all!

Got a feeling I'm missing something obvious just not sure what?

Edit - I was looking at the wrong area of the plot! I'd let it accelerate to a high speed thinking that higher speeds would show the difference more. They do but I'd actually let it accelerate beyond the point where -Id maxed out so it wasn't representative. Moving ProcessCurrents to after SetAngle pushes the frequency at which the controller thinks it needs to start adding -Id up by maybe 5% at 3000rpm. On motors with a higher base speed the difference would be a bit bigger. Not a huge difference but probably worth having.

[johu]

@johi - did you have a chance to look at this? I would have expected ProcessCurrents() to be called after SetAngle() as otherwise it is using whatever value was last calculated for sin and cos rather than the up to date values when it does the Park/Clarke.

Oh, that's unintended. Will fix!

EDIT: I'm wondering why it still worked rather well at least with the Leaf motor. What implications does it have for syncadv? I have now moved the position functions to ProcessCurrents() so we still take advantage of midpoint current reading but of course work with a recent angle.

[Pete9008]

EDIT: I'm wondering why it still worked rather well at least with the Leaf motor. What implications does it have for syncadv?

On the simulations I'm amazed by how little effect it seemed to have (to the degree I was sure I was missing something). It shouln't have an impact on syncadv as that is compensating for the pwm load latency.

Edit - One other thing I noticed was that stability seemed a bit better before moving ProcessCurrents. Think I've got most of it back by tweaking gains but not sure it's quite as good as it was?

I have now moved the position functions to ProcessCurrents() so we still take advantage of midpoint current reading but of course work with a recent angle.

Not sure I understand?

[Pete9008]

More plots!

I've now added the polar operating point plot for Iq Id. It's not as nice as I'd like as the QT chart doesn't seem to be able to put the axis in the center but it will do. It shows the Is (max current circle) and the trace shows how Id and Iq moved during the run (the start of the trace is at the origin).

I've had to run the plots 10ms at a time for the first sec while ramping the throttle to get a nice trace (the throttle ramps should do this with the real firmware).

First a low L motor:

You can see the current following the Mtpa curve up to the Is limit and then moving towards Icrit as the voltage limiting kicks in. Once Id hits the neg limit it then starts ramping the Iq down towards zero. I'm not too sure why it isnt following the circumference of the circle as it moves towards Icrit but I think it's because I dont recalculate the max Iq following the change to Id (Iq = root(is*is - iq*iq) ).

Next what happens if you push the speed so high that there isn't enough Id to keep the voltages under control:

You can see that the currents start circling round Icrit when the controllers go open loop. This is at around 11krpm (not a good idea to get to this point in real life!).

Next a high L motor:

This time Icrit is 75A so once the limiter comes in it starts moving the operating point almost directly down. On different motors this could move to the left or right too dependant on how Mtpa's Id and Icrit match.

If the icrit parameter is badly guessed then this is what you get (motor model icrit at -50A, controller parameter at -75A):

You can see the controller aiming for what it thinks is Icrit but actually ending up circling the real Icrit.

All interesting stuff - just hope it's somewhere close to reality!

[johu]

Just test drove A2 with the angle set before the transforms and it was terrible. Totally shook the car apart. I wonder if calling the ISR twice per PWM cycle has anything to do with the sketchy behaviour with the Prius system. Compared to the Leaf system it has a life of its own. I never know
- Is it the software (and which part of it)?
- Is the inverter doing something "intelligent"
- Is it the high inductance motor?

Here's the revised code in ProcessCurrents()

Code: Select all

   s32fp il1 = GetCurrent(AnaIn::il1, ilofs[0], Param::Get(Param::il1gain));
   s32fp il2 = GetCurrent(AnaIn::il2, ilofs[1], Param::Get(Param::il2gain));

   Encoder::UpdateRotorAngle(0);
   CalcNextAngleSync();
   FOC::SetAngle(angle);

   if ((Param::GetInt(Param::pinswap) & SWAP_CURRENTS) > 0)
      FOC::ParkClarke(il2, il1);
   else
      FOC::ParkClarke(il1, il2);

[Pete9008]

Just test drove A2 with the angle set before the transforms and it was terrible. Totally shook the car apart. I wonder if calling the ISR twice per PWM cycle has anything to do with the sketchy behaviour with the Prius system. Compared to the Leaf system it has a life of its own. I never know
- Is it the software (and which part of it)?
- Is the inverter doing something "intelligent"
- Is it the high inductance motor?

Here's the revised code in ProcessCurrents()

Code: Select all

   s32fp il1 = GetCurrent(AnaIn::il1, ilofs[0], Param::Get(Param::il1gain));
   s32fp il2 = GetCurrent(AnaIn::il2, ilofs[1], Param::Get(Param::il2gain));

   Encoder::UpdateRotorAngle(0);
   CalcNextAngleSync();
   FOC::SetAngle(angle);

   if ((Param::GetInt(Param::pinswap) & SWAP_CURRENTS) > 0)
      FOC::ParkClarke(il2, il1);
   else
      FOC::ParkClarke(il1, il2);

You would expect it to make quite a difference so it's not surprising. Was very surprised by how little difference it seemed to make in simulation

Just added an edit above while you were typing this, the stability did seem to drop after the edit, managed to get most back by tuning gains (dropped kp I think, you can see it in the latest plots) but not sure I recovered all the stability though.

Edit - Increased kp, 600 to 1000

This was how I did it in PwmGeneration::Run, do you see any problem with it that would explain the relatively small change in simulation following the change?

Code: Select all

      //ProcessCurrents(id, iq);
      Encoder::UpdateRotorAngle(dir);

      if (frq > FP_FROMINT(5))
      {
         dir = Encoder::GetRotorDirection();
      }

      CalcNextAngleSync(dir);
      FOC::SetAngle(angle);

      ProcessCurrents(id, iq);

Edit - Can't think why calling the ISR twice would be a problem

[johu]

Yes it is almost the same the way you did it. Just currents are read a few us later (after UpdateRotorAngle() and CalcNextAngle())

So using an outdated angle value makes things more stable?

Calling the ISR twice means on "even" calls you're reading currents while all PWM are (likely) off and on the "odd" calls you're reading currents while all PWMs are likely on, in the center of the period. It's not uncommon to do that, was just wondering if it comes with an extra challenge.

[Pete9008]

Are the currents actually read or are they pulled out of the streamed DMA data. Btw, did you see the post regarding current measurement in the logger thread?

Odd isn't it?

That is an excellent point and one which I hadn't considered at all. It definitely wouldn't help stability and would easily make it a fair bit worse. Its also something that the simulator doesn't reproduce! Would expect it to be worse on low L motors though.

[johu]

Are the currents actually read or are they pulled out of the streamed DMA data. Btw, did you see the post regarding current measurement in the logger thread?

Odd isn't it?

That is an excellent point and one which I hadn't considered at all. It definitely wouldn't help stability and would easily make it a fair bit worse. Its also something that the simulator doesn't reproduce! Would expect it to be worse on low L motors though.

They are pulled from the DMA data, but the earlier done the closer to the middle.
Are you talking about your comment on current ripple? Those 120A were what I calculated and deemed implausible but it might well be. I think the reason it works is although the ADC is not synchronized it will only drift off 4us maximum (half of one conversion round) plus it takes the median of the last 3 values.

EDIT: I should add: I run the Leaf motor at 8.8 kHz (so less ripple) and consistent ISR calls at PWM center while I run the Prius inverter at 4.4 kHz because it doesn't like being run faster.
I could try skipping the calls at period start and only call UpdateAngle() to keep resolver excitation running.

@johu - can either IIRFILTER of IIRFILTERF be used on s32fp types or is it just in and floats?

just discovered that. IIRFILTER is used for integer types (including fixed point) and IIRFILTERF is used for floats

[Pete9008]

Ahh, ok, if you are sampling that quickly it should be fine. Can't see why ripples that high won't happen though (I'm fairly comfortable with my inductance measurement on the Outlander motor). Still need to figure out what is going on on that current waveform. Tempted to see if ADC2 can be used triggered of the PWM reload to do synchronised sampling?

Thanks, couldn't remember whether the >> divide works on negative numbers, does it sign extend it while doing the shift on the arm? That reminds me there are a couple of divide by 8192 that I meant to change to shifts but forgot.

Edit - your edit looks worth a try

[mjc506]

Sorry, I'm being thick and can't build. Is the latest sim code up on github yet?

[Pete9008]

Sorry should have been a bit clearer, I haven't pushed the latest simulator code yet (just the OpenInverter firmware). The simulator code could do with a little bit of tidying up, which should happen over the weekend, and then Ill update github.

@johu, are you ok with the changes I made to the param file? If we can standardise that then the simulator will work with both your and my code builds.

[mjc506]

Told you I was being thick Thanks

[johu]

Yes we do have ADC2

Those are injected samples in the 10ms task stimulated with a 10 Hz sine wave with 90° phase shift

[Pete9008]

Fantastic, that opens up a whole load of new possibilities and should make a big difference to the stability of the current measurements

Edit - have you had a chance to look at the new controllers yet?

[johu]

Now I'm thinking how to best make use of it.
a) "injected simultaneous mode"
Have ADC1 first convert sin-signal and ADC2 cos-signal (at the very same time) and next in sequence il1 and il2
That way there is virtually no offset between currents and angle sampling. Downside: no averaging or median takes place. That said no averaging is done on the resolver anyway and it isn't too noisy. Other downside: currents are not sampled at mid-PWM
b) leave resolver sampling as it is and trigger injected conversion of il1 and il2 on ADC2 at mid-PWM
c) Have ADC2 free running with DMA like right now, just not disturbed by sampling the other 6 signals. Not that trivial as ADC2 doesn't have its own DMA channel but uses the upper 16 bit of ADC_DR(ADC1)

[Pete9008]

Id do b) but using a burst of regular conversions (so that you can have a longer sequence) alternating between i1 and i2, so i1, i2, i1, i2, maybe even a total of 8, and then average the measurements. Not true simultaneous but a lot better than it is at the moment, synchronised to the pwm and less likely to break anything else while making the changes!

[johu]

Fantastic, that opens up a whole load of new possibilities and should make a big difference to the stability of the current measurements

Edit - have you had a chance to look at the new controllers yet?

Just looked at it now, don't understand yet what is going on but might just dump it on Audi.

[Pete9008]

It basically moves the operating point towards the critical current point when amplitude limiting is needed. If the critical current is set correctly it then does the right thing regardless of motor inductance (so its important that icrit is closish to the right value).

If you think about the voltage elipses they are centred on icrit so to reduce amplitude you always need to move closer to that point which is why on a high L motor (edit - low critical current motor might be more accurate here!) increasing -Id can be exactly the wrong thing to do.

Edit - on low L motors the operating pointvtrajectory that this produces isn't perfect in terms of absolute performance but its close enough that I doubt the difference would be noticeable.

The best way to think of it is the controller sets how much amplitude reduction is needed and then the iq and id scaling algorithm uses this to determine how far to move towards icrit. Trying to make the fw or voltage limit controllers control -Id directly doesn't work in all cases because of the phase reversal on high L motors.

[johu]

Ok, like said will see what Prius motor has to say.

More news from ADC2
Noise level:

Again the least noisiest way seems to be discarding the first sample. Averaging of two samples didn't reduce noise. I think the spikes are from the wifi module of my rather old test board. Newer ones have better filtering.

And a nice sine wave (20 Hz)

In comparison noise level of 3-median ADC sampling:

I'd say it's about half the noise

[Pete9008]

The typical noise level on that last plot looks pretty good, what are the big negative spikes though?

Interesting that averaging doesn't reduce it, that suggests that its not true random noise. Also interested to know what causes the first sample noise, I've used the adcs in these chips in that mode before, in fairly high precision measurements, without seeing the effect.

Which sampling scheme are you going with?

Edit - if set up right Im hoping the A2 motor will like it a lot The only bit I'm slightly worried about is controller stability

[johu]

The typical noise level on that last plot looks pretty good, what are the big negative spikes though?

Definitely wifi module.

Here is a chart with it removed and not even discarding the first sample: