IPM Motor Simulation and FOC Software

[Ev8]

Cool thanks for that, not sure we’ve got the numbers 100% than as I’m pretty sure I’m getting more than that out of it, but still highlights my need to increase battery voltage

[Pete9008]

No problem, it was a good exercise to see whether the simulator is anywhere near reality.

Thanks for taking the measurements!

Revised code now on github.

Edit - Agree, pretty sure that we are under estimating the flux linkage on higher L motors (and probably also over estimating L by not allowing for core saturation in the model), both of these could pull the modelled power down.

[johu]

Finally test driving the Petesoft(tm)

First drive with default parameters and icrit=-70, fwmargin=3500 up to about 60 kph. Had slight oscillation on light throttle. No hard blows anymore so that's good!

Now took down vlimki to 1000 and icrit to -60. Less oscillation but suddenly strong regen:

Set fwmargin=2500 and went back, coasting down. At about 80 kph I got unwanted regen out of the blue

So going in the right direction but still not safely drivable.

Just noticed this one still has the delayed angle bug...

[Ev8]

I will try and redo the measurements to confirm the calculated values, I am still advancing syncof by about 2000points and using syncadv of 24 for additional freq linked offset as this does gain me a good amount of power, I know this isn’t the correct way to do things but it makes for a very drivable tune on 5.20r without field weakening until i get to test some new firmware

[Pete9008]

Well it's doing something vaguely sensible, that's a good start

Have you changed the code so that ifw is actually ifw now (not iMtpa)?

Just having a look through the plots now.

How did it feel generally on the first run (as that one looks like it was behaving best!)?

Edit - and is the range for Vlim still 0-100%?

[Pete9008]

I will try and redo the measurements to confirm the calculated values, I am still advancing syncof by about 2000points and using syncadv of 24 for additional freq linked offset as this does gain me a good amount of power, I know this isn’t the correct way to do things but it makes for a very drivable tune on 5.20r without field weakening until i get to test some new firmware

That would be a good confirmation, thanks. I couldn't find anything on how to convert the numbers so had to work it out from scratch so it's quite possibly wrong!

Re. the syncof, I wouldn't do that on the new code if you try it, that does need it set to the centre of the null. Although I suppose with two motors locked together there are all sorts of possible reasons why an offset might be of benefit

[Ev8]

Yes no problem every time I test a new version I go back to a centered syncof

[Pete9008]

Finally test driving the Petesoft(tm)

First drive with default parameters and icrit=-70, fwmargin=3500 up to about 60 kph. Had slight oscillation on light throttle. No hard blows anymore so that's good!
pete01.png

Now took down vlimki to 1000 and icrit to -60. Less oscillation but suddenly strong regen:
pete02.png

Set fwmargin=2500 and went back, coasting down. At about 80 kph I got unwanted regen out of the blue
pete03.png

So going in the right direction but still not safely drivable.

Just noticed this one still has the delayed angle bug...

The limiter doesn't look to be working quite right. Is your code up somewhere?

I'd be interested in simulating it with the negative Iq to see whether the sign change is confusing something (it shouldn't do but worth a look, so far my simulations have all been for pos Iq for acceleration).

Edit - fairly sure the voltage limiter isn't working right there, there are times when it kicks in when ud and uq are nowhere near the limits.

Edit2 - take that back, misreading the plot again.

[johu]

The software is pulled from your github experimental branch last night. Made no changes.

EDIT: cpu usage 45% - checked - aaah! - it's a debug build. Cool it still runs at reasonable performance.

[Pete9008]

Ok, I'll try simulating it with neg Iq later this evening, shouldn't affect anything but just got a nagging doubt. Could you post your param file?

Edit - how much difference does the debug build make?

[johu]

Release build is around 30% CPU usage

Param file attached

[Pete9008]

Had a look at it and it behaves exactly the same with positive and negative torque command so that's good. So I've reverted to testing with positive torque as that's what I'm used to looking at.

Running with your gains I can get it to go unstable:

Which looks a bit like the oscillation in your plots.

Tweaking the gains though gets to this:

It looks like the ud and uq controllers can respond badly to the throttle limiter coming off and saturate, when the limiter then comes out of saturation the uq and ud controllers also react badly and oscillate. I haven't had a look at the limiter gains yet to see if they can be improved on but that's the next thing to look at.

Edit - The above gains are the best I can get it. The I gain can be higher or lower without making big differences but lower P causes the low frequency oscillation above and higher gains cause high frequency oscillation on uq and ud. 1000 seems to be the sweet spot. Similarly the limiter gains about right too. Be very interesting to see if a higher P gain helps in real life too?

