2012: Tuning the Jaguar's Speed Control PID Loop

[NotInControl]

Originally Posted by Ether

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

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.

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]

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.

[jwakeman]

Originally Posted by Ether

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]

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/sh...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]

Originally Posted by jwakeman

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]

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.

[NotInControl]

Originally Posted by techhelpbb

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/sh...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]

Originally Posted by NotInControl

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]

Originally Posted by NotInControl

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]

Originally Posted by vamfun

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]

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.

[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.

[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.