openinverter forum

I've been wondering about the kp and ki values that are typically used for a while as they seem to go against everything I've been taught, and found, about tuning PI loops. My normal approach is try and do most of the work with the P term and keep the I as low as possible. This doesn't seem to work well with OpenInveter and I'd like to understand why.

Simulations to date suggest that both P based and I based approaches will work so thought it might be worth posting an alternate P biased tuning scheme just in case anyone feels like trying it. Whether it works or not, the results could help understand why some approaches work better than others.

I'm still a little unsure about posting it, as I can't test it on a real car myself first, but I think the approach outlined below should be safe to do. In any case, only try it if you understand the concepts behind it and are comfortable with the process.

I'll do it as two posts. The first will explain my understanding of PI control loops - if I'm misunderstanding something please let me know. The second post will be the suggested tuning process for ki and kp.

So control loops. The standard controller is normally called a PID controller - it has proportional, integral and differential terms. The PI controller is a version that just has the proportional and integral terms (the differential is often omitted as it can cause stability problems, is generally a pain to tune and isn't needed in most cases).

The standard control loop has an input that reflects the state of the measured value that it is trying to control and an output that controls the value. The example I'm going to use is a tank of water. The tank has an outlet that lets water out. The PI controllers job is to keep the level of water in the tank at a constant level regardless of the outlet flow. To do this it has an input - the measured water level in the tank, and an output which controls a tap that feeds water into the tank. If there is no outlet flow the tap needs to be closed, if a lot of water flows out of the tank the tap needs to be on. (to equate this to the Iq or Id controller in the inverter, the water level represents the current and the tap represents the voltage we apply to the motor to increase or reduce the current - there are better analogies using water flow for current and pressure for voltage but I find them harder to visualise in terms of control loop operation)

So first the proportional term. This term applies a signal to the output, the tap in this case, that is proportional to the error (the difference between the target level of the tank and the actual measured level on the input). Say the tank is 10mm low it might generate a tap opening of 10%, if 20mm low an output of 20% and so on. This would be a gain of 1 (obviously the gain depends on the units used). A gain of 2 would be 20% for a 10mm error and so on. You can see that as the error increases the tap opening increases. If the outlet flow from the tank increases the water level will drop, the error will increase and the tap will be opened to try to restore the level. There are a couple of interesting points that can be seen from this:

1. First for the tap to be open at all the water level has to be low - the water level must always be a little low for the tap to be on so there is always an error.
2. The larger the flow out of the tank, the more the tap must be opened to keep up, the tap opening is proportional to the error so the error must also get bigger.
3. If the gain is too high the tap can add more water than is needed to balance the flow out. If this happens the level will rise too high and the tap close completely, the water level will then drop till the tap opens again, adds too much water again and then closes. This is control loop instability.
4. If the flow out of the tank is faster than the tap can fill it then the water level will drop and the error will increase no matter what the control loop does - this is the control loop going open loop (where a change in the input does not affect the output)

Point 4 is a fundamental limitation of control loops, there is nothing that tuning the the loop itself can do about it. It is up to the system designer to ensure that it can't happen (e.g. make sure that the tap is big enough).

Points 1 and 2 are the reason why the integral term is normally added to control loops. The integral terms integrates the error, that is it takes the historical sum of the error and uses that to generate an output signal. In the above case if the level had, on average, been a bit low for the the past x seconds it would open the tap a little more. The important thing to note here is that 'the open the tap a bit more' isn't a temporary thing, it will stay on the output permanently, or until the average level has been a bit too high for x seconds at which point it will close the tap a bit.

The idea of the integral is to handle the steady state load requirements of the system. If you imagine the above example with both P and I terms, with the I term averaging over 10seconds. If we start from a case where there is no outlet flow, the water level is at the target level and the tap is closed. If a flow of water starts from the outlet the level will start to drop. the first thing that happens is that the P term starts to open the tap, the I term will start to open it too but only slowly as for most of the last 10seconds the water level has been right. Over those first 10 seconds the I term will steadily increase it's contribution as more of its 10second window contains low water level. During this time the water level will rise due to the increased water flow from the tap, the error will drop and the P term will reduce its output. Eventually, if the outflow rate doesn't change, the I term will take up all the load, the error will decrease to 0 and the P term contribution to the output will drop to zero. It's worth noting that too much I will also make the water level in the tank overshoot in the same way that too much P can.

The way I think of control loops is that the P terms is mainly there to deal with changes in load, the I term is there to cope with the steady state load.

For completeness the D or derivative terms is there to cope with very fast changes. To use the example above it would be if there is a very fast change in error generate a big change in the tap opening. You can probably see why it can cause stability issues.

For anyone who already understands control loops I apologise for the above but thought it worth including before trying to explain how to tune one.

Tuning a PI loop is the process of tweaking the gains of the P and I terms to get the best overall control response. Best is tricky to define as it will vary from system to system. Some systems need to be optimised for response speed and accept some overshoot to get this, some are tuned for lowest error some for stability.

P.S. sorry for another overly long post!

Edit - fixed a few typos in the above.

Finally, how I would go about tuning. Please note that I haven't tried this on a real car, the results below are from the simulator. Only try tuning this way if you are comfortable that you know what you are doing and understand the process.

Before starting make sure that syncofs is correctly tuned.

Edit - This process will probably work best with 5.20 on firmware which has had a bug in the integral part of the PI controller fixed.

The first thing to say is that this is not tuning for how a car drives, accelerates or feels, it is aiming at tuning the Iq and Id control loops so that they can best control Iq and Id. This does not depend on the car or gearbox but on the motor and inverter, more specifically the motor inductance, measurement/filter delays and the inverter loop latencies. Now this statement may not be correct, I think it is, but if it is it means that these ki and kp parameters can be tuned with the car, and motor, stationary. The things that affect the tuning are relatively constant and unchanging with motor speed.

So the way I would start tuning is with the car stationary, in gear (if there are gears), handbrake on and footbrake on. The aim is to lock the motor shaft so that it can not rotate. I'd reduce throtcur to a few tens of amps and then monitor Iq and Id on the webpage graph while using the throttle pedal to introduce transients. The low throtcur and handbrake should keep the motor and car stationary but I would keep the other foot on the brake just in case. Whatever you do do not do this with the motor unloaded (out of gear, clutch down, or on the bench), if you do there is a very good chance the motor will overspeed and be damaged.

Before starting disable MTPA (lqminusld = 0),disable field weakening (fwki and fwkp = 0) and set ki and kp to zero. With is set like this the throttle should have no effect on Iq and Id as seen on the web plot.

First set kp to a low figure, say 10 and see what effect the throttle has on Iq and Id. You should see something like this: First ignore the noise on teh plot, I've just artificially added that to make it a bit more realistic and check the tuning process copes with it OK.
Now on the simulator throtcur is set to 0.5 and full throttle is used, that should give 50A. It doesn't only 20ish, this is because the P term gain is too low and so needs a large error to drive the output. Also note the slow rise, this is down to the motor inductance and the low gain.

Now increase Kp, the next plot shows it for 100: You can see this improves both the risetime and the error.

Now keep increasing, kp=400: A bit better again.

Increasing to kp=1000: This looks a bit better again but you can also see that the noise level on the voltage traces is starting to increase. This sis a sign that it is starting to overshoot slightly so personally I would set it back to 400.

Just to illustrate the point increasing to kp=8000: A big increase in noise for minimal improvement in risetime and error.

So in this case I would settle for a kp of around 400.

Moving to I. Now it's very difficult to see the effect of I on a stationary motor while P is properly tuned so what I suggest is back kp down again to where there is a significant error visible, say kp=100 in the above and then start introducing ki.

Here is the plot for kp=100 and ki=100: Compared to the earlier kp=100 you can see that the I term is coming in during the pulse to reduce the error and is just about getting there by the end of the 2sec throttle application. Too slow though.

kp=100, ki=400: Improved but not there yet.

kp=100, ki=800: About right for me, maybe a bit slow for others.

If you go too far it starts to look like this, kp=100, ki=4000: The overshoot at the start is a sign that the I term is too big. If you are after ultimate performance then maybe but it's also going to start affecting stability.

So I would set it to kp=400 and ki=800 which gives this: Good rise time, minimal error and reasonable noise.

MUCH LATER EDIT - It worth noting that later work has now showed that high inductance motors (MGR, Prius, etc) need much more Integral gain than the above suggests in order to cope with the high back EMF voltages that they generate. The above should therefore be considered a lower limit for these motors.

It is also worth noting that the revised simulator now includes all these voltages and so if you know the motor parameters it can be used, in conjunction with the above techniques, to find a starting point for the gains.

Next I'd turn Mtpa back on and check the Id looks OK too: Which it does,

If that all looked OK I'd wind throtcurr back up a bit and then, very cautiously, try driving the car (keeping below base speed as FW is still disabled) and check the plots looked OK with the motor spinning.

Edit - when looking at the plots for driving Iq and Id should be stable in the steady state and shouldn't overshoot or oscillate following throttle or load changes.

Please note - I've only tested this process in the simulator (I don't have a working car yet) so only try this process if you are comfortable with it and understand the process. It is untested in the real world and in particular goes against the results found when tuning the parameters in the past so be carefull. Interested in results, positive or negative, as they all help develop the understanding of how it all works.

