Alternator control - PID implementation

[kb1gtt]

What is the alternator PWM relative to the output signal?

[stefanst]

I agree - the response has definitely improved. Those oscillations with P=20 are no fun though.
Just for testing sake, I'd say keep the P=20, get rid of I for now and start increasing D until the oscillations stop.

[stefanst]

There's a German saying: "Der Blinde fuehrt den Lahmen" - "The blind man leads the quad".
That appears to be what we're doing here. Nobody here really seems to have much experience with tuning PIDs. I learned some theory about 30 years ago, but no practical tuning.

So, from my- very limited- understanding of things, we may also be able to improve the oscillation problem by increasing the frequency. Try and change the dTime to maybe 20ms or so. Lets see if that helps....

[kb1gtt]

I'm mostly confused by things like this.

; Alternator_PID: I setting
; DBG_TPS_ACCEL: extra fuel
entry = debugFloatField4, "debug f4",float,"%.4f"

Is that extra fuel, or your I setting? I think it's the "I" setting. But it makes me question what I'm looking at.

For clarity, Pset is the P setting, were Pterm is the instantaneous values. Basically Pterm + Iterm + Dterm = output. and Pterm = error * Pset.

Also I don't see your P term or D term, Can you post those terms as i3 and i4.

It appears you still have a fair bit of noise. The first thing you should do is decrease that noise. Check your noise by holding the output steady. AKA Pset Iset and Dset all 0 as well fixed RPM. Then adjust your offset until you have your target. What I'm seeing that looks like noise, but could be caused by the changing duty to the alternator, changing RPM, or it might be noise. I'm not sure what I'm looking at. If you isolate the duty, I can get a good idea if it's RPM or other electrical noise. Once we have a good feel about if it's noise or normal conditions, then we know how much we should trust the signals we are looking at.

You can find what each value should be in steady state by using the setting the Pset Iset and Dset to 0, then adjust the offset. By holding the output steady you can get an idea of what the output should be, which is handy as you will now have a goal to aim at for each step of the tuning process.

Can you do this for a variety of situations. I would say you want values for head lights on and off at a steady 1kRPM, as well as 2kRPM, and perhaps 3kRPM. Can you find those values, then make a recording of the below sequence. Yes head lights on and off a couple times for each RPM.
1kRPM
head lights on and offset adjusted --> Headlights off and offset adjusted --> head lights on and offset adjusted --> Headlights off and offset adjusted
2kRPM
head lights on and offset adjusted --> Headlights off and offset adjusted --> head lights on and offset adjusted --> Headlights off and offset adjusted
3kRPM
head lights on and offset adjusted --> Headlights off and offset adjusted --> head lights on and offset adjusted --> Headlights off and offset adjusted

Once I have that data I an make some suggestions for your Pset, Iset dSet and Offset. Once we have initial predicted setting, we can then do some fine tuning on the car.

Also keep in mind your alternator is controlling energy, but you are controlling voltage. Voltage control is not linear for your alternator. A 1% change in duty at 1kRPM will command a certain number of watts from the alternator. However a 1% duty change at say 3kRPM will command many more watts from the alternator. If you had a conversion from voltage to energy you would linearize your inputs and outputs. PID loops are much easier to do with linear inputs and outputs. However we do not know the energy equation for your alternator, so it will be a bit lumpy, but we should be able to get it there.

Can you try the ON/OFF control?

Also can you re-name the columns in the headers similar to what I have in the below.

This is how I see your current log file. I re-named the fields to make it easier on the eyes.

[stefanst]

What I don't understand is how hard this seems to be. The voltage regulator on an internally controlled alternator is not a very complex device, yet it keeps the alternator output amazingly stable. We're trying with rather sophisticated PID and fail abysmally. If memory serves me right, an internal voltage regulator is essentially just a "P" regulator with a very steep slope and some terrible non-linearity at the extremes. The big advantage it has over what we're doing is a reaction time of near-zero.
So the more I think about it, the more I would advise to go with running the loop more often to improve stability.

[kb1gtt]

Internally controlled regulators have some advantages. They are well shielded and the control bits have very short antennas, so reasonably low noise levels to deal with. They also have very specific knowledge of how the energy is flowing around internal to the coils and such. So they can write a math equation that represents the dynamics of the alternator. In our case we are adding unknown signal delays to the feedback and unknown delays to the commanding signal. As well we have long antennas that pick up other sources of noise. Many internal regulators use the 400Hz ON/OFF control which we have as a control option. However once you start to add signal delays, you can get some odd resonance issues and odd things can happen. So it doesn't always work.

