PID controller tuning help

VEX V5 Technical Support
#1

I’m trying out this PID controller for my robot and this is my first time with it. Are there any specific steps to tuning the PID values? Also, I would like to use the debugger graph but I don’t know how to add variables to it. In addition, would a PI controller be sufficient for turning with gyro sensor?

#2

I recommend watching this:

Even a well-enough-tuned P controller might be sufficient, but a PI would probably be a safe bet. I have yet to encounter a real need for the derivative term in VEX.

#3

Thanks, the video helped a lot! How do you add variables to the debugger graph though? I can only get sensor readings and motor info on it.

#4

Your own variables? Only to debug stream if you need full control.
But if all you need is to see, for example I vs. D vs. P contribution, you can still configure fake motors on unused motor ports (who needs drivebase when tuning PID, right?), let your algorithm send those values to those fake motors and set up data logging series for those ports.
There is also some kind of programmatic access to the data log so all that might be unnecessary, but we haven’t used that yet.

Sample:


{ ... your PID loop code here ...]
    motor[port1] = kI * integral;
    motor[port2] = kP * error;
    motor[port3] = kD * deltaError;
    motor[realMotor] =  kI * integral + kP * error + kD * deltaError;
}
#5

Thanks! One more question, I’m looking into the Ziegler-Nichols Tuning method and I don’t understand what the ultimate gain (Ku) is.

#6

Page 15 of George Guillard’s PID guide says this about Ku:

#7

While I usually agree that PI is suited for most applications, I’d say VEX is unusual in that PD is better. PD controller has been very useful in for VEX robots in my expierence.

The I gain although increasing accuracy in long term, is unnecessary for most applications on 393 motors and often causes more trouble than its worth. E.g., for turns using a gyroscope, I can cause signifigant oscillations that result in considerable drift in the readout and inaccurate target. It also takes a long time to hit the setpoint which is not a luxury one has in a 15 sec auton.

On the other hand, PD control allows for a snappy response time by dialing up P but preventing overshot and still maintaing accuracy with the appropriate D. Its especially useful for quick turns and lifts.

#8

I tried doing that but the values of the fake motors cap at 127 because of the power limit. Is there any way to overcome this?

#9

I don’t know why but I did the same thing before and I just couldn’t get it to work with IMEs so I ditched them and that code works great with regular encoders. I use a kp of 8.

#10

That should be fine as long as you log the full term contribution, not the internal state.
If your “intergral * kI” gets clipped at 127, you know you’re in trouble already.
Either way, you have 8 bits of precision and it’s your call how you scale the “logged” value. You can always go with motor[port1] = myValueThatIsInThousandsRange/50;
At some point, you’d be better off with the debug stream anyway…

#11

I think this page of the RobotC documentation section is what you’re looking for to get the syntax of writing your variables to the datalog. Here’s a link to the datalogDataGroupStart() function, and if you look in the left column, you can see the other functions needed: http://help.robotc.net/WebHelpVEX/index.htm#Resources/topics/VEX_Cortex/ROBOTC/Datalogging/datalogDataGroupStart.htm

#12