Alternator control - PID implementation

It's all about the code!
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Alternator control - PID implementation

Post by AndreyB »

I have a feeling that stable voltage is on my critical path for my Neon, here is the current state of rusEfi PID alternator voltage control (video is boring in the beginning but it gets better)

Looking for hints and suggestions how to improve things, current state of things is pretty poor.

[video][/video]
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: 2003 Dodge Neon (#9)

Post by AndreyB »

I am getting a feeling that battery voltage is my biggest issue at the moment: first of all I need to get stable voltage and then I need to figure out how different voltage affects my injectors. See how AFR goes up or down depending on if I am charging the battery or not:

[video][/video]

Log file is https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/DataLogs/2016-01-21_22.00.18_battery_effects.msl
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Alternator control - PID implementation

Post by kb1gtt »

It appears a large issue is that you are suffering from digitizing noise. This noise is causing a bunch of issues with your PID. You really want to decrease the bandwidth of the input signal making it less than the bandwidth allowed by the PID loop. Filtering the input is a good start, but you can also filter the output.

Also you are suffering from a non-linear control system. A PWM output change of say 1% at 12V is much smaller of a change that it is at 15V. Linearizing your system would help the control loop. I believe you can control the raw output. Please control it and tell me what the output readings are to control to 12.5V, 13V, 13.5V, 14V, 14.5V and 15V? Of course more steps would help better indicate the curve you need to linearize your output, but those few points would provide a reasonably good idea of the curve.

It would help if you can increase you ADC sampling frequency and average over more than 8 samples. That would likely need more than uint16_t, perhaps uint32_t wold work, but you'd have to check how many samples you can handle before overflowing the averaging register. Better would be to use an IIR of FIR filter instead of a basic averaging filter. You could also dampen the output of your PID to help decrease it's spastic tendencies. AKA slope limiting the output, or slew rate limit the output. I would say your PID should react to the input error on the course of about 1 second. If you limit your output such that each PID processing scan only allows the output to change by say 1% max, you would limit the overshoot and instability of the control loop. Also you probably want to limit the + slop differently than the - slope, such that you can come down at say 5% but go up by 1%.

Was that video taken with the 8 deep averaging, or other buffer levels? How often is slow ADC taking samples? Is that 10 voltage samples a second, more, less?

See IIR filter video found here, includes sample C++ code. Gets a bit better closer to video 4
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Alternator control - PID implementation

Post by AndreyB »

kb1gtt wrote:It appears a large issue is that you are suffering from digitizing noise.
Noise is on the order of 0.05 volts, is not that a relatively low level on the scale of current (lack of) control precision? Currently each ADC conversion takes 8 samples (ADC settings: 420 cycle samples with 20 cycle gaps), 10 conversions a second. (so, 8*10 samples per second), can be easily increased if needed,
kb1gtt wrote: I believe you can control the raw output. Please control it and tell me what the output readings are to control to 12.5V, 13V, 13.5V, 14V, 14.5V and 15V?
Let me collect this data. My biggest fear is that constant duty cycle does not provide constant voltage, with alternator load affecting engine RPM and just floating RPMs the values would want to run away from me.

So far I have not played with PID period and/or pid offset. Would it help to reduce or increase the period?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Alternator control - PID implementation

Post by kb1gtt »

I'm expecting the engine is about a 75kW engine (100HP-ish). The alternator is probably around 60A * 14V = 0.840kW. So I'm expecting it would be a near min load on the engine. I guess that at idle you are much lower HP than the full load but I'm also expecting you can't reach the full 60A at low RPM either. The fuel pulse will roughly indicate the HP at that moment in time. If it starts to load down the engine and vary the RPM you could adjust the IAC allowing more air, which would then allow more fuel, and would hold the RPM constant. This is common with known loads, including AC loads. It's also common for un-known load that a PID loop is used to control IAC and keep a fixed RPM. Any how, I'm expecting the RPM will be minimally effected, as well if it load down, I'm expecting it will drop from say 1kRPM to something like 900kRPM. Some testing will show if that's true or not.

Your saying the bouncing needle is accurate to the real world. However that bouncing needle will make your D term go bad quite quickly, as well it causes some lesser issues with the P term. Decreasing the system jitter allows the D term to be of some use, but you probably don't need the D term any how. Easy short term plan would be PI only and don't bother with the D term. The D is really just for when you are trying to get every ounce of performance out of the system. See below about where filters can be placed and how they can help.

http://controlguru.com/using-signal-filters-in-our-pid-loop/

When you say PID period do you mean PWM output or the how often the PID function is executed? I believe you mean how often the PID is executed. I would generally look for that to be processed every filtered ADC reading. If it executes at some other time it can cause some really odd digitizing noise issues.

Ultimately what you really want is a control loop that is controlling the watts the alternator is providing, then you want to adjust the set point watts to get the desired voltage. If we find an equation that relates RPM and PWM in terms of watts, that would linearize much of the equation. AKA your concern that varying RPM will vary the alternator output is correct, as RPM decreases the PWM would need to increase to keep a constant watts on the system. Also you want to cut the PWM to 0% output when below something like 500 RPM, and don't kick in the PWM until you have reached something like 800RPM. But that's later down the road. For now you are turning it on manually after the engine has been started.

Can we find an equation that would allow us to command something like 100 watts from the alternator, then it would look at RPM and calculate the PWM or desired field for the alternator? My 10 minute search has not produced equations yet.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Alternator control - PID implementation

Post by AndreyB »

Played with PID a bit more, made some progress. Each video has a link to the corresponding log file.

[video][/video]

Getting closer and a bit of fuel tune driving
[video][/video]

Auto-tune driving
[video][/video]
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Alternator control - PID implementation

Post by kb1gtt »

Algo related suggestions
-- Add an output slew rate limit. It is currently way to reactive to changes which is causing a bunch of instability. Allow it to only change something like 3% per PID scan. Such that if the PID commands 100% output, it takes 100 PID scans before the PWM output is 100% duty. I believe the PID is being processed 10 times per second, so an allowed change of 3% and 10 scans per second would allow a change of 30% in one second. Also make this a TS controlled option as each system will have a different need. This will cause debug F to become much smoother. Once you have this option increase or decrease the % until it takes you about 1 second to go from 0% to 30% output.
-- Add limits for when the alternator is working. Such that it turns off the alternator if you are below say 400 RPM and it doesn't turn on until you hit say 600 RPM. This should also be a TS settable option.
-- Dtime should be synced with the ADC readings. If the ADC updates once every 100mS, there really isn't any purpose of processing the PID every 10mS. Dtime should allow skipping ADC readings effectively slowing down the PID response.
-- There are many PID algo's out there. It would be great if TS could display the core PID algo, such that people know it's something like the below. Perhaps an Information button or something like that.
error = target - input;
pTerm = pid->pFactor * error;
iTerm += pid->iFactor * dTime * error;
dTerm = pid->dFactor / dTime * (error - prevError);
prevError = error;
-- Some way to display the PID incremental parameters. The I term has a tendency to do what's know as integral wide up. Displaying the terms is really handy for knowing if you are running a risk of the wind up.
-- Once you have some values from your setup, change the TS to display like this "P factor (default 20)" Such that people know the ball park where they should consider starting from.

The below suggested procedure assumes you have a stable reading from your ADC. If the ADC reading is jumping around, you should fix the ADC reading before you attempt the below.

Tuning procedure (very similar to the video's above)
-- Start engine, fully charge the battery, get it to idle a what ever you normal idle RPM is. All optional electrical loads like head lights, blinkers, radio, etc are OFF. Only minimal required loads like fuel injectors, ECU and such minimal equipment is ON.
-- Manually control alternator PWM until you get 13.5V. Do this by setting P, I and D terms to 0, then enter a number for the offset. Write this number down.
-- Now adjust the RPM to something like 2kRPM, and turn on all electrical loads you can, head lights, hazard lights, radio, etc.
-- Manually tune just like before, but tune until you reach 15V. Write this number down.
-- Pick a number between these two limits, probably a bit closer to the idle number, then enter that into the offset. The theory here is that you always have a typical load. The PID needs to control the dynamic parts of the control loop not the static parts. This offset removes the major static parts.
-- Now that you have an offset chosen, Set the target to 14.4 and Increase or decrease P factor until it goes unstable. Turn your head lights on and off to see when it goes unstable. Turn on the head lights for say 1 second, see if it jumps around and acts spastic or if it acts reasonably stable. Then turn off the head lights, and check again for stability. Keep increasing the P factor until you start to get an unstable situation. Write this P factor number down.
-- Set P factor at about half of the above measured value. At this point you should see it attempts to control and operates in a stably, but does not quite reach the target value.
-- Increase "I factor" until you pull into the target voltage as you desire. Again using the head lights to show when it's unstable.
-- Increase the "I factor" until it goes unstable, make sure that unstable numbers is significantly above the stable factor found above.
-- If all goes well use the stable "I factor" and it will operate as desired.
-- If all did not go well, go back and adjust the PI terms until you get the desired results. If you have a problem with Integral wind up, you can try a PD control loop, by using a very high P term then using the D term in an attempt to stabilize the control loop.
Welcome to the friendlier side of internet crazy :)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Alternator control - PID implementation

Post by kb1gtt »

In the video you can see some blah with the gauges. On your video, you held the PWM as a solid 20, but the voltage was bouncing around by +/- 0.25V that's allot of bounce. Also the PWM of 1% was also bouncing around by +/- 0.125V. As you increase your PWM you increased the measured voltage jitter. This measured jitter causes all sorts of problems with your PID. Because the jitter increases with increased GND current, I suspect you have a poor GND connection.

If you have a poor GND. Your ECU GND would be bouncing because of current flowing from injectors and your alternator PWM currents flowing through the GND path. As the higher power currents go through connectors, and through small wires, or bad solder joint etc, they will each induce a certain amount of ohms. Each bit of ohms will cause a voltage drop, which will cause a skewing of you analog reading. If you have .1 ohms of resistance on your GND wire, and 2A from injectors and perhaps 4A from the alternator, for a total of say 6A flowing, you would have a 0.6V drop across your GND wire. Take note that 0.1 ohms is not something most people can measure with a DMM. You instead have to induce a significant current and measure the voltage across the wire.

With a DMM can you measure a voltage from your battery - terminal to your rusEFI GND pin? Are you using both GND wires? Can you add a fat 12 awg or larger GND wire to the other GND of even add it to one of those GND pads? If possible solder it direct to the PCB and connect the end of it directly to the battery with no other connections. For the battery end, use a ring or fork terminal, but you probably don't have good enough crimp tools to do that properly so I would suggest you solder the ring to the wire, then put the ring or fork under the battery bolt head. This would likely decrease the voltage the DMM measures between the battery - and ECU GND. As well it would likely decrease your bouncing.

Also if you sync you ADC readings with crank angle, and sync your alternator PWM with crank angle, you could potentially measure at a time when there are no injectors firing and no alternator currents flowing, or at least you could measure when you have a consistent current flowing in the GND wire. Just like sampling your MAP at a specific crank angle, doing the same with the ADC would likely make a more consistent reading. Then if you know you have a .25V drop because of a 1A current flowing from the injector, you could compensate for that voltage in your calculation. Basically measure at a known time with consistent current flowing, then measure the battery V and allow TS to enter an offset such that you make your DMM match the TS voltage.

Perhaps a calibration option controlled via TS, something that steps you through some steps to calibrate your battery voltage, under certain conditions.
-- First you would set it to just being powered, then type in a calibrated voltage, AKA minimal electrical loading, key on but engine not running. I think this already exists, and is used for dealing with your resistor divider tolerances.
-- Second with fuel pump disabled, turn on injector for say cyl 1 for like 3mS and at 1.5mS measure the voltage again. Make an offset such that the voltage reported during this time would be the same as the first step.
-- Third, turn on the alternator PWM just like second step. Get an offset.
-- Forth, identify the possibility of other injectors that might be turned on at the same time, and calibrate an offset for them as well.
-- Fifth do a validation of each combination of load, turning them on for that 3mS, taking a measurement at 1.5mS recording the results and displaying them such that you can see if you have made proper adjustments.

Once you have this calibration data, when the voltage is being measured you would quickly check what loads are turned on and your reported value would be ADC reading + applicable offsets. This would likely make much of your jitter go away.
Welcome to the friendlier side of internet crazy :)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Alternator control - PID implementation

