Flywheels and Shooter Wheels
 

Our robot uses a single-wheel shooter on a rotating turret. (Actually, it's two wheels close together on one axle, so they act as one wheel for purposes of this discussion.) We're considering adding a flywheel, because it is supposed to help with consistency, given the different ways balls react to the shooter (older balls get softer, so they don't shoot quite as far for the same settings). At least, that's what we've been told.

My question is, has anyone done a test to demonstrate that the flywheel helps, and by how much? How big a flywheel is needed? I enjoy trying new things, but at this point in the season (our second regional is a little over a week away) I don't want to have my team spend a lot of time and resources for something that may be of no value. Possibly it could do more harm than good (causing vibrations, increasing spin-up time, adding weight high on the robot...). But if I saw evidence that it really helps, we could be convinced to give it a go.

Re: Flywheels and Shooter Wheels
 

We decided against a flywheel, because we found that the mass slowed our ability to get back up to speed after a shot. Instead we use a tightly-controlled PID loop with 'normal' speed at about 70% power. The extra 30% "headroom" allows up to spool the wheel back to speed in about 1.6 seconds at present, but we are working to improve the response time.

One difference to your wheel is that we use two powered wheels opposing each other, allowing us to more closely control backspin.

Re: Flywheels and Shooter Wheels
 

A flywheel will allow for tuning your pid more easily. The increased inertia will help damp acceleration and deceleration.

However, consider it as a physics problem.

From a standstill, you need to spin that flywheel up to a given RPM. The heavier the flywheel, the more work it will take, and the longer it will take.

Once you have fired a ball, a given amount of energy is transferred from the flywheel to the ball. Regardless of whether your shooter slows down a little (heavy shooter) or a lot (light shooter), you'll need to use your motors to add that same amount of energy back into the system. The same amount of energy is removed from both systems, so the motors will have to work just as much in either case to add it back in.

The sum effect is that unless you make your flywheel so heavy that you can shoot without having to spin it back up, a flywheel will only slow down your shooting, due to a longer initial spin up time. It may make it easier to tune a PID to control your shooter. We use 8 inch wheels and have managed to tune a fairly accurate pid (+/- 6% speed).

Re: Flywheels and Shooter Wheels
 

I think a shooter with a flywheel can transfer a little more energy than without a flywheel. I am assuming that the rate of energy transfer is proportional to the difference between wheel speed and ball speed. Imagine two identical shooters A and B, except that shooter B has a flywheel. Shooter A will slow down during the launch process, so it will be adding less energy near the end of the launch. Shooter B will maintain its speed (nearly), so it continues adding energy to the ball at a higher rate than A.

What I don't know is, does the flywheel help the launcher behave more consistently with balls of different stiffness? "Consistent" meaning balls exiting the launcher at the same speed, regardless of stiffness.

Re: Flywheels and Shooter Wheels
 

Hello, some of this is slightly off topic but I do have a reason behind it.

During the build season Team 1100 had a huge consistency issue with our basketballs. four out of our five were relatively normal (and behave how the competition balls behaved at WPI regional), but one was especially hard and dense. we had originality built an opposing wheel shooter that was powered by an FP motor on each wheel with a 4:1 reduction using KOP wheels. After testing we where not able to control the speed of the shooter reliably enough to score any balls consistently. We decided to switch to a single wheel shooter with both of the FP motors running on direct drive. The new shooter was capable of shooting 3 pointers from the key according to the math but wasn't meeting that in real life so we had a slight problem. To fix the problem we added two steel flywheels inside our shooter wheel (a 2.3" OD PVC pipe) each one is about a pound and has an OD of ~2 inches. and increased the compression of the ball by moving the back plate in, causing more energy to be put into the ball.

With these modifications we noticed a few changes:

1. More consistency at all speeds, regardless of ball properties
2. Better control of the ball, especially at low speeds
3. Greater top-end range
4. Less effect on our shooter' surface velocity while we were shooting

It should be noted that the only way we could increase the compression was to add the flywheel because the shooter bogged down to much without it.

At the WPI regional we decided to forgo shooting from the key because it was much more consistent to have our operator aim from the fender instead and we didn't fully have the control algorithm for our turret's tilt mechanism up and running. That said, 1100 was the first seed at the regional and only missed 5 balls all competition wile running in AUTO mode. Two of which were due to positioning the robot in the wrong spot to accommodate an alliance partner.

At Boston we intend to run the same auto-mode but shoot 3s from the key.

I hope this helps,
-Dan

Re: Flywheels and Shooter Wheels
 

We didn't actually test out flywheels on my team, but I would think that flywheels would improve consistency. One of the problems with stiffer balls is that they require more energy to compress and thus slow down your shooter much more - taking energy that is not really going towards speeding up the ball. Flywheels, as was said previously, cause your shooter to maintain its speed better when it is transferring its energy to a ball. By maintaining wheel speed, you ensure that "stiffer" and "squishier" balls exit closer to the same speed.

That being said, sizes and weights of flywheels for this purpose would require testing and data. Soooo I guess you either need to try out some flywheels yourself or hope that somebody comes along with the data instead of using general conceptual analysis of the problem.

Re: Flywheels and Shooter Wheels
 

Our shooter, as designed and built, included an aluminum flywheel between the two shooter wheels, on the same rotation axis. Preliminary testing showed all the benefits you would expect, consistent shots and nearly no RPM dip between shots. And, yes, the PID control over the wheel RPM was much smoother. Surprisingly, the flywheel did not make such a difference in the spinup time, as we have plenty of excess shooter drive motor power. As the electronics were installed, it became evident we had a serious weight issue, and the flywheel had to go.

We have solved our weight issues (shortening the tower helped) and now probably have the spare weight to reinstall the flywheel. But, with the importance of bridge balancing, we may not be willing to add back 2 lbs to the top of the tower. That weight may be better spent on adding a "killer bees" style balance steadying stinger. We'll see how our first competition goes this weekend.

Re: Flywheels and Shooter Wheels
 

Thanks for these responses, everyone. This discussion is really helping.

Several people have mentioned PID control. Are you using the Jaguar built-in PID feature, or are you implementing it yourself in the cRIO? Either way, what's your tuning method, and how long did it take? We only have the Thursday at regional competition to get it done.

Re: Flywheels and Shooter Wheels
 

I am confused as to what the difference is between a fly wheel and a shooter wheel??

Re: Flywheels and Shooter Wheels
 

Yes I am also interested in how you guys do PID looping. A code snippet anyone?

Re: Flywheels and Shooter Wheels
 

The shooter wheel is an object that propels the ball from the robot. it may have some inertia but usually doesn't have very much.

A flywheel is a device thats only purpose is to store rotary inertia. It is usually heavy and has most of it's weight as far away from the center shaft as possible to maximize the inertia to weight ratio. Ideally the flywheel would be direct drive from the motor where the shooter wheel would be through some gear reduction.

On many teams these two objects are the same.



On an unrelated note, 1100 didn't need to use a PID control to get consistency in our shooter, just standard PWM drive through a jag.

Re: Flywheels and Shooter Wheels
 

This wouldn't be very ideal (or safe) on a 19,000 rpm motor like the 550.

Re: Flywheels and Shooter Wheels
 

That's not "unrelated"; it's very relevant, as implementing a PID within the limited timeframe is one of my big concerns at this moment. If we can just use open-loop control and still get (most of) the benefit, we are more likely to go for it.

Re: Flywheels and Shooter Wheels
 

You didn't mention in this thread what motor controller you are using. If you are using a Jag via CAN, at least consider using Voltage mode instead of %Vbus. This will compensate for varying supply voltage.

Re: Flywheels and Shooter Wheels
 

You can also do similar compensation in the cRIO by scaling your command based on the battery voltage. A member of team 1986 outlined their specific method of doing so in one of these PID/shooter threads somewhere.

Re: Flywheels and Shooter Wheels
 

Flywheel vs PID control was the biggest unknown we had this season, so we decided to make our shooter as flexible as possible.

I CAD'ed tight-tolerance plates that would bolt onto the side of our 8" IFI wheel using the pre-existing holes, and then had 12 of them watercut out of 1/4" plate. This gives us a total of about ~3.5 lbs in flywheel weight in removeable increments of ~0.6lbs. We haven't actually taken any of the weight off yet because the balls are extremely consistent distance-wise. We have yet to test integration of the software PID, but as a backup we also have human-in-the-loop control via a tactical display.

We have a 2.5 second spin-up time to ~2000 RPM (from the key), but the wheel can aggressively spin up to 3600 RPM in under ~1.5 seconds if we let the motors run without the trapezoidal speed profile.

During initial testing the wheel only spun down about 20% (200RPM-ish) while compressing the ultra-squishy balls 1" and could return to the target speed in about 1 second. We didn't measure spin-down of stiff balls with 0.5" compression, but the distances were the same. We have this ridiculous test & integration plan to figure out compression, PID adjustments, flywheel weights, driving constraints and what the actual balls will be on the field. If I'm not exhausted after tomorrow's practice, I'll report back some actual #'s.

Re: Flywheels and Shooter Wheels
 

Shared test data is always greatly appreciated. Thank you.

Re: Flywheels and Shooter Wheels
 

Ether,

You may be making several assumptions with this statement. This year 1100 is using a single wheel shooter that is mounted direct drive to a Fisher Price motor (9015 or 9013?) our shooter diameter is about 2.3" (although if I rebuilt it I would use 3" tubing instead) and as such we can get away with a very small flywheel.

We know the energy stored in a flywheel can be represented as:
E = (Moment_of_Inertia * Angular_Velocity^2)/2

So if you double the angular velocity you will effectively quadruple the Energy stored in the flywheel. On the same lines, if you have a target Energy you wish to store in the flywheel, then by connecting the flywheel to the motor and not to the shooter shaft you can use a smaller lighter flywheel (more ideal in FIRST applications where shooters tend to be high up in the robot and weight and balance are issues).

The other thing I would like to mention is that the safety of the system mostly depends on the configuration of how things are assembled. If properly done there is no more chance of something going wrong in one model of the system then in the other.

If you have concerns about the safety of direct drive applications of the flywheel/shooter in our robot please send me a PM.

Re: Flywheels and Shooter Wheels
 

We're using Jaguars via CAN. I'll need to check with the programming subteam whether we're using Voltage mode or %Vbus. Thanks for the suggestion, Ether.

Re: Flywheels and Shooter Wheels
 

Our shooter was working rather well on practice day, before very weird electrical problems knocked it out for the rest of FLR. Our tuning method took about an hour, and was as follows (using encoders for feedback):

Start with all values at zero. Increase P until further increases result in a similar stall below the threshold value. (Too low will result in stall, FYI, so start with a value above that). Decrease P to the minimum value in that diminishing-returns range.

Start with a large I. You'll notice that it takes a long time to get up to speed, but it does get up to the target value and holds steady without overshooting. Decrease I until you get a ramp-up that satisfies your needs.

Spin it up, then feed in a ball and make sure that it ramps back up to speed without oscillating. (Ours didn't oscillate using this method).

Leave D at zero.

-------------

That, at least, worked for us... Though if you saw us at FLR you'd just have to take our word for it. (Rattin' smattin' electricity!)

Re: Flywheels and Shooter Wheels
 

You didn't mention if you were using cRIO or Jag PID. I suspect cRIO since you said to start with large I ?

Re: Flywheels and Shooter Wheels
 

Right, sorry. We're using all Victors due to cost and available parts (we have lots of Victors, but not lots of Jags). Starting with the large I was a matter of keeping the stability we needed and then tuning in spin-up speed, rather than trying to maximize spin-up speed and then tune in stability.

Re: Flywheels and Shooter Wheels
 

Ether, would you recommend a different method if we're using PID in the Jag? We are using Jags controlled via CAN, so we have the choice to put the PID in the Jag or cRIO.

This is really helpful stuff. I'm enjoying this thread very much. Thanks, everyone!

Re: Flywheels and Shooter Wheels
 

We have a flywheel that is currently geared 2:1 off of a CIM motor. The flywheel is about 5 lbs I believe or very close to that. We only run it at 80% capacity though because it gets pretty scary when it gets up to full speed, sounds like a jet turbine spooling up, it has a very distinctive whine to it. It shoots the balls pretty decently.

Re: Flywheels and Shooter Wheels
 

Depends on what language and library you are using.

Check out this post, especially the last sentence:

http://www.chiefdelphi.com/forums/sh...33&postcount=6

Re: Flywheels and Shooter Wheels
 

If the PID is in the Jag, why does it matter what language we're using in the cRIO? I thought the Jag already has a PID control built in, and we just configure it (set the constants, etc.).

Anyway, we're using Java, with the library supplied by FIRST.

I understand the basic theory of PID control (I'm no expert, but I have a good idea of the general process). I'm looking for advice on how to obtain the constants for the controller. I figured that might be different for Jag-based PID v. cRIO.

Re: Flywheels and Shooter Wheels
 

I should have been clearer. My point was that all PIDs are not created equal. There are several different "forms" of PID, and in the different forms some of the tuning constants have different meanings.

So if you were using a language/library on the cRIO which used a different form of PID than what is used in the Jag, then you would tune the Jag PID differently from the way you would tune a PID in the cRIO.

By "tune differently" in this context I mean you would have to be aware that, for example, in some forms of PID you decrease the I term to increase the I effect.

It does.

Correct.

Here are some possibly useful links:

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

http://www.chiefdelphi.com/forums/sh...d.php?t=100135

http://vamfun.wordpress.com/2012/02/...ero-placement/

http://uberbots.org/o/Resources/For_...ms/PID_Control

http://www.chiefdelphi.com/forums/sh...04&postcount=3

http://www.chiefdelphi.com/forums/sh...90&postcount=5

http://www.chiefdelphi.com/forums/sh...38&postcount=4

Re: Flywheels and Shooter Wheels
 

Ball consistency is horrible. We're basically calibrating a measured 'swish' from the key, then adjusting a dead-reckoned distance based upon our point of reference and how 'squishy' a ball feels. Terrible. 1218 up in MAR really has somethin special, heh.

Re: Flywheels and Shooter Wheels
 

We decided early on that a flywheel would not be necessary to shoot the short range shots that we decided to work on. A pair of fisher prices driving the first stage of a FP gearbox going via chain to our shooting wheel, overall reduction is between 1:6 and 1:9 (still experimenting to find the sweet spot for consistent fender shots). It spins to top speed in less than 2 seconds. We chose this non flywheel setup for several reasons:

1) short range shots were what we decided to peruse
2) the shooter needs little to no time to spin up, making shooting multiples simple and easy
3)high CG is unacceptable this year, a flywheel up high would raise our CG (currently 5.5-6.5 inches off the ground)
4) our custom gearbox driving the shooter wheel was easily switchable, and if there was a problem then we would simply add more motors until there was enough power available

