PID control discussion

[AbeFM]

Partial sucsess so far. I uploaded my code, the valve seems to open when rpms are too low, close when they are too high, and sit still when you're on target. If y ou're way high it moves quickly, if you're a little high it continues to close over time to max and stays there.

If you jerk the RPM, the derivative term takes over, and it will even open the valve while the RPM is too high - slowing the decent.

It was a bit fast, so I had to run 250 ms loop times with kx terms ~2-10. I divided by twenty and when I compiled I got way more memory issues durring compile, so I'm going back to my version 7 (unposted) which seems to work on the stim.

Going to try it on the car now.

[thebigmacd]

Excellent!

Sorry I goofed in my pseudocode...I had to read someone else's translation to catch my own mistake

This is why code review requires at least two people.

If you jerk the RPM, the derivative term takes over, and it will even open the valve while the RPM is too high - slowing the decent.

What you should find with a decently well-tuned system is it will catch the engine a hundred rpm or so before it gets down to setpoint, then sink down to setpoint. Although I recommend reducing Kd as much as possible, it will prevent the rpm from overshooting if tuned right.

[shameem]

If y ou're way high it moves quickly, if you're a little high it continues to close over time to max and stays there.

You have to set the "gain" term and tweak the overall Kp, Kd & Ki values in order to get a satisfactory response when error is small. In short - high proportional gain (Kp) will provide much faster response - but will also make it overshoot the setpoint - Higher Kd will make it somewhat slower and reduces the overshoot.

If you jerk the RPM, the derivative term takes over, and it will even open the valve while the RPM is too high - slowing the decent.

That might be due to the controller bouncing off of the limit values (0%, 100%) - to avoid that you will have to consider the derivative of the feedback as well -
http://www.jashaw.com/code2.html

[AbeFM]

Thanks for the pointers....

It seems the kP term is just to big, something between 0 and 5 is right.

The integral and derivative terms dominate unless I slow it down (>250ms/loop), and when I do, I need to prop term to be very low.

I tried doing something where I divide everything by 20, but somehow that caused massive errors with the memory, which I still don't understand. The old way works, but either way I keep running into issues where it's on various imposed limits from the MS....

I'll mess with it more later. Right now it's oscillaty as hell, but I can't get small values so I guess I;m stuck with it.
Had to get drunk with friends, what can you do..

[shameem]

PID tuning is a b**** - especially when its being done digitally with sample/hold.....
http://www.expertune.com/tutor.html
http://www.jashaw.com/pid/tutorial/pid6.html
http://www.omega.com/temperature/z/pdf/z115-117.pdf

If you can get some math model of the valve (which should be relatively simple)
http://www.pidlab.com/applety.php?id=8

[AbeFM]

Well, basically, it would be totally dominated by the temporal terms (I, D), until I slowed the loop down from 75 ms to a few hundred. Then the proportional term would make it oscillate. basically, following a trend, it would have been great to have P=1, I = 0.2, D = 0.1 or so. But since they were ints, that made them all zero.

So I did this:

Code: Select all

				ztrans_idle_error_array[0] = targ_rpm - outpc.rpm;	// Error is target - actual, removed typecasting


//output of the form: OUTPUT += Alpha * Error[0] - Beta * Error[1] + Gamma * Error[2]
//Note subtraction of the beta term prevents kP term from summing to infinity
                            tmp1 = (int)(((20 * (long)IACmotor_pos) // Compensate for Ki, etc, being big
                            				+ (z_alpha * ztrans_idle_error_array[0])	//this is the "now" part
                            				- (z_beta * ztrans_idle_error_array[1])		//this is the "last time" part
                            				+ (z_gamma * ztrans_idle_error_array[2]))	//this is contribution from 2 loops ago
                            				/ 20);	//Compensate for larger values of kx

(Which I think is kind of ugly)

But now I'm thinking it might be faster to do this:

Code: Select all

				ztrans_idle_error_array[0] = (targ_rpm - outpc.rpm) / 20;	// Error is target - actual, removed typecasting, make smaller (20x) changes for a given set of gains


