Halved current during field weakening

[johu]

Who exactly do you mean???

There's a crazy German who thinks rev limiters are overrated and a crazy Fin who paves his driveway with Nordlocks.

So here is something for you. It (hopefully) implements the method found here: http://web.mit.edu/kirtley/kirtley/binl ... ontrol.pdf (and in that google code).

When testing I strongly suggest to set your ocurlim to 300A or so, to protect your power stage from my stupidity. Also the sign of fwkp has changed to positive. Start with a value of 1.

Slowly spin up to high rpm and observe that you can do so without tripping the current limit. If so, increase ocurlim to its old value and do the test drive. Your goal is to find an fwkp that behaves well at high speed, i.e. no unwanted regen and good acceleration. Post plots of ifw, iq, id, fstat if your fail.

EDIT: ffwstart is redundant here, because this controller only starts acting when full amplitude is approached. This never happens at low speed.

[johu]

I see it hasn't been downloaded yet, which is good. I want to give a warning: this firmware, despite the fmax being enforced on a throttle level, may also spin up the motor uncontrolled when it is not loaded. So be super careful.

[celeron55]

With the MGR I haven't been able to overpower even just the handbrake yet, so there's not a whole lot of risk. With a more powerful motor it could get scary.

[Zapatero]

So i tested it but i couldn't get any results as it shook a lot in the field weakening area. Called Johannes, so he can have a look into that. I'm happy to test the next version, too!

[johu]

Same results, no surprise. So I tested a little further. Normally the maximum modulation index (internal maximum amplitude) should be able to reach 2/sqrt(3) or 37873 in q15 fixed point notation. So I had set the field weakening threshold to 95% of that, 35954. But it turns out long before that kind of amplitude is reached, the controllers go out of check. It happens at an amplitude of about 23000 that id and iq (with no FW in place) start oscillating heavily. So now I'm trying to find integer overflows or something. Found none in the FOC module itself so far.

I think this means that so far the software was never able to use the full DC bus voltage. The prior FW controller mitigated that quite well but of course that is far less than ideal.

[johu]

Ok, nevermind. The inverter can use the full bus voltage. It is really strange. With FW off I get the oscillation at around 300 Hz but I can punch through it with more throttle. Then I can spin up into the rev limiter with no field weakening and I also see full amplitude. Also the motor sounds smooth again. Something strange happens around 300 Hz and less pronounced at 400 Hz or so.

EDIT: the problem also occurs with syncadv disabled i.e. =0 . Changing syncadv does not seem to change the frequency where the oscillation starts

[Zapatero]

I'm really excited what you'll find out about all of this! Thanks!!!

[johu]

Some more results. I only tested the idling motor now, trying to get rid of the oscillations. The strategy being to disable everything that is frequency dependent. So syncadv=0, curkifrqgain=0, fwkp=0. Ok, there's a change, the oscillations are now further up the rev range, at around 400 Hz only. So now I lowered curki. First to 1000. Oscillations gone! Up until curki=5000 there are no oscillations.
Bringing syncadv back in introduced some oscillation but not as bad. fwkp=-100 as always gets rid of them.

So curki seems the main culprit. This afternoon I had tested with 10000 and curkifrqgain=50. So at 300 Hz we are talking curki=25000. Why does this cause oscillations? I don't know. Let's find out.

[bexander]

So curki seems the main culprit. This afternoon I had tested with 10000 and curkifrqgain=50. So at 300 Hz we are talking curki=25000. Why does this cause oscillations? I don't know. Let's find out.

Isn't this a sign of to much I-gain for the system? It is strange though that the oscillation is less at higher speeds.

As a side note, I might have gotten the Mathworks equations to produce reasonable Id/Iq distribution.

FOC_Mathworks_Calculations.ods

(5.63 KiB) Downloaded 360 times

Playing with Vehicle speed, Imax and T_ref and observing iq_total and id_total.

[johu]

Isn't this a sign of to much I-gain for the system? It is strange though that the oscillation is less at higher speeds.

As a side note, I might have gotten the Mathworks equations to produce reasonable Id/Iq distribution.

