Does anyone know of any way to control shooter wheel speed other than using PID? We are currently using PID and we are getting an oscillating error of about 5%. Any ideas how to minimize this error. (we are currently only using P. And D at all starts an oscillation.)
Use a flywheel, and use Jag CAN Voltage mode or do voltage compensation in the cRIO
We are currently using PID and we are getting an oscillating error of about 5%.
First, look at the signal you are getting from your speed sensor (open loop) to make sure you are actually getting a clean signal.
Any ideas how to minimize this error
Read the several threads here on CD that discussed PID speed control of 2012 shooter wheels.
we are currently only using P
You might want to re-read this thread:
http://www.chiefdelphi.com/forum/showthread.php?p=1114721#post1114721
An oscillation can be changed by changing your P factor. I would think that reducing the multiplier will help, but not knowing your mechanical setup this is just a guess. Experiment by cutting it in half and doubling it, that should tell you which direction to go.
You can write an equation that uses the same set motor speed voltage at a set distance using the same amount of voltage no matter how charged your battery is. See if this helps:
This is untested, but we decided to use the PID VI coupled with a feed forward term to control output velocity.
Make sure you scale the feedforward appropriately and then clamp the result after you add it to the PID output.
-
I have heard a lot about a “feedforward loop”. Is that just an accumulator? A feedback loop? A picture is worth a thousand words
-
How does the sampling rate affect this. I am currently running the loop at 50ms using a Timed Loop. Does anyone know if adjusting this up or down would help at all?
-
Is a 5% error significant or is the inconsistency more likely rooted in a mechanical problem?
No.
A feedback loop?
No.
A picture is worth a thousand words
http://ether.comeze.com/FRC/11822/Speed_PID_dia.pdf
A feedforward term in a control loop is a term that adds to the control output based directly off of the command input or some feature thereof. It doesn’t depend on any feedback, it purely feeds the command signal forward through the control loop.
For instance, in the case of controlling a shooter wheel, there’s a theoretical minimum voltage necessary to run the wheel at the correct speed. Based off this, you could create a feedforward term in your control loop. Take a CIM with no reduction. 12V free speed is 5400RPM. So, if you want to run it at 2700RPM, you know you need atleast 6V output. You create a feed forward term with a gain of (12V/5400RPM). Then, your output is PID output + RPMs * (12V/5400RPM). That way, when you command 2700 RPM, you’re already outputting the necessary 6V to run at that speed. Your PID loop now only has to compensate for the difference between free speed and your loaded speed. Plus, you’re instantly outputting 6V without waiting for an I term to build up enough error to put out 6V for you. Basically, feedforward terms improve the response of your control loop based off features you already know about your system.
warning: If PID output is +/-1 this may not work as expected.
We used a very simple closed loop control that worked flawlessly. We had a jag on CAN bus with an encoder attached to the jag. We used voltage control with a voltage ramp of ~115 V/S. We queried the jag for speed, and if the speed was less than the set speed, we set max voltage. If the speed was greater than or equal to set speed, we set zero voltage. The inertia of the system kept the shooter speed within ~15 RPM of set speed at all times, and when we shot, the voltage immediately went to full for rapid spin-up.
the simplest solution that works is usually best.
I’ve been wondering if that would work for this application. I did something very similar for an automotive actuator I worked on several years ago.
Thanks for posting that.
PS - I assume you had the Jag jumper set for coast?
Yes, coast.
This feed-forward idea sounds helpful. If I understand correctly, PID alone can be done in the Jaguar via CAN, but PID with feed-forward would need to be implemented entirely in the cRIO. The Jag PID doesn’t have any way to add a feed-forward value. Did I get this right?
Can you expand on this some? We’re setting the motor outputs in PWM, so the input to the VI needs to be between -1 and 1 inclusive, so we should make sure that the sum of the feedforward and the output of the PID never goes out of that range. Is that what you mean by “scale the feedforward appropriately”? If not, what do you mean? And what do you mean by “clamp the result”?
Originally Posted by Ether
Make sure you scale the feedforward appropriately and then clamp the result after you add it to the PID output.
Yes, but first let me make a recommendation: Seriously consider the approach Martin has described in his earlier post in this thread. Really.
We’re setting the motor outputs in PWM, so the input to the VI needs to be between -1 and 1 inclusive, so we should make sure that the sum of the feedforward and the output of the PID never goes out of that range. Is that what you mean by “scale the feedforward appropriately”?
No. What I mean by “scale the feedforward appropriately” is that you must scale the feedforward so that adding it to the PID output makes sense.
If your PID setpoint is in rpm, and your PID output is +/-1, then it would not make sense to add the setpoint to the PID output without first scaling the setpoint. Adding 4000 (rpm) to the PID’s +/-1 output would make the PID completely ineffective.
After you’ve added the feedforward to the output of the PID, you should then clamp that sum to whatever range the downstream code is expecting. In LabVIEW I think that’s called “in range and coerce”, or some such thing.
A couple of questions:
- How often were you asking the Jag for the speed?
- How quickly were you running the control loop?
- Were you able to compensate for the load that the ball puts on the motors quickly enough as to keep them at the correct speed?
I’m not Martin, but until he reads your post and replies, here’s a preliminary response:
Questions 1 & 2:
I’m guessing this controller would work fine in TeleOp. If that is the case, the answer to both questions 1 & 2 would be 20ms1.
Question 3:
For this application, no other control scheme provides faster spin-up or recovery time than the controller Martin described2. So if Martin’s controller approach doesn’t respond quickly enough, you won’t be able to improve things by using PID.
1 if the CAN cannot respond that fast, the encoder could be moved to the cRIO and read by the FPGA.
2 we used to call this a “bang-bang” control (for obvious reasons) when I was working aerospace back in the '80s.
. see this: http://www.chiefdelphi.com/forums/showthread.php?p=1146748
. @Martin: what was your criterion for selecting the voltage ramp rate? did you try this with a much faster ramp?
*
*