Just for completeness here is a plot from the simulator of a run using standard ki and kp values: And here is one using the values generated from the above process: I've tried to keep the scales similar on both to make them easier to compare. They both appear to work but do so in different ways.

Pete9008 wrote: ↑Wed Sep 14, 2022 11:18 am Two motors on one shaft does open up some interesting possibilities, you could even use one to dyno the other?

Yes, and with both systems coupled to the same battery the only discharge load is the efficiency losses.

That's what Arlin Sansome has done. He's part of the team behind the VESC based Axiom motor controller.

Pete9008 wrote: ↑Wed Sep 14, 2022 12:06 pm So control loops. The standard controller is normally called a PID controller - it has proportional, integral and differential terms. The PI controller is a version that just has the proportional and integral terms (the differential is often omitted as it can cause stability problems, is generally a pain to tune and isn't needed in most cases).

Of course, 'Fuzzy Logic' was supposed to solve all this.

In many cases, the quicker, cheaper, version, 'Woolly Thinking' was used.

SciroccoEV wrote: ↑Wed Sep 14, 2022 1:05 pm Yes, and with both systems coupled to the same battery the only discharge load is the efficiency losses.

That's what Arlin Sansome has done. He's part of the team behind the VESC based Axiom motor controller.

Now that is a very nice test setup!

SciroccoEV wrote: ↑Wed Sep 14, 2022 1:10 pm
Of course, 'Fuzzy Logic' was supposed to solve all this.

In many cases, the quicker, cheaper, version, 'Woolly Thinking' was used.

I like that!

'Fuzzy Logic' = I don't quite know how it works but it seems to!

Nice write up on pi controller tuning, I have done similar stationary loaded runs, but with test your method out this weekend

Your explanations need transferring to the wiki I too aim to try this at the weekend.

Hope the tuning goes well! Either way could let me know how you get on? (if it doesn't work I'd still like try to understand why)

Not sure what current to suggest, the 50A value I used could still generate a fair bit of torque so start low and build up. It needs to be large enough so that it plots clearly and is reasonably representative but low enough that you can safely keep everything locked stationary.

One other thought on the plotting. The web plot may not be fast enough to clearly show noise and oscillation/stability when plotting the average so if you can it would be worth plotting min and max as well, for both current and voltage, so that you can see if things start to get noisy or oscillate. Min, max and ave all with similar values is the ideal but of you start to see differences then it's a good sign that you are pushing the gains a bit too high (or there is electrical noise in the system).

Edit - Bigpie, while doing this it would be interesting to plot the motor rotor position too. If there is a noise problem on the angle measurement you might see it while tuning (a small movement is to be expected when changing torque due to gear backlash but it should be pretty stable when the current is constant)

So tried stationary control loop tuning today, wasn’t entirely successful, the resolution of the web interface is indeed not really up to fine tuning, especially if your Wi-Fi link is a little flaky like mine! Interesting I ended up with a tuning of kp200 ki350 which seems to drive fairly similar for kp50 ki35000, unfortunately I still get unwanted regen coming off throttle, I did discover whilst stationary tuning that when lifting off the throttle the current drops down and crosses over 0 going pursing current back from the winding before returning to o, I guess this is thanks to the winding inductance. I also witnessed this while test driving that even with regen disabled when lifting off at high speed I get a brief moment of 50amps pushed back into the battery.

I also discovered the high ki I was running was causing some large noisy spikes in ud and uq which are gone with a p led tuning.

Anyway on a tuning note you’ll also have to increase throtramp =100 and either mash that throttle as fast as you can or play with pot settings to decrease the range needed to hit 100% throttle otherwise your looking at the current demand ramping up and not the pure controller response to error.

Very good point on the throtramp, I hadn't thought about the effect it would have. Youre right that a fast edge is needed for the tuning.

The results on kp and ki are pretty much what I was expecting so thats good. Interesting about the voltage spikes too.

Was there any difference at all in the way they drove?

Was the unexpected regen at high or low speed (above or below base freq) and how aggressive was it? Its possible that your syncofs is still a bit out and some Id is being seen by the motor as torque producing Iq? Might be worth adjusting it slightly to see?

Was this just for one motor or did you try both? If both did you find ki and kp pretty similar for the two motors?

Re the 50A into the battery it probably is the inductance. When stationary you effectively store energy in the motors inductance which is then returned to the battery when you come off the throttle. I assume it only lasted for a fraction of a second? Im surprised you saw it while driving though - did it coincide with the regen?

Sorry for all the questions but its interesting stuff

The larger motor I’m running 300kp still 350ki
On the whole it drives smoother than tuned with a low kp high ki, the unwanted regen is now very predictable and smooth and transitions back into normal regen quite smoothly, I’d say firm but not aggressive, this is all at the top end of base speed I think, I’m not running and f/w because of the previous fun experiments with that!
I will try playing with syncof again when I next get a chance

And yes the returned energy I saw was just for a second

That's good, the larger motor should need a slightly higher kp.

If its high speed then this https://openinverter.org/forum/viewto ... 82#p45382 might help with the regen. Alternatively it might make it worse (I have trouble picturing the way motor rotation maps to the iq/id diagram). If you think syncofs is right it would probably be worth a try though.

Edit - Agree on fw, best leave it turned off for now. Is the power similar on both sets of parameters?

Edit2 - I would suggest not pushing right up to base speed at the moment. Without fw there is nothing to limit Uq and Ud and prevent the control loops going open loop. It shouldn't cause the bad regen you get above base speed but could still cause some odd behaviour. Could this be the cause of the regen you are getting at the moment (does it only do it right at the top end or does it occur at lower speeds too)?

Edit3 - The other possibility is Mtpa. If you have it turned on then it adds -Id much the same as fw. The difference is it removes it the moment you come off the throttle. This could be enough to allow you to get just above base freq and then give regen when you back off. Might be worth disabling Mtpa and trying it again? If it is this then we might need a slightly different scheme for merging Mtpa and FW (at the moment they are just added) to prevent the Mtpa's -Id being removed when coming off the throttle.

Pete9008 wrote: ↑Wed Sep 14, 2022 11:26 am I've been wondering about the kp and ki values that are typically used for a while as they seem to go against everything I've been taught, and found, about tuning PI loops. My normal approach is try and do most of the work with the P term and keep the I as low as possible. This doesn't seem to work well with OpenInveter and I'd like to understand why.

Random butt-in as first post but have spent the last few hours catching up on this topic - very interesting stuff!

Bit of background, I've spent a lot of time tuning inverters as part of an electric motors company I'm working for. I must say, I've observed exactly the same phenomenon with industrial Sevcon, Curtis, and more recently Emdrive controllers - a higher I gain tends to be required compared to P, in the factor of 10-100x variation..haven't quite figured out a possible reason for it myself. Possibly down to relatively high system inductance for SPM/IPM motors, in effect already 'smoothing' dynamic response out somewhat compared to steady state?

Need to find some time to download your simulator with openinverter SW.. got a lot of catching up to do!

Yes power level is more or less the same on both sets of tunings, pretty sure I have tested with mtpa off and with mtpa tuned differently and it still occurred, with mtpa off though torque falls flat pretty quickly and acceleration up to the speed where I have an issue takes a while, there is a possibility my base speed is lower than I thought and I’m pushing past it using offset sync and mtpa to weeken the d component already hence when I try adding f/w I run out of control. Previous testing lowering the syncof and disabled mtpa didn’t help much here but that was before I retuned the main control gains

Sounds like the mod in the link above might be the best next step then, I'm pretty sure it will help just not sure by how much. I should be able to do a build that includes it but with the warning that it would be completely untested on real hardware. Let me know if you would be interested in giving it a try.

Edit - don't think the above is going to help with the regen. Thinking about it the voltages on the motor will be lagging the real rotor position. This will turn -Id into Iq which will cause unwanted acceleration not regen. I think you are either pushing into the fw region using the Mpta -Id or have your synofs a little out. Two ways to check, either turn off Mtpa and see if it still happens or try it at a slightly lower speed. In both cases if it goes away then you are pushing into FW, if not it is probably a syncofs error.

At low speeds upto 2k rpm it doesn’t happen, at speed approaching 4K rpm lifting off will trigger unwanted regent and it persists down to 2.5krpm and transitions back to normal, at speeds above 3krpm triggering regen by baking also results in unwanted regen that persists down to 2.5krpm and transitions to normal. Perhaps this is my actual base speed for my pack voltage 80s

With Mtpa disabled can you get above 2.5krpm?

Also what speed does the motor go up to in the Lexus?

Edit - a plot of uq and ud while accelerating and then coasting down would give a pretty good idea of base speed if your wifi connection is up to it?

Edit2 - 2500rpm does sound too low but then Toyota do boost up to fairly high voltages in their inverters so it is possible? Is the 4krpm with FW or just Mtpa?

Just had a look with the simulator and if I set flux linkage to 120mWeber (not unrealistic) and voltage to 280V it gives a base frequency of around 3krpm so 2.5k doesn't seem implausible. If I turn Mtpa on it then revs to twice this and does give regen when coming off the throttle (back down to 3k), so this is looking quite likely.

Need to have a play with the FW gains and I also have an idea on how to improve the way Mtpa and FW -Ids are combined which should help. Will let you know how it goes.

Edit - at the moment the kp and ki loops also go unstable towards the end of the regen so it might explain the problems you had there too.

Edit2 - Simulation seems to match your results very closely, both above and below base. What motor speed do you need to achieve to meet your performance requirements?

OK, think I have a solution that I'm happy with

First a few plots to summarise how it's performing with 5.20 code.

First a plot which is supposed to be similar to EV8's setup, base freq at around 200Hz, no Mtpa and no FW: Next with Mtpa enabled. This allows it to accelerate past base frequency: But if you go past base frequency and come off the power you get unwanted regen: If FW is also enabled then: Bit better but still get the unwanted regen.

All the above are using kp led tuning, with ji led tuning the last plot looks like this: Next post will be with the revised approach for FW and Mtpa

Yes it will slowly accelerate over 2.5kprm with mtpa turned off but with it on and set to 1mH and 150mwebber it happily accelerates strongly up to 5krpm which is my cut Rev limit, I’d like to achieve 6k if possible so I can hit over 60mph in a single gear but it’s not crucial, a stable 5k would be fine by me, swapping between 3’rd and 4th gear to go on fast roads isn’t an issue.
I intend to do some more testing this evening when the traffic quiets down, currently on charge

I guess this also explains why with a almost full battery the unwanted regen isn’t there as It shifts the base frequency higher

Ev8 wrote: ↑Sat Sep 17, 2022 1:38 pm Yes it will slowly accelerate over 2.5kprm with mtpa turned off but with it on and set to 1mH and 150mwebber it happily accelerates strongly up to 5krpm which is my cut Rev limit, I’d like to achieve 6k if possible so I can hit over 60mph in a single gear but it’s not crucial, a stable 5k would be fine by me, swapping between 3’rd and 4th gear to go on fast roads isn’t an issue.
I intend to do some more testing this evening when the traffic quiets down, currently on charge

Pretty sure now that you are hitting base frequency. The simulation has convinced me that the -Id from Mtpa is quite effective at FW and allows you to push well past base frequency. The trouble is when you then come off the power the Mtpa -Id disappears, the FW disappears and you get the regen.

Ev8 wrote: ↑Sat Sep 17, 2022 1:57 pm I guess this also explains why with a almost full battery the unwanted regen isn’t there as It shifts the base frequency higher

Might lift it to 3krpm rather than 2.5 but that's about it. If it gets rid of it completely then there is something else going on too?

I've now changed it so that the Mtpa -Id feeds into the FW controller. If the Mtpa current is more negative than the controller ouput the controller output is forced to the Mtpa value and the integral reset to match. This means that when you come off the power the FW controller holds the -Id for as long as it is needed. If you are below base freq the -Id ramps down in a couple of hundred ms, if above base freq -Id is maintained.

Plots - first the baseline - revised firmware but with Mtpa and FW disabled: With Mtpa: With Mtpa and coming off the throttle: Same as before so the changes don't appear to have broken anything.

Now enabling Mtpa and FW: This needs a little explanation. You can see the FW coming in from around 1sec with the red and orange traces dropping on the Controller Currents plot and it is held on when the throttle is backed right off at 2sec. There is no unwanted regen but we do now have unwanted acceleration. This is down to the effect I mentioned before where the controller is using the current rotor angle to calculate the motor voltages rather than the predicted rotor angle at the point the new PWM will come into effect. Adding the sync compensation (still using the SyncAdv parameter for conveniance as it's there) allows this to be tuned out: This looks pretty good. No unwanted regen, no unwanted acceleration, stable -Id and the controller currents and motor currents now agree with each other.

If the compensation is set a little high you get this: A little but of unwanted deceleration but not an issue. The problem comes if you go a bit too far with the compensation: The Iq and Id control loops go unstable and we are back to the unwanted regen. No worse than the unmodified code but still there.

Now a value of 5 for the sync compensation should work for every install, it's set by the inverter controller loop frequency and sampling latencies and shouldn't need changing so maybe this is acceptable. The better fix would be to reduce controller latencies but I still haven't worked out how to do that.

Edit - Final plot showing how the currents ramp down below base frequency, around 200ms. This will probably be hidden by the throttle ramps in real life. Also noticed that the sync compensation value can safely be pushed a lot higher if you are not pushing so far past base freq (the above plots are a bit unrealistic going up above 3x base). If you are only going to twice base then is seems stable up to fairly silly sync compensation values.

Edit2 - what's really interesting about this last plot is you can see the back emf increasing when the throttle is released which looks very odd. What is happening is that the Mtpa -Id is being removed and so it is no longer suppressing the back emf. The Uq voltage therefore needs to increase to compensate for it!