PDA

View Full Version : 2012: Tuning the Jaguar's Speed Control PID Loop


Mr. Lim
01-14-2012, 07:26 AM
There is a lot of background information here:

http://www.chiefdelphi.com/forums/showthread.php?t=90508

I am continuing this discussion in a new thread for the 2012 season, and would like to limit it to the specific methodologies you've used to tune your JAGUAR'S Speed Control PID Loop, and its pros/cons.

Method 1:
Use P-Only control, and tune the P constant until you achieve a stable loop at 50% of your setpoint. Leave I and D as ZERO. Do not touch them, do not pass go, do not collect $200. Now set your setpoints at TWICE the magnitude you actually desire. Profit.

Pros:
Simple to tune, and gives you a stable response.

Cons:
Far from ideal response. You will likely have offset and/or oscillations around your 50% target. You cannot take advantage of I or D because they depend on P being able to take to your setpoint.

Ether
01-14-2012, 09:08 AM
Method2: Use a PI control, and tune the I gain the way you would "normally" tune the P gain. Then tune the "P" gain the way you would "normally" tune the D gain.

Why? Because the drivetrain plant does not contain an integrator when the input to the plant is voltage and the output (that you are trying to control) is speed.

Mr. Lim
01-14-2012, 09:54 PM
We did a fair amount of work with Method 2 today as proposed by Ether.

We obtained fairly stable results, and would argue that they are overall better than Method 1.

There appears to be a major weakness with Method 2 however.

The I-term appears to be capped. Theoretically, even a small I-term should cause the speed control loop to reach its setpoint eventually. It might take a long time, but it should reach the setpoint, given enough time.

It does not.

What we're seeing is the maximum speed we can achieve is directly proportional to the I constant.

This is unfortunate, because we have been able to find some I-constants which appear to work beautifully, however since the I-term is capped, we can never quite achieve our top speed.

Capping the I-term is usually a great way to ensure our PIDs don't wind up too much, however in this case, it's inhibiting us from ever getting to our top speed.

Mr. Lim
01-16-2012, 05:39 AM
After another day of working on this...

I'm back to my opinion from 2011:

The Jaguars desperately need a Feed-Forward implementation in its speed control PID loop.

Everything else we've tried has seemed like a messy workaround which just won't give us as tight control as we want for either our drivetrain or shooter.

Are there any active Jaguar firmware developers from TI who are on ChiefDelphi who we can reach out to?

Right now, this feature is a) what is stopping me from recommending the Jags to our area's mid to upper tier teams, and b) a pretty standard speed control feature, which should be included in any speed PID controller worth its weight.

NotInControl
01-17-2012, 11:02 PM
Hello all, I am the Control System Engineering for Team 2168 the Aluminum Falcons.

Its going to be very hard to lock down a method of tuning the PID gains without fully understanding the implementation of the Controller in the Jag.

No two PID implementations are equal, and depending on weather the PID controller is an Ideal, Series, or Parallel implementation greatly affects how to go about tuning them.

For example, in the ideal case changing P has an effect on both I and D, where as in a parallel implementation, each term can be independently tuned.

Does anyone know if this implementation has been made available? Last time I looked the documentation was no where to be found.

I am going to spend more time this season reverse engineering the Jags and understanding the implementation, as my team does use CAN and I would likes to move my control loops off the CRIO... I will post my results.

However in the mean time, I have been working on a complete video walk through to show a simple way to tune the gains of a PID controller using Matlab and Simulink.

All the videos are not up yet, but the most important one is, the video which shows how to tune the gains. The video, m-files and .mdl files, and complete labview project are also available from our team website at:

http://team2168.org/index.php/resources/programming/217-pid-control-tutorial


The custom PID controller I use is also provided to be used by any team who so desires, all I ask is that you give credit to us, if you do use it. Even though the files are provided in labview, I will soon also provide a Java implementation.

The example in the video covers tuning position control gains but it is easy to extend the method for speed control on your own. In the next few days I will be posting an official walk through for tuning speed control gains as well.

