PID controller tuning help

  1. 6 months ago

    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?

    @randomguy 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?

    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.

  2. Barin

    1 Feb 2018 Answer Arizona
    Edited 6 months ago by Barin

    @randomguy 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?

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

    4 Feb 2018 V5 Beta Tester

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

    8 Feb 2018 Menlo Park, CA 1666

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

    Mathematical Tuning
    ...begin by disabling all three constants (set them to zero).
    1. Increase kP until you get steady continuous oscillations. These need to be stable and consistent. Record this value as “kU” (ultimate or critical gain).

  7. Ashwin Gupta

    8 Feb 2018 California FRC 3476

    @Barin I have yet to encounter a real need for the derivative term in VEX.

    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. @nenik 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; }

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

    14 Feb 2018 meme city 8381B

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

    14 Feb 2018 V5 Beta Tester

    @randomguy I tried doing that but the values of the fake motors cap at 127 because of the power limit

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

    14 Feb 2018 Menlo Park, CA 1666

    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

 

or Sign Up to reply!