//output of the form: OUTPUT += Alpha * Error[0] - Beta * Error[1] + Gamma * Error[2]
//Note subtraction of the beta term prevents kP term from summing to infinity
                            tmp1 = (int)((long)IACmotor_pos) // This is the "+="
                            				+ (z_alpha * ztrans_idle_error_array[0])	//this is the "now" part
                            				- (z_beta * ztrans_idle_error_array[1])		//this is the "last time" part
                            				+ (z_gamma * ztrans_idle_error_array[2]));	//this is contribution from 2 loops ago

[shameem]

Multiplying and dividing the process variable or error is not a good solution - you may fortuitously hit a good tuned spot for _your_ setup with the _current_ conditions for a _period_ of time. Any slight change anywhere in the system (e.g. hysteresis) - you will have to go through this process all over again. My lab instructor back in my college days used to yell at me for doing that.

If you find yourself having extra time - maybe play with this - might be easier to tune - since it correlates the parameters with time response...

calc_change= (Proportional*(Error[0] - Error[1])) + (Reset * Error[0]) + (Derivative * (Error[0]- (Error[1] *2) +Error[2]))

//Proportional is usually "1" - makes things much simpler
//Derivative -> Derivative value in minutes (kinda like delay in minutes)
//Reset -> reset rate in repeats per minute

It is the exact same version of the equation you used - just written differently....

tmp1=(int)((long)IACmotor_pos) + Kc *(calc_change) //Kc is the controller gain

This equation assumes that the loop time is 1 second - for reduced time (e.g. 100ms) i think its either Kc/0.1 or Kc*0.1 (i am not sure about this).

A good way to tune this is start with proportional only - find a good value and then add integral - and then add derivative - but this method was back in the days of 286 computers and PLCs - i dont know if it still holds true....

[AbeFM]

I'll have to look at that a bit more to get it, right now I don't.

The issue with dividing the error is that the closest I can get to stable is 2/factor. I.E. if I divide the error by 20, then there's a 40 rpm window where the idle is basically uncontrolled, and I will just float across there constantly.

The biggest issues are all sorts of lock outs - it's so hard to get it to where it even wants to control, it's hard to tell if it's working. So often if goes to full positive open and stays there, and overrun fuel cut it turning on and off and the motor is going all OVER the place.... I can't see if the terms are doing what I want.

Normally - like with the MS "PID" control, I have to play tricks like drop it in gear and stall the motor till it's stable and enterint PID mode.

If I could get it to ALWAYS be in PID mode, I could better tell if what I'm doing is working.

So, there's two issues, my messing with the algorithm, and my trying to get around the megasquirt enough that I can test.

I guess I'd just like a way to get the valve to close, and to get it to more smoothly transfer from cranking position to PID controlled.

[Fred]

The biggest issues are all sorts of lock outs - it's so hard to get it to where it even wants to control, it's hard to tell if it's working. So often if goes to full positive open and stays there, and overrun fuel cut it turning on and off and the motor is going all OVER the place.... I can't see if the terms are doing what I want.

Turn OFF the overrun control, etc etc. Tune that region of the ign and fuel tables such that with a fixed pwm (easy to implement now for you) you can stab at the gas, partially release the clutch, turn on stuff and off again and it recovers gracefully after the load is removed without doing anything funky. You need the engine tuned first. I don't know if it is, but last time you told me anything about this, you said it was barely tuned or not tuned. You need a smooth nice tune before you try to do things like this.

Lock outs should be easy to disable shouldn't they?

Fred.

[AbeFM]

Yeah - the only trouble is you can never really tell what's happening. None of it is logged or output in any way, so it's only by knowing each and every single thing the MS might do that you can guess why it behaves a given way at a given time.

I assume I'm hitting over-run fuel cut since pulse widths go to zero after a set number of seconds, and seems to come back at a repeatable RPM.

It would be awesome if there was something to tell you when the modes were being fucked with, but there isn't.

At least, yes, the motor behaves very nicely. Which is why I've let the idle thing go for so long. Basically, the set idle thing works incredible, only I have to idle at 950-975 such that when it's cold out, my headlights are on, or any other perturbation, it doesn't drop more than 200-250 rpm. If there were a PID-ALWAYS-ON, and a SPARK-AND-FUEL-TABLES-ONLY, I'd know what was going on in like eight seconds. Secondly would be a way to keep an eye on either the error terms, or something.
-Abe.