PD Loop drives straight forever

I have been following this youtube tutorial in order to make a PID loop. I have taken out the Integral as I am using this in my drivetrain and don’t want it to oscillate as one of my teammates advised.

I finished following the tutorial, but I find that my PD loop drives straight forever. Currently, I have the “desiredValue” set to 100, assuming degrees. What did I do wrong?

after exiting the loop, you have to call coast/stop to end the continual spinning of the motors. The code will help your autonomous drive straight, so uncoast it using time based functions for a little time to manipulate the robot driving straight and change some of the positive and negative values to turn… It will require quite a lot of testing.

I’m not very familiar with PID myself, but hope this helps.

I am assuming that you are using Conner’s tutorial on VEX PID. I think your problem is that you copied it straight, but forgot to read his comment after.

" Fair Warning: I am unsure if I have the positive and negative motor values correct, as this is all done on the top of my head. So If the robot is continuing to go even after the lateral position is reached, change

error = averagePosition - desiredValue;


error = desiredValue - averagePosition;

If the robot continues to go even after the turning desired is reached, change

turnError = turnDifference - desiredTurnValue;


turnError = desiredTurnValue - turnDifference;

Helpful information:

If you need any further clarification, respond below and I can answer :slight_smile:"
ref: https://www.vexforum.com/t/vexcode-pid-tutorial/73706

Thanks! This works - sort of… Now, the code carries out the actions I tell it to, but after wards, seems to have a strange movement, basically twitching back and forth forever until I stop the program. I have a video demonstrating this.

In the code, the only action I have set is desiredTurnValue = 720;

What you’re seeing is that your code is oscillating around the endpoint. Because you have nothing to tell it that you’re close enough, it’s going to continually try to reach the endpoint, but it can’t quiiiiiite get there, as your Kp and or Kd values are causing steps large enough to drive it one way past the endpoint, so it overshoots, and tries to move back, which undershoots.

And that is PID oscillation.

My advice, if it’s within a certain amount of your target, don’t take any motor action.

Dang, even without the Integral it was just oscilliating the whole time? In that case, couldn’t I just lower the kP/kD variables until it stops doing so? I’m not sure about what you mean in your last statement.

Technicall? Yes. Effectively? No, not really. You have to keep in mind that there are multiple types of PID loops; some are designed to keep an always-moving system held to a some target. Others are finite systems, where they end at a certain point.

In this case, you have a finite system, in that you get to a desired target and you are basically done (until the next target).

In this case, you need to find a sweet spot where your motor position is within X degrees (say 2 or 3), and if it’s within that range of the target, tell the motors to stop, and then when your target moves again to be more than 2 or 3 motor encoder degrees, the system starts up again.

Nitty-gritty: you’re ultimately dealing with the joys of floating-point math. I’m not going to get into the depths here, but effectively think of it as you’re 0.0000000000001 degrees away from your target, but you can’t get there because you’re stuck between 0.0000000003 and 0.000000004, but you can only move 0.000000002 at a time.