This is the first year where we are
actually trying to do some of the more “complex” stuff. We are having a lot
of trouble with PID loops, attached are some pictures of our teleop and begin code. http://i.imgur.com/3I3u1PJ.jpg
http://i.imgur.com/9EC0OGa.jpg
http://i.imgur.com/yc3qZVO.jpg
P is proportional gain. That gain pushes back based on how far off you are. I is integral gain. It pushes back based on how long you’ve been how far away. Finally, D is derivative gain. It pushes back based on how fast you’re going away.
In LabVIEW, it works a little weird, as you’ll notice you have proportional gain, integral “time” and derivative “time.” The way this works is that when you increase the P gain, all three gains are actually being increased, and the “time” values are multiplied by the P values to get their respective gain values (in a very weird way, there are extra multipliers in there, so don’t go trying to figure out what your gains are, just roll with it)
You have to tune PID loops no matter what, it takes time, it’s slightly dangerous (integral gain can run away from you fast, so have your hand on the E-stop), and honestly it’s far from easy.
Good luck!
I am also part of this team. We understand the theory of the PID loop, but are having a hard time understanding if our application is correct. We have a PID loop to rotate the robot with a gyro to a set point and the PID works fine it that situation. At least with a tolerance of about 5 degrees. But getting the encoders to rotate at a constant speed is the issue. We are wondering, if there is an issue with how we are getting our rate. If our rate is outputting a value that makes sense. Why our PID loop does not reach our setpoint.
If your robot doesn’t complete the movement, try raising your integral gain.
The robot is not completing the ramp up to speed. This solution you have proposed is, if I understand correctly, helpful only if the motor does not have enough power to get up to speed. This is not the case as the robot is off the floor and the wheels are free spinning. As i increase the P value it climbs, but then begins to behave erraticly and the motor values jump quickly between 1 and -1.
Leave the P value at a value thay does produce erractic behavior, such as the value above, and increasing the I anywhere from 1000 to 1 will also produce erractic rate changes and sometimes stop producing a motor output.
1000 to 1? We’re talking FRC robots in Labview here. The units on the I and D values are in minutes. It’s really weird, I know.
Also, if the motor overshoots an oscillates, increase derivative gain.
As stated, the Labview PIDs are weird and, for us, have always defied tuning in a way that we understand.
Though you may not wish such a change, I have attached our PID VI. It has inputs consistent with common PID control practice (i.e. not coupled). It is a re-entrant VI so you can use it multiple times, and there are comment statements in it to explain its use, but feel free to PM me.
CustomPID_v2.1.zip (29.1 KB)
CustomPID_v2.1.zip (29.1 KB)
We too are using PID this year and are having some luck with it for a change.
I’ve attached a couple of images of some helper VIs we created. The drive VI uses the NI LabView PID. We didn’t have much luck controlling turns with it so we created our own PID using Proportional only. Seems to work pretty well too.
For driving we only use the encoders to tell us when to stop, the gyro works with PID to keep us going straight.
Looks nice.
Do you realize that the *In Range and Coerce *function has it’s upper limit disabled (by default)? That’s why it’s a clear box, rather than a filled box like the lower limit has.
Right-click on the function and choose Include upper limit
Wow! As many times as I’ve used it I never noticed that. Something new every day.