# Speeding Up and Slowing Down a Flywheel

Our team is having trouble with speeding up and slowing down our flywheel gradually. We’ve tried all sorts of code, but we can never get it to work. Our goal is to write code where our flywheel gradually speeds up when R1 is pressed, and gradually slows down when R2 is pressed. We’re not having any success with this so any help would be appreciated.
We’re using python on Vex v5

I can try to do it on blocks but I’ll be useless to help with text code

I haven’t gotten the code to work personally, however it would be simpler to try and use up/down buttons to control your speed percentage in increments. I have seen other teams get this to work.

Few different ways to do this.

1. write code using variables where they increment (with a delay to prevent ramping to 100% in a fraction of a second) as long a either button is pressed
2. limit torque while buttons are pressed, but have full torque available once up to speed (to quickly recover from launches)
3. etc
1 Like

I use a velocity shift code, where if I press certain buttons it goes up or down by a set amount. I can provide the code if needed.

1 Like

I’d recommend watching your watts and temp.

Motors, unless carefully coded, tend to use max watts until they are at target velocity. Given the mass of the flywheel, the motor has a tendency to oscillate above/below target rpm… using more power during this time.

If you want slow start/stop… torque limiting the motor, which ties directly to watt limiting it, is probably the way to go.

Could write code to measure & calculate total power used by either method… that would be cool.

We use volts to do anything less than 100% flywheel power, but using velocity for 100% works well because the motor doesn’t accidentally overshoot.
The oscillation, in my thinking, seems to be caused by the motor using velocities and stopping or slowing down it’s acceleration when nearing it’s target velocity, but because of the flywheel weight, the flywheel continues faster than the motor wants, so it tries to slow it down, but then undershoots, so speeds up again, entering a loop.

My team uses velocity shift code in increments. Here’s our code:

`````` if(Controller1.ButtonLeft.pressing()){
firstBool = true;
}
else if(firstBool){
flywheelSetSpeed(shortRange);
}
if(Controller1.ButtonDown.pressing()&&firstBool == true){
firstBool = false;
secondBool = true;
}
else if(secondBool){
flywheelSetSpeed(longRange);
}
if(Controller1.ButtonRight.pressing()&&secondBool == true){
secondBool = false;
thirdBool = true;
}
else if(thirdBool){
flywheelSetSpeed(midRange);
}
if(Controller1.ButtonUp.pressing()&&thirdBool == true){
thirdBool = false;
fourthBool = true;
}
else if(fourthBool){
flywheelSetSpeed(defaultRange);
}
}
else{
// Resetting the flywheel to its default range
flywheelSetSpeed(defaultRange);
// Resetting all of the Booleans to their false states
firstBool = false;
secondBool = false;
thirdBool = false;
fourthBool = false;
}
``````

I’ve found that velocity changing in increments to be the best way, generally. Here, we use increments of 25% motor power. I’m not very knowledgeable on volts, as I’ve always just defaulted to using motor percentages.

1 Like

According to some pretty convincing data from (sylvie?) the encoder is inaccurate, sometime showing a value above/below the true value.

But the build in pid is not tuned for a flywheel either. A flywheel is an edge case for pid, whether vex-provided or user-built.

Instead of a code you could make a ratcheting flywheel that will gradually slow down and to speed it back up you can limit the motors torque to like 50 percent.

The encoder explanation would explain the oscillation, but I also doubt that it would act the same on a flywheel ratio without a flywheel attached. In my mind, the mass of the flywheel has to have something to do with the oscillation, but that’s just a guess right now.

Also, the built in pid seems to lack the function to slow down when nearing its target, as far as I can tell. This feature would likely, if made correctly and working in the circumstances, solve the oscillation. In my little knowledge of the concept of pid, does this feature or lack thereof qualify the program as not being a full pid, eg. a pd? (from what I can tell P I and D are 3 different ways to program the function of where i am, where i should be, and how to get there, and PID is integrating all 3 ways)
(Yes this contrasts with my above hypothesis of the oscillation cause)

1 Like

I can’t answer any of that with enough confidence. If I wanted to explore it, I would capture data (rpm, watts, etc) and try to see exactly what’s going on.

It’s worth noting that this does not appear to be a problem if you simply use 100% speed. The oscillations happen at reduced speeds only, which calls some of these ideas into question.

1 Like

I believe that the oscillation not occurring at 100% speed would be due to the motor physically not being able to use more power, therefore being unable to overshoot. I also agree that capturing more data would be the next best action to investigate further.

When I say 100% speed, I mean rated speed/rpm of 600 rpm. And a good flywheel, at 600 rpm (using blue cartridge) can use as little as 1.5 watts, leaving 9.5 watts available for reserve.