2012: Tuning the Jaguar's Speed Control PID Loop

[NotInControl]

Originally Posted by Ether

Some questions:

What wheel were you using?

What speed(s) were you controlling at? What was the approximate voltage at each speed?

I was using a 5in. colson wheel and controlled the motor speed between 500 rpm and 2500 rpm. I was not able to record voltage data because as mentioned, the interface I was using was through BDC-COM.

Can you estimate the approximate transfer function from speed command to measured speed?

The answer to this question would also answer your other question on the voltage at each speed. I have not done the complete testing yet, but the transfer function is obviously non-linear. Which could be reasons for spikes in rpm around the set point. Ideally, a speed controller will clamp its output to the last output once the setpoint was reached, to prevent these fluctuations due to non-linear motor controllers.

Did you collect any data, such as time traces of speed command and speed output (for step commands or sinusoids).

Sounds like your looking for information on rise time and settling time? Because I was running the Jag using BDC-COM, I wasn't able to record actual output information (unless there is a feature I am unaware of).

I tuned the gains of the controller to have a rise time of about 0.3 seconds and settle just under 1 second. Just visually, I would say settling time was closer too 2 seconds. When I run the setup on the CRIO, where I can log output data from the Jag I will be able to graph it and view true rise time and settling time for the response.

I am confident that the Jag will perform well under certain applications. It is my personal stance as a Control Engineer to have filtered feedback signals, and account for external disturbances if I need too with additional control, which the Jaguar can't do. I am confident the Jaguar can perform good speed and position control, but a smooth response where the controller is not being overworked may be hard obtain because the Jaguar does not allow the user to account for the variable non-linear effects. For FIRST purposes, I think the Jags can accommodate.

Hope this helps,
Kevin

[Ether]

Originally Posted by NotInControl

controlled the motor speed between 500 rpm and 2500 rpm

How closely did the actual measured speed match the speed you were commanding?

I ask this because other teams have reported that they could control speed, but the actual speed did not match the commanded speed.

[NotInControl]

Originally Posted by Ether

How closely did the actual measured speed match the speed you were commanding?

I ask this because other teams have reported that they could control speed, but the actual speed did not match the commanded speed.

In all cases my steady state error was +/- 200 rpm. Now I say this sparingly. The only indication I had of actual speed was the readout from the BDC-COM interface, which was fluctuating within this range.

However, I would argue that most of that fluctuation is due to the lack of smoothing the input rate of the encoder and causing the PID loop to iterate to reduce the error. If there were no noise in the feedback signal, fluctuations in the output can be fixed by reducing the P term of a PI controller, however this will reduce your rise time.

[Mr. Lim]

Some anecdotal notes to share with you: we're using 256 ppr Greyhill 63R series encoders, directly attached via surgical tubing to a ~6" wheel. We run them from 200-1800 RPM.

The vanilla PID implementation in the Jags is not well-suited to speed control PID. Tuning them using traditional methods as you have been may be futile. Hence the reason why I started this thread in the first place. Many of us have been down the same road you have, and have been left bitterly disappointed in the results.

The first two posts in this thread are exceptionally valuable IMO, as they are workarounds on how to massage the Jag's limited speed control PID into something workable.

If you insist on using more traditional PID tuning methods, I can suggest method #3, which is a more conventional DOES appear work for systems with very little resistance or changes in dynamics (i.e. a free-wheeling shooter wheel).

Start with 0 for all terms. Increase P until you reach approximately 50% of your setpoint. Adjust it down until you find the P value that results in the least amount of fluctuation in speed. You may need to reduce the P significantly to get a very stable value. You should be able to get ~1% deviation from wherever your speed happens to settle. The important thing here is that your output rpm remains as rock solid as possible, and you've pushed it as close to 50% of your setpoint as you can get it.

Now bump up your I term 0.001 at a time until your system finally achieves your setpoint. Use the least amount of I possible such that your system can reach it maximum speed.

[mjcoss]

Worked on this last night to try once more to tune the PID loop for speed control on our shooter motors. Unfortunately, I don't seem to be able to get a stable system over the entire range. Between 500 and 2000, I see pretty stable values, but system starts oscillating as I move up between 3000 and 4000. 4000 is close to the maximum that the motors can do.

I applied the method mentioned here where I got a stable min P @ 50% set point, then added I to get to the set point. Is there no reason to add the D term is is the Jaguar PID just to flaky?

I'm not sure whether to keep tinkering with this or just declare it stable enough.

---Michael J Coss

Originally Posted by Mr. Lim

Some anecdotal notes to share with you: we're using 256 ppr Greyhill 63R series encoders, directly attached via surgical tubing to a ~6" wheel. We run them from 200-1800 RPM.

The vanilla PID implementation in the Jags is not well-suited to speed control PID. Tuning them using traditional methods as you have been may be futile. Hence the reason why I started this thread in the first place. Many of us have been down the same road you have, and have been left bitterly disappointed in the results.

The first two posts in this thread are exceptionally valuable IMO, as they are workarounds on how to massage the Jag's limited speed control PID into something workable.

