Flywheel Help!

Can someone please tell me how your flywheel is able to shoot balls (consistently) as fast as your intake can work? I’m wondering if 4 motors isint enough to recover fast enough. Or if i have too much friction somewhere. Or if its all in a code to recover quickly. Any help would be greatly appreciated! Thank you so much!

It really depends on how you built the flywheel. ( is it 2 wheels or just one ) and where you have the ball entering the launcher. The problem we had back when we were using a flywheel was that the wheels were squeezing the ball too hard. If it is a double flywheel you should start from there. If its a single flywheel you should try adjusting the curve that the ball rolls off of when it is in contact to the ball ( Picture ). If the ball is being squeezed too hard on the wheel it will put pressure on the motors. This will lead to the wheel slowing down and increasing the speed up time needed to fire again. ( Lowering your firing rate.)
Hope I helped & Good Luck!

Alright so here’s a few things that our team has done:

-Added encoders:

This is a crucially important step to consistency, it really does help, and I honestly think it is 110% the way to go. I know that I haven’t implemented it in the best way possible, so I’m not going to post my code, and I’m going to let other people on the forums here try to explain the best algorithms to use, however they will need to know if you are using easyC or ROBOTC.

-Ball Feeding Mechanism:

This is also crucially important, the way that the ball enters your launcher is very important, and the best bet to get it centered each time, is to have two rails that the balls ride along. Also, you might want to add some sort of “roof” so that the ball enters the launcher at the same height each time.

-LED Indicator:

We also added an LED indicator, so that we can know exactly when the flywheels have reached the target RPM, which is best to fire the ball at. That looks pretty simple in code, here’s an example of what it looks like, I’ll use XXX for numbers which you will have to insert.

if(RPM > XXX && RPM < XXX) {
SensorValue[LED1] = true;
}

else {
SensorValue[LED1] = false;
}

If you need any other help let me know!

Thank both of you so much! Im building a single flywheel. Does anyone know if running 3 motors on the flywheel will still have high fire rate? and also do you know if using a heavier or lighter wheel is better? Heavier wheels take longer to speed up but have more momentum but lighter wheels speed up faster and have less momentum so im wondering what would work better?

I also have a question about the LED? How do you wire the led into your robot? Which port do you come out of to give power to the LED? I really love the idea about the led because i know it will help.

Again thank you both for helping me!

you could decrease the speed of the intake to give it time to recover

If your launcher shoots Full court, 3 motors will have at most an OK rate of fire. If you could squeeze for the fourth it would make all the difference. On my flywheel earlier this year, we had 3 motors and it couldn’t handle the power needed(partly the ratio) to sustain faster outfield firing. But infield was perfect and could shoot 1-2 balls a second. We had a 4in omni-wheel on a 1:40 (1:25 *1.6) 3 motor flywheel.
Also recovery may require you to increase the voltage to the motor for a short time to get the motors back up to speed. See the physics of the flywheel post about how power decreases after every shot.

I agree with the above post, the more motors the better, it’ll go faster, have more torque, etc. Also, we ended up going with the heavier wheel with more momentum, but it was almost a flip-a-coin type of thing, both performed almost identically.

As far as recovery time goes, that’s another encoder thing… It’s something we haven’t had to implement, as our robot recovers fast enough without it anyway, you’ll just have to see, but here’s some information about it: So you’ve obviously by now heard of a PID loop. This is the loop in your code that takes the value of the RPM of the motor, and adjusts the power of the motor to compensate for battery loss, resistance, etc… It’s basically ensuring that your flywheel is spinning at the exact same RPM every time no matter what. Anyhow, you probably want to use the I portion of the loop first, and then incorporate the P portion if you need your recovery time to be faster… Don’t worry about the D part of the loop… We only had to use the I portion, and the algorithm for that looks like this:


power += (set - actual)*kP

Power being the power being fed to your motor,
set being your target RPM,
actual being the actual live RPM of the launcher,
and kP being the scaling constant (which you’ll have to play around with a bit, it’s the number that the launcher power is multiplied by, but mind you, since the code loops so fast, ours ended up being something like .000005 or something, but it all depends on your launcher and what your target RPM is, so most likely, if you try to do a half court shot, you’ll want to tune kP for that as well, rather than just using the same one you used for full court)

As far as the P part of the loop goes, this is where other people are going to have to help me out, since we haven’t used it, I haven’t had to learn how to do it.

As for the LED, that’s easy, and yes, it really does help a lot… We used one of the extender cables that come with your kit, plugged it into a digital port on the cortex, and plugged the LED into the other end of the extension cable. In your motors and sensors setup, under digital sensors, pick a port, call the led something (like LED1) and set the type of sensor to “VEX LED” here’s a good picture on how to hook it to the end of your extension cable:

Let me clear some things up since you don’t seem to understand PID all that well.

What you posted above is the algorithm for the P/Proportional part of the PID controller. The I/Integral part of the PID controller is:


Integral = Integral + lastError;
lastError = error;

Error is the difference between your target value and your current value. The Integral acts as the running sum of past errors and helps the robot to ** gently accelerate ** to the target value. In the final calculation for PID, you’ll use a constant(that requires tuning)multiplied by the integral, like so:


power = error * kp + integral * ki;

Notice how I only used an assignment operator? The “+=” operator shouldn’t be used in PID as it will never allow the final output to stop the motors since you will be continuously adding on to that final output.

Also make sure to start with the P controller before adding on your I and D controllers. There’s a reason it’s called PID and not IPD.

Sorry, but I am a bit confused by what you have wrote. I usually write my I Controller as:


Integral =  Integral + (current_error * ki);

So is there a difference between these 2 statements? And if so, what are the effects of these differences? Thanks!

Four motors should be enough to operate it.

I don’t think that there’s much difference between the two.

In your example, you’re using the current error to calculate your running sum which is okay. I use the error from the last running of the loop since I think it’s better to have the Integral running behind the P controller slightly so that the Integral doesn’t grow too big too fast.

You also use your Integral constant to multiply the current error. I’ve always used ki in the ending statement so that it will apply to integral after it has been calculated. I believe that this has a greater effect on the final output to the motors. The way you use the Integral constant seems to help limit the integral value by not allowing the current_error to grow the Integral quickly. This may be why you don’t need to use the error from the last looping of the PID.

Both solutions seem to work well enough, so you keep doing you.