You would think so, but I remember that too little I-gain caused trips because the controller wouldn't transition fast enough when switching from acceleration to regen hat high rpm. Basically it has to swing from full negative amplitude to slightly positive. That said, back then the anti-windup wasn't fully working.

Good to see with the equation. If this leads nowhere we might try that.

[bexander]

Added so the calculation works for both positive and negative reference torques.

FOC_Mathworks_Calculations_3.ods

(14.07 KiB) Downloaded 407 times

Note: I have changed the motor inductances (Ld and Lq) so I get a base speed matching what celeron55 tested i.e. no FW below 150Hz or 942rad/s. I will have to figure out a better setup to measure these parameters if this is to be used.

[bexander]

I've started implementing the mathworks equations into the SW, viewtopic.php?f=7&t=2025&p=33315#p33315

[celeron55]

Did fresh tests on 5.17 with syncadv=10 (the default value). I played with all parameters that I thought might be interesting. I did tests with wheels in the air, wheels locked using the handbrake and very short road tests.

The result is, there's no difference to how it performed before - uselessly bad performance above 40km/h. At speeds slower than 40km/h (fstat=150Hz) it's possible to tune it to work relatively smooth and it has enough torque to spin the wheels on ice and slippery snow. Ud hits the floor at around 80Hz. Same as before, nothing to see there.

Interestingly with wheels in the air it's possible to make it spin faster than I was comfortable with. I took it to about 550Hz or 150km/h. It does take many seconds to get there.

viewtopic.php?p=32876#p32876

So here is something for you. It (hopefully) implements the method found here: http://web.mit.edu/kirtley/kirtley/binl ... ontrol.pdf (and in that google code).

This seems interesting but I need more information before trying it. Is the source code available somewhere?

[celeron55]

http://web.mit.edu/kirtley/kirtley/binl ... ontrol.pdf

"Since the current regulator loses control of the instantaneous machine phase currents under such conditions [4], the current vector command must be continually adjusted so that it always resides safely inside the voltage ellipse. However, it is desirable to approach the ellipse as closely as possible under heavy load conditions in order to deliver maximum power from the IPM machine"

This seems to match what I have seen in my previous tests that have included syncadv changes and where I have been trying to figure out the actual iq-id current vector that is happening.

I'm not sure if I get this, but how I understand it currently is that in practice before ud hits the floor, the iq-id vector has to be moved closer to the motor's characteristic current point. Moving the iq-id vector closer to the characteristic current point should always result in gaining more room in ud.

At the characteristic current point no torque is generated (due to iq=0A), so to generate meaningful torque, you have to maintain as much iq as you can.

The iq of the characteristic current point is always 0A, and the id varies between motors. The characteristic id is constant and it can be anything, from 0A to higher than the maximum current for the motor. When the characteristic id of the motor is higher than the maximum current of the motor, you can drive the motor without thinking too much about the characteristic id.

The Leaf motor and many others have a characteristic id higher than the maximum current. In such a motor, the way to get maximum field weakening is to point the iq-id vector increasingly towards -id using maximum current. Actually, what I said before was a lie - in these motors you cannot infinitely approach the characteristic current point, thus ud inevitably hits the floor at some point with increasing speed.

The MGR has a characteristic id much less than the maximum current, which is the source of our problems. In such a motor, if you point the iq-id vector increasingly towards -id using maximum current, you go way off from the characteristic current point and don't get field weakening.

So, before ud hits the floor, the iq-id vector has to be moved closer to the motor's characteristic current point. This generally involves decreasing iq, and either decreasing or increasing id so as to target the characteristic id. This can be done using a limiting mechanism with a ratio between iq and id, and a base offset for id, as the id limit has to be centered around the characteristic id. Basically: limit iq down, and limit id within a range of values around the characteristic id. The faster the speed, the smaller the allowed range will be. A reasonable ratio for the limiting seems to be something like 1 iq : 3 id but it of course depends on the motor.

It seems to me the field weakening controller could be set up to control a limit like this.

[johu]

Could you somehow graph this? Like speed on y-axis, d and q current (at full load) on y axis?

I thought about another FW algorithm today. I let my wife drive and watched fstat and uq (q voltage). Basically uq is rather proportional to fstat and changes slightly with current request. So I was thinking, I could set the FW controller to limit uq by increasing -id. This would leave FW current in place even when coming off throttle, which the current algorithm does not or too slow.

