@jtrv Thank you so much for this tool! I’ve been prepping our students on how they can use it during the season. Should the “pulley 2 teeth in mesh” be (44-15.4). This pulley is getting over 180 degrees of wrap.
Good find. It looks like the teeth in mesh formula is only valid for the smaller pulley:
where N_d is the teeth on the small pulley, CD is the center distance, D is the larger pulley diameter, and d is the smaller pulley diameter. I had mistakenly assumed that I could just throw in the larger pulley teeth in for N_d to get the larger pulley’s teeth-in-mesh, but I guess not.
I can’t seem to find an equation for the larger pulley’s teeth-in-mesh factor. Maybe it is 44 - 15.4?
I believe the formula you are looking for is described here:
https://roymech.org/Useful_Tables/Drive/Timing_belts.html
In the section labeled “Determining the timing belt length”
The drivetrain calculator is now generally available.
As usual, I expect some problems. Let me know if/when you find any. I intend to add presets for various swerve modules eventually.
I’ve re-added the stall load field to the linear mechanism calculator. It isn’t perfect, but some people were asking for it, so it’s back.
Thanks to @Jochem , the arm calculator will soon feature deceleration calculations. Since he helped me re-learn diffeq, this should also propagate to more accurate calculators in other areas as well.
I’llLimelight, an integrated vision coprocessor try to get this fixed soon. Good find.
The linear mechanism calculator has been updated using a differential equation model to simulate it. It no longer factors for deceleration, but will (again) in a future update. It does model acceleration far more accurately now.
Effectively, this uses the following differential equations:
where J is the effective MOI, \omega is the rotational velocity, b is the viscous friction constant, K_T is the torque constant, I is current draw, L is inductance, R is resistance, V is voltage, and K_E is the back EMF constant. I’m using a best-guess measurement of 0.0001 kg*m^2 for the MOI of the motor shaft, 00004 Nms/rad for the viscous friction coefficient, and 0.000035 for the motor inductance.
We can re-arrange these to solve for acceleration and current change over time:
We can then use RK4 (source) to approximate the system with a resolution of ~1000 steps per second of simulation. Note that these equations need to add in gear ratio, motor count, motor efficiency, and “anti” torque (gravity) as well, in order to properly represent the system, but this is the fundamental model.
This results in a far more accurate acceleration curve, as well as an accurate current draw over time curve.
In order to simulate the system with a current limit, the motor will approximate the change in current using a non-limited current, but approximate the change in velocity with min(I_{\text{limit}}, I). This provides a smooth transition from limited to non-limited current draw.
Next update will be the arm calculator.
Thanks to @Jochem , @pchild , and @jlmcmchl for their help on this.
Couldn’t you get a much better estimate of the viscous damping by using the motor’s published free current?
Those equations already do factor in motor efficiency after applying a torque representing the motor’s own friction due to modeling the resistor and inductor behavior. If you re-arrange the differential equations to have an independent variable of applied torque, you will end up getting power and efficiency curves very close to the locked rotor testing graphs the vendors publish.
Probably yes, I hadn’t thought of that.
Sorry, that was a typo. What I meant was gearbox efficiency. Unfortunately there seems to be a Discourse bug where any post with TeX embeddings aren’t editable (submitting the edit gives a 403).
Just a quick note, I in that equation is armature/stator current, not supply current (which I feel “current draw” may imply). While the motor controller is current-limited, it does not output 100% duty cycle, as that would exceed the current limit (I_stator = (V - bemf)/R). Since supply current is stator current * duty cycle, the two currents are not always equivalent when current limits are enabled.
I’ve put together a quick Desmos graph that approximates the relationship between supply and stator current when you apply either type of current limit.
Thanks for the Desmos! ReCalc currently does not do a very good job of differentiating the two; it’s on my 2024 offseason to-do list. It’s a little hand-wavey at the present moment with this kind of stuff as you’ve noticed.
How is the supply-limited duty cycle formula derived?
Starting from the DC motor equation:
I_stator = (V - bemf)/R
Dividing everything by voltage gives you a good approximation using duty cycle:
I_stator = (dc - (v/v_max)) * I_stall
From there you can define everything in terms of I_supply and solve for duty cycle:
I_supply = dc * I_stator
I_supply = I_stall * (dc^2 - dc*v/v_max)
dc^2 - dc*v/v_max - I_supply/I_stall = 0
dc = v/(2v_max) + sqrt[(v/(2v_max))^2 + I_supply/I_stall]
If I recall correctly the current limit on REV motors are on the stator current. I don’t know if that’s the case for the Kraken and Falcon too, but if the current limit is on the stator then the input current shouldn’t matter too much right? Because the motor behaviour also depends on the stator current and not the input current.
TalonFXs provide both a stator and supply current limit, so teams can choose what’s best for their application.
If the goal is to prevent breakers from tripping, the supply current limit is appropriate, since the breaker sees supply current to the device.
If the goal is to limit the torque applied, or to limit the heat generation in the device, a stator current is appropriate.
You can even use both limits at the same time. A good example is for a drivetrain, where the wheels would slip with stator currents above 150 amps. You would set the stator current limit to 150 amps, and a supply current limit to 40 amps, with thresholds so it triggers when supply current exceeds 60 amps for 0.5 seconds. This way you’re allowing the maximum amount of torque to the mechanism while still ensuring the breaker doesn’t trip.
A little late, but just getting around to asking about this. I’ve been playing around with the flywheel calculator and I’m curious how “accurate” people have found the estimated exit speed of the game piece to be. I know this is all mathematically ideal estimates so they should be taken with a grain of salt, but I’m curious what people’s experiences have been of the calculator vs. reality.
I recently used the flywheel calculator to estimate the exit speed of a tennis ball shooter for an offseason build/physics project, and the numbers ReCalc gave were ~1.5 times higher than the measured exit speed (12 to 15 m/s). It looks like ReCalc assumes all of the energy transfer is put into translational velocity and disregards rotation, so with more projectile spin ReCalc would be less accurate.
I’d gladly use it early-season to estimate gearing and speeds, but for anything past that like trajectory or distance calculations, or with a mechanism that produces high spin, the difference would probably start piling up.
If anyone would like to re-create my values, the build was a 6 inch Colson Performa geared 1:1 to a Falcon, and a 1/16th curved polycarb hood with .25" of compression along a 120 degree arc.
I’ve run across something that looks like a bug in the linear mechanism calculation, or at least some very surprising behavior.
With the linked settings, a gear ratio reduction of 24:1, 25:1, and 26:1 all will take about 1.8s. 27:1 will suddenly only take 0.9s, and the time will start plummeting and current draw will explode at higher ratios. And at a 125:1 reduction it thinks we’ll draw 2000 A and move 3000 in/s which is clearly bogus.
Edit: and this same kind of behavior seems to be happening across all? of the motor options.
Thanks for the report. That was a hard bug to find, but pretty obvious in hindsight. A push is currently deploying and should be live in a few minutes.
Essentially the motor code uses the RK4 method to approximate the motor model. The model itself uses a few motor constants that I’m estimating, and don’t have exact values for, such as inductance and rotor inertia.
Specifically, the change in velocity over time in this system is roughly approximated by:
where K_T is motor torque constant, N is the number of motors, e is the efficiency (fraction 0 to 1), T_G is the gravitational torque, B is the motor viscous friction constant, \omega is the velocity, and J is the effective rotor inertia.
The effective rotor inertia depends on what mechanism the motor is driving - in this case, the elevator:
where L is the load, D is the spool diameter, and G is the gearbox ratio.
When G gets sufficiently large, J_e becomes sufficiently small, causing \Delta \omega to balloon extremely quickly. However, you may have noticed I’ve left something off the effective inertia formula - the motor’s inertia itself! So the real formula is
And I used 971’s approximation of a Falcon MOI here. It won’t be accurate for every motor, but should be vaguely close enough.
I believe there is an issue with the calculator. This is something I got when using the linear calculator:
It gives pretty crazy unrealistic values for brushed motors, but when using the brushless motors in the calculators it works as expected. I saw these erroneous values for other motors in the calculator as well.
Hi, this is a known issue, I’m using the same inductance for all motors, which is not accurate for brushed motors. It has been on my to-do list to fix this, but due to the low usage of brushed motors and several ongoing things in my personal life taking up time, I haven’t gotten around to it.
@jtrv does the flywheel calculator take into account that I might set the motor to 12v until I reach my target rpm even if the target rpm is lower than the free speed of the motor?