Post by kb1gtt »

Might as well keep the flood of posts going :)

About ouput slew rate limiting, it should be allowed to be differ from + to -. It will have a faster reaction to a + command, and probably slower in the - direction. So you may want it to be 3% in the + but 5% in the -.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Alternator control - PID implementation

Post by AndreyB »

There are all great comments! https://sourceforge.net/p/rusefi/tickets/256/ https://sourceforge.net/p/rusefi/tickets/257/

I just need to dig myself from 28 inches of snow now :)
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Alternator control - PID implementation

Post by AndreyB »

Looks like I need fast & precise voltage control to get precise fuel control :( I wish I have a hardware regulator.

https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/DataLogs/2016-02-04_21.53.19_alternator_pid.msl

PID parameters & state are the seven columns towards the end.

[video][/video]

PS: car is parked, I am turning headlights off/on.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Alternator control - PID implementation

Post by kb1gtt »

Can you make the logs with these names, the name you have are kind of hard to understand.

TS Pterm, TS Iterm, TS Dterm, TS Poffset, Alt PWM, PID P, PID I, PID D. The PWM should equal PID P + PID I + PID D + TS Poffset.

One item I think you need is a compensation for changes in RPM. When you add and remove about 60W of load, your RPM dropped from 1300 rpm to about 1100 rpm. Lets say you were drawing 10W, and you dropped RPM by 200 RPM. If you keep your PWM the same, you won't produce 10W, you'll produce perhaps 8W or something similar. At times when you added the load your PWM went up by nearly 10 units, before it started to make the voltage climb. You could potentially have a modification based on RPM. Really what the loop needs is to control watts, not PWM. The PWM should be the byproduct of the watts PID loop.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Alternator control - PID implementation

Post by AndreyB »

I've changed the column names in the log file to make it more readable, the firmware would stay as is for now to balance usability with the amount of bytes produced but good point to manually edit headers prior to publishing.
kb1gtt wrote:One item I think you need is a compensation for changes in RPM... You could potentially have a modification based on RPM. Really what the loop needs is to control watts, not PWM. The PWM should be the byproduct of the watts PID loop.
I have no idea what you are proposing exactly. Are you suggesting detecting if headlights are on or off as a requirement for better voltage control? Are you suggesting some kind of a table based on RPM for some of the PID parameters? Which ones?

I would like to reiterate that my test is a bit flawed - in real life I am mostly interested in stable voltage at different RPMs while driving. For a comfortable test I am sitting in an idling car and changing the load instead of changing the RPMs. At the end of the log file there is a short section where i play with the throttle pedal instead of playing with the headlights switch.

Image
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Alternator control - PID implementation

Post by kb1gtt »

For the injectors you have a look up table that adjusts the pulse to make for a consistent grams of fuel delivery. I think we need the same for the alternator. I believe it would be a 2D table with RPM for one axis and amps for the other axis. Each cell would be the PWM required for that RPM to produce the desired amps. AKA if you are below your desired voltage, it's because the alternator is not generating enough amps. If you generate more amps you'll increase the voltage. This look up table would linearize your PID control loop, and make it much better to tune.

I also see your alternator will decrease at a different rate than it will increase. I'm kind of thinking you want a D+ factor and a D- factor. Such that you dampen at a different rate when your delta change is + vs when it's -. Might be the same for integration, but I'm not sure you'll need much beyond a PD control loop.
Welcome to the friendlier side of internet crazy :)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Alternator control - PID implementation

