2012: Tuning the Jaguar's Speed Control PID Loop

[dyanoshak]

Originally Posted by Ether

I suspect I am not the only Windows user who would rather have a ZIP file that I can manually open than an "installer" the actions of which are unknown until it is run. Who knows what it is going to "install" and what settings it will change and whether it is going to need admin privileges etc etc.

EDIT: for Windows users, you can avoid running the "installer" EXE file and instead inspect and then extract (with folder structure) the contents of the "installer" EXE file using the free app 7-zip. Does anyone know of a similar app for Linux?

Did changing the extension to ".zip" not work (like I stated above)? I just confirmed that on my windows machine I am able to unzip the full folder tree with no issues using the default windows "Open with Compressed Folders..." explorer option.

[Ether]

Originally Posted by dyanoshak

Did changing the extension to ".zip" not work (like I stated above)? I just confirmed that on my windows machine I am able to unzip the full folder tree with no issues using the default windows "Open with Compressed Folders..." explorer option.

Yes, that works. Sorry, I don't know how I missed your earlier post.

A note on the download page that it is simply a self-extracting ZIP
might spare future downloaders a moment or two of apprehension

[Mr. Lim]

Originally Posted by Ether

I don't know is this is possible without completely breaking the Jag's comm protocol, but a flexible way to implement that would be updated Jag firmware which supports a second input command to the Jag (in addition to the setpoint) so that the user could use a lookup table or nonlinear equation or other arbitrary processing (based perhaps on open-loop experimental measurements) to create that "feedforward" command.

Until and unless the Jag firmware changes, moving the controller completely out of the Jag allows this flexibility, as some have suggested on other threads. An example is attached.

At this rate, I would be happy with a linear feed forward, where:

Output = Kff * setpoint + Kp * error + Ki * integral + Kd * derivative

All this would require is the ability to pass another constant (Kff) along to the Jag.

Even if the linear response isn't perfect, the PID loop will likely be responsive enough to make up the difference.

[Ether]

Originally Posted by Mr. Lim

At this rate, I would be happy with a linear feed forward, where:

Output = Kff * setpoint + Kp * error + Ki * integral + Kd * derivative

All this would require is the ability to pass another constant (Kff) along to the Jag.

Yeah, I was taking that as a given, but dreaming of a better way:-) Your suggestion I think would be minimally invasive; a simple change that wouldn't break anything.

[WizenedEE]

Originally Posted by Ether

Does anyone know of a similar app for Linux?

I just used "unzip" but it depends on the distro.

[NotInControl]

Originally Posted by gpetilli

I applaud what you are trying to do - as an engineer, I strongly dislike the guess and check method. I downloaded your files, but am getting a "bad link" error in simulink for the PID Controller. I am using version 2008b will all toolboxes loaded. Also, your Matlab model appears to be setup for position, any intent to upgrade for speed mode?

I took a different path to a closed form solution. I am using Team 1640 - Sab-BOT-age Drivetrain Model to predict the step responce for various drive trains, using Astrom's (less overshoot than Ziegler-Nichols) equations to calculate P-I-D then as Either said - loading the calculated D into Jag P, calculated P into Jag I and 0 into Jag D. We are getting reasonable performance on the testbot. We intend to poll the Jaguars for step response data using voltage and PID control and compare results but things always take longer than you expect. This was all done with Excel spreadsheets - which i can share if you like.

Thank you for the support... I don't know if you were able to check out the video but one of the pre-reqs is matlab/simulink version 2009A or greater. The reason you are getting a bad link is because you are using simulink 2008. That particular PID block is only available with the 2009 and greater version of the control system toolbox.

I was going to do another tutorial for users with older versions of simulink/matlab but I thought it would be fruitless because First teams can get free licenses for new mathwork software by contacting mathworks from this link:

http://www.mathworks.com/academia/st...irst-robotics/

I'd really recommend getting a new license so you can use the method I demonstrate but If youd like to use 2008, there is another tool you can use, but it is not as simple and not as easy to understand.

In matlab 2008 type sisotool in the command line. A gui will show up if you have the control system tool box installed... you can use this gui to tune your controller, provided that you set it up correctly. Check the Mathwork help files on this tool.. it will be a great start.

-Kevin

[NotInControl]

Originally Posted by gpetilli

Also, your Matlab model appears to be setup for position, any intent to upgrade for speed mode?

Yes, I have another tutorial on speed control, just editing it is what is killing me. I also have a Java implementation to put up as well.

Hopefully, I can get everything up on our website within the next couple of days so that teams can make the max use of them.

-Kevin

[MaxMax161]

