IPM Motor Simulation and FOC Software

[johu]

That is simply awesome that now this can be modeled instead of putting yourself, your car (driveshafts) or even someone else at danger. Your probably right about the shortcoming of the current FW controller. Could you try this variant: https://github.com/jsphuebner/stm32-sin ... -control-2

in foc.cpp it has a modified MTPA that includes the regulated FW current right away. It does (almost) exactly as you say, trying to keep iq amplitude from maxing out. Of course this only works if measured currents and angle match together, otherwise it can cause unwanted acceleration as it drives current into the motor that is no longer proportional to throttle input.

BTW the speed limiter is not part of the core control loop but it's simply one of the deraters called in vehiclecontrol.cpp

[Pete9008]

That is simply awesome that now this can be modeled instead of putting yourself, your car (driveshafts) or even someone else at danger. Your probably right about the shortcoming of the current FW controller. Could you try this variant: https://github.com/jsphuebner/stm32-sin ... -control-2

in foc.cpp it has a modified MTPA that includes the regulated FW current right away. It does (almost) exactly as you say, trying to keep iq amplitude from maxing out. Of course this only works if measured currents and angle match together, otherwise it can cause unwanted acceleration as it drives current into the motor that is no longer proportional to throttle input.

BTW the speed limiter is not part of the core control loop but it's simply one of the deraters called in vehiclecontrol.cpp

Yep, quite pleased with that result!

Learnt the hard way that sometimes it's worth spending a bit of time on a simulator as, even if it's not perfect, it can provide good insights into what might be happening. Not sure I would have ever figured out how the code worked without being able to single step though an set breakpoints!

I've had a look at your code and it does virtually the same as mine (except yours is more elegantly coded!). The only different is you call the FWcontroller from the setTorquePercent function while I still have it in the main loop (I prefer the later as it is too easy to change how often setTorquePercent is called without realising the implication). Unfortunately I can't easily simulate it yet as I hacked pwmgeneration-foc.cpp around quite a lot while getting things working, also I only call setTorquePercent when something changes in the GUI (could that be causing any problems in the simulator - had a look and it seemed OK but I'm wondering now).

[Pete9008]

Not too sure what the best thing to do on this is now, options are:

1) Tidy up the code so that it can be used with a standard OpenInverter checkout.
2) Have another look at the MTPA torque calculations. The equations seem to give torque values for Id currents that I just don't believe meaning the simulation is probably heavily overestimating reluctance torque.
3) Just release it as is but the simulator/openinverter integration is very hacky and likely to cause people problems.

Any thoughts?

[Pete9008]

And just for completeness here is the plot with MTPA enabled:

and to make it easier to compare with MTPA disabled:

You can see the increase in torque, it reaches a higher speed in a fraction of the time. I just don't believe this increase!

There is also a slight deceleration on removal of the torque demand but this could just be the control loops settling (as they are obviously far from optimal).

I'm going to have a look at the MTPA equations again, as is it's just not realistic.

[Pete9008]

Had another look at the MTPA equations and I'm fairly sure that my model isn't correctly calculating the Id resulting from the input Vq and Vd.

Don't think this impacts on any of the results to date but it would explain why the model is showing so much reluctance torque. Haven't got time to look into it any more now but may get a chance to have a look over the weekend.

[Pete9008]

Could you try this variant: https://github.com/jsphuebner/stm32-sin ... -control-2

in foc.cpp it has a modified MTPA that includes the regulated FW current right away. It does (almost) exactly as you say, trying to keep iq amplitude from maxing out. Of course this only works if measured currents and angle match together, otherwise it can cause unwanted acceleration as it drives current into the motor that is no longer proportional to throttle input.

Just realised another difference, you do

Code: Select all

int32_t ifw = fwController.RunProportionalOnly(ABS(Param::GetInt(Param::uq)));

I do the same but use the peak pwm duty cycle. The trouble with using uq is that even if it's below the target ud could still be pushing the duty cycle into saturation causing the same problem. By using the pwm duty cycle I hope to avoid this; the problem then is that it's a very noisy control signal due to the 3phase and I'm wondering whether this is why it isn't very stable and need more filtering.