Post by kb1gtt »

When charging, we need a way to control the voltage, as well we should avoid over current conditions with the alternator. We should specify the expected internal resistance of the battery, as well as the max capabilities of the alternator and max capabilities of the battery.

Generally batteries should go through a 3 stage charge cycle, bulk, absorption, and float. In our application, we should assume every time the engine is started, you first do a bulk charge, followed by absorption, then float.

-- Bulk is to recharge as fast as possible with out damaging the system. This could be the batteries internal limit, but for car alternators is typically the alternators ability to produce current. An automotive starting battery typically has a max charge rate of about 50A. See below linked, or attached Exide guide for reference. We should charge at this max rate, until the battery absorption voltage has been reached. Then we should switch into the next stage. It is also common that an OEM will have this addressed by design. If you have a 60A alternator you won't exceed the approx 50A limit. However if you have a 120A truck alternator, it becomes more of a concern.
Battery Charging & Storage Guidelines 5_9_13.pdf
(57.82 KiB) Downloaded 381 times
originally found here http://www.exide.com/Media/files/Downloads/TransAmer/Battery%20Care%20and%20Maintenance/Battery%20Charging%20&%20Storage%20Guidelines%20%205_9_13.pdf

-- Absorption is where you keep the voltage at a set voltage and let the current change as the loading requires. This is where the PID control comes into play.This will have a target set point as noted in the below page. It notes 2.40V to 2.45V/cell (14.4V to 14.7V) However you don't want to stay here for ever as it decreases the battery life.

