Alternative to PID speed control

[mommazzboy]

Originally Posted by Ether

Make sure you scale the feedforward appropriately and then clamp the result after you add it to the PID output.

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"?

[Ether]

Originally Posted by Ether
Make sure you scale the feedforward appropriately and then clamp the result after you add it to the PID output.

Originally Posted by mommazzboy

Can you expand on this some?

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.

[plnyyanks]

Originally Posted by Ether

In LabVIEW I think that's called "in range and coerce", or some such thing.

Right you are

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