IPM Motor Simulation and FOC Software

[Pete9008]

Just thought this over again. The dutycycles array in FOC is 32 bits. So no overflow there. In pwmgeneration the 32-bit value is shifted for using in the timer hardware. So now 65536 will become, say 4096 which is also the wrap around value programmed in TimerSetup(). In fact any value above the wrap value will just map to full-on. That's why this hasn't really caused any issues.

So this "overflow" presents a problem to the logger but not to the timer hardware. In fact I'm thinking the "fix" might be counterproductive as it shortly turns off the PWM signal.

I'm not familiar with that feature and could do with reading up on it. I've had a look but I'm struggling to find any details, do you have a link?

[Bigpie]

The 'fix' seems to have mostly cured my cutting out issues though. Maybe that's just a side affect of the briefly turning off PWM?

[Pete9008]

There were two changes put in, the pwm one and another to fix a possible overflow in the fixed point math in the inverse transform. It could be the later that made the difference?

[Ev8]

Tested the lasted build this morning, no unwanted acceleration in field weakening. Still getting unwanted regen though, and regen under braking oscillates badly,

Kp=60
Ki=35000
Fwkp =1
Fwki =50
Fmargin =5000
Fwcurlim= -100
Syncadv = 7
Syncof = 10500
Fwstart=100

Possibly some control loop tuning can help

Software is noticeably more stuttering when pulling away

[Pete9008]

Just thought this over again. The dutycycles array in FOC is 32 bits. So no overflow there. In pwmgeneration the 32-bit value is shifted for using in the timer hardware. So now 65536 will become, say 4096 which is also the wrap around value programmed in TimerSetup(). In fact any value above the wrap value will just map to full-on. That's why this hasn't really caused any issues.

So this "overflow" presents a problem to the logger but not to the timer hardware. In fact I'm thinking the "fix" might be counterproductive as it shortly turns off the PWM signal.

Just tested this and you're right, the pwm val does need to be allowed to go to the full 1<<16 to get to 100% on on the pwm output so the -1 'fix' needs removing!

I suppose the best way to think of this is that the PWM register is actually 16bit so there is no overflow there either, it just means that the timer count value never gets there which is exactly what you want to 100%. Values above 1<<16 also give 100% which also makes sense when you think of it that way.

Checked the other end just to be sure and 0 does give 0% too

All I can assume is that this is the change that is helping viewtopic.php?p=44583#p44583 which would be a bit annoying as we originally found it back in August!

[Pete9008]

Tested the lasted build this morning, no unwanted acceleration in field weakening. Still getting unwanted regen though, and regen under braking oscillates badly,

Kp=60
Ki=35000
Fwkp =1
Fwki =50
Fmargin =5000
Fwcurlim= -100
Syncadv = 7
Syncof = 10500
Fwstart=100

Possibly some control loop tuning can help

Software is noticeably more stuttering when pulling away

Starting to think that you have a high inductance motor (the need for high ki tends to suggest that, it's also a Toyota motor isn't it ? which are designed to run at higher voltages) which would explain a lot of the regen issues. If so the changes I'm working on at the moment should help. The issue is that they are significant changes and I've no way of testing them on real hardware (although the simulator does seem a lot more true to life now)

[Ev8]

Yes mine will be a high inductance motor, being from a Lexus rx400h they are basically oversized Prius motors, for now I’ve rolled back to software you build for me with the added syncadv because it’s alot more drivable.

[Pete9008]

High inductance motors are a nightmare to control

If I wasn't more confident in the model now I'd be sure there was something wrong with it!

It's showing a couple very interesting things:

• High current gains cause oscillation at low speed.
• Low current gains cause inadequate control authority at high speeds (unwanted acceleration even with throttle limiting!)
• You get very pronounced torque reduction even at relatively low speeds (due to the wLdId and wLqIq terms soaking up all the volts)

