Good way to bring shooter to exact speed?

[team-4480]

Hi,

We recently decided to put an encoder on our shooter so that we can stop setting the shooter to a percentage of the battery power to an actual rpm. The problem we have now is how do we exactly program it to go to a certain rpm?

My best guess would be to use a PID loop and then limit the output to not include negative numbers so that the shooter doesn't suddenly change directions. We have tried just writing a linear equation like speed = distanceFromRPM * .01 +.4 but that usually didn't work well and the time it took to reach the desired RPM had a huge variation.

We just want a method that takes very little time to get up to the RPM and is consistent. Any ideas are appreciated and welcomed!

[ThaddeusMaximus]

Originally Posted by team-4480

Hi,

We recently decided to put an encoder on our shooter so that we can stop setting the shooter to a percentage of the battery power to an actual rpm. The problem we have now is how do we exactly program it to go to a certain rpm?

My best guess would be to use a PID loop and then limit the output to not include negative numbers so that the shooter doesn't suddenly change directions. We have tried just writing a linear equation like speed = distanceFromRPM * .01 +.4 but that usually didn't work well and the time it took to reach the desired RPM had a huge variation.

We just want a method that takes very little time to get up to the RPM and is consistent. Any ideas are appreciated and welcomed!

Take-Back-Half (TBH) control.

[team-4480]

Originally Posted by ThaddeusMaximus

Take-Back-Half (TBH) control.

What do I start H0 with? Something low?

[ThaddeusMaximus]

Originally Posted by team-4480

What do I start H0 with? Something low?

I've a terrible memory. As a wise Shia LaBeouf said, "Just Do It": Make sure there's no safety hazards with the shooter running at full blast and try something

I could be wrong but with at 15000 PPR encoder and 5000 RPM, we were using a H0 somewhere in the thousands...

[team-4480]

Originally Posted by ThaddeusMaximus

I've a terrible memory. As a wise Shia LaBeouf said, "Just Do It": Make sure there's no safety hazards with the shooter running at full blast and try something

I could be wrong but with at 15000 PPR encoder and 5000 RPM, we were using a H0 somewhere in the thousands...

Is this generally how you would do it?

            #define self.last up top
            ....

            self.difference = 3200 - self.encoder.getRate() #3200 is the target RPM
            self.averageDiff = ((self.last + self.difference)/2)*.0000005 #Finds difference and averages then multiplies gain
            self.totalSpeed+=self.averageDiff #Adds it to the PWM speed
            self.last = self.difference #Gets ready for the next time
            self.speedShooter=self.totalSpeed #Sets the speed

[ratdude747]

I'd go for a PID. You'll need to convert the encoder count to a 0-1 range of speeds, but otherwise, if it's like it was back in the old days (2011), it's pretty easy to set up.

