PID Help

Technical NI LabVIEW
1

Hey guys, our team is looking into using PID with encoders and implementing them on our drive system. I’ve gotten to the point where I can change the setpoint at will and get our motor to drive an encoder to a specific value, but we cannot seem to get it to do so without a considerable amount of overtravel.

In this code, Distance is the recorded distance in pulses of the encoder. We have calculated that a pulse is equal to approximately .73 degrees travel of the shaft of our motor, so anything more than a pulse off is not acceptable.

http://i.imgur.com/zc2iMgA.jpg

In this code, the left and right trigger buttons are no longer being used. The controller axis is being used to set the setpoint. Since the maximum magnitude of our process variable (Distance) is 124, I have taken the axis value and multiplied it by 124, so a value of 1 on our axis will set the setpoint of our PID at 124.

Here is a picture of our gains, outputs, etc:

http://i.imgur.com/PKx6P7i.jpg

These values are the results of me trying to tune them is such a way that our motor can get to a specified value with a high amount of precision without overshooting, and without taking a long amount of time to adjust the value to an acceptable range.

If anybody has successfully run PID.vi with an encoder with high precision, could you please look and see what I am missing here? And if you have had this type of issue, could you tell me how you resolved it?

Thanks,
William

2

Does this motor have a load on it?
PID hits a target somewhat better when there is some sort of drag to slow it down. An unloaded motor will coast right on by the setpoint until the PID reacts to bring it back where it will probably coast by again.

Why is your output scaled to +/-50 instead of a typical motor +/-1 ?

Have you considered plotting the waveform to visualize how the system is behaving?

3

At the moment, no, it does not.

4

I originally had the output set to full 100/-100 capacity, and was just trying anything to alleviate the overtravel on the system. I haven’t considered plotting a waveform yet.

5

For a test load you can just add something harmless (mostly harmless) to rub against the motor shaft.
Also, setting your speed controller to Brake mode will help a little bit.

6

I am not the most knowledgeable on this subject but, you seem to be taking the distance out of the encoder, since a drivetrain is set up for continuous motion shouldn’t your PID be targeting a specific rate at which the wheels should be spinning? (assuming this is for dynamic input, such as driving in teleop, not autonomous movement) There is a rate output on the encoder, so do you want your code to look a little more like this?

Code: http://i.imgur.com/5Jja5Ce.png

What I have written here may just be a load of garbage. It has not been tested, it just seems logical to me. I tried to comment my thought process.

7

My first impression is that your proportional gain is very high, which is likely to result in lots of overshoot and oscillation. My second impression is that your integral time is very short, which is likely to result in lots of overshoot and oscillation.

Start by setting the gain very low and the times to zero (which will disable the integral and derivative terms). Put the appropriate load on the motor and start increasing the gain until it becomes unstable, then back the gain down again. If you don’t get to the set point in a reasonable amount of time, set the integral time to a value slightly longer than you think it should take to get to the set point, and tweak it from there. You might be able to ignore the derivative term completely.

8

You’re being set up for failure if you’re trying to control to +/- 1 sensor tick. I always aim for getting 10 times the resolution compared to the accuracy requirements.

9

I agree with Joe.

So from the OP, it appears that you are using a 500 pulse encoder mounted directly on the motor shaft? Do you have any gear box before the wheels and what is the ratio? What size wheels? Assuming a 5:1 gearbox and a 4" wheel (~12.56 circumfrence) would give distance resolution of 0.005" Is that really what your accuracy requirement is? I recommend double checking your requirements.

10

I am not the most knowledgeable on this subject but, you seem to be taking the distance out of the encoder, since a drivetrain is set up for continuous motion shouldn’t your PID be targeting a specific rate at which the wheels should be spinning? (assuming this is for dynamic input, such as driving in teleop, not autonomous movement) There is a rate output on the encoder, so do you want your code to look a little more like this?

Code: http://i.imgur.com/5Jja5Ce.png

What I have written here may just be a load of garbage. It has not been tested, it just seems logical to me. I tried to comment my thought process.

I may have not been clear as to what this PID is meant to control. We are planning on a swerve type of drive system, where the encoders are meant to keep the wheels at a set “zero” position and then rotate at the direct control of the joystick, with the max position of 90 degrees calculated out to be the 124 pulses or “Distance” value on the encoder. So, in my opinion, no, the rate of the encoder should not be what I am looking for/ trying to control.