There is probably one further stage of limiting needed too. Even with FW it could conceivably get to a point where even with the max -Id the voltage is still insufficient and then the fw loop will limit so again leading to loss of control. At this point the torque demand would need to be reduced to prevent loss of control.

[Pete9008]

Had another look at it this morning and I can't get the FW control loop to be stable. When the pwm dutycycle hits the soft limit -Vd is added correctly and the motor happily continues to accelerate into the FW region. The problem is that when the pwm dutycycle reached the soft limit and -Vd is added this increases the total voltage and so further increases the pwm dutycycle which then causes more -Vd to be added and so on. This cycle continues until the hard dutycycle limit is reached at which point the dutycycle settles back down but then the cycle restarts.

The FW works and allows the speed to go above base without any unwanted regen issues but there is a strong oscillation on both Iq and Id. It's at about 12Hz and so will probably be noticeable when driving too.

Run out of ideas for now.

[Pete9008]

Think I know how to do it

Use @johu 's approach for field weakening based on a control loop against Vq but then add a second loop on top than monitors the pwm duty cycle and backs off torque request/Iq if it approaches the limit. I'd been trying to do both functions in one loop which doesn't work.

Will give it a try this afternoon.

[celeron55]

I'd say just release code already, even if it's just to make a distributed backup. But more optimistically someone with skills and time will also take a look at it.

I like where this is going. The latest conclusion about not staying within the controllable window matches my findings.

[davefiddes]

Interesting project and something I really wanted to get to with my Tesla M3 inverter project. As part of my work on that I refactored the PwmGeneration control loop into FocPwmGeneration and SinePwmGeneration cross-platform template classes. There is a ton of unit tests to excercise them and they all run correctly on x86_64 as well as STM32 and TI C2000. The code-base is very close to Johu's stm32-sine (cross-platform aside) and might be useful. You can find it here: https://github.com/davefiddes/c2000-inverter/

[Pete9008]

I'd say just release code already, even if it's just to make a distributed backup. But more optimistically someone with skills and time will also take a look at it.

I like where this is going. The latest conclusion about not staying within the controllable window matches my findings.

