NI Labview PID Encoder Feedback

[Captain Planet]

My team has been trying to create a PID loop with encoder feedback to control our shooting arm this year. However, the motor output has been very erratic, fluctuating wildly. If we set the P, I and D values very low, (ie 0.001) it slows down, however, it is still not very accurate. Below is the VI we have been using for testing. Could someone provide a little guidance?

[Iaquinto.Joe]

You should be using the rate from the encoderget.vi as opposed to the distance. Additionally, the EncoderOpen.vi distance per tick should be calculated based off your encoder ticks/rotation divided by the circumference of your wheel. The NI PID provided does not work with rates, only distances. Because you are measuring a rate, the PID behaves differently. Distance I becomes Rate P; and Distance P becomes Rate D; Distance D becomes Rate D'. I have a custom PID from team 51, Wings of Fire, that allows you to use a rate PID, but I will have to ask them if it's okay to post here or give to you.

Hope I can help!

[plnyyanks]

Originally Posted by Iaquinto.Joe

The NI PID provided does not work with rates, only distances. Because you are measuring a rate, the PID behaves differently.

Where did you get this idea? The PID VI is entirely mathematical - it doesn't care what the inputs are, all it does it brings the error of the system (Setpoint - Process Variable) down to zero. It will work exactly the same with encoder rates and distances, provided that the SP and PV are scaled the same way (and the constants are tuned properly). I'd be more than happy to explain how some of the math works, if you'd like.

As for your specific system issues, it just looks like the constants aren't tuned properly. Read a little bit about PID Theory (also: wikipedia) and take a look at some tips on designing a good controller (the rest of that page is helpful too). You may also want to start with the Ziegler-Nichols method for tuning (start with all zero, bring P up until it oscillates, add D to dampen and add I to correct for steady state error.

Just another note - if I remember, the LabVIEW implementation of the algorithm doesn't use Kp, Ki, and Kd as straight constants. It actually uses time constants for I and D (so it has Kp, Ti, and Td). You can see details of the NI implementation here. You can verify this in the help popup (ctrl-H) for the VI. Plan your constants accordingly.

Originally Posted by Iaquinto.Joe

Additionally, the EncoderOpen.vi distance per tick should be calculated based off your encoder ticks/rotation divided by the circumference of your wheel.

You do need to do this though - remember what I said above about proper scaling? That will put the output of the Distance from your encoder Get to be in realistic units (depending on how you scale it).

Also, what is that .02 constant doing? Is it wired to dt? You can delete that - the PID VI will calculate it for you if unwired.

[Iaquinto.Joe]

We weren't very sure on how the time constants worked, but we all knew how the traditional constants worked. I guess you could use the NI PID, but the traditional kP kI and KD constants were easier for us to work with. I really like the diagrams and explanations though, I think I'll break them out the next time I'm explaining PIDs to the team

[Joe Ross]

Originally Posted by plnyyanks

Where did you get this idea? The PID VI is entirely mathematical - it doesn't care what the inputs are, all it does it brings the error of the system (Setpoint - Process Variable) down to zero. It will work exactly the same with encoder rates and distances, provided that the SP and PV are scaled the same way (and the constants are tuned properly). I'd be more than happy to explain how some of the math works, if you'd like.

Here's a thought experiment for you. When you reach a certain distance, you want the output to be 0. When you reach a desired setpoint of 50% speed, what do you want the output to be?

[Captain Planet]

Thank you to the people who have posted, I will try your suggestions as soon as I can. However, it seems there is some disagreement, so I'll pose a more specific question. If am I to use a PID loop to control the angle of our shooting arm, should I get the rate output or the distance output from the encoder? As I understand it, the rate becomes 0 as soon as the motor stops moving, so I'm uncertain as to how I'd implement moving the arm to a specific angular position with it.

[Joe Ross]

Originally Posted by Captain Planet

However, it seems there is some disagreement, so I'll pose a more specific question. If am I to use a PID loop to control the angle of our shooting arm, should I get the rate output or the distance output from the encoder? As I understand it, the rate becomes 0 as soon as the motor stops moving, so I'm uncertain as to how I'd implement moving the arm to a specific angular position with it.

I think the disagreement came because of the ambiguity of shooting arm. Now that you clarified you want angle, you should definitely be using the distance.

[plnyyanks]

Originally Posted by Iaquinto.Joe

We weren't very sure on how the time constants worked, but we all knew how the traditional constants worked.

If you take a look at the implementation, it explains how the time constants relate to the traditional ones.

Here's the overall function:


The P component (Kc * error):


I [(Kc / Ti)integral(e)]:


D (Kc * Td * d(error)/dt ):




So, if you take a simple version of the formula like below...

Then:
Kp = Kc
Ki = Kc / Ti
Kd = Kc * Td

Make sense?