This is a repost from a different thread (http://www.chiefdelphi.com/forums/sh....php?p=1111803) but I thought the info might be useful here

Reading through the data sheet I got this;

The input frequency of the QEI (Quadrature Encoder Interface) inputs may be as high as 1/4 of the processor frequency (for example, 12.5 MHz for a 50-MHz system)

I double checked the specs of the jag processor just in case and it's 50 MHz.

I hope this helps!

[NotInControl]

So I finally had a chance to play with PID control on the Jag over can... below is my initial assessment... note these are just my opinions so don't let it sway you in making your decision when choosing the Jags over the CRIO.

First off, I was controlling a CIM motor, directly coupled to a shaft... spinning a 6in wheel. I was using BDC-com directly connect to the Jag (so it was a black jag) over a USB to serial interface, and there was only one Jag on the network. My encoder was a 256 pulse per rotation grayhill encounter (or as TI likes to call it a 256 line encoder) tied directly to the shaft using shrink tubing.

Summary:
I was able to effectively get pretty accurate speed control using a PI controller, and good postiton control just using a P controller. However, the problems that I noticed are with paramters that I can not control due to the nature of the Jag being a black box PID controller to me. I talk about these nuances below, and because of them I don't think I am comfortable enough to use the jags for my PID loops this year, even though I will still be running CAN-Bus for all of my motors.


First impressions:
Encoder sampling time - The sampling time of the encoder seemed to be very slow. It was "good enough" for most of what I wanted to do but slow for really high speed rotations. To stablaize around 2500 RPM, I was noticing +/- 200 rpm jumps from the speed readout.The feedback from the sensor is an integral part of how reliable the controller will be... and there was no way to average the output of the encoder to smooth it out on the Jags (as I would do on the C-RIO using an N-point average). But the biggest problem was, I don't know what the sampling time of the encoders are - looking at the data sheet, section 8 does not mention sampling rate as it does for other inputs, The rate that it does talk about seems to be encoder velocity specified in Mach (unit M). So not knowing how fast the encoder is sampling is a pretty big deal to me. I would expect the sampling time to be in the kHz range, in which case it is fast enough I wouldn't care. Now the fluctuations I was getting from speed could have easily been due to a torsional spring effect due to the loose coupling of the encoder to the shaft, but I can't be certain without further testing.

No Integral wind-up prevention - (Or at least im not sure if the controller contains this feature) - When I look at the code posted... PID.c seems to have integral level min and max values to prevent integral windup. However, we can't be sure that the code were looking at is the code that is runing on the FIRST version of the JAG can we? I don't see why there would be two different versions of the firmware on TI's end, but using BDC com I did not see a way to provide limits on the integral. So windup is an issue, and although I didn't notice any wind-up in my tests, I didn't run the test long enough to make sure there was no windup. Windup can take seconds or even minutes to see the effect.

One encoder/One Motor - This is an obvious one, but because the encoder is tied to only one motor, it is difficult to control two motors using one encoder. I am sure there are solutions available, but at a risk I am not willing to take unless my back is against the wall and the loops are maxing out the cRIO (which I don't think will be the case).

However, if you can over look these problems, I was able to get a decent controller in about 10 mins on the Jag and would recommend the Jag for certain non-critical tasks. My gains were P=0.08, I=0.004 for speed control and P=0.3 for position control.

I used Matlab/Simulink to determine the gains of the controller.


Thanks,
Kevin

[jwakeman]

My plan this year is to use the Jaguars in current control mode. I will run a speed regulator on the cRio which is commanding the set points for the jaguar current controller. So to say it another way a speed regulator running on the cRIO wrapped around a current controller running on the jaguar. I have had success running the jaguar in current control mode (It basically worked no matter what I set the gains too!). I haven't tried wrapping the speed controller around them yet but i can post back here if others are interested in the results once I do so. I figured I would just post this configuration here as a possible alternative to full speed control on the jag.

[Ether]

Originally Posted by NotInControl

...

Some questions:

What wheel were you using?

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

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

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

[Ether]

Originally Posted by jwakeman

a speed regulator running on the cRIO wrapped around a current controller running on the jaguar.

Could you share the reasoning that led you to suspect that a current inner loop would be superior to a voltage inner loop?

[dakaufma]

Originally Posted by NotInControl

One encoder/One Motor - This is an obvious one, but because the encoder is tied to only one motor, it is difficult to control two motors using one encoder. I am sure there are solutions available, but at a risk I am not willing to take unless my back is against the wall and the loops are maxing out the cRIO (which I don't think will be the case).

Easy workaround: if you splice the encoder's two data wires (power and ground from one jaguar, data A and B to both jaguars) you can use one encoder to control multiple motors.

[Ether]

Originally Posted by dakaufma

Easy workaround: if you splice the encoder's two data wires (power and ground from one jaguar, data A and B to both jaguars) you can use one encoder to control multiple motors.

This has been discussed in great detail here at CD within the past year in various threads. You might find them interesting reading.

[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