Please check it out, and post any feedback you may have.


-Kevin

Joe Ross
01-17-2012, 11:09 PM
The jaguar source code is available, but not the easiest thing to find. http://www.ti.com/tool/rdk-bdc24-cd

dyanoshak
01-17-2012, 11:18 PM
The code isn't the easiest to find but maybe my post in the aforementioned thread can help:

http://www.chiefdelphi.com/forums/showpost.php?p=1013476&postcount=41

gpetilli
01-18-2012, 09:08 AM
Hello all, I am the Control System Engineering for Team 2168 the Aluminum Falcons.

Its going to be very hard to lock down a method of tuning the PID gains without fully understanding the implementation of the Controller in the Jag.

No two PID implementations are equal, and depending on weather the PID controller is an Ideal, Series, or Parallel implementation greatly affects how to go about tuning them.

For example, in the ideal case changing P has an effect on both I and D, where as in a parallel implementation, each term can be independently tuned.

Does anyone know if this implementation has been made available? Last time I looked the documentation was no where to be found.

I am going to spend more time this season reverse engineering the Jags and understanding the implementation, as my team does use CAN and I would likes to move my control loops off the CRIO... I will post my results.

However in the mean time, I have been working on a complete video walk through to show a simple way to tune the gains of a PID controller using Matlab and Simulink.

All the videos are not up yet, but the most important one is, the video which shows how to tune the gains. The video, m-files and .mdl files, and complete labview project are also available from our team website at:

http://team2168.org/index.php/resources/programming/217-pid-control-tutorial


The custom PID controller I use is also provided to be used by any team who so desires, all I ask is that you give credit to us, if you do use it. Even though the files are provided in labview, I will soon also provide a Java implementation.

The example in the video covers tuning position control gains but it is easy to extend the method for speed control on your own. In the next few days I will be posting an official walk through for tuning speed control gains as well.

Please check it out, and post any feedback you may have.


-Kevin

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.

nixiebunny
01-18-2012, 10:35 AM
The jaguar source code is available, but not the easiest thing to find. http://www.ti.com/tool/rdk-bdc24-cd
I don't see the source code anywhere in that zip file. Lots of PDFs, but no code tree. Is it hidden in one of the application programs or PDFs?

Joe Ross
01-18-2012, 10:54 AM
I don't see the source code anywhere in that zip file. Lots of PDFs, but no code tree. Is it hidden in one of the application programs or PDFs?

I told you it's tricky ;-)

Install RDK-BDC24-CD-683\Software\StellarisWare\SW-RDK-BDC24-8264.exe. The code will then be in C:\StellarisWare\boards\rdk-bdc24\qs-bdc24

nixiebunny
01-18-2012, 11:14 AM
I told you it's tricky ;-)

Install RDK-BDC24-CD-683\Software\StellarisWare\SW-RDK-BDC24-8264.exe. The code will then be in C:\StellarisWare\boards\rdk-bdc24\qs-bdc24
That would explain why the source files didn't show up on my Mac.

dyanoshak
01-18-2012, 11:34 AM
That would explain why the source files didn't show up on my Mac.

I believe you can change the ".exe" extension to a ".zip". It is a self extracting zip file, so by doing this you can manually unzip it.

-David

nixiebunny
01-18-2012, 11:44 AM
Thanks for the info. It turns out that you have to run the Windows installer program, which builds the source code tree as part of the install process. Typical Windowsness. I carried the file to my Windows box in the workshop and had much more luck.

My day job involves work on telescopes run by Linux computers, so I have gotten used to finding source code without executing an app first.

