Speed PID Function

[davidthefat]

May I suggest using a different unit than RPM? The input is in the range of hundreds and thousands, but the output is from -1 to 1. If you were to use FPS instead, which would be 0 to 14 FPS or so at maximum, you will get more stable outputs since you do not have to use such tiny constants.

[Ether]

Originally Posted by davidthefat

you will get more stable outputs since you do not have to use such tiny constants.

Are you suggesting that round-off errors using double precision floats cause instability if using RPM?

[davidthefat]

Originally Posted by Ether

Are you suggesting that round-off errors using double precision floats cause instability if using RPM?

Perhaps, wrong choice of words. Consider this: if the system can, in fact, go up to 1000 RPM, the initial error when starting up from rest is 1000 RPM. In order for you to get the appropriate output from -1 to 1, your P constant will need to be about 0.0001. Now, that is not accurate at all, but trying to demonstrate that the constant will need to be tiny. But if that same system was measured in FPS (You are using RPM to derive this, so it will be the same accuracy as measurement), you will only be getting FPS up to 14 FPS at most. You have less of a range to work with, so the P can be about 0.1 instead. I was just pointing that out because his picture showed the P to be 0.3, which is way too big for a system measured in RPM. Just tuning it would be easier and I doubt the round off will have much errors using doubles.

Of course, always check your inputs and outputs to be in range.

[vamfun]

Originally Posted by Ether

Can you address this in a bit more detail?

Are there some fairly simple tests that a team could do to obtain this number?

Or do you recommend calculating, and if so it might be helpful to do a blog entry on that or post some example calculations here.

note-velocity-pid-loop


This note on Velocity PID controller addresses your questions on how to obtain the open loop motor time constant tau_m. If testing is available always use that source since there is really no such thing as a spec motor. However, I use spec data to precompute gains since the gains will be adjusted anyway when we optimize the loop gains during integration testing. Often , very little adjustment is needed.

The note also comments on various ways to implement a PID loop in software.

[Ether]

Originally Posted by vamfun

note-velocity-pid-loop

Thanks.

A couple of suggestions:

The figure is barely readable. Can you upsize the resolution, or provide a vector graphic option?

Also, you might want to clarify that what you are calling the "motor time constant tau_m" is not the time constant of the motor itself, but the time constant of the plant (motor plus whatever it is driving). It's slightly confusing on first reading.

[vamfun]

Originally Posted by Ether

Thanks.

A couple of suggestions:

The figure is barely readable. Can you upsize the resolution, or provide a vector graphic option?

Also, you might want to clarify that what you are calling the "motor time constant tau_m" is not the time constant of the motor itself, but the time constant of the plant (motor plus whatever it is driving). It's slightly confusing on first reading.

Ok, added the plant stuff. BTW, you just click on figure to see it full size.

[Ether]

http://vamfun.wordpress.com/2012/02/...city-pid-loop/

"Apply a normal PID loop with speed as the input, set the D term to zero and have a high integration gain , KI, that responds quickly to the error and holds the speed reference when the error goes to zero. The integrator must have full authority in this case. KP is adjusted to add damping and minimize the overshoot. This is the method I recommend and was the basis for the last post on precomputing PID gains."

Caveat:
The following is an excerpt from a post dated 01-14-2012 in the thread titled 2012: Tuning the Jaguar's Speed Control PID Loop :

Originally Posted by Mr. Lim

The I-term appears to be capped. Theoretically, even a small I-term should cause the speed control loop to reach its setpoint eventually. It might take a long time, but it should reach the setpoint, given enough time.

It does not.

What we're seeing is the maximum speed we can achieve is directly proportional to the I constant.

This is unfortunate, because we have been able to find some I-constants which appear to work beautifully, however since the I-term is capped, we can never quite achieve our top speed.

Capping the I-term is usually a great way to ensure our PIDs don't wind up too much, however in this case, it's inhibiting us from ever getting to our top speed.

[vamfun]

It has been a while since I looked at the JAG cpp ... what is the actual limit they impose? The WPILIB PID integrator limits are ok.

Also, since I have been nursing a cold over the weekend, I decided to expand a little more on the PID loop driving a torque controller. This is a subcase of the PID with feedforward but it has a nice topology that allows direct control of torque. This is basically the back emf approach discussed earlier in this thread. I wanted to show a method for precalculating PID gains in this case.

Note: Velocity PID loop driving a torque input


I also cleaned up the velocity control loop figure and added a few comments to my last notes. The addiditons are mostly highlighted in color.

[Tom Bottiglieri]

Originally Posted by vamfun

note-velocity-pid-loop


This note on Velocity PID controller addresses your questions on how to obtain the open loop motor time constant tau_m. If testing is available always use that source since there is really no such thing as a spec motor. However, I use spec data to precompute gains since the gains will be adjusted anyway when we optimize the loop gains during integration testing. Often , very little adjustment is needed.

The note also comments on various ways to implement a PID loop in software.

You note that tau_d = tau_m/r. How does one find R? Do we just choose this? If so, what is a reasonable choice?

[vamfun]

Originally Posted by Tom Bottiglieri

You note that tau_d = tau_m/r. How does one find R? Do we just choose this? If so, what is a reasonable choice?

Tom, tau_d is the time constant of your closed loop system.... and that is your choice... usually it is driven by the timing constraints of the shooter design. As in the example at the end of my note we wanted the shooter to be within 5% (I had a typo of 1%) of the target speed in one second. Since this is a first order exponential response the output will have a step response of

v_out = v_in*(1 - exp(- t/tau_d) .

The % error as a function of time is err% = 100*exp(-t/tau_d);
t= tau_d , err%= 37
t=2*tau_d, err% = 14
t=3*tau_d, err% = 5
t=4*tau_d, err% = 2
t=5*tau_d, err% = .7

So to meet the 5% in 1 second we needed 3 time constants to elapse which means 1 sec = 3*tau_d. So tau_d = .333 seconds and that in turn drives r the ratio of tau_m/tau_d.

It is important to note that you must have excess torque to take advantage of the gain increase caused by the PID loop. Our nominal target speed for the key is around 2000 rpm. So we designed the the max speed to be 2.5 times the nominal.

In general, you have a feeling for how much you want to speed up the response of your system. It is this ratio that determines r. Of course r has bounds like any amplified system. I like to keep it under 5 and nominally about 3.

Edit:
The pole/zero placement method I described gives you a lot of gain margin so usually the limiting factor is not stability but rather system saturation caused by large command changes or noise in the command signal. Saturation makes the system nonlinear and the response can no longer be predicted by tau_d. High frequency noise is amplified by KP and can be unevenly rectified by saturation causing a bias offset the error signal and unwanted current transients. So it is difficult to generalize about what gains are tolerable. I know 254 has lots of experience with PID loops and you might share what your experiences are relative to tolerable gains in a velocity loop.