BU information found here http://batteryuniversity.com/learn/article/charging_the_lead_acid_battery also see this page http://batteryuniversity.com/learn/article/charging_with_a_power_supply Also also see this page http://batteryuniversity.com/learn/article/equalizing_charge

-- Float is when you keep the voltage at a set voltage and let the current change, it's the same algorithm as the absorption, but the voltage is set to a lower level. According to the above BU page, that's 2.30V to 2.35V/cell (13.8V to 14.1V) See above link for additional details.

Also from the BU link above
The charge temperature coefficient of a lead acid cell is -3mV/°C. Establishing 25°C (77°F) as the midpoint, the charge voltage should be reduced by 3mV per cell for every degree above 25°C and increased by 3mV per cell for every degree below 25°C. If this is not possible, it is better to choose a lower voltage for safety reasons. Table 2 compares the advantages and limitations of various peak voltage settings.
The PID input and output should be a measure of amps, such that the voltage stays at your target of 14.4V. So why can we measure voltage and have it function as a method for reading watts? It's because your electrical system should have reasonably fixed resistance. The internal resistance of the battery is by far the lowest resistance. As higher ohm loads come an go, the change in resistance seen by the alternator is minimal. If you have a fixed resistance, then ohms law means that current and voltage are directly proportional to each other. This direct correlation is why we can measure voltage and use it to control the input current as part of the PID control loop. If we specify the internal resistance of the battery, we can do some math and make this current in and current out from the PID loop. By specifying the internal resistance, we can control the over current during the bulk phase of charging.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Alternator control - PID implementation