Ether
01-18-2012, 01:01 PM
My day job involves work on telescopes run by Linux computers, so I have gotten used to finding source code without executing an app first.

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 (http://www.7-zip.org/). Does anyone know of a similar app for Linux?

Ether
01-18-2012, 03:37 PM
The Jaguars desperately need a Feed-Forward implementation in its speed control PID loop.

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.

dyanoshak
01-18-2012, 03:57 PM
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 (http://www.7-zip.org/). 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
01-18-2012, 04:10 PM
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
01-18-2012, 04:12 PM
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
01-18-2012, 04:27 PM
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
01-18-2012, 07:32 PM
Does anyone know of a similar app for Linux?

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

NotInControl
01-19-2012, 01:22 AM
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/student-competitions/first-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
01-19-2012, 01:26 AM
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
01-23-2012, 09:20 AM
This is a repost from a different thread (http://www.chiefdelphi.com/forums/showthread.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
01-23-2012, 02:22 PM
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
01-23-2012, 04:09 PM
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
01-23-2012, 04:50 PM
...
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
01-23-2012, 04:53 PM
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
01-23-2012, 09:26 PM
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
01-23-2012, 09:59 PM
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
01-24-2012, 06:13 AM
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

NotInControl
01-24-2012, 06:31 AM
This has been discussed in great detail here at CD within the past year in various threads. You might find them interesting reading.



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.



I am aware of these conversations and I am interested in how well splitting the encoder worked for other teams who has ran this way during competition, what noise level increases they were seeing, and the reliability rate.

Ether
01-24-2012, 08:42 AM
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.

jwakeman
01-24-2012, 11:17 AM
Could you share the reasoning that led you to suspect that a current inner loop would be superior to a voltage inner loop?

To be perfectly honest I discussed it with two individuals who I consider to be much smarter than me in the area of motor control and closed-loop control in general and they both identified this as the best way to go (independently). I think one consideration was that you wouldn't have to be concerned with inducing currents above the 40 amp limit of the jaguars and therefore also wouldn't have to protect against doing so with ramp rates on voltage. Also I believe we said that a speed controller controlling current is 'more natural' than controlling volts because current is essentially equivalent to torque and is a deriviative away from speed. That last line was regurgitated if you can't tell. Finally, in my contol classes I remember adding an inner current control loop to enhance the performance or speed regulators. That's the best answer I can give for now..

techhelpbb
01-24-2012, 11:19 AM
Re: NotInControl

I couldn't find anyone that made this work in competition last year...and this is probably the reason why:

http://www.chiefdelphi.com/forums/showthread.php?t=89697&page=3

So as a participant in those prior conversations I'll tell you what I found:

The encoders do not split nicely like that. I encourage you to look at the produced output signal when you are doing so using an oscilloscope.

There is a chance you can get them to work regardless of the issues it creates but I suspect the system noise will occasionally get the better of you. I will not speculate on how often, but from what I've seen using wiring well within the standards of inspection for U.S. FIRST (and load tested beyond the standards)...often enough you might consider it an issue...especially in systems with many loaded CIMs.

Ether
01-24-2012, 01:04 PM
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.

Yes, please do.

NotInControl
01-24-2012, 03:42 PM
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
01-24-2012, 07:14 PM
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.

NotInControl
01-25-2012, 02:52 PM
Re: NotInControl

I couldn't find anyone that made this work in competition last year...and this is probably the reason why:

http://www.chiefdelphi.com/forums/showthread.php?t=89697&page=3

So as a participant in those prior conversations I'll tell you what I found:

The encoders do not split nicely like that. I encourage you to look at the produced output signal when you are doing so using an oscilloscope.

There is a chance you can get them to work regardless of the issues it creates but I suspect the system noise will occasionally get the better of you. I will not speculate on how often, but from what I've seen using wiring well within the standards of inspection for U.S. FIRST (and load tested beyond the standards)...often enough you might consider it an issue...especially in systems with many loaded CIMs.

Thanks for the info. I figured it wouldn't be as easy as splitting the encoder signals. But like I said I know there are solutions available, but at a risk. I'd rather be done with it on the CRIO than debugging the problem through the last week of build on the Jag.

As for the method I use to determine the gains:
I prefer the more modern approach of simulating the plant and designing a controller to a model and then implementing in on the real system and tweaking from there. I create a plant model in matlab or simulink and use the control system toolbox to determine the gains (within a close range because my model is a linear approximation of the system and doesn't account for all physical effects of the system.)

Guess and check methods like Ziegler-Nicholos methods do work but I feel that Guess and Check methods only work if you really have a background in control systems or have enough experience with controllers to know exactly how to react when you see certain behavior. I'd always recommend the modern approach, because at a minimum it will give you a starting point for your gains, where you can then tweak by hand. I'll always recommend the simulation approach over guess and check.

The gains for my test on the Jag were using the same process I documented in the video I posted earlier.


Regards,
Kevin

techhelpbb
01-25-2012, 06:49 PM
Thanks for the info. I figured it wouldn't be as easy as splitting the encoder signals. But like I said I know there are solutions available, but at a risk. I'd rather be done with it on the CRIO than debugging the problem through the last week of build on the Jag.

As for the method I use to determine the gains:
I prefer the more modern approach of simulating the plant and designing a controller to a model and then implementing in on the real system and tweaking from there. I create a plant model in matlab or simulink and use the control system toolbox to determine the gains (within a close range because my model is a linear approximation of the system and doesn't account for all physical effects of the system.)

Guess and check methods like Ziegler-Nicholos methods do work but I feel that Guess and Check methods only work if you really have a background in control systems or have enough experience with controllers to know exactly how to react when you see certain behavior. I'd always recommend the modern approach, because at a minimum it will give you a starting point for your gains, where you can then tweak by hand. I'll always recommend the simulation approach over guess and check.

The gains for my test on the Jag were using the same process I documented in the video I posted earlier.


Regards,
Kevin

I posted a design I have used to cleanly split the encoders in the past early last year. Someone else posted a decent schematic of the basic idea. I still have no idea if it would pass field inspection even after 'open sourcing' it on Chief Delphi so I won't assure anyone that if you use it you'll be legal and the COTS rules might not help you. I can only say that it does electrically isolate both Jaguars from each other with regards to the encoder. It won't help you if you overload the Jaguars. It won't help you if you have wiring problems (extremely common), it won't help you if you busy out the CAN, it won't help you if the PID loop misbehaves, it won't help you if you set the system improperly. We abandoned CAN and went straight to PWM and eventually removed the Jaguars from our control system during 2011 (I currently have them mounted on my test frame). We had a few Jaguars fail and we had some wiring problems and since we were using PWM anyway we felt the additional space and ruggedness (off hand observation) the Victors have offered us were a good trade.

The way Jaguars in particular often end up getting tuned isn't a very clean solution because it often requires some familiarity with the system being tuned that ends up making the results somewhat arbitrary. Turning a value up till you get oscillation, for example, would imply that the person looking for the oscillation really understands what they are looking for. Having experience in the matter helps greatly, but, sometimes even that can fail you if there are many overlapping issues.

Add to this the chance that the PID loops available in the Jaguar might be ill suited to the system loads and you're starting to get into the sort of territory that in a 6 week period might be overwhelming.

I agree that modelling the system is advisable, and after attempting this pre-season in 2011, I personally can't imagine anyone jumping into this during season without some serious commitments of time in preparation. I have seen it pay off for people to just hit the 50% mark and not further detail their situation but then have that fall apart during competition when they experience wear and tear. As detailed in other posts certain modes seem much less prone to issues than others.

Having worked with a team to write some very complex synchronized PID loops in the cRIO in Java in the past, I have to agree with many of the other teams and mentors. There is much to be said for implementing the PID in the cRIO even if it pushes the limits of the cRIO (a matter that everyday seems less an issue of concern). I hope that we someday deploy a Jaguar based solution on one of our robots but it seems certain it won't be this year for us.

I do want to make it clear that I have invested much time into the Jaguars as far as making them work and I see the merit of their designs. It is just a unique challenge within the parameters of this competition.

vamfun
01-29-2012, 05:18 PM
Guess and check methods like Ziegler-Nicholos methods do work but I feel that Guess and Check methods only work if you really have a background in control systems or have enough experience with controllers to know exactly how to react when you see certain behavior.
Regards,
Kevin

Funny, I always though it was the other way around. The Z-N methods were ment for guys that didn't understand control theory. The cookbook method was a way a plant manager could get his plant under control if he was unable to model the dynamics and apply control theory. The PID is a similar device.

Anyway, I took a look at your video and code. You did a great job and I wish our team had the capability. We are using C++ and I have longed for that data/plotting capability to tune the PID loops. I know teams like 254 have used a similar data loging scheme that reads the data bus and plots it using a custom LV GUI. Have you done any of this with C++ or can you offer some suggestions on the best way to set PID constants on the DS , send them to the robot and retrieve the sensor data and display it.

jhersh
02-01-2012, 02:31 AM
Anyway, I took a look at your video and code. You did a great job and I wish our team had the capability. We are using C++ and I have longed for that data/plotting capability to tune the PID loops. I know teams like 254 have used a similar data loging scheme that reads the data bus and plots it using a custom LV GUI. Have you done any of this with C++ or can you offer some suggestions on the best way to set PID constants on the DS , send them to the robot and retrieve the sensor data and display it.

The original CAN Jaguar examples from 2010 showed a decent way to do this. They don't use the modern APIs, but the concepts are all still applicable. You can still download them from firstforge.wpi.edu in the CANJaguar project.

mjcoss
03-07-2012, 03:53 PM
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

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
03-07-2012, 07:36 PM
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.

dakaufma
03-07-2012, 07:43 PM
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.

mjcoss
03-08-2012, 12:18 AM
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

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
03-08-2012, 01:28 AM
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
03-08-2012, 03:12 PM
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
03-08-2012, 04:48 PM
My impression is that GetStatus is a LabView thing not for WindRiver C++.

jhersh
03-08-2012, 06:07 PM
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()

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
03-08-2012, 06:10 PM
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
03-12-2012, 06:24 PM
Yes. Mea culpa

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

---Michael J Coss

6xpoppy
03-13-2012, 01:56 PM
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

Ether
03-13-2012, 02:24 PM
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.

Would you mind just posting them here as a ZIP attachment?

NotInControl
04-04-2012, 11:48 PM
Funny, I always though it was the other way around. The Z-N methods were ment for guys that didn't understand control theory. The cookbook method was a way a plant manager could get his plant under control if he was unable to model the dynamics and apply control theory. The PID is a similar device.

Anyway, I took a look at your video and code. You did a great job and I wish our team had the capability. We are using C++ and I have longed for that data/plotting capability to tune the PID loops. I know teams like 254 have used a similar data loging scheme that reads the data bus and plots it using a custom LV GUI. Have you done any of this with C++ or can you offer some suggestions on the best way to set PID constants on the DS , send them to the robot and retrieve the sensor data and display it.


This year for our team we used Java... and with the help of the SmartDashbaord I have created a GUI for PID tuning that I used on our 2012 bot. Since We were running our own custom PID controllers on the CRIO this was very helpful.

So while I haven't done it with C++ per se, the code in java and the smartdashboard can help you get similar functionality.

I also worked on a new tutorial for tuning gains, using Matlab and Simulink, in order to get a more accurate controller. The method of tuning is the same as in my original video, but the method for modeling is different.

In the previous videos modeling of the plant was done using parameters provided by the datasheets of the motor and physical modeling techniques. However, there is always error between the model and the apparatus because of parameter mismatch.

The new method is based on taking measured data by running the actual system and logging to the file its performance to a step response, and using that data in matlab to perform parameter estimation. The estimated system is a far better realization of the plant model and allows for a more accurate controller design the first time around.

I am trying to find the time to post all this stuff, its just been hard. - My apologies

gpetilli
10-29-2013, 04:02 PM
I had the same idea of predicting the step response. Attached is my cut at estimating PID values of the drive train UNDER LOAD (without risk of crashing into walls). I have not tried this on the actual robot yet, but it will hopefully be a good starting point.

I have updated the post with a new excel to correct some typos

gpetilli
10-31-2013, 02:24 PM
1) Updated with PID in either robot FPS or motor RPS.
2) Improved wheel slip to use either static or kinetic friction based on previous state.