If you insist on using more traditional PID tuning methods, I can suggest method #3, which is a more conventional DOES appear work for systems with very little resistance or changes in dynamics (i.e. a free-wheeling shooter wheel).

Start with 0 for all terms. Increase P until you reach approximately 50% of your setpoint. Adjust it down until you find the P value that results in the least amount of fluctuation in speed. You may need to reduce the P significantly to get a very stable value. You should be able to get ~1% deviation from wherever your speed happens to settle. The important thing here is that your output rpm remains as rock solid as possible, and you've pushed it as close to 50% of your setpoint as you can get it.

Now bump up your I term 0.001 at a time until your system finally achieves your setpoint. Use the least amount of I possible such that your system can reach it maximum speed.

[Mr. Lim]

I have not been able to get the Jaguar's D term to give me any useful kind of system response when in Speed control.

Is your system oscillating with a regular period at the high RPMs? Or is it behaving erratically?

If the latter, you might just be getting a lot of noise on your encoder signal. You will run into problems if you are running your encoder wires beside your motor power wires.

[mjcoss]

It's a bit erratic and it may well be just noise. I played a little more with it tonight, and feel like it is stable enough. One thing that I meant to mention, and was a bit surprised by was that the Get[() function on the Jaguars just return the set point, not the current speed. We have the encoder signal split, going to the digital side card, and I've been using the digital side card encoder to track the performance of the speed control.

I expected that the Jaguar would have reported the current speed, not the set point. I played some with the D term but got nothing useful.

---Michael J Coss

Originally Posted by Mr. Lim

I have not been able to get the Jaguar's D term (to give me any useful kind of system response when in Speed control.

Is your system oscillating with a regular period at the high RPMs? Or is it behaving erratically?

If the latter, you might just be getting a lot of noise on your encoder signal. You will run into problems if you are running your encoder wires beside your motor power wires.

[jhersh]

Originally Posted by mjcoss

It's a bit erratic and it may well be just noise. I played a little more with it tonight, and feel like it is stable enough. One thing that I meant to mention, and was a bit surprised by was that the Get[() function on the Jaguars just return the set point, not the current speed. We have the encoder signal split, going to the digital side card, and I've been using the digital side card encoder to track the performance of the speed control.

I expected that the Jaguar would have reported the current speed, not the set point. I played some with the D term but got nothing useful.

---Michael J Coss

You need to use GetStatus to find the measured speed. The headers / context help contains information. You should read it.

-Joe

[mjcoss]

Originally Posted by jhersh

You need to use GetStatus to find the measured speed. The headers / context help contains information. You should read it.

-Joe

My CANJaguar.h does not have a GetStatus method, nor does the WindRiver IDE show any method by that name for my CANJaguar object. And I do look at the headers.

---Michael J Coss

[mikets]

My impression is that GetStatus is a LabView thing not for WindRiver C++.

[jhersh]

Originally Posted by mjcoss

My CANJaguar.h does not have a GetStatus method, nor does the WindRiver IDE show any method by that name for my CANJaguar object. And I do look at the headers.

Sorry... I had the wrong name... GetSpeed()

Originally Posted by mikets

My impression is that GetStatus is a LabView thing not for WindRiver C++.

You are correct... I forgot that the C++ implementation calls out the status each separately.

[jhersh]

Originally Posted by mjcoss

My CANJaguar.h does not have a GetStatus method, nor does the WindRiver IDE show any method by that name for my CANJaguar object. And I do look at the headers.

/**
 * Get the recently set outputValue setpoint.
 * 
 * The scale and the units depend on the mode the Jaguar is in.
 * In PercentVbus Mode, the outputValue is from -1.0 to 1.0 (same as PWM Jaguar).
 * In Voltage Mode, the outputValue is in Volts.
 * In Current Mode, the outputValue is in Amps.
 * In Speed Mode, the outputValue is in Rotations/Minute.
 * In Position Mode, the outputValue is in Rotations.
 * 
 * @return The most recently set outputValue setpoint.
 */
float CANJaguar::Get()

/**
 * Get the speed of the encoder.
 * 
 * @return The speed of the motor in RPM based on the configured feedback.
 */
double CANJaguar::GetSpeed()

[mjcoss]

Yes. Mea culpa

While I was looking for the GetStatus(), I found GetSpeed(). Meant to mention that in the post.

---Michael J Coss

[6xpoppy]

My name is Martin Kanner (an old time controls engineer) and I have been mentoring for team 353 for 6 years. I marveled at the technology of the PID but I coudln't see how it could be applied in an engineering fashion with the information available. My basic point is that a closed loop is designed for performance and stability. This is not to be accomplished by trial and erorr. My experience has been with the application of Bode analysis and Bode plots. I have completed 3 files so far entitled "The PID Revisited". I expect to complete two more files to be complete. I believe they contain the basics for designing closed loops. If anyone is interested, I'll e-mail PID11, PID22 and
PID33. They are pretty short but I believe contain some simple but important fundamentals. My e-mail is, msixxpoppy@hotmail.com

[dakaufma]

Tuning with P is appropriate for position control PIDs but for speed control I should be your primary constant (imagine that the wheel is spinning just faster than the desired speed: P will try to reverse the motor). There are a couple of threads about this on CD with details.