Some people said that in order to use a flywheel a ratchet would be required or a deceleration program. What is a ratchet and why would not having one damage the motors.
It allows the flywheel to continue freely spinning for a short period of time even after the motors stop rotating. Else the momentum of the flywheel as it attempts to continue spinning against an unpowered motor may damage the motor.
so how does it work?
A ratchet can spin in one direction but not the other. When you try to spin in the other way, it locks. You can find a bunch of photos and videos of them in VEX. I’ve got some I built as demo pieces I’ll probably photograph in the next day or two, but some searching will turn up examples faster. You can also look at bicycles and many wrenches, especially socket wrenches, among other things.
I’m not sure we really need ratchets with the V5 Smart Motors, though. Motor.setStopping(vex::brakeType) has “coast” as one of its options. Depending on how the motors are built, this could allow a fairly free spin or it could have a decent amount of loss. But it’s not like ratchets don’t have a lot of loss. The bigger question is if there is any significant back EMF from forcibly spinning the motor’s shaft and if it has any chance of doing damage.
Is there an event that runs when the robots are disabled for competition? Because if not then you couldn’t call the stopping function at the very end right?
I’m not quite sure why you need an event in particular for this. There are events that start pre-auton, autonomous, and user control. You could run motor.setStopping() during pre-auton, autonomous, or user control as you need. You could even switch things around between multiple settings in the middle of things if you want. You really don’t need to track any event for this if you’re set up properly for competition.
I was thinking that the flywheel would run the entire game?
Probably a waste of energy. You could. Even then, you might want to let it slow down some between shots to account for shorter shots. I think the typical will be to let it wind down until balls have been picked up, and then have it pick up to a certain speed based on how far away from the target the robot is and which height flag it’s aiming at.
Yeah we could probably do that, but is acceleration a problem? We’ve never used a flywheel before and people have had varying acceleration times.
From my experience, there should be no problems with accelerating the fly wheel , if you your gear ratio isn’t insanely high, then there should still be enough torque to accelerate. Especially with v5 motors, those are much more powerful
So uhh, I’d rather not have to wait for a spin up before every shot. You can easily tune a flywheel to shoot high and low with the same power where the only difference is the distance from the flag post. Picking speeds and waiting for acceleration to occur sucks imo (It also sucked in NBN).
There can be an acceleration if your flywheel is not built well. For reference, my flywheel accelerates to max speed in about 1.5 seconds with a high momentum flywheel but I’ve seen waaayyy varying times. Either way, I wouldn’t want to wait for acceleration before each shot especially in that crowded zone where you can get pushed in an instant.
Judging by your comments @newbievex, we are viewing robot designs similarly which is cool. I personally don’t have a ratchet because I just haven’t seen my flywheel damage my motors but I know it is a thing that happens. Generally speaking, I would want a ratchet for the end of the match where the robot gets forcibly powered off. If you have a flywheel that damages ur motors the only other way I see is to modify your competition control file to run a loop that slows ur motors down to 0 when the robot gets disabled, which is obviously illegal.
- There is a reason I said “typical.” I’m sure some will do more what you suggested. But if you look at quite a few comments on the forums and some videos, people really seem to like both the rapid-fire possibility of going high-to-low in targeting the flags as well as being able to shoot from any distance. In fact, quite a few people have commented on this specifically as an advantage of the flywheel v. using a single puncher or single catapult at varying distances.
- You’re 1.5 s is fairly trivial. If it took a lot longer, probably not. Consider the possibilities. Maybe you’re going around flipping a few caps. Do you not have 1.5 s before firing a ball? Maybe you’re closer, about to pick up a ball and then a second and then drive to the right spot to shoot. Do you not have 1.5 s from the first ball you pick up? You could have the motor trigger off of the first ball intake even so that you don’t have to do it manually. The moment the ball enters your robot the flywheels could automatically start going while you go after another ball or drive to where you’ll shoot from.
The fastest rapid fire I’ve seen is 929U’s and to my knowledge it’s just the same speed for both with a well-tuned hood. Also, I’m confused by your 2nd point. I’d rather waste no time than waste 1.5s that I could be using to shoot or intake more balls after shooting.
I would ask them. Flywheels slow down when used. Do they get it sped back up in the small interval? Maybe. They do drive forward while shooting, which allows hitting two different-height targets at the same speed. But requiring the same speed will put a cap on how fast you can do a rapid-fire. It may not be a significant cap, though. 448X has a significant amount of time between shots, and they do move forward, so I would totally buy that their shots are at the same speed, but they’re not really doing rapid fire. My main point was being able to shoot from different distances. WPI ri3d isn’t doing rapid fire but very clearly fires at different speeds to handle varying distances. Again, I’m not saying you have to; I’m saying so many have said that a big advantage of the flywheel is the ability to vary distance so easily, and since that uses varying speeds I expect we’ll see a lot of varying speeds.
If it takes your flywheel 1.5 s to go from stopped to full speed and you have to waste 1.5 s, I highly recommend revisiting your tactics. You don’t have to do everything sequentially. You can do things concurrently. The only way a 1.5 s speed up costs you 1.5 s of wasted time is if you only do it sequentially with other things. What I’m saying is there are plenty of other things in the game that will take you more than 1.5 s, so there is no need to try to constantly run your flywheel at its full speed. You certainly can, but it’s unnecessary. If the delay is significantly longer, then you’ll eventually run into such an issue.
Also, as for the point with ratchets, there is no team at all that runs their flywheel at full speed for the entire game. That’s a DQ right there. Again, I don’t know the specifics of the V5 smart motor. If the flywheel is running at full speed and the robot hits 0:15 or 2:00 and the motors stop, how much back EMF is produced and can it potentially damage the V5 motors?
Speed loss when shooting is the reason people opt for a high momentum flywheel to keep that speed loss to a minimum to where it can regain it’s speed close to instantly after a shot.
Also, I never said you couldn’t do things simultaneously. Starting up a flywheel in auton and in driver is the only time you legitimately have to speed up and you can do other things while you are starting up. My thing is that there is rarely a time where you are going to be say scoring a cap on a post and shooting a ball in this game (This is coming from scrimmage practice and videos from friends). It’s just too cluttered for that ideal to become reality. Looking at matches this year so far with actually capable robots (Sorry public YouTube videos lul) people who start up their flywheel every time have a significantly slower cycle time because of this factor.
Also, as to your last point, how is running your flywheel all match a DQ? Contrary to your secondary point there, there are so many teams that run their flywheels all match that your post seem like you are misinformed. Heck, even the OP was planning on doing it. To the best of my ability, I don’t see anything in the rulebook stating “Thou shalt not run thine flywheel all matcheth”
If you increase the flywheel’s rotational inertia, you’ll reduce the angular momentum loss. However, increasing the rotational inertia also increases the kinetic energy needed for a given speed, increasing the time it takes to provide the energy to get the flywheel up to speed. (I’ll have to do some calculations to gauge where the ideal is.)
1.5 s to accelerate meaning 1.5 s of lost time says exactly that.
Thus the contradiction. If you’re not shooting a ball at the same time as you’re dealing with a cap, then you have legitimate time to speed up a flywheel. If you ever have 1.5 s or more between any shots, you have the time if it takes you 1.5 s to speed up. The only way this isn’t true is if you manage to shoot balls every 1.5 s or faster (not average, but each gap no longer than 1.5 s) throughout the whole match.
They’re probably not starting up their flywheels at good times, thinking too much of running them sequentially instead of concurrently.
I’m sorry, but your statement is blatantly false. You are not allowed to avoid responding to field controls. As I said, your robot needs to stop at 0:15 and 2:00. Please explain how you are allowed to keep your robot’s motors going after autonomous and before driver control legally. Show me these “so many teams” whose robots don’t stop running their motors at the end of autonomous. If you can’t avoid responding tot he field controls, then you can’t run the flywheel the whole match. No, I’m not nitpicking something. I’m pointing out that the robot will hit a point where the flywheel is going quickly and the power is killed to the motors. The motors don’t care about the details of the rules, whether the stop is caused by your code or by the field controls. They care if this generates a huge back EMF through them that could potentially damage them. Avoiding this back EMF is a big part of using a flywheel, as I noted in my original reply.
LOL. Did you actually take what I said as “They are keeping their flywheel on through auton” I said that you would have to start it up in auton and in driver. If I only meant start it once and keep it going then I would not have mentioned driver. Anyone who has even glanced at a game knows that keeping it on during the phase between auton and driver is not legal. I thought I wouldn’t have to explain that lul.
is a very hard claim to justify. Every robot that starts their flywheel up just so happens to be starting them incorrectly and you are the only 3 trillion IQ person that knows the correct times to start a flywheel? Seems improbable imo, but hey. You could be the next Einstein for all I know
So you are suggesting speeding up the flywheel after every shot, shooting, stopping power, then speeding back up again since you just so happen to have 1.5 seconds of time before you are doing something. That’s one of the exact reasons why I advocate keeping it on the entire match. That rapid switching between speeds is not good for a motor. That’s one of the big reasons people use ratchets, ie the original reason for this thread. I’d rather have 2 spikes of power switching than multiple in a match. To add on, it just doesn’t make logical sense to turn something off then turn it back on near immediately to do the same task. As to this EMF thing that you are referencing, like I said in my earlier post, that 100% depends on how you build your flywheel and gearbox. Mine is built in a way to reduce all force exerted back into the motors and many other people take these necessary precautions (Having a fast wheel spinning is pretty dangerous lol)
I do want to note that so far, the best teams in NBN and (imo) Turning Point so far keep their flywheels on all match, so I’m guessing there’s a correlation lul.
- I thought it worth pointing out that even trying to run the flywheel at a constant speed throughout the match does not avoid the EMF issue from stopping that ratchets protect against.
- I said this is because the robots motors must stop at two points in the match (0:15 for the end of autonomous, and 2:00 for the end of user control).
- You specifically disagreed with my point about the robots having to stop at 0:15 and 2:00 (presumably only 0:15 part since you’d already agreed with 2:00).
Yes, you did say that. It may not be what you thought, but it is what you wrote, even though earlier you explicitly agreed with what I’d said for the end of user control, just not for the end of autonomous. Your comment didn’t look sarcastic, and you even tried to back it up with a bunch of things. Your new statement wasn’t corrected until I called it out as blatantly false. Now you’re walking it back just like you walked back the comment about not being able to speed up a flywheel while doing other things. I’m glad you’re taking it back, but don’t be surprised when people read what you write as what you write.
That’s what I thought, which is why I was shocked you wrote the opposite. I was looking for tags or something to indicate your statement wasn’t serious and just found things being piled onto your argument that the motors don’t have to stop at at least one of those points.
Oh, come now. Do you really need to get rude like this? You specifically said their cycle time is low, and we know it doesn’t have to be so long as they start it up at better times. Therefore they aren’t starting the motors up at the right times to avoid this extra delay. That’s just a statement of fact given the numbers and that you are telling the truth about some robots you watched. And as for every robot starting incorrectly, I never said anything close to that.
No, that’s not actually what I said. Can you find any statement above where I said you shouldn’t control the slew rate? I even try to control the slew rate on my blender at home as best I can with the manual controls. Happily, it’s starting to look like the V5 smart motor may have built-in slew rate control - we’ll see.
I agree. Of course, nothing I said even vaguely implied otherwise anyway.
Hey man, I found a video. Hope it helps!
They’ve probably figured it out by now as this thread is 2 months old.