PID Speed Control

[JewishDan18]

I was looking to use encoders to control the speed on the motors via a PID loop this year. I've done a lot of searching, and have not found the answers I'm looking for. I have no experience using PID loops, so bear with me for a moment.

Using the WPILib PIDController, I made a wrapper for the encoder to get speed, but I'm a little confused about the output. If I use the Jaguar for the output, it seems to me that as the robot approaches my desired speed, the motors will slow down (since error will approach zero). To me, it seems that the output of the PIDController should be used as the acceleration of the motor. Is this what is commonly done? It seems to me that the Jaguars are capable of an extremely high acceleration rate, which will lead to high levels of oscillation. Does one combat this by setting the constants to be quite small? Or is my premise of using acceleration fundamentally flawed? I'd like to get input from someone who has done this before, as there is no one on my team who has.

Thanks in advance,
Dan

[Jared Russell]

Your intuition is correct: If speed is your source of error and Jaguar PWM is your output, then your proportional term will become 0 once you hit the setpoint.

Here is a great thread on this topic from a couple of years ago: http://www.chiefdelphi.com/forums/sh...&highlight=PID

The short answer: You need to accumulate your output over time and use that instead. In essense, yes, you are controlling motor acceleration (just as in a position loop, you are controlling motor velocity).

What you have now:
Jaguar_PWM = Kp*error + Kd*error_derivative + Ki*error_sum

What fixes the problem:
Jaguar_PWM += Kp*error + Kd*error_derivative + Ki*error_sum

[JewishDan18]

Thanks. That thread is exactly what I was looking for. The last poster had some of the same concerns as me (lag when setting speed and the oscillating around the set point).

I'm hoping that we can get the CAN issues worked out, we can use the built in functionality. If not, I'll tinker with acceleration control, and if that fails, I think I'll do something similar to what Alan did, and set a distance target ahead of the robot proportional to the speed I want to go.

Thanks again!

[Ether]

Originally Posted by JewishDan18

I was looking to use encoders to control the speed on the motors via a PID loop this year. I've done a lot of searching, and have not found the answers I'm looking for. I have no experience using PID loops, so bear with me for a moment.

Using the WPILib PIDController, I made a wrapper for the encoder to get speed, but I'm a little confused about the output. If I use the Jaguar for the output, it seems to me that as the robot approaches my desired speed, the motors will slow down (since error will approach zero).

Yes, the motors slow down, but... they slow down to the "desired speed" (not to zero).

Think of it this way: a PID tries to drive the error to zero. Since your error is a "speed error", when the error is zero, it means your actual speed (measured by the encoder) is equal to your "desired speed" (the command you are sending).

If you use only the "P" term of the PID, you will always have a small speed error. That's where the "I" term comes in. The "I" term causes the PID to keep slowly bumping up (or down) the speed as long as the speed error is non-zero.

The "P" term gives you dynamic response, the "I" term gives you steady-state accuracy.

[JewishDan18]

So as the proportional error drops, the integral error picks up for it? That makes sense.

[Ether]

Originally Posted by JewishDan18

So as the proportional error drops, the integral error picks up for it? That makes sense.

You could look at it that way.

The proportional part responds immediately and aggressively to large errors, but is satisfied once the error is "sufficiently small"*. The integral part makes relatively slow corrections, even to large errors, but doesn't give up until the error is essentially zero.


*how small is "sufficiently small" depends on how high you have the gain turned up for P.

[BradAMiller]

Originally Posted by JewishDan18

I'm hoping that we can get the CAN issues worked out, we can use the built in functionality. If not, I'll tinker with acceleration control, and if that fails, I think I'll do something similar to what Alan did, and set a distance target ahead of the robot proportional to the speed I want to go.

A new release of Java was just published last night that includes very improved CAN Jaguar classes. Give it a try, should work much better.

[JewishDan18]

Awesome, I updated my plugins and got all control methods working except the speed control I'll keep working with the encoder to make sure it is working properly.

[buildmaster5000]

Originally Posted by BradAMiller

A new release of Java was just published last night that includes very improved CAN Jaguar classes. Give it a try, should work much better.

Unfortunatly, using the PID control of the Jaguars was ruled illegal by Q&A.

Originally Posted by http://forums.usfirst.org/showthread.php?t=16140

There is no rule that prohibits the Jaguars from reading the values from the encoders, however note that Rule R49 requires that the ROBOT must be controlled by the cRIO. In other words, commands may not originate in the Jaguar or any other controller, they must originate in the cRIO.

As my team was going to attempt a similar setup, would someone mind explaining how to setup closed loop speed control (I am really a mechanical guy who has inherited part of programming this year as the main programming student deemed swerve "too hard"). We are using java and have a operating chassis for the swerve. Currently the software "works" as designed but there are different speeds for each wheel, even when the PWM output is the same to each wheel.