PID Explanation

Here is a great video that explains PID in a very simple (and fun) manner. It’s in Portuguese, but it does have closed captioning that you can turn on.
http://www.youtube.com/watch?feature=player_embedded&v=7BDjZYGHupE#!

How do you turn on the english subtitles?

Click the “cc” in the bottom right of the video player.

Since this thread is about PID, I want to ask a few related questions:

  1. What are some tricks you / your team use to tune the constants? I’ve seen a lot of arms on various videos and they are very stable, however, I wasn’t able to replicate the same results.

  2. Do you put any code to cap the integral to prevent it from flooding the system?

  3. Is there a way to have real time feed back while tuning the PID? The way I tune it is change the constants, plug cortex into the joystick (which means I’m unable to read the variables on the robot) and repeat. I didn’t research much about the build-in debug functions in RobotC for Cortex. Is there a way to have real-time feed back & joystick control at the same time?

Thanks!

It’s a very informative and well-made video, but it doesn’t really explain how exactly the P, I , and D are related. In fact it only seems to explain P in-depth.
I would imagine you would have to do a lot of tweaking for the constants to get it to work well, and with an arm you may have to account for constant voltage to keep the arm up.

Running the debug just after downloading code onto your robot lets you see all inputs and outputs (in RobotC). There should be a window on the bottom of the screen with the list of variables.

Yeah there’s the list of variables in the bottom of the window. However, I’m trying to find a way to have joystick input also while the Cortex is still connecting to the computer (so the variables would continue polling and updating on the screen).

Lastly, another question: if you / your team is using PID control to have the arm stay at a certain height with a decent mount of load on the arm (like 6 elements), do your motors trip the breaker or stop running (for PID to be able to work it needs to give out certain level of power to the motor so it doesn’t fall. However the motor is not moving so it’s stalling the motor, which might cause the breaker to trip)?

You can pull up the joystick joystick control debugger window, or, if you want to see the numbers side by side, you can write the relevant channels to variables and have it show up with the rest of them.

With any piece of code that keeps the arm at a certain position, the motor will have to do that. Your job is to make sure that the arm is not too heavy for the motor to lift comfortably.

Here is some advice that @smartkid posted https://vexforum.com/showpost.php?p=230209&postcount=13

Work on the Kp constant first. There’s lots of advice on the internet but with PID loops the mechanics affect tuning as much as the software.

Yes.

Program the cortex via the joystick using the orange USB->serial cable. If the robot is not driving around then I tether the joystick and cortex using the USB A-A cable to save the joystick batteries. Make Kp, Kd & Ki variables (usually floats) so you can modify them directly in the global variables debug window (just type in a new value and hit return). This means you do not have to compile/download every time to change the loop parameters, once you have them figured out then hard code them.

Here was a RobotC example I posted a few weeks back https://vexforum.com/t/a-pid-controller-in-robotc/20105/1

Very good example jpearman!
To prevent flooding, I’ve always just multiplied the Integral * 2/3, so that every time around the loop, the results of the previous calculations (Integral + Error) get smaller (sort of like a weighted memory).
So, Integral = (Integral + Error) * 2/3
Is that a good way to do things, or would a thing that resets the Integral to 0 if it gets out of bounds better?

To be honest I don’t know, but there are several techniques to prevent integral windup. Most of the PID work I’ve done has the firmware buried inside third party servo or stepper motor controllers, you supply the constants but the details of the control loop are generally hidden.

The biggest issue I’ve found with PID control of VEX parts is the backlash between the gears. For example, the students and I were playing with this a couple of weeks ago.

https://vexforum.com/attachment.php?attachmentid=4942&stc=1&d=1323203280

An arm using two turntables that are electronically geared. We could get the control fairly reasonable but there is so much mechanical play in the gears controlling the upper turntable there was no hope of fine tuning it in the way we wanted.
arm_turn2.jpg

Has anyone tried using the Ziegler-Nichols method for finding the constants? From the description it looks like it may overshoot, which seems bad for VEX (you want to get to a value as quickly as possible).
From the table on the linked wikipedia page, it looks like decreasing Kp and increasing Kd will get rid of overshoot (and increasing Ki compensates for the decrease in Kp). Is this consistent with anyone’s experience?

In the past (2007 FRC), with double-jointed arms, we’ve calculated the desired angle for the second joint based on the error in the first joint and a desired height (this was all done using the FRC PIC).

Then, any error we have in the shoulder joint (that we can sense but on compensate for) will be corrected in the elbow joint (which has more precision), to achieve the same height.