Very good point about the backup. I need to get my head round git (I'm comfortable using SNV but never managed to transition to git)

Interesting project and something I really wanted to get to with my Tesla M3 inverter project. As part of my work on that I refactored the PwmGeneration control loop into FocPwmGeneration and SinePwmGeneration cross-platform template classes. There is a ton of unit tests to excercise them and they all run correctly on x86_64 as well as STM32 and TI C2000. The code-base is very close to Johu's stm32-sine (cross-platform aside) and might be useful. You can find it here: https://github.com/davefiddes/c2000-inverter/

I like the look of you C2000 inverter project, look forward to seeing future updates on it. I had wondered about doing the same thing for the SinePwmGeneration but realistically can't see it making it anywhere near the top of the list. For the time being I also want to maintain compatibility with existing builds.

Thanks for the link, I'll have a look. I don't suppose you have a module of test stubs for the STM32 timers for use when compiling on x86_64?

[Pete9008]

Bit more progress on the code yesterday. I've revised chunks of PwmGeneration::Run() so that both Ifw and throttle backoff are now controlled by PI controllers running off Utotal. The targets are set so that Ifw comes in first and then when it runs out of range the throttle backoff comes in.

In the process of doing this I had a lot of problems with getting the loops to stay stable. Some of this was just tuning but most of it was due to what I think are a couple of bugs in the existing code.

First, I was seeing voltage waveforms (amplitude is calculated from dc voltage * max dutycycle) like this:

I believe that this is overflow on the fixed point maths in the FOC class. Changing the function to this seems to have fixed it:

Code: Select all

void FOC::InvParkClarke(int32_t ud, int32_t uq)
{
   int64_t u[3];
   //Inverse Park transformation
//   s32fp ua = (cos * ud - sin * uq) >> CST_DIGITS;
//   s32fp ub = (cos * uq + sin * ud) >> CST_DIGITS;
   int64_t ua = (cos * ud);
   ua = (ua - sin * uq) >> CST_DIGITS;
   int64_t ub = (cos * uq);
   ub = (ub + sin * ud) >> CST_DIGITS;
   //Inverse Clarke transformation
   u[0] = ua;
   u[1] = (-ua + FP_MUL(SQRT3, ub)) / 2;
   u[2] = (-ua - FP_MUL(SQRT3, ub)) / 2;

Old code is the commented lines, new code is the int64_t bits. A better solution would probably be to change the FOC module to use one less fraction bit but don't want to do this without @johu opinion.

With the changes the waveforms are:

The second issue was with the PI controllers. It seemed that is some cases the I term would wind up, and the anti-windup would kick in correctly to limit it correctly, but it would then not recover once the control signal came back in range. It turns out that if the input manages to go from saturation in one direction (with the anti-windup active) to saturation in the opposite direction in a single loop it would lock up. Wondering if this is what EV8 saw when the car rolled forward?) Adding an extra condition on the anti-windup seems to have fixed it:

Code: Select all

   if ((ylim == y) || (ABS(esumTemp) < ABS(esum)))
   {
      esum = esumTemp; //anti windup, only integrate when not saturated or if will reduce saturation
   }

With those mods and a LOT of tuning I've got to this:

This is the revised code on a full throttle run to near max speed (2 x base), coasting for 1sec and then decelerating, again at 100% throttle. To explain a little, the control runs at full Iq till around 2s when the FW starts coming in (-Id starts to increase), then at about 3.5s Vq again hits the limit and it starts backing off the throttle (Ivlim is mislabelled, it is actuall the % throttle available). Note - MTPA is disabled for this plot.

I had to give up on using the dutycycle as a control variable as it is too noisy. Instead it uses Utotal (calculated using FOC::GetTotalVoltage(ud,uq)). I'm not sure as the set points for the control loops are quite right. I use (FOC::GetMaximumModulationIndex() - 8000) for FW and (FOC::GetMaximumModulationIndex() - 2000) for throttle limiting to get them to come in in a nice staged way but don't fully understand the code in GetMaximumModulationIndex so it is a bit of a guess and might be limiting too soon/late?

Bit of further tuning as it occasionally goes a little unstable (so far just noisy not dangerous!) and I'm not happy with the way I'm backing off the throttle but it is getting there.

Final comment - I've got to say I have huge respect for everyone who has managed to develop and tune the OpenInverter on a car. It's felt like hard work tuning it on the simulator (with breakpoints and debug) but doing it on the car must be 1000x more difficult. Seriously well done to Johannes and everyone else for the perseverance and skill it must have taken!

[Pete9008]

And one more plot, same as above but with MTPA enabled:

Two things to note:
1) I don't believe this plot! To get the same speed I've had to increase the car mass by a factor of 4, that's 4x more torque which just isn't believable. I need to review the MTPA equations (both OpenInverter and simulator to find the bug).
2) This plot does not have the 1sec coast as if it is included the motor gets to full base speed and at that point there is no throttle control left to decelerate with!

It does still seem to work though which is encouraging (although there is more tendency to oscillation in the Vq control).

I'm going to leave looking at the equations for now and concentrate on getting the simulator to work with unmodified OpenInverter builds so that I can release it.

[davefiddes]

Thanks for the link, I'll have a look. I don't suppose you have a module of test stubs for the STM32 timers for use when compiling on x86_64?

Sorry, not yet. I haven't got to putting any test code around the core inverter and VehicleControl at this point.

[Pete9008]

Sorry, not yet. I haven't got to putting any test code around the core inverter and VehicleControl at this point.

No problem, thanks for letting me know though.

That's this afternoons job then...

Edit - 149 build errors to sort out, not great but could be much worse!

[Ev8]

I can’t can’t help with the coding I’m afraid but as soon as you’ve got some complied software that need testing on real hardware then I’m your man!

[Pete9008]

Question for anyone familiar with the OpenInverter code - does it do space vector modulation? If so where is it done in the code?

