PIDs out of control

[wildaburk3160]

After getting our drive system running, we've run into some trouble with our PIDs.

We have four independent steering modules each with a potentiometer, all run by PIDs. We've gotten them successfully working as a crab drive/ being able to rotate.

However, one or more motors will occasionally rotate, spinning out of control without any input from a driver. I'm not sure what would cause this issue if, for the majority of the time, the code does what it's supposed to just fine.

I'm at a loss as to what would cause this issue. Any ideas?

[Ether]

Originally Posted by wildaburk3160

We have four independent steering modules each with a potentiometer

A pot can only turn so far. How are you dealing with this limitation in your software?

[gpetilli]

Originally Posted by wildaburk3160

After getting our drive system running, we've run into some trouble with our PIDs.

We have four independent steering modules each with a potentiometer, all run by PIDs. We've gotten them successfully working as a crab drive/ being able to rotate.

However, one or more motors will occasionally rotate, spinning out of control without any input from a driver. I'm not sure what would cause this issue if, for the majority of the time, the code does what it's supposed to just fine.

I'm at a loss as to what would cause this issue. Any ideas?

Unexplained failures have a habit of returning at the worst possible moment - yes it is an issue. One common intermittent stability error is as you rap around from 360 to 0 degrees (and 0 to 360), you may introduce a toggling of the sign and magnitude of the error signal. I would start looking at the way you wrap around the circle.

To Ether's point, I assume you are using one of the newer "absolute encoder" http://www.andymark.com/product-p/am-2899.htm for the feedback? If not, you should consider something similar that will not be damaged if you over rotate. Again, this device will have a "discontinuity" at the 360->0 point that needs special consideration.

[Ether]

Originally Posted by gpetilli

To Ether's point, I assume you are using one of the newer "absolute encoder" http://www.andymark.com/product-p/am-2899.htm for the feedback? If not, you should consider something similar that will not be damaged if you over rotate. Again, this device will have a "discontinuity" at the 360->0 point that needs special consideration.

I assumed he is indeed using a pot (as he said). Some pots have no mechanical stops, but they have a small "blind spot". If his controller is being commanded to an angle within that blind spot, I can imagine how that might make the controller go nuts, especially if his angle error computation is not finding the shortest angle.

[awallace3160]

(OP on a fellow programmers computer here)

We are using 5-turn potentiometers and they are only intended to rotate 180 degrees maximum. We try to make sure that the pots are set to rotate near the middle of each ones range so as to avoid over rotating them if they go a little bit beyond the desired setpoint.

We are using the PotentiometerGetNormalized.vi to get our values, which return as a percentage of the total voltage, we have found. So, we are trying to return 3-4 decimal accuracy on each potentiometer.

So, I'm not sure if our program trying to reach this accuracy is hitting the pots' "blind spot" or not, because I'm not absolutely sure what that means.

[Ether]

Originally Posted by awallace3160

We are using 5-turn potentiometers and they are only intended to rotate 180 degrees maximum.

It's not clear what you mean. It could be interpreted at least 2 different ways:

1) The wheel is currently at 179 degrees and it is being commanded to go to -179 degrees. The controller will rotate the wheel 358 degrees counterclockwise to get to the commanded angle, because the controller does not want to exceed 180 degrees.

or

2) The wheel is currently at 179 degrees and it is being commanded to go to -179 degrees. The controller will rotate the wheel 2 degrees clockwise to get to the commanded angle, because that is less than 180 degrees movement.

Which of the above descriptions is what you intended? (or something else?)

We try to make sure that the pots are set to rotate near the middle of each ones range so as to avoid over rotating them if they go a little bit beyond the desired setpoint.

When you process the signal from the pot, do you let the signal go beyond 180 degrees? Or do you constrain it to be in the range +/-180 before using it? In other words, say the pot is at zero degrees, and then gets moved 181 degrees clockwise. Will your processed pot reading be +181 degrees or -179?

We are using the PotentiometerGetNormalized.vi to get our values

I don't know what that means, but it sounds like it is converting the pot reading to +/-180 degrees. If such is the case, depending on your code that could make the controller go nuts. I suggest you post your code for review.

So,I'm not sure if our program trying to reach this accuracy is hitting the pots' "blind spot" or not, because I'm not absolutely sure what that means.

If you've got a 5-turn pot and you are centering it and avoiding over-rotating, there should be no blind spot (a dead area where there's no usable signal).

[wildaburk3160]

From what we've gathered, the PotentiometerGetNormalized.vi gets the voltage reading from the potentiometer and returns it as some sort of proportion of the total possible voltage. It seems that 90 degrees ~ .1 change in the returned value.

So, if we were to set our "midpoint" at the middle of the pots rotational range, we would set our setpoint to .50. Our goal then is to rotate at maximum 90 degrees in either direction from this point. Theoretically, this should change the value by .1, but it has a small variation, so we have it set to where we manually control the "maximum" and "minimum" values of the pot.

None of these values we have set come up near the extreme values of rotation, which would either be "0" or "1".

We haven't thrown in any limitations to rotations in the program other than how far we can change the setpoint, but I will soon implement something.

[Ether]

Originally Posted by wildaburk3160

the PotentiometerGetNormalized.vi gets the voltage reading from the potentiometer and returns it as some sort of proportion of the total possible voltage

As I said, I am not familiar with PotentiometerGetNormalized... but for a 5-turn pot, 1/4 of a turn (90 degrees) would be (1/4)/5 = 0.05 of the total range.

[wildaburk3160]

Well, regardless of it's particular function, do you have any other ideas as to why this problem is occuring?

[Ether]

Originally Posted by wildaburk3160

Well, regardless of it's particular function, do you have any other ideas as to why this problem is occuring?

It's either hardware or software. Here's a good way to find out if it's software:

Originally Posted by Ether

I suggest you post your code for review.

[GeeTwo]

Originally Posted by Ether

It's either hardware or software. Here's a good way to find out if it's software:

And to help figure out if it's hardware, it would help if we understood just what hardware you're using, how it's connected, and how it's supposed to work. Including links to spec sheets would also be helpful!

[1uan]

However, one or more motors will occasionally rotate, spinning out of control without any input from a driver. I'm not sure what would cause this issue if, for the majority of the time, the code does what it's supposed to just fine.


you may want to check your PID gain values, a method you may want to use is the Ziegler-Nichols Method https://controls.engin.umich.edu/wik...uningClassical

[Chris Hibner]

We noticed this past weekend that every so often, one of our drive motors will just start spinning at a high speed, even though we had a 0 hard-wired into the Set Motor Output VI. We still haven't figured out the cause yet. The speed controller (a Talon from last year) was green, which signifies that it thinks it is getting a valid speed command. We didn't find any short circuits of any type. We just stopped the code and restarted it, and the problem went away. This makes us a bit nervous. I'm wondering if it could be related.

[wildaburk3160]

Here are the PID Gains:



Now that I am taking another look, they may be a bit high. I was uneasy about how high they were but when they were first tuned it seemed to work just fine, so I let it slide.

[plnyyanks]

Your P value might be a little high, but that will definitely depend on the nature of your system. Here's the implementation math, for reference:

Furthermore, you should read the help doc for the PID VI - it actually uses time constants, so Ti and Td might not behave as you would intuitively belive.



Images from this page

Originally Posted by plnyyanks

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.