Doing the math for a flywheel launcher is surprisingly involved. I’ve created this spreadsheet to simplify it. The paper that the math is based on is linked in the README. Originally based on JVN’s design calculator.

I plugged 'Snow Problem’s launcher parameters into it and got a trajectory pretty similar to what we saw on the real robot, but I’d really appreciate more validation, especially for higher-MOI systems and any data about recovery time and peak current that you can provide!

Your power calculation is incorrect.
Power [watt] is torque [NM] · rotation speed [rad/sec]
or
Power [Killo-watt] is torque [NM] · rotation speed [rad/sec]/1000
You wrote in line 5 power [Killo watt] = torque[NM] · rotation speeed[1/minute(aka RPM)]/1000
You need to multiply the rotation speed [RPM] by 2pi/60 to get the speed in [rad/sec]

Anyway, this is a very cool tool and you can add stuff to it like additional motors’ data, efficiency curve (output power over input power(aka voltage times current)) and more

Good catch. I’ve updated the link in the OP to the fixed version and added the efficiency curve.

Right now the data in there is from the CIM motor, but you can change it to any other motor by copying the data from motors.vex.com into the “Motor Parameters” folder.

I used OSP Tracker to analyze the video that he shot from the side, and considering that this was caught at 8x normal speed, the data gives a launch speed of 26.1 ft/s- almost exactly what the model predicts! See also: (Rough) Launch trajectory

I’ve been working on a similar calculator for a while now, and I’ve been stuck on a few things. I took some time to look over how you handled these problems, and I want to confirm that I’m understanding your solutions correctly.

Problem: When the ball exits the shooter, the wheel’s tangential speed my or may not match the tangential speed of the ball (i.e. the wheel may or may not be slipping on the ball). If the wheel does slip on the ball as it exits the shooter, we don’t know how fast the ball will be going and therefore how much energy is transferred to it. Solution: Assume by the time the ball exits the speeds will match

Problem: The ball may roll on the hood with or without slipping, depending on the compression and CoF of the hood. If the ball rolls with slipping then we don’t know how much rotational kinetic energy is transferred. Solution: Assume the friction between the ball and hood is large enough for the ball to roll without slipping.

Problem: Shooters are controlled with a closed-loop controller, so its response will be determined by the specific tuning. We can calculate the theoretically optimal tuning, but that’s a difficult problem. If we assume a ‘perfect’ controller (i.e. gives full power until it reaches the desired velocity, then gives the exact holding velocity) then the spin-up and recovery times will be shorter than in reality. Solution: Assume the difference in spin-up/recovery times will be insignificant for well-tuned systems.

Problem: Speed after shot is determined by energy transferred during the shot. Some of that is calculable (e.g. linear and rotation kinetic energy) but some isn’t (e.g. friction, compression). Solution: Use a “Shot Efficiency” constant to account for non-calculable losses.

Problem: The steady-state wheel speed (and spin-up/recovery times) are theoretically very sensitive to differences in viscous friction (air drag), which is hard to calculate. Solution: Assume the viscous friction forces are negligible compared to the torque provided by the motors.

Problem: The analytical solution to the spin-up/recovery time is based on the assumption of a linear system, which doesn’t work well with things like current limits. Solution: Assume that the motors are working without current limits, or if they are current limited then the difference between the angular momentum they would have added to the system if not current limited and the actual angular momentum added with the current limits is negligible.

If these assumptions hold true for most shooters, that’s great! Certainly makes my life easier to implement my version of the calculator. Until this season I haven’t had a shooter system to test my calculator against, so I haven’t been able to test some of these assumptions. I’d love to hear if anyone else has been able to compare the results from this calculator to the real life dynamics.

You’re basically right about everything, but I wanted to clarify a few points.

Basically yes. As far as I can tell, my math is correct for this, but this leads to very unrealistic recovery times and shot rates (based mostly on gut feeling). Especially because the the theoretical recovery time is on the order of milliseconds, my guess is that the tuning of the controller dominates recovery time in these systems (given that the default rio control loop period is 20 ms). This means that the “recovery time” calculated by my spreadsheet is an absolute theoretical maximum and can be used to compare between setups, but probably won’t be similar to the real-life performance.

I didn’t even consider air drag, honestly, because I assumed it would be so low- my default state is “spherical cow in a vacuum.” Do you have rough numbers for how much this affects the system? Also note that this is running on a theoretical perfect closed-loop controller so steady-state air drag shouldn’t affect the system.

