It automatically selects the best gears for a shifting gearbox given the high and low gear speeds, the wheel diameter, some information about the gear stage configurations, and a list of available gears.
This is actually just a webpage adaptation of a spreadsheet I developed for my team a year or two ago. I got tired of trying to find two pairs of gears (that we had in stock) with the same C-C distance that also gave the robot the right speeds.
I get this error when I switch the units to ft/s and click calculate:
I’m not sure how you’re defining “best” here when talking about ranking gear combinations. There are two “ideal” gear ratios, so what are you actually trying to optimize?
Also, I think you’re using “transmission efficiency” incorrectly. Transmission efficiency is the percent of the motor’s output power that makes it to the wheels. There are no parasitic losses of speed, so that’s equivalent to the percent of torque generated at the motor that makes it to the wheels. The robot’s top speed should always be the motor free speed divided by gear ratio multiplied by wheel radius, regardless of the drivetrain’s efficiency. The efficiency affects how quickly the robot can accelerate, which won’t make a difference for this calculator.
The optimization is looking for the least square of the sum of the differences of the two calculated speeds and your inputs. It doesn’t always get what you want, which is why I put in displays for the 3 top outputs.
“Top speed” is the speed at which the motors no longer apply a net forward force to the robot to accelerate it. As mentioned in the tooltip, this is “transmission efficiency” between the motors and the GROUND, not the motors and the output shaft of the gearbox (or something else). No FRC robot ever achieves the free load speed of the motors because there are torque losses (as you mentioned).
To be fair, it’s not a totally correct usage of the term, but it’s a factor that nearly every FRC designer takes into account so I needed to implement it in the tool. I could change it to say something else like “usable speed percentage” (or something else) but I’m not sure that’s any better.
The constant for “usable top speed divided by free speed” is different from “torque at the wheel divided by torque at the motor”. The latter is the “transmission efficiency” (aka “geartrain efficiency” aka “efficiency”). On JVN’s design calculator the former is called the “speed loss constant”. In the early years of custom drivetrain calculators it was a good way to approximate a robot’s real-world speed based on motor specs and gear ratio. Nowadays there are calculators that model the robot’s acceleration to top speed that show this much better, so using an “adjusted top speed” based on an arbitrary coefficient is a lot less popular.
If “speed loss constant” is good enough for JVN, it’s good enough for me. I’ll change it in the next update once I figure out these errors.
One clarification, in my personal calculations and spreadsheets, I always use “transmission efficiency AT STALL” which is the same thing as the “speed loss constant”. This is how “reduction efficiency” is implemented in the CRP Linear Mechanism Simulator. It basically shifts the motor speed vs torque line down by that percentage.
In basically every power transmission system, the transmission efficiency is dependent on speed. That’s because the dominant source of loss comes from dynamic friction which (roughly) doesn’t change with speed. There are other types of friction that do, but more on that in a second. Here’s a quick spreadsheet: Variable Transmission Efficiency - Google Sheets
As far as I know, there is no FRC calculator that attempts to accurately calculate the losses (friction) of a drivetrain. The most “sophisticated” models just break some equivalent of the “speed loss constant” (or “transmission efficiency at stall”) into smaller chunks based on the quantity and type of power transmission stages.
Okay, the reported errors have been fixed and uploaded to the website.
The issue with changing the units to ft/sec was a typo where I used “=” in an if statement instead of “==”. So basically it changed the ID of one of the HTML elements instead of checking the ID.
The firefox issues were just due to some weirdness with the default values for HTML elements. I just specified the values I wanted instead of the defaults and it fixed it. In addition, I implemented some rounding in those inputs to make switching between units cleaner (I really hate floating point numbers).