PID throttle/speed control

[mgeerts]

Background:
I am currently writing control firmware for a machine that is powered by a honda engine through a hydrostatic transmission. The transmissions is infinitely variable and has a throttle control on it (the motor has no throttle control, it just runs at 3krpm).

Attached to the throttle on the transmission is a DC motor with encoder. I have developed the required PID controls to accurately move the throttle motor.

Attached to the machine is a speed sensor. I have developed the required firmware to accurately measure the speed. The load on the system is randomly variable so a constant input and throttle does not result in constant RPM.

Requirements:
I need to develope a PID controller that will take the RPM of the machine as a process variable and the position of the throttle motor (setpoint feeding the throttle PID) as a manipulated variable.

The problems:
The task at hand is quite simple except that there are two problems...
1. The coupler between the motor and the throttle is horrible and has about as much lash as the total range of motion of the actual throttle. ie, the throttle has a 13 degree range of motion, but in order to change directions the motor has to rotate about 10 degrees before the throttle starts to move the other way.
2. The throttle response is non-linear. I would guess that it is nearly exponential, running about half output speed at 90% throttle.

I am not very worried about the non-linearity. What I'm wondering is how to produce a PID control that can handle the lash in the coupler without huge overshoots. The motor can settling on any position in less than 1 second but the RPM only needs to settle on the desired setpoint in 10-15 seconds.

Any suggestions?

Thanks,
Matt

(I have been writing firmware for nearly 3 years in a custom electronics company. I have done PID motor controls on multiple projects, but they usually very straight forward motor speed/position control)

 

[roydm]

First of all you have to remove all the slop in your linkages, you will never get the PID to work with all that play.
If you have a simple link lever arrangement between the throttle and the motor you can change the angle of one lever to give a more non-linear response.
If you have a cam on the motor you can change the cam profile.
Regards
Roy

 

[itsmoked]

Ah.. I beg to differ Roy.

You probably can get it to work. It will take a lot of screwing around though. You may end up with something that's not even a PID but just full digital psychotrol.

I'd try doing a standard P control to prove the concept but deal with the slop automatically. Since you seem able to quantify it well just run the P but in the control add and subtract the play depending on which way the control variable needs to swing. So toss in the lash to the actuator drive every time the control needs to reverse.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[mgeerts]

Thank you both for your responses.