[Abricos]

Do you checked the noise when Franks board was in a completely closed metal housing ???

[stefanst]

Going back to a much older part of the alternator discussion:
Miata High-Speed-Feedback Alternator Control (For NB Miatas): It appears that the value of 10ms for the frequency (or rather period) of the feedback loop was misleading. It appears that the HF needs to be done at 20KHz - now that's true HF!

Also from what I found, control loop for Chrysler alternators should run every 10ms and PWM base frequency should be 225Hz. Integral term should be roughly half of P-term.

[kb1gtt]

There are different general parameters for different reasons. Nichols method is a common approach, it has an I term that's aprox 1/2 of the P term. Well it depends on your oscillation frequency. If you oscillation's are tuned just right to get that Tu term to be 1, then the I term would be 1/2 of the P term.
https://en.wikipedia.org/wiki/PID_controller#Ziegler.E2.80.93Nichols_method

The various time delays in the signals really mangle these general tuning algorithms. The ideal math equations typically do not have time delays included in the middle of the modeled system. These real world time delay variations really causes a bunch of problems with the tuning methods noted on the wikipedia page.

[AndreyB]

Fresh logs

First file warm up, 2nd file only radiator fan and at the end there is a sample with alternator off to check noise without alternator. Last file radiator fan and headlight.

https://svn.code.sf.net/p/rusefi/code/misc/logs/2003_dodge_neon/2016-09-19_alternator.7z

Update: forgot to mention - in this file P,I,D is all set to zero, I am manually controlling only offset.

[AndreyB]

10ms acually looks really nice! That's with radiator fan and playing with headlight switch and RPM in the end of the log.

https://svn.code.sf.net/p/rusefi/code/misc/logs/2003_dodge_neon/2016-09-19_19.57.21_10ms_o20_p20_i0_2.msl.7z

[kb1gtt]

Looks like you still have some electrial noise. I understand you found a 1uF cap, I would say install that when you get a minute.

[kb1gtt]

Looks like your PWM is typically between 20 and 35. I would say try an offset of 20, such that you P term doesn't have to compensate for that amount. Then try tuning your P set until it oscillates when you cycle your head lights. When you find that value, divide it by about 2. Then start to increase your I term and see if it pulls in to the target. then if it oscillates a bit try increasing the D set.

I should get on the phone with you and walk through it with you some time. Need to hit they hey for now, perhaps I can catch you Thursday.

[stefanst]

In the last round of logs, what are the different debug outputs? I don't think it's what you posted earlier any more.

Also:
- Have you tried to run more "P" with the timebase set at 10ms? I still think we need a lot more "P". See if you can get it to overshoot, but not oscillate
- Increase your "I" - a lot!

[kb1gtt]

In the logs I have been opening with notepad++ then changing the Time header line like this

Time RPM CLT IAT TPS MAF MAP AFR vBatt Load ignAdv Knock speed s2rpm dRPM airMass pedal trg err idle position fuel: pulse fuel: base fuel: VE fuel: duty cyc fuel: load extra fuel: load change fuel: TPS change fuel: TOS enrich fuel: wall corr ms fuel: wall amount baroCorrection fuel: IAT corr cltCorrection dwell PID Duty PID Iterm PID Prev error PID Iset PID Dset PID Pset PID offset debug i3 warn error int temp tCharge

Which then allows much easier visibility of the data, as shown below.

I've been copy and pasting that line from when I updated it from the original file. After I paste that line I then open the log and it's much easier to view.

[stefanst]

Pasting this header leads to the same result I had before: The three logs posted by @russian on Sept. 19th don't make much sense.
- PID duty is now an integer value that changes in steps of 5 or so.
- PID I term is locked at 0 (could be if I-adjustment is 0)
- PID pset is 0
- ...

And all the other values, except previous error just seem plain wrong.

[kb1gtt]

Just getting to look over your most recent log. I see at 54 seconds, the Iterm went wild, which made the PWM go wild. Integral windup is a big problem. You could add limits on the I term to prevent wind up issues. I see it's normal range is between 8 and 27. So perhaps you could add a min of 0 and a max of 35. That would help prevent the oscillation issues. Also the P and D terms should have limits. I also know several temperature controllers PID loops have a "band" that's around the target. If you are outside this band, your I term is 0. AKA your P term gets you to say 13V. Then you adjust your offset to get to 14V. However then you put on a load, and your voltage drops to say 13.5V. Lets say the band is +/- 1V, the I term will pull you up or down to maintain the target. I don't know if make sense. I should probably draw pictures.