Post by AndreyB »

left side - idle warm-up, right side - a bit of driving. Note how vBatt is oscillating while driving :(

I=0.25 & D=1 at the end
https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/DataLogs/2016-02-15_20.55.45_warmup.msl
Image

more driving with lower I=0.1 & D=0.1. less absolute oscillation but still pretty scary
https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/DataLogs/2016-02-15_21.09.49_drive2.msl
Image

what should be the next set of parameters to try?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Alternator control - PID implementation

Post by kb1gtt »

vbat is still jumping around. It looks like you have pushed to the limits of stability such that it is oscillating a bit. I think you did this to get the voltage sane at least when you have a steady state RPM. What I'm seeing is that your electrical load is probably reasonably consistent. However as your RPM changes you are changing by about 10% of your alternator PWM, just to deal with RPM changes. I think you really need to make adjustments based on RPM, as your PID should be delivering the same electrical watts.


Any how, alternator stuff. Broken record time I see alternator PWM duty is changing by 10% due to RPM changes. This requires your integration to change from 14 @ 978.5S, to 23.7 @ 988.9S. If you could remove this integration time due to RPM changes you could be more aggressive in your I term tuning. If you could be more aggressive in your I term you can be less aggressive in your P term. A less aggressive P term would result in less oscillation.
Welcome to the friendlier side of internet crazy :)
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Alternator control - PID implementation

Post by AndreyB »