One pro of the flywheel design is we considered using it as a gyroscope to balance the bridge more easily, this was ruled out as too complex and heavy.

Re: Flywheels and Shooter Wheels
 

Here is Team 2848: Jesuit All-Sparks PID Wheel Control Machine. It runs inside periodic tasks. It can be triggered anywhere in code through the use of a Global Variable or it can be over-ridden on the front-panel for easy calibration/testing.

Re: Flywheels and Shooter Wheels
 

Thanks for posting code, Baronep. How did you determine the constants for your PID?

Re: Flywheels and Shooter Wheels
 

Try this instead:

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

Re: Flywheels and Shooter Wheels
 

Thanks for the link to that thread, Ether. I especially liked the clear description of feed-forward, including your diagram.

We're heading to our second regional (Buckeye) tomorrow, and will implement some (wish we could do all) of the ideas in this thread. I'll let everyone know how it turns out.

Even if we don't have time to implement most of these improvements during competition, I now have more ideas for off-season projects for the team.

Re: Flywheels and Shooter Wheels
 

This could very well be the ideal way to control a shooter wheel's speed.

• Fastest possible spin-up and recovery time
  
• No tuning necessary
  
• Stable over a wide range of loads
  
• Extremely simple to code in any language

Think about how this works. Whenever the measured speed is below the setpoint, full voltage is applied to the motor, providing the fastest possible spin-up and recovery. When the motor reaches the desired speed, the power is removed (voltage set to zero). Since we are controlling speed (not position), there is no overshoot due to "momentum". There is no "momentum" to carry it past the setpoint, since the setpoint is speed, not position. Once the power is removed from the motor, the acceleration goes to to zero immediately*, so there is no further increase in speed.

The only overshoot is caused by the sample time: since this is not a continuous (analog) but rather a discrete (digital) controller, the power to the motor is updated only once each execution cycle. But if the execution cycle time is 20ms (e.g. TeleOp), then the maximum overshoot in rpm would be 0.020*wheel_acceleration_in_rpm_per_second. At motor speeds typical for a shooter and with sufficient moment of inertia in the wheel, the wheel acceleration is low enough that when multiplied by 0.02 creates a very small maximum overshoot.

Once the wheel is at the setpoint speed and the power has been removed, the wheel will of course begin to decelerate (due to friction, windage, etc). But the moment it goes below the setpoint, maximum voltage is again applied* and the cycle repeats.


*subject to any voltage ramping that may be in use