It would be really handy to have the P term and D term. I'm not sure if the oscillation is the P or the I term. I'm guessing the oscillation is caused by the I term, but it could be the P term.

[AndreyB]

@ sorry forgot to mention - in the bundle of three files P,I,D is all set to zero, I am manually controlling only offset.

@ will add more debug fields and add dTerm (pTerm = pid->pFactor * error and we have both)

[stefanst]

Any chance to get a 40KHz fast field implementation for NB Miatas in software any time soon, or should I get started on the hardware implementation in the proto-area?

[AndreyB]

40KHz I doubt that in software

[stefanst]

Done some more googling/reading on Miata NB alternators. It appears now that the stock ECU uses PWM at 250Hz. That makes much more sense than a 40KHz bang-bang!
But other aftermarket solutions have had problems with controlling the alternator using PWM, so one brand came up with with a 'modified hysteretic loop control'. And this control is using a minimum 'stay in state' time of 50microseconds. And when you turn something on and off in 50us, you could argue that's a 40KHz loop. So that's presumably where the 40KHz, I found reference to, came from.
All that being said, we may actually be able to make this work using 250Hz PWM with PID, which appears to be what Mazda does.

[kb1gtt]

I seem to recall it is currently 400Hz, and it's a simple above or below target algo. Basically at what ever the tick time is, it checks if it's above or below target, and turns on and off the output accordingly. I seem to recall this tick is once ever 0.0025 seconds for the 400Hz base frequency.

[AndreyB]

C320 is now 0.1uF, R323 unchanged.

Getting BOM for a new assembly order. Do we want to make 0.1uF the new C320 value on official on Frankenso 0.5? Is that a better hardware filter value for alternator analog input?

[kb1gtt]

I guess I don't see any real problems with that. This is a low pass filter, the original had the roll off knee at 100kHz, this change moves that to 10kHz. For something like the alternator, you could probably change that to 0.1kHz and still get a good enough signal. Doing this would prevent a bunch of software headache. So I say lets do it.

[AndreyB]

OK, does it mean we do the same for C210 - designated CFLT and C220 - designated IAT?
What about TPS and MAP?

[kb1gtt]

The Vbat is always going to be connected to Vbat, so changing that one is less of an issue. Changing the others can be a different situation. We are not guaranteed that people will follow our suggestions, and we are not guaranteed that we won't want a faster response time. While we could determine what kind of bandwidth is desired for TPS, we would have a different desire for CLT, and other sensors. If we start changing the component values I fear we are going to force people to start changing components when they have a problem. As it stands now issues can be resolved in software filters, which allows for soldering free solutions. I'm not just being lazy, I'm thinking the way it's designed now is more flexible with out the need for a soldering iron.

While we are talking EMI / noise, does anyone know of a source which shows the impedance of components over a range of frequencies? If I wanted to create a low pass filter with a low pass of like 10 Hz and a blocking band of like 20db or more from 10kHz to 200MHz, I would need to know the components better that I currently do. I seem to recall that the values posted in datasheets is measured at something like 1kHz. So who knows what kind of uH or uF's I get at 10kHz to 200MHz. I understand some simulation tools can make some decent predictions as they have SPICE models. However I could do that if I had better data to work from.

[AndreyB]

The Vbat is always going to be connected to Vbat, so changing that one is less of an issue. Changing the others can be a different situation. We are not guaranteed that people will follow our suggestions, and we are not guaranteed that we won't want a faster response time. While we could determine what kind of bandwidth is desired for TPS, we would have a different desire for CLT, and other sensors.

This is a legit argument but it our reality where we do not have a great software solution and the input is pretty much designated CLT/IAT, I think it would be reasonable to make some hw changes for the assembled batch. After all we are not changing the PCB - people who assembled kits have the freedom, people who get assembled would usually follow the default pinout.

[stefanst]

@russian and I found a little problem with PID today. This presumably not only applies to the voltage regulator, but potentially to all PID controls.

It's already recorded in the Issue Tracker: https://sourceforge.net/p/rusefi/tickets/353/

