Re: PID Help
 

Alright, after another talk with a mentor, it's been clarified that we don't need such exact precision. Our problem was that the motor was overshooting by over 20 pulses at some points, then taking 5-10 seconds to readjust to a reasonable position. So, I will take some previous suggestions about tuning the PID so that we can get the motor returning to a more reasonable pulse count, perhaps +/- 5 pulses, without wildly missing the mark beforehand.

Re: PID Help
 

This sounds like your system is under-damped. Either add a mechanical dampening as suggested above, or (better) tweak your "D" (derivative) value to digitally dampen the system.

Using the analogy of an automobile suspension

• P tells how strong your spring is. That is, how fast does the pushback grow as you get farther from the set point?
• D tells how dampening your shock absorbers are. A large magnitude for D will help the values settle quickly.
• I doesn't have a good auto analogy unless you're a low rider with adjustable lift built into the suspension. I helps correct systems that settle out somewhere other than the set point. I usually think of it as the "Kentucky Windage" term.

Re: PID Help
 

Okay, so I've gotten to the point, with some tuning, that I can get the motor to get to a set point in a good amount of time, but with a maximum error of six, sometimes eight, pulses. With one pulse ~ .73 degrees, this could lead to the wheel being almost six degrees off center.

Since we are planning to run four motors, each with their own encoder and PID loop, this could result in motors possibly being twelve degrees off collectively, and working against each other, rendering a swerve system useless.

My mentor seems to think that the reason the motor can't get to the setpoint in either a reasonable amount of time or a reasonable range (these two seem to be mutually exclusive) because the PID calculates the output out to a very long decimal, but the process variable (encoder pulses) is only giving it integers to work this.

I disagree.

I think that as someone has earlier replied, it is a resolution problem. With .73 degrees per pulse, it gives us very limited margin for error. I believe that this problem could be solved by the use of a potentiometer, a much more precise analog sensor, rather than an encoder, a digital sensor.

So, should we go ahead and try a potentiometer, or am I doing something incorrectly in the tuning of the PID?

Thank you for your continued input.

Re: PID Help
 

Watch this video, especially at 9:03

Re: PID Help
 

This video refers to the gains as Kp, Ki, and Kd. In the PID gains cluster connected to the PID.vi, the I and D terms are labeled Ti and Td, as in derivative time and integral time.

So, are these functioning the same as an Ki and Kd, or are they functioning in some other way?

On another note, I went through the Zeigler-Nichols process described in the video, and after calculations, the Kd I was supposed to have came out to be ~ .0004, which is beyond the three decimal accuracy of the PID gains control. I ended up having to settle for .001.

After some testing, the minimum overshoot averaged around 4 pulses, with varying amounts of greater overshoot. This could have been caused by having to settle for a Td of .001 instead of .0004.

One thing mentioned in the video is sensor lag, where a sensor can't send pulses fast enough for the PID to process it correctly. Could there be an issue of the PWM cables not having a high enough frequency to keep up? Would an analog sensor be a viable fix to this supposed problem?

Re: PID Help
 

Also, after some design changes, there is another reduction and the resolution is now .48 degrees/pulse.

Re: PID Help
 

Forgot you were using LabVIEW. It uses a different form of PID. Check the LabVIEW documentation.

Re: PID Help
 

I do not know LabVIEW well, so this might already be what you are doing/the default behavior, but you should read your encoder in 4x decoding mode. This will effectively give you four times the encoder's CPR in resolution.

I doubt very much that you are experiencing significant sensor lag. Quadrature encoders are nearly instantaneous compared to the time constant of your mechanism.

Re: PID Help
 

They are different. LabVIEW uses the "Academic form" of PID instead of the "parallel form" that most tutorials assume. See the conversion details at the bottom of http://zone.ni.com/reference/en-XX/h...re_conversion/ for some insight into what the differences are and what they mean.

Re: PID Help
 

Aha! Thanks for this Alan. I've been reluctant to use LV's PID because I couldn't relate the gains to the time inputs. Now I see how I could use the conventional gain coefficients that I read about in the tutorials. I didn't know a different perspective existed.

Re: PID Help
 

You can adjust the number of digits the control displays if you right click on it and click on "Display Format...", and mess with the settings there.