As for tuning said PID, there are various ways (google it, as I don't have my controls textbook handy). Whichever tuning technique you use, you'll want to get it so it has a quick response without breaking anything, blowing anything, or oscillating. I'd avoid over-tuning (getting it really, really spot on) as you're liable to become marginally stable (which puts you one bit of drift away from instability).

Yeah there is probably an easier FRC-specific way to do this, but this (minus the PID code) is what they do in industry and will likely produce the best results possible with your hardware. As many of us know, controls can be temperamental to tune, but when you get it right, it will deliver.

[Ether]

Talon SRX PIDF 1 2

TBH 1 2

Bang-Bang 1 2

[Tom Bottiglieri]

Use the Talon SRX in speed control mode. The update rate and onboard filtering is better than anything you'll be able to get in code running on the crio.

[thatprogrammer]

Originally Posted by Tom Bottiglieri

Use the Talon SRX in speed control mode. The update rate and onboard filtering is better than anything you'll be able to get in code running on the crio.

What if he decides to use a roboRIO?
Also: Is there a way to use the roboRIO's PID class or make a custom PID class that can do speed control?*

*Could you just use a generic PID controller and use the following piece of code? (As ratdude747 implied)

if(Motor_Speed<0){
Motor_Speed = 0;
}

[kiettyyyy]

Originally Posted by thatprogrammer

What if he decides to use a roboRIO?
Also: Is there a way to use the roboRIO's PID class or make a custom PID class that can do speed control?*

*Could you just use a generic PID controller and use the following piece of code? (As ratdude747 implied)

if(Motor_Speed<0){
Motor_Speed = 0;
}

That's what he meant. The SRX is extremely capable..

[thatprogrammer]

Originally Posted by kiettyyyy

That's what he meant. The SRX is extremely capable..

I thought the emoji would make my sarcasm obvious.
I brought up the idea of "limiting" the PID's output range from 0-1 (As suggested by ratdude747) in case if someone wishing to control a flywheel didn't happen to have an SRX handy.

[GeeTwo]

Originally Posted by Ether

TBH 2

This links to this post:

Originally Posted by Ether

^Following up on the above^

You can improve the spinup response of TBH by clever selection of the initial values before you change the setpoint "S" from 0 to your desired speed.

Do a simple open-loop test to establish the approximate value of motor command (in the range 0 to +1) required to hold your wheel speed at the target value. Call this experimentally determined motor command value "M". It doesn't have to be exact.


To start your spinup do the following:

Set S to your desired wheel speed; initialize Y=1, d=1, and b=2*M-1; and turn your speed controller on.

Since Y=1, you will be applying full voltage to the motor to spin it up (just like bang-bang). Y will remain equal to 1 (applying full voltage) during the spinup, because there will be no zero crossings until you reach the target speed S.

When you reach the first zero crossing (at the target speed), the TBH algorithm will set Y (and b) equal to (Y+b)/2 = (1+(2*M-1))/2 = M, which is the experimentally-determined motor command value required to maintain the wheel at the target speed. You will immediately have the correct (or approximately correct) motor command for your target speed. This will reduce overshoot and oscillation.

If I read this correctly, this will not work some of the time, but not in all cases:

• If M (the first approximation to the speed) is exactly right, this would result in a tiny overshoot (as the controller notices and reduces the applied voltage) followed by a decay ramp* back to the desired speed. -- GOOD (and quite lucky)
• If M is a bit low, this would result in the same tiny overshoot followed by a decay ramp* towards a speed less than that desired. At some point, this ramp will cross the desired speed, and the remainder will function exactly as Take Back Half is intended -- GOOD
• If M is a bit high (results in a speed greater than the acceptable variation from the desired speed), this would result in the same tiny overshoot followed by a decay ramp* towards a speed greater than that desired. The speed will never again cross the desired speed, so TBH will make no further adjustments, and the speed reaches an asymptotic limit outside of the desired speed range -- NOT GOOD.

I would expect more consistent results by calculating the initial b as 2*M'+1, where you are confident that M' is below the "proper" value for M, perhaps 75% or 90% of your "best estimate" depending on how well you know this number.


* - As long as the system has continuous, monotonic response near M, and some sort of frictional losses, there should be a decay ramp of some variety or other, which is enough for my argument. If the system is linear near voltage M, and the frictional losses are viscous (proportional to speed), this will be a classic exponential decay ramp.

[Ether]

Originally Posted by GeeTwo

...If M is a bit high (results in a speed greater than the acceptable variation from the desired speed), this would result in the same tiny overshoot followed by a decay ramp* towards a speed greater than that desired.

You don't ramp "towards a speed greater than that desired". You ramp toward the setpoint S, by reducing (or increasing) Y. When you cross the setpoint, the sign of the error changes, and Y is adjusted.

Originally Posted by GeeTwo

The speed will never again cross the desired speed

Y will be integrated in the proper direction until the sign of the error changes. You will cross the setpoint.

[GeeTwo]

Perhaps I missed something really basic, but this is how I read these posts:

Originally Posted by Ether

You don't ramp "towards a speed greater than that desired". You ramp toward the setpoint S, by reducing (or increasing) Y. When you cross the setpoint, the sign of the error changes, and Y is adjusted.

This is only true over the longer course if/when Y is regularly adjusted. I was referring to the period between the first and second crossings of the setpoint speed, during which the voltage applied is held constant. My contention (presented below) is that the second crossing is never achieved in my third case (estimate for M is too large), beginning from a standstill.

Originally Posted by Ether

Y will be integrated in the proper direction until the sign of the error changes. You will cross the setpoint.

How does integration of Y cause the sign of the error to change? The "crossing" is determined by whether d and e have the same sign bit. Y is not part of this calculation, only S (setpoint/desired speed) and P (measured speed).

Here's what I'm considering: for simplicity, let's assume a ridiculously simple system such that over the range of 0.2 to 0.8, the asymptotic/terminal speed is equal to the applied voltage multiplier (for a fresh battery). The target speed is 0.5, but M for a desired speed of 0.5 was previously mis-measured at 0.6.

At initialization, b = 2 * 0.6 - 1 = 0.2. e=S-P begins positive, as the motor is not moving (Set point speed definitely faster than measured speed).

The applied voltage multiplier at startup is 1.0, which causes the shooter to promptly reach a speed of 0.5. By the time speed reaches [for argument's sake] 0.51, the applied voltage is adjusted to 0.6, and e is set to a negative value (that is, running too fast). The speed then continues to increase until asymptotically reaching 0.6. d continues to return negative values, so signbit(e) == signbit(d). The if clause in your loop is never reached, and the voltage is held at 0.6 -- until the battery voltage drops so that a voltage multiplier of 0.6 cannot maintain a speed of 0.5. At that point, the algorithm would begin to work as desired, but the match would likely be long over.

[Ether]

Originally Posted by GeeTwo

How does integration of Y cause the sign of the error to change?

Because Y is the output to the motor controller, and the integration of Y is always in the direction to drive the speed toward (and then past) the setpoint... which causes a change in the sign of "e".