Edit2 - I think what is happening is that the ud controller isn't making the transition from neg to pos in time and it goes open loop. The P gain helps it to respond a little quicker so that it can catch iq in time. Actually, looking again, you can see it in the first plot. While ud is ramping from neg to pos id actually goes more negative (which makes matters worse) rather than more positive (as it does in the second plot). This is enough for the control loop to go open gain. Again, this is where the dq decompensation (or was is decomposition?) you mentioned should help, and allow the loop gains to be reduced, but I really don't want to go there! An alternative approach might be some kind of feed forward from the throttle to the control loops?

[Pete9008]

Think I know what's going on:
When coasting at high speed the uq margin is driving the limiter.
If the uq margin decreases it causes the limiter to increase
We're below icrit so this increases -Id towards icrit
This increases the amplitude of ud
Which takes up more of the available total amplitude
Which forces the uq controller limits to be reduced
Which further reduces the uq margin and so the cycle repeats

Essentially we have positive feedback when the limiter comes in if accelerating while coasting (slightly unusual test case). Difficult to simulate as the model doesn't include any hills! Were you going downhill at the time, it looks like it the plots but confirmation would be nice?

Should be fixable but too late to turn the PC back on now, will try to have a look tomorrow evening.

Edit - wondering if it could even make the margin go negative, not sure my code covers that eventuality, it might need a couple of extra checks in the margin calculation to catch it.

Edit2 - checked and code should handle negative margins ok.

Edit3 - definitely thinking the error limit on the controller should be changed to track with fwmargin. Wondering if the reduced slew rate could be harming stability in this case.

[Pete9008]

Wondering if the best (and simplest) way to fix this is to move the limit controller into the 1ms task. 1ms should allow time for the uq and ud controllers to settle before the next run of the limit controller reducing the positive feedback effect. The downside is that 1ms might be too slow for the limit controller to work effectively. Only way to find out is to try it; I'll try simulating it tonight unless you have a chance to test it before then.

Edit - what I'm going to try instead of the above is leave the limit controller in PwmGeneration::Run, but not run it every pass. It is then possible to have much finer control of how often it runs to get the optimum balance of response speed vs stability. It also locks the run ratio of the limit vs uq/ud controllers more accurately.

[johu]

I have had some success playing with the simulator and Prius parameters. I have put my code back in:

Code: Select all

         int fwPermille = fwController.Run(Param::GetInt(Param::amp));
         s32fp ifw = Param::Get(Param::manualifw) + ((fwOutMax - fwPermille) * Param::Get(Param::fwcurmax)) / fwOutMax;
         Param::SetFixed(Param::ifw, ifw);
         idMtpa = (fwPermille * idMtpa) / fwOutMax;
         dController.SetRef(idMtpa + ifw);

         s32fp limitedIq = (fwPermille * iqMtpa) / fwOutMax;
         qController.SetRef(limitedIq);

So now idMtpa is also limited

I set curkp=400 and curki=10000 and getting good stability:

One thing I noticed is the simulator doesn't seem to do throttle ramping. So if I go from 100 to 0 it does it right away and controllers don't like that. A typical ramp rate is 5%/10ms and 0.5%/10ms for regen. Can you put that in? Also would be nice if the Accel/Coast test did the same and could be run for some custom time (maybe from the top runtime field)

[Pete9008]

One thing I noticed is the simulator doesn't seem to do throttle ramping. So if I go from 100 to 0 it does it right away and controllers don't like that. A typical ramp rate is 5%/10ms and 0.5%/10ms for regen. Can you put that in? Also would be nice if the Accel/Coast test did the same and could be run for some custom time (maybe from the top runtime field)

It was a conscious decision, I'm treating it kind of like a safety margin, if the loops can cope with that then they should have a reasonable margin for stability. I'll add a check box to enable ramps though so that the effect can be seen.

Also going to add a road gradient field. The coasting downhill is a particularly nasty test case for high L motors above base freq and it needs to be possible to simulate it. The tendency to oscillate is going to be there for any scheme that has any form of limiter. I think the best fix is to allow time for the uq and ud loops to settle between limiter changes. I'm guessing that something between 5 and 20 runs of the uq/ud controllers for each run of the limiter will be about right.

[Ev8]

Wow in that power graph you can clearly see the different operation modes, that’s cool

[Pete9008]

Trouble is it shouldn't look quite like that

There should be constant torque region followed by a constant power region (the power should have stayed up at 15kW). Johannes, what did the operating point do? Doesnt look like the limiter followed the right path causing the torque to drop off too quickly.

[Pete9008]

Throttle ramps have been added to the simulator. Not sure the ramps are going to have quite the impact that's hoped, they still disturb the controllers bit instead of getting one big disturbance you get lots of smaller ones. It does help the operating point plot make more sense though

I have also added a road gradient so that the accelerating while coasting can be simulated and have used it to try and simulate the problem mentioned above - but I can't create it. Think the relative magnitudes of uq and ud must be minimising its effect?

While looking at this though I have come back round to needing separate ifw and throttle limiting controllers. The existing scheme works well for Id but isn't doing the right thing for Iq on high L motors. So it looks like two controllers again, the FW one moving Id towards Icrit and the throttle limiter moving Iq towards zero.