This tends to explain why speed dependant gains seemed to help in the past - we may need to reintroduce them.
It also explains the high integral gains on high inductance motors, they are needed for control authority at higher speeds.

Going to take a break and then try putting speed dependant gains back in and see what happens.

[Ev8]

Well I’ve Ordered a cheap LCR meter to do some measurements,

[Bigpie]

Which one? I'll get one too

[Ev8]

Just the cheap crap £27.99 on Amazon one surely it’ll get results in the ballpark

[Pete9008]

Great news on the LCR bridges, looking forward to having more data

I've had a VERY frustrating afternoon here, but what I think might be a good, but unexpected, result.

The day has been spent trying to get the new control loops stable, it was looking quite promising this morning but all fell apart after lunch. Whatever I tried it just seemed to jump from stable operation to crazy oscillation. It wasn't until by pure luck I got a setup where the instability happened right at the start where I could reliably capture the waveform and step though the code at the exact point it happened.

So this is what was happening:

Not very nice! for some reason the PWM values are all over the place (@Bigpie, I have a feeling this is what was actually causing your trips as it is exactly the behaviour that you described).

Having followed it though the code the lines responsible appear to be these in foc.cpp:

Code: Select all

   DutyCycles[1] = (-ua + FP_MUL(SQRT3, ub)) / 2;
   DutyCycles[2] = (-ua - FP_MUL(SQRT3, ub)) / 2;