Issue:
If we have exceeded the ability of the controlled device to hit target, the I factor will keep accumulating and approach infinity. Which will take a lot of time to undo, once we are able to reach target. Overshoot or undershoot for an extended period of time will result.

Example:
We just started the car and the battery is partially depleted. In addition it's dark outside and we're running the lights, the radiator fan and the interior fan. Even with the alternator going full-tilt, the desired target voltage can't be reached until the battery-depletion is at least partially rectified.

Setup:
Offset: 40
P-factor: 50
I-factor: 0.1
D-factor: 0
Target Voltage: 14.4V
PWM signal can go from 0% to 100%.
So our target voltage is 14.4V. The PWM-signal to the alternator is at 100%. But we're still only at 13V actual voltage. The difference between target and actual is 1.4V -> P-term is 1.4*50 = 70. We add that to the offset of 40 and we're already at 110. So we're driving the PWM in full saturation, even without an I-term. But since we're not reaching target, the I-term keeps adding up. A few seconds later the I-term has reached 10,000. The alternator has slowly charged the battery and we're able to reach target voltage. The actual Voltage reaches 14.5V, Offset is still 40 and now P-term goes to -0.1 x 40 = -4. But that's completely pointless, since I-term is still at 10,000, so the resultant value is 10,036 or so. The I-term decreases by -0.1 x 0.1 = -0.01. Next go around the voltage has increased to 15V. The P-term drops to -24. Still the resulting command is 10,016.

And so on and so on. Until I has come back down to useful values, the alternator is going full-tilt, overcharging the battery and potentially frying circuits.

Suggestion: Limit the I-term to the allowed maximum less the added value of the other three combined:

If (I-term > Max - (P-term + D-term + offset) ) then I-term = Max - (P-term + D-term + offset)

But what if P-term is highly negative? Let's say -500? Then in theory the I-term will be allowed to reach a maximum of 100- (-500 + 0 + 40) = 560. Would this hurt at all? I don't think so, but what do I know....

We also need to establish a minimum for I-term according to the same rules.

[stefanst]

Thanks for documenting the debug fields- it really helps debugging
On the topic of debug fields:
Looking at some logs, it appears that
- i1 is the P setting
- i2 is the offset value
- i3 seems to be counting resets or something like that

[kb1gtt]

When tuning PID, I often look for my range of output by manual control. Basically set the system for full load. Then manual control the output. Then do the same for minimum load, and again for typical load. It's common that I find the steady state conditions are something like 10% output for min load, 30% output for normal loads and 50% output for full load. The 100% and 0% are typically only used for dynamic states. Knowing what your steady state should be is handy because as you are tuning, you have a general idea of what your output should be if you can obtain steady state. I find it handy to know what I'm aiming for as I tune.

So lets say you set it for the normal load, which should have an output of 30%. You then turn your P term to be as large as possible and stable, perhaps following some general guides like Ziegler–Nichols or one of the others to help figure out what is stable. Typically you'll be something like 1/2 of what ever your P term was before it started to oscillate. Once you have a stable P term, take note of how far off the steady state % is, as well how far off your target you are. You know it should be 30%, and 13.4V but lets say it's 25% and 13V. So your I term needs to add 5%. Then do this again at the minimum load, and lets say it's off by say 2%, then do it again for the maximum load, and it will might be off by say 7% and off by 1V. At this point you can set your I term limits to something above 7% or perhaps 8% to help prevent the I term from winding up to much.

You can now set your offset to be 0.4V, or 5%. In theory you normal situation would have a steady state I term of 0. Your I term is still 0 at this point.

Also your maximum 7% and 1V error is now going to be less. Probably it would be 3% and perhaps 0.5V. So if you have a band, you can now set the band to a least 3% or 0.5V, which ever you can set. Often the band can stay at 100%. But it will need to be above this measured value, or your PID will not operate properly.

Now set your control loop to either the min load, or max load. Do it for which ever you think is the hardest to control. Then increase the I term until you are close enough to your target. Note this minimum I term. This is the most stable, but slowest I term.

Now do this again, and increase the I term until the control loop goes unstable. This I term is going to be aggressive and border line unstable, but will get you to target fastest.

Pick an I term that's in between this min and max that you just determined.

Setting your time base is harder to explain. If you are winding up your I term too fast, you can decrease the time base, but keep in mind that it can also cause instabilities if it's too slow.

Now test it and see how it goes. Adjust the terms in small increments until you are happy with the tune.