Of course this doesn't solve the other issue you mention

[celeron55]

@johu Can you provide the source for the Oct 17, 2021 firmware, please?

I went testing it, and it didn't really improve anything (didn't break anything either), but I think the idea is in the right direction. Here are two graphs that I took when driving using that firmware.

I should mention fwkp seemed to do basically nothing, but I played with throtcur. I would like to see the source to know what was actually happening.

Here throtcur was 3 for the entire drive. I think I might have changed fwkp from 1 to 10 halfway through, not sure. At the later portion I started testing whether varying the throttle would get me more speed, and I think it might have. Didn't plot the throttle though:

In the next drive fwkp was 5 or 1, whatever, it didn't really change anything, but I varied throtcur along the drive while keeping the throttle at 100%, and it changed the "high" speed performance (i.e. performance at around 40-50km/h or 150-200Hz). Near the end you can see the wiggly fstat line while potnom was maxed all the time. I was browsing throtcur values between 0 and 4 or so, and found out that about 0.7 gave me some acceleration, while values outside of that lost the acceleration. Of course once I stopped the car could barely move with throtcur=0.7 and I had to increase it again to something between 2 and 6.

Less current = more acceleration? Sounds like characteristic current to me. Now I need to somehow understand what was happening with the iq-id vector and what that might tell me.

EDIT: Placed the graphs the wrong way around. Fixed.

EDIT: Also, why doesn't openinverter provide any throttle mappings? I already added mine to one firmware, but keep losing it when switching firmwares.

Code: Select all

diff --git a/src/throttle.cpp b/src/throttle.cpp
index 9570c95..8ba975a 100644
--- a/src/throttle.cpp
+++ b/src/throttle.cpp
@@ -100,6 +100,11 @@ float Throttle::CalcThrottle(float potnom, float pot2nom, bool brkpedal)
    {
       potnom -= brknom;
       potnom = 100.0f * potnom / (100.0f - brknom);
+
+      // Apply throttle mapping
+      //potnom = potnom * potnom / 150.0f + potnom / 3.0f; // About ^1.4
+      potnom = potnom * potnom / 133.333f + potnom / 4.0f; // About ^1.5
+      //potnom = potnom * potnom / 100.0f; // ^2.0
    }
 
    return potnom;

[johu]

oh, forgot to push that, now it's here: https://github.com/jsphuebner/stm32-sin ... fw-control

throttle mapping: just integrate it like that: new parameter(s) that defaults in a way that throttle map stays linear and can then be changed to something non-linear. Either polynomial coefficients or a mode parameter like "throtmap" -> linear/quadratic/...

With that done, pull request it

[johu]

Less current = more acceleration? Sounds like characteristic current to me. Now I need to somehow understand what was happening with the iq-id vector and what that might tell me.

I have made some progress with the "other" FW controller, i.e. the one that tries to keep uq from saturating: viewtopic.php?p=38670#p38670

You can also set when it becomes active, so say maximum possible amplitude is 30000 and you set "qmargin" to 4000 then it will start adding extra id at 26000. Not sure if that helps the characteristic current issue, if I understand correctly at some point total motor current must be limited?

[celeron55]

Not sure if that helps the characteristic current issue, if I understand correctly at some point total motor current must be limited?

That's how it appears to me. I have too little motor control experience to actually try to figure out a working feedback loop that would do anything useful in achieving that.

I used one evening in attempting to write something new, with absolutely no useful results. Well, the code compiles, I'm a programmer after all, but the feedback I set up didn't end up making any sense and in practice it's just a very silly oscillator.

[johu]

I used one evening in attempting to write something new, with absolutely no useful results. Well, the code compiles, I'm a programmer after all, but the feedback I set up didn't end up making any sense and in practice it's just a very silly oscillator.

That's what control loops tend to do
EDIT: speaking of which: looks what my zero export controller is currently doing:

So asked differently, you lowered throtcur while 100% on throttle. Likewise you could have just come off throttle and thereby increased power.
Trying to think how to detect that condition. Of course we could introduce some frequency parameter but I bet it will shift around with varying battery voltage. Can you do some more plots with the "other" software? Maybe add some notes where this spot is where current needs lowering