(Jared, I've moved alternator part of you other post here and moved thermostat part of your post into http://rusefi.com/forum/viewtopic.php?f=3&t=696)

so, what would be next smallest possible incremental change you are suggesting? Are you suggesting a curve for Offset based on RPM, or are you suggesting a curve for P-factor based on RPM? Please pick one, not both.

What would be your suggestion for initial values for the new curve? Let's assume 4 or 8 points in the curve.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: Alternator control - PID implementation

Post by stefanst »

I probably missed a lot of other discussions on this, but what type of input does your alternator expect? Have you scoped the output from the OEM ECU?
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Alternator control - PID implementation

Post by kb1gtt »

There is a bunch of stuff relative to alternator hardware found here http://rusefi.com/forum/viewtopic.php?f=4&t=747

The control is a 400Hz PWM signal.
Welcome to the friendlier side of internet crazy :)
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: Alternator control - PID implementation

Post by stefanst »

We have to be able to figure out the alternator thing. Can you post a log that shows rpm, vbatt and PID output for alt. control?
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Alternator control - PID implementation

Post by AndreyB »

(trying to clean-up all PID-related messages under one thread)

Still todo: https://sourceforge.net/p/rusefi/tickets/257/ and https://sourceforge.net/p/rusefi/tickets/256/
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Alternator control - PID implementation

Post by AndreyB »

Here are some fresh logs: https://svn.code.sf.net/p/rusefi/code/trunk/misc/logs/2003_dodge_neon/2016-09-11_alternator_pid.7z

rusefi.ini file now has some info on which debug filed is what when:
; Alternator_PID: alternator duty cycle
; DBG_TPS_ACCEL: from TPS
entry = debugFloatField1, "debug f1",float,"%.4f"

; DBG_TPS_ACCEL: to TPS
entry = debugFloatField2, "debug f2",float,"%.4f"

; DBG_TPS_ACCEL: tps<>tps table value
entry = debugFloatField3, "debug f3",float,"%.4f"

; DBG_TPS_ACCEL: extra fuel
entry = debugFloatField4, "debug f4",float,"%.4f"
Attachments
screenshot.png
screenshot.png (40.59 KiB) Viewed 18810 times
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: Alternator control - PID implementation

Post by stefanst »

So until 15.4s everything looks pretty much like I'd expect. P is trying to fight the good fight, but is dealing with a very jittery input signal. I is slowly catching up to get us to where we're going. And since we're not really overshooting, D isn't really called into action much.

I'd say we need more smoothing on the Vbat signal and more aggressive numbers for P and I. There's no overshooting that I could find. So more aggressive it is. I would also use a higher offset value- probably around 20 or so.

Did you turn on some serious loads at 15.4s? RPM drops like crazy, voltage drops and then I is trying to -very very slowly- catch up.
g
And then what happened at 35.7s? All the sudden the PID drops into the basement- almost like it has been reset. Voltage drops at the same time, even though we didn't overshoot and nothing else seems to happen much.

It also looks like your AFRs drop when the voltage drops. May need more lag time compensation at lower voltage.

So:
Edit: 0) Make Vbat signal more smooth. Do it in hardware by adding a cap if you have to. Don't try and fight three different interdependent battles in software if one of them is easily fixed in HW.
1) Find out what happened at the times mentioned: 15.4s and 35.7s
2) Increase offset (maybe to 20?)
3) Increase P- maybe double or triple and see if we get any overshoot
4) When P is tuned (giving us a little bit of overshoot) start working on I
5) Then try and tame the overshoot with D
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Alternator control - PID implementation

Post by AndreyB »

0) let's change hardware filter. What values do we want? At the moment I am using defaults
1) this whole log car was parked. I was playing with throttle manually and changing idle valve position via TS. There is a chance that changing stuff via TS was resetting PID regulator.

just added PID regulator reset counter as debugInt3.
just added idle position into TS log file

actually I've realized that the log above has more info in debug values:
; Alternator_PID: alternator duty cycle
; DBG_TPS_ACCEL: from TPS
entry = debugFloatField1, "debug f1",float,"%.4f"

; Alternator_PID: current integration term
; DBG_TPS_ACCEL: to TPS
entry = debugFloatField2, "debug f2",float,"%.4f"

