IPM Motor Simulation and FOC Software

[Ev8]

Happy to test anything new. Pete feel free to pm me a build if you don’t want to go public with it.

[Ev8]

Sorry just realised that doesnt sound very open source spirited, just saying I’m happy to beta test dev code

[Pete9008]

No problem, understood what you meant. Also to be clear I fully intend to release all the code.

Mixed feelings, very keen to know whether it works in real life but I have made quite a few changes.

In particular allowing Vq to go negative allows regen to continue decelerate below zero, i.e. to start to go backwards No idea whether there is anything in the higher layers of the code that would catch and stop this behaviour (@johu ?) but it's not a nice thing to have lurking in the code.

I still need to run the final code though a few simulation on low L motors just to make sure none of the high L changes have broken anything and then need to check that the control loop is still running quickly enough (should be, haven't added that much). May send you something once that's done.

[Pete9008]

Worth putting a reference to this post here too viewtopic.php?p=47502#p47502

[SciroccoEV]

In particular allowing Vq to go negative allows regen to continue decelerate below zero, i.e. to start to go backwards

The stock Leaf inverters will do just that!

If you want regen, you send negative torque requests. If you haven't set your VCU up to stop requesting negative torque below a certain speed, then it will come to a stop and then run backwards.

[Pete9008]

As someone who was taught to feather the brakes while coming to a stop that would be quite alarming

[Pete9008]

Nice one! Will try that next. Today I tested the current limit posted elsewhere (here?). Acceleration is starting to be rather good but then I got unwanted regen again (where ud maxes out into the positive):

grafik.png

This is in Audi, i.e. Prius high inductance motor

That's looking good

Fairly sure the latest changes will sort the unwanted regen, they also seem to give a pretty good increase in toque too. Let me know if you need any details.

[mjc506]

Awesome work

I personally would have no problems treating the inverter/motor as a torque engine, but probably not ideal for the normal OI boards with throttle pots and all OI does have a 'min braking speed' (I forget the parameter name) though which cuts regen below a certain speed.

[RetroZero]

Well done Pete and co! I can't wait to get my hands back onto my Prius build and do some testing too. A huge effort and what seems to be an awesome solution for the trusty Toyota builds (ps, most of this is over the top for my pea brain )

[johu]

If you commit your latest changes I can try them out, either integrate them in my build or just straight build a binary from your code. Will see.

Regarding regen that is governed by higher level code. It is ramped down towards 0 at regenrampstr and its direction is always synced with the current motor direction. So rolling backwards in forward gear will result in a positive torque request and vice versa

[Pete9008]

Well here's an interesting complication!

Just ran the simulation on a low L motor and it seems the FW controllers gains are the wrong way round Now I did reverse it while rewriting the controllers as had reversed their sense and convinced myself I'd just got confused while doing it - looks like I hadn't.

It turns out that if you are running a high L motor with Mtpa it is quite possible for the Mtpa to request more -Id current than the critical current of the motor. This has the interesting side effects because once you are past the critical point the effect of Id in terms of compensating the bemf is reversed

Going to have to have a bit of a think about how to address this. If we had an accurate measurement of the critical current then could possibly just check where the operating point was with respect to it - but since we are guessing that's not going to work.

Edit - @johu - do I remember you experiencing some issues with the phase of Id reversing?

Edit2 - this is really quite nasty, the effect of Id for FW is reversed depending on which side of the critical current you are, and depending on the throttle and Mtpa settings you can end up on either side of it. Going to have to take a break from this and have a ponder. Anyone got any ideas?

Edit3 - Not so sure about this now, the FW controller seems fairly broken so need to fix it first then review the gain polarities.

Edit4 - Found the problems, the PI controller anti windup doesn't like negative gains (fixed) but there is also an integer arithmetic rounding error that I'm not too sure how to sort out yet. The gains do seem to be reversed though so it looks like the issue for controlling FW on high L motors is real. Probably be Friday before I can look at it again.

[Pete9008]

@johu, is there any chance that you could do a test next time you are working on the A2?

The maths says that when -Id that exceeds critical current it will cause the motor voltage to start increasing again. This is really non intuitive for me and it would be great to have a physical confirmation that it is a real effect. Could you capture a few plots with Mtpa, fw and regen disabled but with manual Id set, one at 0A, one at -45A (critical current for the Prius?) And one at a higher level (-80-90A would be nice if you are comfortable going that high). In each case we need to see the uq and ud plots while coasting (doesn't need to be that fast, just enough to see uq clearly in the 0A plot and how it changes in the others). If the maths is right the 0A and 90A plots should be similar and the 45A plot a lot lower in amplitude (0v at the critical current).

Edit - added disabled regen in the above.

[Pete9008]

Might be a relatively easy fix that is still reasonably robust.

The problem with the existing FW controller is that if the voltage is too high it adds -Id. If it finds itself on the wrong side if Icrit this will actually increase the voltage so causing the controller to run away. If you had a precise value for Icrit this could be catered for but since it's exact position isn't know and will change with motor current there is still plenty of scope for controller runaway.

I think the solution is instead of adding -Id move the operating point towards Icrit (the same approach which currently seems to work well for throttle limiting in both high and low L cases). There is still scope for non ideal behaviour if the operating point gets close to an imperfect Icrit position but the control loops shouldnt suffer from run away.

Hopefully have a go at this tomorrow.

Edit - been mulling this over while doing other things and it has occurred to me that with the above the FW and voltage limit controller outputs could both be summed and fed to the existing block that moves the operating point towards Icrit. It then occurred to me that the two controllers would then be doing almost exactly the same thing (except the FW only watches the uq margin while the voltage limiter watches both). This would mean that the FW controller could be omitted and the voltage limit controller left to do both tasks

The slightly annoying thing is that while working on it yesterday I disabled the voltage limit controller while concentrating on the FW one that wasn't working. If I had left it turned on I think it would have been working fine on low L motors too!

Edit2 - thinking more the two controllers are not quite the same, the fw controller should just move Id towards Icrit, the voltage limit should move both Iq and Id. Combining the two into one will cause a slight reduction in power in fw. Can't decide whether this is enough to justify the complexity of the extra controller or whether there is a way for a single controller to neatly do both without the compromise. Hopefully try a few things in the morning to see what works.

Edit3 - given that for a low L motor Icrit is likely to be more than 500A Id will change faster than Iq when moving towards Icrit. Also given that Iq will probably be limited by the increasing Id anyway combining the controllers shouldn't be that much of a performance penalty in fw. Will test tomorrow.

[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?

[johu]

I have made that log you said, just coasting down a hill with regen and FW disabled but various fixed FW currents programmed. At the higher currents I started with low FW current and only switched in the higher value once I was rolling.

The results are rather surprising. Lets look at the 50 Hz value for uq
- ifw=0 -> -7322
- ifw=-20 -> -7352
- ifw=-45 -> -4941
- ifw=-90 -> -11

So at ifw=-90 it looks like we have completely eliminated the rotor field! Even at 100 Hz hardly any voltage is needed to keep iq=0. Then as soon as ifw is lowered to -9A we need uq=-17259 digits to stay at iq=0A. Also once again we see that there is no frequency dependence of ud but when driving with MTPA suddenly there is. syncadv=7 at all times
EDIT: at -90A ifw the inverter tripped out a number of times so you'll see some strange data
EDIT2: while off-throttle regen was disabled brake pedal regen was still enabled. So at the end of each run you see positive iq. And then ud suddenly changes sign and has much higher magnitude. So the two are very closely coupled. That's probably what "dq decoupling" is useful for.

Also did another test drive on a level road. It drives fine at full throttle (although not mighty powerful) but starts doing weird oscillations when trying to maintain speed

[Pete9008]

Thanks for doing that, it looks like it ties in well with the maths

It does suggest that either the motor Ld is lower than we thought, or the flux linkage is higher. The values we were working on would have suppressed the field at 45A not 90A. Some of it could be due to core saturation but i doubt that much (especially on only 90A of Id). Maybe 150mWeber and 2mH plus a bit of saturation.

If you are comfortable going a little higher it would be really interesting to see if the voltage increases again with more than 90A?

Could the oscillation be when the Id goes above 90A and the field start coming back? There would be some odd effects when the current crosses Icrit.

Edit - what's dq decoupling?

If its started tripping then going higher would be a bad idea. Wonder if the tripping is because the loops don't like the phase reversal on uq?

[johu]

Could the oscillation be when the Id goes above 90A and the field start coming back? There would be some odd effects when the current crosses Icrit.

Never goes above -90A so I don't think that's it. Seems to get to the point where ud changes sign. The car felt like the plot looks. Accelerate, decelerate.

Edit - what's dq decoupling?

It a feed forward method to anticipate the coupling of d and q, it's in one of Dave Wilson videos, don't remember which one.

If its started tripping then going higher would be a bad idea. Wonder if the tripping is because the loops don't like the phase reversal on uq?

No phase reversal, it randomly tripped while just rolling. Not sure why.

[Pete9008]

Can't think of a good reason for the oscillation, will keep thinking about it though.

I can see the benefit of the dq compensation, with a higher L motor the voltages really do seem to move around a lot. You would need a pretty good model of the motor to get it to work though!

I'll have a look at the spreadsheet when the PC is on

[johu]

Yes, not too excited about anything that needs a precise motor model either

Just had a think about combining idMtpa and iFW. How about using the maximum (minimum, technically) instead of the sum?

Will be amongst things I try tomorrow

EDIT: moved closer to your limiter implementation

Code: Select all

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

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

fwController goes from 1000 to 0 as max amplitude is approached. Might indeed make sense to control qlimit-uq instead, hmm

EDIT2: I think I now understood your RunFW function. Could also be achieved without altering the PI class by calling PreloadIntegrator:

Code: Select all

if (idMtpa < ifw) //MTPA current less means greater magnitude!
  fwController.PreloadIntegrator(idMtpa);

EDIT3: with the permille semantics this no longer works though...

EDIT10000:
Also thought about this characteristic current and what it means more intuitively. It is the PURE d-current that completely eliminates the rotor field. So when combined with q-current d-current may be higher than the characteristic current to create additional reluctance torque. Only once we removed all q-current then d-current should be below the characteristic current.
I think above implementation achieves this quite well when fwcurmax is set to characteristic current. When the amplitude has reached its target only pure d current is left and all q current completely suppressed.

[Pete9008]

Thought about using the min but was worried that it could introduce oscillations as the effective control passed from one controller to the other. Summing keeps both controllers running closed loop for more of the time. See my edits above for other thoughts on the controllers.

The moving towards Icrit looks common to both implementations, fairly sure it it the way to go. Need to bear in mind that you might be approaching it from either side though.

RunFW does slightly more but that is the idea and would do 90% of it without the extra function. Btw, watch out for the anti windup, its not happy with negative gains.

You've got it with the critical current Bear in mind though that it is the current that gives the minimum uq, moving away from it, in either + or -Id directions, will cause the magnitude of uq to increase (but with a phase change depending on direction).

Fairly sure I know how to make my code work now. I'll try it tomorrow and if it seems ok create an 'experimental' branch on github and push the changes to it.

[Pete9008]

Couldn't resist giving Wednesdays code a quick run with just the voltage limiter controller enabled (FW controller disabled), before starting the changes ,to see whether the idea worked and it looks very promising

This is the same code that runs the high L motor but running a low L motor.

First a plot (taken from an earlier post) showing the old code:

And a plot showing the same run but with the new controller:

And a run showing the coast still works fine too:

Going to call that a sucess!

Couple of points worth noting. First the limiter comes in a little later (because it aims for a lower margin than the FW controller) and second the terminal speed is slightly lower. This might be due to a change in the model (there was a bug with the flux linkage updating in the model so not sure whether the motor was actually using the shown 90mW or 150mW in the first plot) or whether this is due to the slight performance reduction inherant in just using the limiter (mentioned in an earlier post). I'm going to add an Iq/Id polar plot to the simulator to make it easier to see what the operating point is doing during the simulation to see which it is.

[Pete9008]

And one more plot that has accelerated to a higher speed (~7krpm) which shows detail of what the currents do at the point where it changes from accelerating to coast:

Id is around -333A while accelerating and changes to -140A when coasting to maintain control of the bemf (bemf of 250V reduced to the max inverter voltage of 190V). There is a bit of oscillation during the transition suggesting there is still a bit of work to do on the controller gains but overall not too bad

[johu]

Also been out driving with yesterdays change

Drives well but doesn't like coasting

And doesn't like low throttle. Full throttle and regen work fine, no unwanted regen.

But unwanted acceleration. This seems to be clearly down to uq being limited to the negative. Don't quite understand why it wants to go negative.

I reached 120 kph on that one

So I should allow full swing of uq once above a certain speed. That will still suppress low speed juddering but won't cause issues in FW.

At one point I set fwcurmax to -90A and it went into unwanted acceleration really fast. Maybe -80A is still too much I don't know.

So in general with this setup it was not possible to coast once above a certain speed. Maybe it's the MIN() function, not sure.

Very keen to test your code once pushed.

[johu]

Wow, that was quite something! Flashed that latest firmware on Touran with the amplitude limit revised (not that it makes a difference on that motor, see for yourself)

Code: Select all

      if (frqFiltered < FP_FROMINT(30))
         qController.SetMinMaxY(dir < 0 ? -qlimit : 0, dir > 0 ? qlimit : 0);
      else
         qController.SetMinMaxY(-qlimit, qlimit);

First, a subtle try with throtcur tuned down to 3 and ocurlim to 500 in to be able to kill off unwanted acceleration with the current limit:

At around 300 Hz you see FW come in slowly

Then with the normal parameters downhill and up to 500 Hz. Performance is spectacular for my standards, no problems transitioning to regen and out of regen, no controller saturation. Just wow

Admittedly current waveforms don't look pretty but at least they work.

[Pete9008]

Looking good

Sorry, I've had a bit of a slow start to the morning. Got thoroughly fed up with resizing all the simulator windows every time I restarted it do decided to make it save and restore the window states and geometries. Should have only been a 10min job but took most or an hour! Working now though.

Removed the FW controller and it all looks good. I've also figured out how to make the one controller give the best of both worlds by making use of the remaining margin on the q and d controllers to change the trajectory of the operating point slightly so going to try that now.

Edit - that code on the uq limit dependant on speed is a good idea, I'll include that!