[celeron55]

I'll see what I can do. Once again I wish I had a dyno.

Maybe some sort of firmware modification could be done where you could script the test to be done beforehand. Once you press the throttle halfway the test would begin executing, and if you release the throttle the test would pause. If you fully pressed the throttle the car would accelerate using default parameters, so that you could still give way to other traffic when needed. This way you could focus on traffic while the testing steps would be done exactly as planned.

Or maybe even something where the motor would dyno itself. The firmware could for example test for 100ms, then for another 100ms accelerate or decelerate using default parameters to maintain desired speed, and then again for 100ms it would run the test parameters. The plotting system could be modified to separate the alternating modes into different plots.

Or more simply, just a system which collects data fast enough that you can just do a full acceleration with wheels in the air, and you would get a useful series of data points. The entire run would probably only last for 1000ms or so. You would have to collect one data point every 1ms, or at least 10ms.

[johu]

Continuous data would be possible by disconnecting the wifi module and connecting a serial cable. The stream command can stream out forever or with very many samples.

[LeonB]

Here is another article which explains the topic of characteristic current, voltage ellipses and field weakening and also presents some formulas:
https://ieeexplore.ieee.org/document/6457462
Especially figure 8 and the related text are great for understanding what’s going on. They also come up with formulas and step by step explanations on how to calculate id and iq. The main difference being, that they are interested in constant torque and thus, have a torque as input which makes for some quite lengthy calculations. In our case, we command a current and thus, can save on a lot of the math.

So, in a perfect world, an id-iq diagram would look like that:

The current limit is given by our throttle input Is:

2.PNG (4.12 KiB) Viewed 7555 times

We can freely choose id and iq within this circle and in the best case, we would choose the intersection of the MTPA curve and current limit. However, there is also a voltage limit. Id and iq have to fulfill the following equation:

3.PNG (10.26 KiB) Viewed 7555 times

As the name suggests, it depends on the voltage Vs that is the peak value of the maximum phase voltage.
In the idiq diagram, this voltage limit is an ellipse with its center at the characteristic current:

4.PNG (1.99 KiB) Viewed 7555 times

Thus, the diagram would look like that:

Now id and iq have to lay within the current limit circle and the voltage limit ellipse (the red region). If one would hit the voltage limit and still keep requesting more and more current outside the allowed area, the resulting currents will not reach the requested values (ud maxes out..). One could just take back the throttle and reach the intersection between the MTPA curve, current circle and voltage ellipse (position A in the image below):

This probably explains celerons experience with lowering throtcur yielding more acceleration. However, this also decreases overall power. Instead, one could move along the voltage ellipse till one reaches the intersection between ellipse and current limit (position B). Not on the MTPA curve anymore and thus not as efficient, but more power and torque.

How could this be implemented in the software? One would need to check if the voltage limit condition is fulfilled and if not, increase id till the condition is fullfilled (while at the same time fulfilling the current limit). For that one needs the flux linkage as well as q and d inductance. At least for the prius gen 3 motor I could find these values rather easily. Sadly, both inductances depend on id and iq and thus, a lookup table would be required. In the article they also write about how they have got theirs, but at least for a start one could use some rather conservative numbers and just test if it does any difference at all (i.e., ud doesn’t maxes out).

[ThatGuy]

So, I'm working with a friend of mine on a new project. He ordered the gen2 Prius inverter co troller board and it showed up yesterday. Woo-hoo!! Our plans called for using the MGR discussed in this thread, and we are kind of set on those plans. I have read a couple threads on here in their entireties, ultimately leading me to this one. I was kind of sad when I got to the end of it only to find nothing really conclusive. Is this the end of the road here, or has this conversation continued elsewhere? We are sort of a ways off from any level of serious testing, but I want to get my mind wrapped around it as best I can in the meantime. If someone could point me in the direction of further discussion I'd appreciate it, if the MGR has become a kind of dead end knowing that with certainty at the beginning phase of the project would be great.

[johu]

Hi and welcome

Maybe here viewtopic.php?t=2611