The reason I ask is that I now have the simulator almost working with the standard build files but my pwm output now looks like the below rather than the simple sine waves that I did have:

Now this looks very much like SVM. I had previously assumed that the SVM was buried in a bit of code that I hadn't included (which suited me as it messes up the voltages going into the simulator) and that now the simulator uses the full build it was getting included - so I went looking for it to see whether it could be disabled - but I can't find it!

In the SINE build it is in the SineCore::Calc(uint16_t angle) function but a very similar code block in the FOC::InvParkClarke() function replaces it the FOC code and it doesn't appear to do SVP. I'm running out of ideas here to any suggestions would be welcome.

Edit - I take that back I can't find it in the SINE build either, the code that I thought was adding the 3rd harmonic is just doing the fundamental.

Edit2 - Is it done somehow by the SineCore::CalcSVPWMOffset() function? I had assumed that it was just doing DC offset removal but that does n't work for three phase signals. Is it a clever and processor resource efficient way of getting SVM? I had commented this function out in my build so that would explain things.

Edit3 - I think SineCore::CalcSVPWMOffset() is the SVM code, after all all SVM is doing is adding a common mode offset voltage at the 3rd harmonic. Subtracting the average of the the 3phase signals probably would do this. Will try doing the reverse in the simulator to see if I get back to sin waves.

Edit4 - It is this code that does the SVM so in answer to the above - yes it does and in foc.cpp - very clever way of doing it! The problem now is that I have no idea how to get from the SVM PWM wavforms back to non modulated versions - the way I was going to do it doesn't work because I have lost the offset value used in the SVM calculation. Ideas still welcome

Edit5 - Out of ideas on this. I need a set of non modulated pwm values in order to keep the Park/Clarke transforms on the motor model happy (the motor may not care about a common mode voltage but the transforms do!). The only way I can see of doing this is to replace the foc.cpp file in the OpenInverter code with a local project version but I'm not keen on that as any changes to the file wouldn't be reflected in the simulation. The only other alternative is to use delta rather than star voltages to feed the Park/Clarke - will this result in a constant phase shift that can be compensated for?

Edit6 - Ignore ALL the above. The problem was completely non-related to SVM but rather was due to a parameter change that I hadn't noticed when updating the param_prj file Working much better now.

[johu]

Glad you figured it out. Thought I tested this for overflow but apparently missed something.
int64_t doesn't work for some reason and also it would be quite a performance hit. Can you try

Code: Select all

   s32fp ua = FP_MUL(cos, ud) - FP_MUL(sin, uq);
   s32fp ub = FP_MUL(cos, uq) + FP_MUL(sin, ud);

Also found issues with this anti-windup method elsewhere (my zero grid export script) so that seems to need another overhaul as well

[Pete9008]

I can’t can’t help with the coding I’m afraid but as soon as you’ve got some complied software that need testing on real hardware then I’m your man!

The only problem is that I can't compile it myself yet, I don't have any hardware to test it with and am uncomfortable releasing it without some kind of sanity check on it. Fortunately johu has kindly agreed to have a look at the code once I'm done with it which should clear the way to releasing it.

Glad you figured it out. Thought I tested this for overflow but apparently missed something.

I think your code is better than mine at limiting the total voltage before calling the output routines and so the overflow doesn't appear to occur in the original code. I'm going to have a look at dynamically updating the PI controller limits to see if my version can be improved.

Also found issues with this anti-windup method elsewhere (my zero grid export script) so that seems to need another overhaul as well

I tried a couple of other methods first but they introduced discontinuities in the controller and made things worse. Your code, with the extra test on the if statement, seemed to be the overall best solution.

[Pete9008]

The simulator code now works with standard builds. You can just checkout a standard OpenInverter source tree into a project subdirectory and it uses it. I've also ported all my mods into a standard build and can run that too. The only awkward bit is that if using the original code you need to use a new param_prj.h file as otherwise you get build errors.

I've also done a little tidying up so the plots look a little different (forced the q and d voltages/currents to have the same colours and changed motor speed to be in electrical Hz rather motor rpm).

