PID Help

[wildaburk3160]

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

[Mark McLeod]

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?

[wildaburk3160]

At the moment, no, it does not.

[wildaburk3160]

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.

[Mark McLeod]

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.

[Skyehawk]

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.

[Alan Anderson]

Originally Posted by wildaburk3160

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

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

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.

[Joe Ross]

Originally Posted by wildaburk3160

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.

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.

[gpetilli]

Originally Posted by Joe Ross

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

[wildaburk3160]

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.

[lamk]

A potentiometer may be a more appropriate sensor.

[Skyehawk]

Originally Posted by lamk

A potentiometer may be a more appropriate sensor.

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.

[GeeTwo]

Originally Posted by lamk

A potentiometer may be a more appropriate sensor.

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.

[wildaburk3160]

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.

[Joe Ross]

Originally Posted by wildaburk3160

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

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.

Originally Posted by wildaburk3160

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