Electric motors can exert torque anywhere from almost no torque to stall torque. If a drive gets into a pushing battle with a wall, the motors exert stall torque until they stall, but if you just spin a motor without connecting anything to it, it will exert almost no torque. You will notice this in the speed of the motor, since
power = speed * torque
However, there is a third case, which is between stall torque and free speed, and this case is basically everything. With a 4 speed motor drive on 4" wheels, and 15 pounds of weight on the drive, you will notice that the drive motors are not spinning at 160 rpm, which is the free speed of speed motors, but the motors do spin. Motors only exert as much torque as they need to, (or are able to, in the case of the robot vs. brick wall pushing battle). I haven’t observed flywheel acceleration enough to confirm, but the motors most likely exert the most torque at the instant that the motors turn on, before the flywheel starts to spin, when it exerts stall torque, and as the flywheel accelerates, the motors exert less and less torque to compensate for the increased speed (power remains fairly constant). I have a sneaking suspicion that if someone graphs the velocity of a flywheel, it will be exponential, with the slope decreasing as time increases.
As for Tf, I wrote that part in a slight hurry, so I didn’t name my variables at all well. I will fix that particular in my original post. Tf is actually how long the ball is in contact with the flywheel. I’m not sure if it actually makes a difference because neither the ball nor the flywheel know when they will lose contact, so I don’t think acceleration is affected by the length of the hood. While it is important for acceleration, lengthening the hood past the point at which the ball’s and flywheel’s angular velocities match actually increases friction, and therefore recoil. I don’t know how to incorporate time of acceleration into this formula, but it’s not the way I did it before. I will change that variable name to Tfly, and make sure I mention in that post that I did a bad math thing, and I don’t know how to fix it. Now I see why schools do physics first. =)
As @lpieroni is doing an excellent job enumerating input parameters that we need to know to understand flywheel recovery time, I would like to deal with the first prerequisite: equation for flywheel’s angular velocity as it accelerates.
You don’t have to take theoretical mechanics or electric engineering class in college to be familiar or understand these exponential curves as they are very common. schoolphysics ::Welcome::
Lets consider a single flywheel launcher driven by n motors:
I is the moment of inertia of the flywheel (and geartrain that leads up to it)
Im is the moment of inertia of an individual motor (it is almost negligible compared to I)
k is the gear ratio between motors and flywheel (for example 25:1)
w is angular velocity of the flywheel (it is k times larger than angular velocity of the motors)
α is angular acceleration of flywheel (same k multiplier over the acceleration of motor axle)
τfr is net torque of friction resistance in the geartrain as measured at the flywheel axle
Vpwm is the voltage coming out of pwm controller and applied to the motor
Cmt is some coefficient which links input voltage and output stall torque coming out of the motor
Cemf is some other coefficient which links motor angular speed with reduction in its output torque
The first equation expresses Newton’s law for torques around flywheel’s axle. The sum of torques on the left side required to accelerate flywheel and geartrain components (including motor internal gears) and counteract friction in all bearings and gear-to-gear interfaces is coming out of motors’ output torque on the right side.
Since we have to link processes around flywheel’s and motor axles there is a number of (k) sprinkled around. If you think it is a bit confusing, you are in the same boat with me. Essentially, torques coming from motors to the flywheel axle and angular velocity and acceleration coming from flywheel to motor axle both need to be divided by k.
Solving differential equation for w(t) will yield the formulas and corresponding curves.
We don’t really care at this point about values of the specific coefficients. It is only important to find the shape of the curve for angular velocity as a function of time and see how it depends on various launcher parameters like moment of inertia of the flywheel.
The graph shows velocity in case when motors are disconnected from geartrain and are idling and the case where motors are accelerating flywheel. If you need the values for Cp, Cf, and Ct coefficients for your specific launcher you can conduct those two experiments and determine them from the logged data.
Cp corresponds to the max idle angular velocity your motors could deliver and depend on motor’s electrical characteristic minus internal friction and electrical losses. (Another extra credit question: what are the units for Cp?)
Cf corresponds to the friction losses in your geartrain when it is waiting for launching balls. (Cf is measured in the units of angular velocity).
Ct corresponds to the inverse of the max flywheel acceleration your launcher could deliver - it depends on power your motor could output and flywheel’s moment of inertia that it needs to counteract. (Ct is measured in the units of time)
If you find this familiar it is because I have recycled most of the names and the graph from the position estimation thread which, while not very readable after the forum upgrade, has some additional informaion. For example, backstory about Cemf and interesting details about VEX motors.
Please, keep those great answers coming, while I work on my next posts.
I agree that it is a difficult subject. Depending on the launcher design you may or may not want to let the ball go before its velocity matches tangential velocity of the flywheel.
My preference would be to keep the ball in touch long enough for the velocities to match. Otherwise you will need to run flywheels at much higher RPMs than necessary and, I think, it is the main cause of some launchers shredding the balls more than others.
This is actually very important point and one of the last puzzle pieces I was looking for. Let say we designed the launcher’s backplate to minimize any unnecessary time interacting with the ball.
Then what would be the energy losses due to friction as a result of ball going through the launcher? Where would those losses occur and what is the formula for that?
For simplicity we will not consider any losses due to ball’s surface sliding off the flywheel’s surface before their velocities match.
During the short time when when flywheel launches the ball most of the energy to do that is coming out of flywheel’s kinetic energy. After ball is launched flywheel’s angular velocity will decrease from initial ω_1 to some ω_2 corresponding to the change in the kinetic energy.
That energy will be used to accelerate the ball, spin it (in case of a single flywheel), compress it, and the rest will be converted into heat via friction. For simplicity I will omit the spin component and friction losses between surfaces of the ball and flywheel before their velocity match.
The energy (work) used to compress the ball will be product of compression force Fc and compression distance Hc. In reality, it is some complex integral depending on ball’s density and shape, but for this exercise we will represent it as a product of some mean values.
Similarly, extra friction in the flywheel’s bearing, when ball is compressed, will be a product of extra torque due to friction τfr and some angle theta that flywheel rotates while it compresses the ball. τfr itself is the product of Fc and some coefficients corresponding to bearing’s material and geometry. Instead of angle of flywheel interaction with a ball, you can use the product of flywheel’s angular velocity and the time of interaction, which may be easier to understand.
Now lets assume that ω_1 corresponds to the 80% of the max speed that the motors could deliver for our launcher design. Then as launcher waits for the ball, motors will be commanded to stay at power level corresponding to ω_1 and, after the ball is launched, and speed drops to ω_2, we will command motors with the max power for the best recovery time.
We are interested in finding the difference between times t2 and t1 when speed curve corresponding to max power crosses ω_2 and ω_1 respectively:
Finally substituting Ct with some launcher parameters from the previous post we get the final equation for the recovery time:
So the question would be: is there any practical use in expressing recovery time in terms of a bunch of an obscure coefficients, which nobody knows anyway?
First of all, lets note that the gear ratio (k) and percentage of maximum power your launcher runs at (p) are not independent.
When you design the launcher you will know some minimum ratio (Ko) that is necessary to make full court shots at max power and then you have a choice to increase (k) for increased power margin and therefore a better flywheel recovery time. Here is an updated formula that reflects it:
Then we use an online graphing calculator to plot how recovery time would change as a function of one of the input parameters when everything else remains unchanged. There are two constants that appear in the equations: 0.25 assumes that as we launch the ball flywheel loses a quarter of its kinetic energy, and 0.55 is the percentage of nominal speed that I would run my launcher for the best recovery time.
The blue curve (1) shows almost linear relation between ball’s mass, compression force, or bearing friction and resulting increases in the recovery times. Essentially, (x) stands there for the percentage of kinetic energy of the flywheel that it takes to launch a ball. For example, the heavier the ball is the longer it will take to recover.
The red curve (2) shows how recovery time would change if we vary flywheel’s moment of inertia while everything else remain the same. Evidently once moment of inertia is large enough it doesn’t affect recovery time, because we are replacing energy lost by the ball. Larger moment of inertia only affects flywheel startup time and targeting accuracy in respect to varying balls.
The orange curve (3) shows how recovery time depends on the amount of power margin you have in your launcher. It is kind of obvious even without this graph that with better power margin you get faster recovery time, but it is nice to see the shape of the curve to make your design decisions. On one hand you may want to make p = 0.55 for the fastest recovery, on the other hand you may set p=0.8 and save a motor or two while not being that much slower. Just note that exact placement of the curve depends on percentage of kinetic energy loss and you may want to test both of your options experimentally.
Edit: I did this post in a hurry yesterday and missed an important point about connection of k and p. This has been fixed.
We know the formula for the recovery time and how it depends on various launcher parameters. But how would it apply to your specific launcher configuration?
Lets look at the example of our test launcher. We have a speed motor driving 5" flywheel with 16:1 external = 25.6:1 total gear ratio.
We have this little program which logs some vital statistics to the Debug Stream every 5 msec:
The first test we run with the motor disconnected from the flywheel geratrain and it settled at ~161 RPM which is about 100.6% of its nominal speed at Vbat = 7.5v.
The second test was run with motor driving flywheel and, after several seconds, velocity settled at 143 RPM. This is 18 RPM below the max idle speed and represents friction losses in our launcher (see Cf coefficient few posts above). We need about 137 RPM to shoot full court, so this means there is very tight power margin and long recovery time, but it is perfect for this type of testing.
This is the graph from the data collected in the Debug Stream with velocity in red and acceleration in green:
First of all, notice a big spike at the beginning - it is not an instrumentation error or a flux. It is a very real thing due to the slack in the gear train. The exponential curve accelerating heavy flywheel starts a bit later and you can see battery voltage drop as the motor draws lots of current. When you program your speed control you may want to increase power gradually to protect gears from the shock.
Second interesting point is that readings out of getMotorVelocity() are noisy. Whether due to electromechanical properties of IME, round off errors in the firmware, or something else you are getting values that keep jumping inside ~10 RPM band while you expect your flywheel to run smoothly. The code above applies exponential smoothing with 3/4 coefficient to filter out some of the noise.
Even with the smoothed velocity the acceleration values are still noisy. This is expected with a very small sampling interval we have, but it is good enough to detect “abnormal” events. By looking at the speed curve you can, probably, guess that there was a ball launched around 8 sec. Programmatically we do this determination by testing if acceleration value drops below some negative threshold.
The second graph zooms in on the ball launching event:
You could see two distinct acceleration spikes as the ball interacts with the first and second flywheel stages of our launcher. First, around 7.876 sec velocity drops from 139 to 128 RPM, then around 7.946 sec from 141 to 127, and then to 123 a bit later. Note that it is speed as measured at motor’s IME and not the actual velocity of the flywheel. The spike you see at 7.921 is likely due to the funny way slack travels in the chain connecting flywheel stages.
The important numbers from this experiment is that our flywheel took about 0.175 sec to launch a ball and had decelerated from ~14116 = 2256 RPM to ~12316 = 1968 RPM, which corresponds to about 24% of flywheel’s kinetic energy.
If you would like to improve your launchers recovery time, I would suggest you to conduct similar experiment and find out: friction coefficient (Cf), time to launch a ball, and velocity drop after the launch. This way you can assess how your launcher stacks up against others and what you will need to work on. Also, if anybody would like to post their numbers to this thread, please, feel free to do so.
Technik jr looked at the graphs in the previous post and spotted something curious which could account for the most of the measurement noise.
Can you spot it too?
I used to seeing noise in the measurements all the time. In most cases there is nothing you can do about it, except for computing its standard deviation and configure your filters to ignore it.
However, technik jr must have seen this picture and pointed out that the shape of the raw velocity graph, after the ball had launched, looks just like the gear teeth, and therefore it must be slack between teeth causing all that noise when contact moves from one pair to another.
That was a neat observation. Lets look at some additional data to see if this actually is the case:
Obviously, there is more than one process that feeds into the noise, but you can clearly see some pattern. About every 100 msec there is repeating up-down following by similar down-up pair of spikes. I have underscored six down-up pairs. First ends at 8.1 sec and the last ends at about 8.565 sec.
Approximate period of this pattern is (8.565-8.1)/5 = 0.93 msec, which corresponds to frequency of about 10.75 Hz (events per sec) or 645 RPM. Now we need to see if there is anything in our system that runs at that frequency.
It looks from the graph that an average motor velocity during those events is 130 RPM, so we can compute angular velocities of all axles in the system:
Apparently, our frequency of 645 RPM matches the best with 650 RPM for the first flywheel stage axle. For each axle rotation there are two similar but opposite jumps in the velocity. My best guess is that the axle is slightly bent and velocity fluctuations happen as it gets close or away from something.
When we inspected the axle visually or turned it by hand we didn’t feel anything wrong with it. So effectively, we were able to detect a problem with the hardware and, hopefully, point to the right component just by analyzing the noise in our logged data.
One of my college professors liked to talk how, before the age of digital telemetry, experienced field engineers were diagnosing problems with industrial equipment just by listening how it run over the phone or radio. What may appear like magik to some is actually a very simple method if each component in the system runs at the unique frequency.
If you want to impress the judges you should definitely analyse the noise in your flywheel velocity readings and print which component is about to fail to that little LCD screen.
In their 974x reveal thread@Cyber brains mentioned that they have switched from IME to QuadEncoder for better flywheel control:
I figured out it will be easy for me to do this experiment. I connected quad encoder to the axle marked with 650 RPM on the diagram in the previous post. The IME encoder gear is the one on the axle marked 3185 RPM so you can see how many components there are in between.
My setup is not as clean as 974x’s. While my encoder is just one chain link away from the flywheel, it is still in the power delivery path. In contrast, 974x have placed their encoder away from the power path and should get very clean readings physically smoothed by the flywheel.
In my setup IME velocities and accelerations are computed the same way as in the earlier code (few posts above). Raw-QE velocity is reported every 5 msec, and computed based on the difference between current quad reading and the one it had 20 msec earlier. Then Smooth-QE is computed by exponential smoothing Raw-QE values with a=3/4.
You can immediately see that there is less noise in the velocity reported by the quad encoder (red) then by IME (green). However, some noise is still present, including few spikes.
Now lets zoom into the portion of the graph where the ball is being launched:
It looks like Raw-QE velocity (red) has at least half the noise of the Raw-IME (green) and is on par or slightly better than Smoothed-IME. However, if you look at Smoothed-QE line (yellow) you could see that it is much more stable and noise free than any other curve.
So, if anybody wants to have super accurate flywheel telemetry, they should take @Cyber brains advice and mount Quad Encoder away from the power path or, at least, as close as possible to the flywheel and apply some sort of smoothing in software. Just be aware that encoders should not be run above 1133 rpm or you risk damaging it or getting incorrect values.
That’s really interesting, that the use of a quad encoder closer to the flywheel results in less noise, although I’m really not that surprised. If you have been able to find what that is caused by, is that caused primarily by fewer gears between the encoder and flywheel, the behavior of quad encoders versus IMEs, or something else? If a flywheel is geared 7:1, so there are only 2 axles (the motor and flywheel axles), would the same effect be just as prominent, or would the reduction in number of gears cause less noise in the IMEs as well?
Usually, there are multiple sources of measurement noise and when they all are of the same magnitude and mixed together you get white noise. However, if you could see a pattern, it means that some of the sources contribute more than others. In our logs, in addition to 650 RPM pattern described earlier, you could see another wave in IME readings with ~0.5 sec period especially evident behind QE curve. This is, probably, some imperfection with motor output axle or 60t gear, rotating at 130 RPM.
Measurement noise could be the result of the way you measure and collect your readings, as well as unmodeled physical processes in your system. For example, when you estimate your gear ratios you are very unlikely to model bent axles, but it could be a significant source of small torque fluctuations between your gears.
First, lets look at how we collect the measurements. Quad encoder is connected to the axle which rotates at about 650 RPM, and with 360 ticks/rev you get about 78 ticks per 20 msec measuring interval. Since we cannot measure in fractional ticks, on average you could expect 1.3% uncertainty in encoder readings and 5% uncertainty in time.
When you compute velocity based on those values you could easily end up with 6.3% uncertainty. (To be precise we would need to compute standard deviations, but lets just do a simple sum here). At 130 RPM 6.3% would be an error of 8.19 RPM! To decrease the error we could go to the larger sampling interval like 100 msec, but then the results will be lagging behind. Alternatively, you can apply some sort of smoothing, which will give you speedier answer with the reduced noise.
In contrast with quad encoder, IME’s getMotorVelocity() will give you almost instant velocity reading (delayed only by a couple msec) with uncertainty of < 1.5% (see here). The downside of using IME is that there is a long geartrain between where it is being measured and the component which velocity you need to know. It is not a problem with slow driving wheels, but any errors caused by the imperfections in the geartrain will be multiplied many times in case of the flywheel.
The second source of the measurement noise is mechanical. If gears or bearings are unevenly worn, axles are bent or making contact with the metal frame, or motor mount is misaligned it all will introduce uneven torques and friction as it runs and will show up in the measurements.
So I could only guess what is the cause for the noise. To answer your question with certainty I would need to replace or improve each component of the system one by one and see when the noise starts to disappear.
Mechanically, I don’t think there is much that could be done in our case. We made significant progress in the build quality since the beginning of the season and our launcher runs very smoothly to the touch. There is a limit to the precision of the VEX parts and you could push kids only so far. They already have to go through the 8-screw realignment process if they need to replace sprocket with another size and, beside me, there is only one team member who has enough patience to do it.
In your case going with the smaller number of parts is always a good choice. Every, potentially misaligned axle is the source of additional friction and measurement noise. So my guess is that discrepancy between IME and Quad will be less prominent.
It is always best to log and plot the measurements to understand what is really going on inside your launcher. For example, if you have two axle 7:1 geartrain, and you see large discrepancy between IME and quad encoder connected directly to the flywheel, then you may have some mechanical issue inside the motor. However, if motor is well lubricated, gears are good, and everything is aligned then you may see almost no difference between the two encoders.
You can push the accuracy envelope by taking encoder beyond the flywheel, like 974x did, but in many cases applying software smoothing might be enough to achieve better results.
My team recently rebuilt a single flywheel, and we noticed that depending on where the hood was placed, the balls would get weird angles, even though it was mounted using 45 degree brackets. Does the point at which the ball loses contact with the hood affect the angle of the ball? In other words, will a ball not necessarily leave a single flywheel at the same angle as the hood is mounted? I would assume it can, but I’m not sure what the math behind it would look like. It’s also distinctly possible that the hood was mounted too close to the wheel, and the balls were bending the polycarbonate hood significantly.
This is an interesting question. Without seeing your backplate it is a wild guess, but I think, in addition to bending, it twists in the plane of flywheel as the balls go through. Then when balls are about to leave the launcher the polycarbonate rebounds while being at an angle.
If you can do a slow motion video of the ball launch you may be able to see what is going on with the backplate and, in best case scenario, even notice the difference between launching the softest and the firmest of the balls.
In the ideal launcher (if such thing could ever be built) backplate will bend just enough to compensate for the ball firmness such that all balls will endup in the same place (high goal) despite slightly different energy transfer from the flywheel, their ballistic coefficient, and trajectory. If you can figure out what is going on with your launcher you may just as well be able to build such backplate.
I will try taking a slow-motion video of launching a very soft ball and a very hard ball tomorrow and seeing what the difference in backplate movement is. We could definitely tell the backplate was bending, since it oscillated after each shot, but I wasn’t sure if that was the only cause of our problem, since we didn’t see exactly how much flex the backplate showed during the launch.
For the benefit of people who are rebuilding their flywheels or doing FRC Stronghold and are not familiar with VEX forums, here are some threads you may want to read for the additional information on optimizing flywheel launcher.
First of all, there is a continuation of the measurement noise discussion and some more graphs from my experiments in the moving average thread.
Also, related to the flywheel mass are the discussions about improving firing rate: 16957, 17410, and you simply cannot miss wild speculations around 4664C’s mystery launcher.
In addition to understanding importance of handling measurement noise in the velocity readings for good flywheel speed control, you may want to think about delays in the control loop that affect stability of the algorithm and how using different motor ports influence that.
Once you done with the theory, you could take a look at the hybrid flywheel PID code, which we field tested and it seem to be working quite well.
@technik3k Is there any way you could finish the “Secrets to a low friction launcher” series? I’m still really interested in how you guys use the High strength bearing with something else to reduce friction on the flywheel.
I will certainly ask the team to make another video. I couldn’t promise anything as they are busy re-configuring the robot for the next competition.
However, I could say that the proper alignment plays just as important role as the parts you choose for the bearings. The special bearings we made using old torque gears from 393 motor are, probably, only necessary if you want to build something exotic like a single-motor full-court shooter (see Dec 23 post). Otherwise a pillow or a regular bearing should work just fine.
Once again, make sure everything is properly aligned, axles are not bent, and there is no metal to metal friction anywhere.
Hi, I am currently designing a ball launching machine using counter rotating wheels, and I was wondering if you could help me out.
In order to determine the RPM required for each wheel, I have use v = omega * r, taken the ball speed to be an average of the tangential speeds of each wheel. Would this be correct? Also, how would the contact area affect this? Surely the larger contact area, the more force would be produced but would I be able to calculate this? Any advice would be appreciated.
Hi, one more question, as each wheel is powered by an individual dc motor, would I calculate the motor torque using T = I * alpha where I is the moment of inertia of the wheel (1/2 * m * r^2) and alpha is the angular acceleration in rad/s? Thanks in advance
Yes, your formula for RPM determination is correct.
The contact area does not affect performance of the launcher much. If the contact area between ball and the launcher was perfectly flat then it would cancel itself out from the formulas. The force of compressing the ball and the surface material, that it interacts with, will affect performance of the launcher.
Most of the threads this season measure ball compression in distance units. For example, 0.5" compression would mean that 4" ball was squished to 3.5" when it was going through the launcher.
Yes, this is the right formula. You have only 1 motor per flywheel, but if you had (n) motors then they would produce (n) times the torque, and if you have a gears between motors and the flywheel that increase omega (k) times it will reduce torque coming from the motors (k) times.