Your first two points are big assumptions I made in the interest of modeling. My guess is that on a launcher with reasonable compression, a grippy hood, and ~90 degrees or more of wrap, those are probably pretty good assumptions to make.

Like I said so far I’ve compared 3324’s prototype and 'Snow Problem’s launcher (I measured the speed on video too), and I’m hounding my friends that are still on FRC teams to provide their data as well. I’m also interested in getting data on recovery time and current spikes because I probably made the biggest/most unreasonable assumption for calculating those.

On a sidenote I’m impressed that you were able to digest that much from my terribly disorganized spreadsheet formulas

Inherently, this makes sense. Only a small percent of the energy stored in the flywheel is transferred to each ball, so in theory the recovery time should only be a small fraction of the spin-up time. But the system is measured by sensors and controlled by a controller that doesn’t have such fast update rates, so in reality it takes a lot longer. In these time scales the motor inductance likely also plays a roll that we usually would consider negligible.

I ran a quick simulation in MATLAB (assuming no current limiting, only viscous friction, etc). Using a 2x 775pro shooter with a 2:1 reduction and 0.004 kg-m^2 MoI (approximately our current setup). With no viscous friction the open-loop system response to a 12V input looks like:

The steady-state speed of this system is 8343 rpm, and it takes 6.21 s to reach 8000 rpm. That’s only a 10% reduction in steady-state speed, but a 41% increase in spin-up time.

* This number isn’t based on any experimental testing or anything. It’s just a sample number to show that adding viscous friction that causes a relatively small change in steady-state speed can cause a large increase in spin-up time. It’s possible that the real number is much lower and negligible, or much higher and the effect is even more pronounced.

I will definitely be comparing the results from this calculator to the behavior of our shooter once our programmers get some sensors on the final prototype and start to add things like closed-loop control, spin-up/recovery time measurements, etc.

I’ve spent the past few years developing my own design spreadsheet, so I’ve gotten pretty good at deciphering gibberish Excel formulas from having to read my own

I come up with a slightly different equation for the speed transfer. The main difference being that I place the center of the ball’s linear motion at a distance Rw+Rc (Rc being the radius of the compressed ball) from the center of the shooter wheel. Have I missed something?

I’ll redo the math when I have a bit of free time. I took the math wholesale from the paper after quickly verifying it, so I couldn’t list off the assumptions they made. I also don’t really grok how the compression changes the momentum transfer- does that actually get the ball spinning faster?

Considering compressed radius instead of uncompressed changes the model a lot, and currently the data looks closer to assuming it’s uncompressed when computing rotational momentum transfer.

I haven’t done a physics homework problem in 20+ years, but their very first equation confuses me. I’m pretty sure it’s just wrong.

As for the effect of ball compression – the MOI of the ball is definitely reduced, but I wouldn’t want to do the math to figure out how much. Using the uncompressed MOI is probably close enough. But it’s easy enough to include the compressed radius in the r x mV component of angular momentum.

The way I read the setup is to be the conservation of linear momentum. I don’t think it’s wrong, but it is curious that using the conservation of angular momentum doesn’t yield the same result.

I’ll definitely redo my math to include compression in this. It doesn’t seem to have that much of an effect, but worth modeling everything.

The most accurate version of this I can get based on currently available data is my original model using linear momentum. The angular momentum based speed transfer yields a much lower transfer % than linear momentum, which means one of a few things:

I underestimated MOI for all these systems (true, but the only thing not considered is pulleys, belts, and shafts all of which have fairly low MOI, and the difference would require a roughly 100% increase in MOI for these systems)

I have an error somewhere else in the spreadsheet

I made an error collecting data (possible, but these also fit the parabola trajectory math)

Physically, I can’t explain why the angular momentum math doesn’t work. The linear momentum math makes sense in my head at least, but could easily be wrong. The end of it at this point is that this matches the data so far, and we are engineers in the end.

Well, if it were a linear momentum problem, we’d need to include the rest of the robot in the system, and we’d just learn stuff like how fast this robot would be sent backwards after it shot a ball (on a frictionless surface, naturally). The spinning flywheel on the robot would have nothing to do with that.

This is definitely an angular momentum problem. It’s a lot like the bullet & disk problem here in reverse, for example.