Having both versions available allows for a direct comparison so original OpenInverter code first:

Now this uses the original hard coded (so ignore the Lq-Ld parameter in the GUI) MTPA algorith and you can see the high levels of -Id current being added throughout the frequency range. You can also see the FW coming in at higher frequencies.

Next the revised code, firstly with MTPA disabled:

And finally the revised code with MTPA enabled and the Lq-Ld value set the same as the hard coded value:

In terms of motor power the revised code without MTPA appears to do best but this is probably because the motor model is set up for low saliency (Lq = Ld) mainly because I don't trust the simulation torque calculation for high saliency motors yet.

Next thing to do is figure out github and put the simulator on it, but before I can do that I need to sort out my web browser as it doesn't seem to play nice with github (does anyone else have problems using it with Firefox?).

Edit - the legend on the graph should read 'Throttle Available (%)' not 'Throttle Reduction (%)'

[RetroZero]

Bravo for all your efforts, I think this is a huge step forward in helping out the community (like myself) who have no competencies in this field. I'm following along with lots of Wikipedia visits to broadly understand what your are (attempting) to do. Thanks for the persistance.

[Pete9008]

with lots of Wikipedia

You and me both!

Definitely been a learning experience! On the space vector and PWM I found this site https://www.switchcraft.org/learning/20 ... -pwm-intro much more useful though, it even has fancy animated graphics of how it all works.

[Pete9008]

Johu's comments above got me thinking about how I'd implemented things and having had another look I realised that the code should be using dynamic limits for the Iq control loop. I then realised that his code already did and that I had removed them while making my mods Now reinstated.

Also, using the dynamic limits controls the output voltage amplitude much more precisely, which improves control loop stability, so I no longer have problems with overflows on the dutycycles (although I'm going to change the code to match his suggestion anyway as a safety net). With these changes the throttle reduction control loop is fairly redundant; it does trigger very occasionally but since it is in I have left it in place as another safety net just in case I've missed some test case.

This is what the simulation runs look like now. Fist the same 10second run as above:

This is more or less identical to the previous except the control loops are more stable and the output voltage is much better controlled. Unfortunately the top speed is reduced slightly as it is no longer over driving the pwm. On the plus side I haven't managed to run out of throttle control authority at all, even at top speed which is a big plus.

Here is a plot of a fun to full speed followed by a 1sec coast followed by 100% deceleration which all looks pretty good:

I still want to implement johu's suggestion of moving some of the MTPA calculations out of the main loop but hopefully then it should be ready to test.

One last bug (sort of) with the PI controller. I had been setting ki and kp to zero to disable the FW and voltage limiting functions but it turns out that although the output is controlled the internal integral error term continues to ramp up. Not a problem for loops that are permanently off but caused some odd effects while changing gains while debugging and also on one loop which has dynamic gains. The following code has fixed this:

Code: Select all

int32_t PiController::Run(s32fp curVal)
{
    s32fp err = refVal - curVal;
    s32fp esumTemp = esum + err;

    if((kp != 0) || (ki != 0))
    {
        int32_t y = FP_TOINT(err * kp + (esumTemp / frequency) * ki);
        int32_t ylim = MAX(y, minY);
        ylim = MIN(ylim, maxY);

        if ((ylim == y) || (ABS(esumTemp) < ABS(esum)))
        {
           esum = esumTemp; //anti windup, only integrate when not saturated or if will reduce saturation
        }
        return ylim;
    }
    return minY;
}

Edit - 'Throttle Reduction' line in the plots is now actually throttle reduction. 0% means no reduction, 100% means throttle input fully reduced to zero.

[RetroZero]

Someone is not letting this bone go.
Can't wait to try it out. I'll start by putting the right oil in my transaxle hey Johu?

[Pete9008]

Just having another look at the MTPA calculations as they don't look quite right. First graphed the original and revised MTPA calculations in the inverter software (this is for Lq-Ld = 1mH so the currents should be quite large!):

So the difference is unlikely to make any real difference. So why are the -Id currents in my code so much lower? Looking at that next