Re: Speed PID Function
 

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.

Re: Speed PID Function
 

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

Re: Speed PID Function
 

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.

Re: Speed PID Function
 

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.

Re: Speed PID Function
 

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.

Re: Speed PID Function
 

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

Re: Speed PID Function
 

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 :

Re: Speed PID Function
 

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.

Re: Speed PID Function
 

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?

Re: Speed PID Function
 

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.