Roy, for now the linkage will have to remain sloppy. "They're working on it" (aka, fixing it costs money, so deal with it because we're not paying you extra for the time to deal with it). This is a direct coupler between a rotating throttle shaft and the motor. No cams, no arms, etc. The slop exists because they are connecting the motor to the throttle shaft using a modified swivel head from a 3/8th drive socket set. The mounting can't guarantee perfect axial alignment with 0 runout, so they went with a sloppy option. I'll start pushing them to deal with this issue.

Keith: Straight P control? Wouldn't that result in a slight movement into the slop area and then stopping regardless of the incorrect RPM? Maybe I have confused myself. Should my PID controller be spitting out an expected throttle position, or the expected rate of change of throttle position? (By all means call me a beginner at PID). I don't really want to add a mess of "if" statements to the code, i'd rather a control algo just take care of it. Settling time does not always have to be consistent and there's a lot of room for settling.

 

[itsmoked]

I'm not advocating for just a P controller. You definitely need a PI possibly even PID. I was just saying if you can get a simple P to function correctly you should be able to get PID to work too. If you want to dive in at the deep end go ahead, it might not be much harder.

Yes! The expected throttle position is what you're commanding. If you pulled a PID controller off-the-shelf you would be screwed as Roy suggested. But, since you are able to write the algorithm yourself you can add whatever features and tweaks you need. All I'm saying is changes in commanded direction need to have the lash offset added to them.

You run your PID normally. The numbers running in it are all what you'd expect. You just look at the direction shift and add the needed lash offset before actually commanding the throttle. And, YES! You will damn well need to use IF statements. Who cares? They're cheap. You can't generally run good product specific control without them.

Doing it this way will allow you to keep a relatively sane PID with the lash addition. When they stop screwing around and fix the lash issue you then just drop the lash adding/subtracting code.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[Compositepro]

It is possible to develop control algorithms to compensate for slop but in most cases that is more complicated and expensive than getting rid of the slop. In your case it could be as simple as putting a spring on the throttle so the load on the coupling is always one direction.

If you are a carpenter a hammer is the solution to every problem. It you write software...

 

[mgeerts]

Compo - best advice ever... use a hammer!
Here's another wrench for you: I can't use a spring because it is controlled by a DC motor running on battery power w/solar charge. The constant draw required to keep the throttle in place would kill my power requirements!

Roy, would this lash compensation happen between the RPM PID's output and the Throttle PID's input?

So lets say the throttle encoder returns 0-1200 and the lash is 200 encoder counts (the actual throttle motion is 1000 counts). The throttle position is 0-100%. In its starting state, the throttle has been driven down to zero so the lash must be compensated for immediately.

Required throttle % / filtered encoder setpoint
0 / 0
10 / 300 (10% of 1000 is 100, plus 200 for lash)
20 / 500 (lash is accounted for)
30 / 600
20 / 300 (600 - 100, -200 for lash)
40 / 700 (300 + 200, +200 for lash)

Does this make sense?

 

[waross]

Don't use a spring return. Use a spring across or over the coupling to keep the slack taken up in one direction.

Bill
--------------------
"Why not the best?"
Jimmy Carter

 

[Compositepro]

There is no gear reduction on the motor? That would not be wise at all. You would be constantly turning through the dead band and using power all the time.

 

[roydm]

As Waross says remove the slop by biasing the throttle closed with a spring or Bungee cord wrapped around the shaft between motor and throttle
Roy

 

[eeprom]

I have seen a similar problem in a small electric tractor. In the tractor, the throttle cable turned a pot (which was not in the throttle handle), and the variable leg of the pot went to the DC motor controller speed reference. So, I should ask, how are you measuring the throttle position? I would assume that the throttle is turning a pot somewhere. And that pot is serving as a voltage reference. Is it possible to directly read the pot voltage?

EE

 

[mgeerts]

Valid questions and suggestions, thanks.

The position feedback is on the motor only. There is an encoder on the back of the motor and a gearhead on the front connected to the sloppy coupling then to the throttle. Due to the encoder/gearhead combo I have very fine control of the motor (500ppr quadrature = 2000counts per rev, times 48:1 gearhead = 96k counts per rev).

In my last reply, I address Roy about the slop compensation, I meant to address Keith.

 

[mgeerts]

Keithe, I have a pretty basic PID question for you. I asked you before if I was controlling throttle position, or controlling rate of change of throttle position. You said "Yes! The expected throttle position is what you're commanding."

That got me thinking. When my error reaches zero, if i'm using a P controller as you suggested, then my output would be zero... How is that controlling the throttle position directly (unless my setpoint is zero!). Does it make more sense that I should either be using a I-only controller, or using the output as a "rate of change" of throttle?

Maybe I just need a lesson in PID.

 

[BobM3]

When error equals zero, your throttle (or in this case your motor) is at the commanded position so you don't want any more output. I.E., if you command 100 pulses clockwise and you've moved 100 pulses clockwise your error would be zero and you would not want to command the motor to move any further.

The integral term, I, would help if you had some friction in the system. Say you commanded 100 pulses and moved 90 pulses. The error would be 10 pulses. If the gain was small and the friction was high enough then the command to the motor for that error might be too small for the motor to overcome the friction. The integral term would keep increasing the command (for a constant error) until the motor could overcome the friction.

 

[mgeerts]

Bob, thanks for the clarity. So my PID output is actually "how much to move the throttle" not "where the throttle should be moved to". That's cool.

The throttle actually has its own tuned PID position control that runs at a much higher frequency than the RPM control is going to run.

 

[BobM3]

Yes, that is correct. The PID uses Command, Feedback, and Error where

Error = Command - Feedback.

The PID output signal to the motor is Error x gain (and/or integral (I term) of Error and/or rate of change of Error (D term)). Some PID controllers allow you to apply the Rate term (D) to either the Error or the Feedback.

 

[mgeerts]

Thanks. I've got those basics down. I have done some PID control in the past, but generally it is motor position or speed as the process variable and speed as the manipulated variable, everything being counted in the same units. This is the first time i've taken in a machine's output speed and had to control its throttle. The change in "measure" has confused me

 

[itsmoked]

Hi mgeerts.

BobM3 stated it all very well. You seem to have it now.

Also your 'lash' examples above are exactly what I meant.

I worked on a a guy's CNC router that has a failing gear box with insane lash. The software for the machine lets you input the lash amount. Whenever the tool reverses direction the controller has to add or subtract the lash from the commanded position. Same as you have it above.

If you add that after the PID you can adjust it separately from the PID and that means adjust it down to 'gone' when they get their act together.

The problem with a crappy throttle setup that causes lash is not so much dealing with the lash but dealing with different lash for each and every unit that comes down the line. Each unit will have a different amount of lash and so will need individual setup. Then if the lash changes with wear it will need re-adjustment.

You could possibly create a self adjusting lash algorithm. On start-up you command some fixed low speed. Then slowly reverse to a slightly lower speed like 1 RPM you note how far the throttle has to go to cause a change, reconfirm back the other way. Then you hand that lash value off to the PID back-end lash compensator. Might work.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[mgeerts]

Thanks Keith,

Luckily, I should only have to deal with lash on the prototype. Calibration mode won't be an option. This is a large piece of agricultural equipment and you can't really just "toy" with the revs - testing is really combersome, even.

I think we can call this case-closed. Thanks for your input everyone. I'll deal with the non-linearity if it turns into a problem.