Now in the debugger ub is getting down to -37931 (possibly less, that's just the value I captured), now multiplied by root3 gives -65698 which by my reckoning this is slightly too big to fit in a Q15 32bit signed fixed point variable, which is overflowing. This then messes up DutyCyles[1] and DutyCycles[2] which then creates a big offset which messes up the space vector modulation calculation and messes up DutyCycle[0] too.

The fix is this:

Code: Select all

   ua = ua/2;
   ub = ub/2;
   DutyCycles[1] = (-ua + FP_MUL(SQRT3, ub));
   DutyCycles[2] = (-ua - FP_MUL(SQRT3, ub));

Which then gives this:

Much better

I'm fairly sure this has been popping up in simulation for a while, I'd adjust something which and simulations would just go a bit odd. I thought I'd found it with the changes mentioned above (which are still worth doing) but I'm now pretty sure that this has been the cause of a lot of my problems (and probably a lot of the nuisance trips people have experienced in the real world).

Can't decide if that's a good or bad day, I've found the bug but haven't achieved any of the things I set out to do today

Edit - Good day, without adjusting anything the simulation for a high inductance motor is now stable Hopefully just need to find and undo all the changes I made while trying to locate the problem and retune all the gains now.

Edit2 - Had a bit more of a play with the simulator and it is still not as stable as I'd like. I also can't get much in the way of performance out of the Prius motor model at 350V, maybe 25-30kW. Increasing the voltage to 500V helps but I still doubt it's getting much above 40kW. @johu, how does that compare with your findings on the A2?

[Ev8]

Constantly impressed by the work happening lately, which is unfortunately a lot of it is just over my head at the moment, but we’ll done to all involved

[Pete9008]

Realised the I got my logic a little wrong above (still find the Q15 fixed point a little confusing)

-37931 is in Q15 and represents -1.158, it is being multiplied by 1.732 (or 56754 in Q15 ) which should fit in the Q15 fine. However, it does still overflow but the above explanation is wrong.

The overflow actually occurs within the multiply operation within the FP_MUL macro. The sum being done is -37931 x 56754 = -2.153e9 which is bigger than the -2.147 e9 that can be stored in a signed 32bit number. A possible fix would be to change the macro to split the >>15 into a >>7 and a >>8 on the two arguments which should prevent the overflow but is less efficient and loses precision (or a >>1 on the arguments and a >>13 on the result which retains most of the precision but is even slower). Overall the change detailed in the earlier post is simplest, most efficient and loses no precision. Just need to keep in mind the limitations when using the macros.

Edit - wonder whether it would be worth building in some conditional compilation checks on overflow conditions that would only be compiled in the simulator and throw a warning if they happened?

[Ev8]

https://www.researchgate.net/publicatio ... MSM_drives
a little off the current topic but an interesting read non the less, this paper details a self tuning mtpa control scheme that doesn't require fixed parameters and doesn't follow a linear path,

[Pete9008]

https://www.researchgate.net/publicatio ... MSM_drives
a little off the current topic but an interesting read non the less, this paper details a self tuning mtpa control scheme that doesn't require fixed parameters and doesn't follow a linear path,

Interesting concept although it might be one of those ideas that's better at producing research papers than working solutions!

I like the idea of self tuning but I think it needs to be applied to a setup that is already 90% of the way there, essentially just to tune out manufacturing tolerance, wear or environmental changes (that's how its used for lambda/knock tuning on ice engines). Unfortunately we're not 90% there yet (getting close though!). Their other argument is that traditional Mtpa tuning is too computationally intensive but thanks to Johannes highly efficient code we can do it with capacity too spare.

Now if we could get to say two standard configs, one for high L and one for low L, and then have something like this running in the background to fine tune it that would be a nice solution

[Ev8]

Yes I did think this is going to be processor heavy but still a nice idea! I have some background playing with stand-alone ice ecu capable of producing Base mapping purely on wide band lambda and other data… so I found the concept intriguing, agreed it’s totally not for now

[Pete9008]

Definitely something to near in mind for the future

My brain is just refusing to work properly today so not going to be much progress. Did turn on the computer though, just to check I hadn't forgotten to uncomment a bit of code yesterday (and I hadn't so that's good!) but while it was on I noticed something in yesterdays results for the high inductance motor. Here is the plot:

This is with Mtpa enabled, field weakening (although it's not doing much in the plot because Mtpa is asking for more than enough -Id), throttle limiting (based on total voltage amplitude) and the throttle limiting aiming the operating point trajectory towards the critical current point. A two second acceleration followed by a 1sec coast. Overall it's not too bad and coping better with the motor inductance as well as any other simulation I've run (both partial and full motor models), no unwanted regen, no unwanted acceleration (any slight trace can be tuned out with syncadv which is why it is now set to 2). There are a few bits that I'm not happy with though:

• The stability isn't as good as I'd like (probably fine but then I have perfectionist tendencies )
• The performance is not great (vehicle mass is down to 100kg to allow the simulation to run in a reasonable time)
• There is a nasty ripple in the speed trace at the start. It only lasts a few tenths of a sec but it shouldn't be there.
• For the first ~0.8sec the motor traces are not where they should be, the Id trace in particular is way off

It's also worth noting that despite throtcur being set to 3 it is only using a fraction of this which would make the throttle pedal feel a bit odd - exactly as if there was a throttle limiter in fact! Might need to come up with something more progressive, or just accept that it is pointless setting throtcur too high.

Now the total amplitude is being correctly limited to stay within the the possible working area but what I've noticed is that the Vd controller is still saturating at full negative output. What this made me realise that just keeping the total voltage amplitude within bounds is not enough, if just one of the controllers goes open loop we lose control of the motor (back to the if we want to control two independent outputs values (Iq and Id or phase and amplitude, etc) we need two control variables (Vq and Vd), if we lose one we don't get to chose which output is affected, due to their interactions both are). This explains the ripple in the speed/torque (it coincides with the Q controller going in and out of saturation) and the error in the Iq and Id during the first 0.8sec.

What does this mean? What I think is that instead of using the total amplitude as the control input for the limiter we should be using the absolute magnitude of whichever is the larger of Vq or Vd (uq and ud values in the firmware). Not to sure whether the field weakening control input should just be Vq, Vq and Vd (as per the limiting) or stick with the total amplitude?

Any thoughts/comments welcome!

Edit - One other thing worth mentioning, since adding the full motor model to the simulation the Mtpa modelling seems much more realistic. It now gives around 10-20% extra torque compared to Iq alone which seems much more realistic.

Edit2 - A neater way to do the above would be to add a function to the PI controller so that the margin between the output and the nearest limit could be queried. These values would then be used as inputs to the limiter and Fw controllers. This has the advantage that it would be controlling to the margin rather than an absolute value meaning it will automatically track any changes to controller min and max values (it is also more intuitive).

[Bigpie]

Well over my head here now. Have you found more overflow issues?

[Pete9008]

Well over my head here now. Have you found more overflow issues?

The Q15 stuff mentioned above? yes, think so. I reckon this is the one I've been chasing for ages. Each time it happened, I'd go looking for it and find something which would fix it for a while but then it would come back. Turns out that it only happened if the output voltage was pushed right up to the theoretical maximum (which the control loops try to stop happening) so it only happened occasionally. Each time it happened I'd find something and it was enough to pull the signal down just a tiny bit and stop it happening so looking like the thing I'd found was the cause (but the real problem as still there). All the earlier things are real potential overflows, and are best fixed, but I'm fairly sure that this one has been casing most of the problems (at least mine and probably real ones too).

I'm hoping that this, and the ideas in my last post, will get us to something that will work well on both high and low inductance motors. Need around another day on it to make the final changes to the code and then put the different motor scenarios through it to see how it performs.

[Pete9008]

I might have a working controller for high inductance motors

So for reference here is yesterdays plot (sec acceleration followed by 1 sec coast):

And here is today's:

The differences are fairly pronounced.

• The currents during teh first 0.8sec are now fully controlled
• The oscillations at the start of the speed trace are gone
• The motor voltages all make sense (that's a first )
• And most interesting the voltages during the coast are almost zero even though the motor is still spinning at 4k5rpm!

So what's changed:

• The FW and throttle limiting controllers now use the remaining margin as the control parameter (Vq for FW and the smaller of Vq and Vd for throttle limiting).
• The throttle limiting controller also now has a limit to the max error. This keeps the output rate similar for both pos and neg errors (otherwise the error can be 1000 for increasing limiting and 64000 (sort of) for decreasing limiting - makes it tricky to keep is stable)
• The FW is now working properly in coast. It essentially sets -Id to the motors critical current, at this point the back emf of the motor is exactly balanced by the wLdId terms and so there is not net voltage at the motor terminals. It makes sense too (I think), no voltage = no power dissipated = no deceleration
  
  And just for completeness here is the same plot followed by 1 sec of 30% deceleration:

  

  As soon as deceleration is requested the voltage is allowed to build up to drive current back into the battery. There is a brief moment of instability when the deceleration is requested which I can't seem to get rid of but it doesn't seem to cause a problem and I'm hoping that the throttle ramps on the full OpenInverter firmware will prevent it from happening.
  
  Edit - Also interesting is the shape of the motor speed trace. The acceleration profile is getting much closer to what would be expected for a IPM motor with an almost constant power region.

[Pete9008]

And for reference some plots sowing the same run with different throttle settings.

10A:

20A:

30A:

40A:

50A:

100A:

200A:

It can be seen that once you get above a throttle current of 50A there are diminishing returns in increasing it further. Doing so gives a little more power for a very brief period from standstill but as soon as the throttle/voltage amplitude limiting kicks in it provides no benefit.

I was curious what benefit the higher voltage used in the Prius (via the boost converter) would give so here is a 200A plot but with the battery voltage increased from 350V to 500V:

[Romale]

this is a super achievement.
I can't wait to test it in real conditions ))

[Pete9008]

And more plots, this time a direct comparison between the current firmware on a high inductance motor and the new code. In each pair the current firmware is the first plot and the new code is the second.

10A:

30A:

50A:

100A:

If the simulator and reality are anywhere near each other than that should be a worthwhile improvement

[johu]

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):

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