My first impression is that your proportional gain is very high, which is likely to result in lots of overshoot and oscillation. My second impression is that your integral time is very short, which is likely to result in lots of overshoot and oscillation.

Start by setting the gain very low and the times to zero (which will disable the integral and derivative terms). Put the appropriate load on the motor and start increasing the gain until it becomes unstable, then back the gain down again. If you don’t get to the set point in a reasonable amount of time, set the integral time to a value slightly longer than you think it should take to get to the set point, and tweak it from there. You might be able to ignore the derivative term completely.

I will do all of this as soon as possible.

You’re being set up for failure if you’re trying to control to +/- 1 sensor tick. I always aim for getting 10 times the resolution compared to the accuracy requirements.

I’m not sure what you mean by getting 10 times the resolution compared to the accuracy requirements.

So from the OP, it appears that you are using a 500 pulse encoder mounted directly on the motor shaft? Do you have any gear box before the wheels and what is the ratio? What size wheels? Assuming a 5:1 gearbox and a 4" wheel (~12.56 circumfrence) would give distance resolution of 0.005" Is that really what your accuracy requirement is? I recommend double checking your requirements.

We are using a seven pulse per rotation encoder mounted on a gearbox with a 71:1 reduction, so there are 497 pulses per motor rotation. Since we are only wanting to rotate 90 degrees clockwise or counterclockwise, we divide that number by 4, getting 124.25, or for our purposes, 124, pulses.

I want to reiterate that we are using these motors and encoders in the context of mounting them on top of our drive motors and rotating them 90 degrees clockwise or counterclockwise, allowing a “sideshifting” motion, increasing field mobility.

Thank you all for your input, and I hope I addressed all the issues properly.

11

A potentiometer may be a more appropriate sensor.

12

This is true, simply make a mounting bracket for the potentiometer and provide linkage to your swerve module, coaxial is another route that completely circumnavigates this issue.

If youre dead set on using an encoder for your swerve feedback then you should look into tuning your PID methodically and slowly. For high reduction applications like this your proportional will be a pretty small number (0.2 would probably be a good starting point). Ignore I and D until you reach something under control that levels out. Hope you have some success.

13

Most potentiometers will only rotate a certain number of rotations (often about 240 degrees), making them inappropriate to steer a swerve drive. We used a Hall-effect sensor that simulated a continuous rotation potentiometer for our kicker last year. I believe it cost about $50 from McMaster-Carr, but I don’t have the model number. I did a bit of browsing, and found several devices of this type under “angle sensor”, but I couldn’t find anyone who posted a price on the web site.

14

This is true, simply make a mounting bracket for the potentiometer and provide linkage to your swerve module, coaxial is another route that completely circumnavigates this issue

We would like to get the encoders working properly, but potentiometers are not completely out of the running. As far as an alternate strategy, I’m not sure what you mean by coaxial.

15

Someone decided that for your system, you needed accuracy of ~+/- 0.75 degrees. Since you have a resolution of almost the same, you need to be perfect. If you’re sensor reads that is 1 tick away from where you want to be, you don’t know if it’s a tiny fraction of a tick off, or almost a full tick off. Since your sensor doesn’t know the difference, your software has to respond to them the same. If you’re only a tiny bit off, you might overshoot, and if you’re almost a full tick off, you might not move far enough. It makes it very hard to tune.

Imagine instead that you’re accuracy requirement was 0.75 degrees, but you’re sensor measured 0.075 degrees (10 times the resolution compared to the resolution requirements). You would know the difference between a very small bit off, and 0.75 degrees off, and your PID controller could output a different value based on how far off it is.

I’m assuming you’re using an AM PG71 based on those numbers. Given that the free speed is 75 RPM, You would move 90 degrees in 0.2 seconds. That’s very fast and hard to control, especially with your resolution challenges. If you instead added an additional 4:1 gear reduction, you’d do a full motion in 0.8 seconds and you’d have 4 times the resolution at the same time.

16

Someone decided that for your system, you needed accuracy of ~+/- 0.75 degrees. Since you have a resolution of almost the same, you need to be perfect.

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.

17

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.
18

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.

19

Watch this video, especially at 9:03

20

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?