; Alternator_PID: previous error
; DBG_TPS_ACCEL: tps<>tps table value
entry = debugFloatField3, "debug f3",float,"%.4f"

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

; Alternator_PID: D setting
entry = debugFloatField5, "debug f5",float,"%.4f"

; Alternator_PID: P setting
entry = debugIntField1, "debug i1",int,"%d"

; Alternator_PID: offset setting
entry = debugIntField2, "debug i2",int,"%d"
2) next time will use offset 20
3) did you say "P-"? at the moment it's just one P - see https://svn.code.sf.net/p/rusefi/code/trunk/firmware/controllers/math/pid.cpp - feel free to propose code changes
Attachments
frankenso_vbatt_default.png
frankenso_vbatt_default.png (10.96 KiB) Viewed 18806 times
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: Alternator control - PID implementation

Post by stefanst »

I'd say plop a 1.0uF cap after the 10k resistor. This should give smooooooth values. Maybe a little slow to react, but shouldn't be too bad.
And with "more P" I meant increase the value from 5 to maybe 20?
I'll take a look at those other debugs.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: Alternator control - PID implementation

Post by kb1gtt »

I see C16 C23 C6 C7 are 1uF, so you probably have this value on hand. That would make a 10 HZ low pass filter, it's step reaction time would be about 0.05 seconds until it was 99.5% accurate. So it's reasonably fast, but perhaps getting a bit slow, as your alternator can move that voltage quite allot in that amount of time.

I see C10 C104 C11 C12 C13 C14 C165 C18 C20 C211 C24 C251 C291 C355 C356 C357 C471 C601 C602 C603 C604 C701 C702 C9 are 0.1uF. If you want a try a filter with a lower filter knee, you could try a 0.1uF which would be a 100 HZ filter knee, it would have reaction time of 0.005 seconds until 99.5% accurate, and the filter knee would be 100HZ.

The original filter has a filter knee of 1kHz and a reaction time of 0.0005 seconds. I had chosen the original values such that I got pretty much all the valid analog data into the STM, then software could choose what to toss out. I know you can make pretty much brick wall low pass filters with very consistent signal delays. This is not possible with physical components, as they will always have variable signals delays. Also if you have the CPU cycles to spare, not only is it more flexible allowing you to adapt the filter via software if you have a problem in the field, it also allows you lower cost MFG costs as you have less components to keep track of. However materail costs are minimal for this kind of thing, so that doesn't really apply until you hit larger qty which we are not likely to reach.

Any how, feel free to change it up. If it works and makes things better, we can change the BOM as required. I encourage the higher filter knee, such that you get the ability to pick and choose in software. However I understand the get it done approach. Why spend hours in software if you can do it in seconds with an iron.

Once you get a more smooth VBAT, you might want to try the ON/OFF control again. I suspect this noise was your problem with ON/OFF control.
Welcome to the friendlier side of internet crazy :)
stefanst
contributor
contributor
Posts: 703
Joined: Wed Feb 17, 2016 12:24 am
Location: USA 08530

Re: Alternator control - PID implementation

Post by stefanst »

If we're running the loop only every 100ms, I think taking 50ms (0.05s) to get to 99.5% accurate should do the trick.
I agree that the smoothing should be done in code in the end. For now I vote for the KISS principle....
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Alternator control - PID implementation

Post by AndreyB »

C320 is now 0.1uF, R323 unchanged.
offset always 20
P=20 did not go well as you see
P=10 seemed better in terms of reacting to RPM, but...

I had intermittent wipers on by mistake in the beginning and you can see how one swipe of wipers drops voltage down. Later I was playing with headlights, again - turning headlights on or off is not handled nicely.

But as I said, handling RPM changes seems to be better, or am I making this up?

https://svn.code.sf.net/p/rusefi/code/misc/logs/2003_dodge_neon/2016-09-18_22.09.53_alternator_pid.msl.7z
Attachments
screenshot.png
screenshot.png (49.8 KiB) Viewed 18775 times
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: Alternator control - PID implementation

Post by AndreyB »

stefanst wrote:These are not the msl logs I'm looking for.....
Sorry. Link fixed, will remove these messages in a bit.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Post Reply