New simulator code is on github.

[johu]

Cool, will check it out.
Have been playing with the simulator pretty much all day. Not quite sure it represents reality quite yet, for example the Leaf motor (provided the parameters are right) jumps into FW way to early, around 2000 rpm or so. In general it seems harder to get the simulated controller to play nice than it is in the car. Will post more once I have some harder data on the differences.
EDIT: in the car attenuation starts around 4000 rpm and FW at 7000 rpm

I also made an experiment in determining the derate-factor via a simple IIR filter on amplitude margin:

Code: Select all

         int amplitudeErr = (FOC::GetMaximumModulationIndex() - Param::GetInt(Param::fwmargin)) - Param::GetInt(Param::amp);
         amplitudeErr = MIN(fwOutMax, amplitudeErr);
         amplitudeErr = MAX(fwOutMax / 10, amplitudeErr);
         amplitudeErrFiltered = IIRFILTER(amplitudeErrFiltered, 100 * amplitudeErr, Param::GetInt(Param::fwkp));
         int derateFactor = amplitudeErrFiltered / 100;

the factor 100 is there to keep the filter from underflowing. I borrowed some left over parameter for filter constant A constant of 10 makes it look nice. That way the slew rate is more controlled but it still reacts faster then the spooling up of an integrator.

[johu]

And here comes the real world test and I'd say: problem solved

Uphill acceleration and some regen, all nice and controlled, no oscillations or anything:

Downhill with light throttle, here we loose it a little bit at 100 kph:

Unfortunately that was the last run for today because the drive shaft came loose Gotta fix that tomorrow.

I also disabled syncadv for that run, I don't think it makes much difference. This is also the single ADC version.
Will test it in Touran next and then probably draft another release as it's again an improvement over the last version.

EDIT: gotta say even though the simulator might not quite match up yet it's still a helpful guide. Keep it coming
EDIT2: also interesting to see that uq no longer randomly changed sign

[Pete9008]

Have been playing with the simulator pretty much all day. Not quite sure it represents reality quite yet, for example the Leaf motor (provided the parameters are right) jumps into FW way to early, around 2000 rpm or so. In general it seems harder to get the simulated controller to play nice than it is in the car. Will post more once I have some harder data on the differences.
EDIT: in the car attenuation starts around 4000 rpm and FW at 7000 rpm

Did you try different values for flux linkage, that changes the base freq quite a bit. Just to check, you're not mistaking the transition from constant torque to constant power as being the same as base freq are you?

I also made an experiment in determining the derate-factor via a simple IIR filter on amplitude margin:

Code: Select all

         int amplitudeErr = (FOC::GetMaximumModulationIndex() - Param::GetInt(Param::fwmargin)) - Param::GetInt(Param::amp);
         amplitudeErr = MIN(fwOutMax, amplitudeErr);
         amplitudeErr = MAX(fwOutMax / 10, amplitudeErr);
         amplitudeErrFiltered = IIRFILTER(amplitudeErrFiltered, 100 * amplitudeErr, Param::GetInt(Param::fwkp));
         int derateFactor = amplitudeErrFiltered / 100;

the factor 100 is there to keep the filter from underflowing. I borrowed some left over parameter for filter constant A constant of 10 makes it look nice. That way the slew rate is more controlled but it still reacts faster then the spooling up of an integrator.

Interesting idea, keen to see the results.

Just pushed another change, fwmargin wasn't updating from the gui properly (hadn't realised that a param SetInt doesn't trigger an update!).

My experimental branch is still the best I can do as far as a smooth transition into constant power. I'm sure two loops should be better above base freq though but I can't seem to get them to work at the moment

[Pete9008]

Not sure there is a lot more I can do on the simulator till we have better data so it will be going on the back burner for now (unless bug fixes are needed - highly likely!). It will be interesting to see how everyone gets on with it.

The goal was to a) better understand motors and b) see whether the FOC/FW issues could be fixed. I'm happy with where we are with a) and convinced we are going to get to b) so job done for now

[johu]

Did you try different values for flux linkage, that changes the base freq quite a bit. Just to check, you're not mistaking the transition from constant torque to constant power as being the same as base freq are you?

Not sure, but I did observe the attenuation coming in a lot later on the actual motor. Increasing flux linkage makes it come in even earlier. Never tried values below 90 though.

Interesting idea, keen to see the results.

Well see here: viewtopic.php?p=47848#p47848
Code also on github (master)

Just pushed another change, fwmargin wasn't updating from the gui properly (hadn't realised that a param SetInt doesn't trigger an update!).

ah yes I thought it wasn't updating but didn't spot the mistake

[Romale]

And here comes the real world test and I'd say: problem solved ...

Ocurlim 100 isn't this too low a value?
or is it something else now, not the maximum current of 100 amps?
earlier I remember there were 900 and 1000 and even 5000 for some people