Alternative to PID speed control

[Kevin Sevcik]

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.

[Ether]

Originally Posted by Kevin Sevcik

Then, your output is PID output + RPMs * (12V/5400RPM).

warning: If PID output is +/-1 this may not work as expected.

[martin417]

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.

[Ether]

Originally Posted by martin417

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?

[martin417]

Originally Posted by Ether

...PS - I assume you had the Jag jumper set for coast?

Yes, coast.

[Cal578]

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?

[Ether]

Originally Posted by Cal578

The Jag PID doesn't have any way to add a feed-forward value. Did I get this right?

Yes. See this post:

http://www.chiefdelphi.com/forums/sh....php?p=1108556

[mommazzboy]

Originally Posted by martin417

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.

A couple of questions:
1. How often were you asking the Jag for the speed?
2. How quickly were you running the control loop?
3. 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?

[Ether]

Originally Posted by mommazzboy

A couple of questions:
1. How often were you asking the Jag for the speed?
2. How quickly were you running the control loop?
3. 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 20ms¹.

Question 3:
For this application, no other control scheme provides faster spin-up or recovery time than the controller Martin described². So if Martin's controller approach doesn't respond quickly enough, you won't be able to improve things by using PID.


¹ if the CAN cannot respond that fast, the encoder could be moved to the cRIO and read by the FPGA.
² 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/sh....php?p=1146748
. @Martin: what was your criterion for selecting the voltage ramp rate? did you try this with a much faster ramp?