ReCalc - An online mechanical design calculator with shareable URLs

Hi all,

I’ve been on and off productive during quarantine, and during my free time, I spent a lot of time creating an online mechanical design calculator to solve a lot of my frustrations with others available:

ReCalc is a collaboration focused mechanical design calculator, available to help you design robots with others who may be on a different computer. It accomplishes this by allowing each calculator to generate a shareable URL which you can send to another person and they’ll instantly be able to see your parameters for your mechanism, as well as being able to modify it without modifying yours.

Here’s an example of a belt calculator URL.

The inspiration for this came from me getting increasingly annoyed with sending people screenshots of the WCP Belt Calculator, only for them to send a screenshot back, only for me to have to type all their inputs in on my own computer.

Google Sheets is great, but I’ve been frustrated in the past with the graphing and permission options, as well as the load times. ReCalc unfortunately isn’t as “forkable” as Google Sheets, so you can’t add your own features (unless you’re a React dev :D).

ReCalc also hosts some various info tables, giving you mathematical insights on common FRC products like motors, filaments, or compressors.

It also has a web-based Driver Station Log Viewer that is very imperfect but does technically work.

Please note that ReCalc is still very young and imperfect. There are still lots of things I want to get done, like gear loading calculators, improving the current calculators (eg re-doing the pneumatics calculator), and adding features to the DS log viewer. I know that first impressions of something are extremely important, and ReCalc isn’t as done as I want it to be before posting, buuuut kickoff happened and a lot of teams are meeting remotely right now and I figure I might as well let people use it early.

If you find any bugs or issues, please let me know and I will do my best to fix them right away. I appreciate your patience :slight_smile:

I would also love any feedback about UI, UX, or calculator ideas. If it’s bad please feel free to roast it and tell me what I should change.

Thank you to @AriMB , @pchild, and @dydx for their calculators that have greatly helped me learn more about physics and robots in order to make this.

Thanks all, have a good and safe season.


As an endorsement, I’ve been using ReCalc since it’s first iteration early in quarantine, and it’s quickly become my favorite design calculator. It has great ease of use, and everything is well organized and clear. Also, Justin is a great dev and responds to advice quickly. Thanks for doing this!


This is super cool, I love the idea of being able to save and share links. This is something that annoyed me about Excel based calculators.

I assume “Radius” and “Weight” are of the flywheel and you do a solid-cylinder approximation. I’ve found that the specific MOI of various wheels does change a lot based on the structure and the solid-cylinder approximation is fairly poor. It might be worth adding an option to input a custom MOI value, and have a table of various COTS wheel MOIs available.


The belt calculator would be significantly more useful if it was not bound to belts sold by FRC vendors.

For example, vbeltguys has the following tooth counts available for 5M belts:
[24, 25, 36, 40, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 138, 139, 140, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 158, 160, 162, 163, 164, 165, 166, 167, 168, 169, 170, 172, 173, 174, 176, 178, 179, 180, 182, 184, 185, 186, 187, 188, 190, 192, 193, 195, 196, 198, 200, 204, 205, 207, 208, 210, 212, 216, 218, 220, 221, 222, 223, 225, 226, 227, 229, 230, 232, 235, 236, 237, 239, 240, 242, 245, 247, 248, 250, 252, 254, 256, 259, 260, 267, 270, 275, 276, 278, 280, 284, 285, 290, 291, 298, 300, 304, 305, 306, 317, 319, 320, 323, 334, 337, 338, 340, 344, 346, 350, 356, 358, 360, 374, 376, 379, 389, 392, 400, 420, 422, 432, 450, 470, 475, 500, 505, 530, 550, 560, 582, 624, 640, 651, 674, 680, 686, 750, 754, 760]


I have it on my todo-list to remove this restriction. Currently it simply does belts in 5T increments up to a certain number (I think a couple hundred). I’m planning on adding an input field that allows users to change that increment and max number.

Yes, that’s what I did.

I’ll add custom MOI field to the todo-list. I think you can get that from some CAD programs? Which would be useful for teams to enter.

edit: since posting I pushed a bugfix to the flywheel calc which should improve spin up time estimations and added @cadandcookies’s request.

Note that currently if you set a high belt tooth maximum (eg - how long of a belt it will try to find is the best for your C-C target), the page may slow down while its calculating. There is an improvement for this (with asynchronous calculations) on the horizon, however I only just figured out how to do it and it’s only implemented on 1 calculator (the arm one).


This is very cool.

I found myself hovering my mouse over the name of each value looking for a tool-tip explanation of the value. Slightly hesitant to insta-share this with the team without more explanations of what each value on each sheet means. Ideally some of these would be accompanied by diagrams that visually explain some of the values.

Looking forward to using it more in the future!


I’ve heard the exact same ideas and sentiments among groups I’ve shared this with. It’s on the todo list, but is a sizeable undertaking. I’ll move it up on my priority list :slight_smile:


From a quick overview, it looks very nice! I’ve been considering migrating to a web-based calculator but I haven’t had the free time recently. I’m a big fan of the “copy link” idea, I may have to steal that if I ever make the switch.

I have a few notes/questions from a quick look through:

  • You should probably add current limits and variable bus voltages to your motor calculations. Lots of teams use current limits nowadays with the proliferation of smart motor controllers, and at the end of the match your battery might not be at 12V.
  • For the time-to-goal calculations, have you run any tests to see how accurate the simulations are? On motorized mechanisms that need to accelerate from a standstill and only travel for fractions of a second (like an arm rotating 90°), I have a feeling that motor inductance and voltage sag will have a pretty significant effect.
  • How are you closing the loop for the time-to-goal calculations? Is this mechanism hitting the goal at full speed or at a stop? If the former, the deceleration time will probably be significant. If the latter, I’m interested in how you’re controlling the system.
  • For the flywheel calculator, how are you determining the “optimal gear ratio”?
  • I’ve actually been trying for a few years now to develop a flywheel calculator, but I’ve never been happy with the results. From my testing and simulations, there are two factors that make flywheel calculators inherently untrustworthy. The first is the motor inductance and voltage sag issue I mentioned earlier. When dealing with stuff like recovery times, those issues make a significant difference in the small time frame. The second problem is viscous friction. Since flywheels spin very fast and with very little torque, small changes in the viscous friction coefficient can make big differences in the free-speed and spin-up times. I talked a bit about this on the thread for Julia’s Flywheel Calculator. Have you done any testing to check how accurate the numbers are?
  • On the filament page you give a description of elastic vs plastic deformation, and the example of a rubber band. The example of elastic deformation is good, but plastic deformation would not be equivalent to the rubber band breaking. Breaking is the failure point, at the end of plastic deformation. Between the yield strength (elastic/plastic limit) and the failure point, there is plastic deformation which is more akin to stretching the rubber band so much that when you release it it’s permanently stretched and doesn’t return to its original size.

Re-reading this, it sounds very negative so I want to repeat that this is a very good start! Looking forward to seeing what further improvements you have in store :slight_smile:

1 Like

Agree, I just need to learn more about how to simulate that :slight_smile:

I have not been able to run any physical tests due to quarantine and myself moving to a new city. I would tend to agree however I truthfully don’t know the answer to how much of an effect they would have.

Good question, it’s the former. I agree that deceleration time could be significant but it’s also a decent amount of math that I just haven’t gotten to. I haven’t seen many other calculators account for this so I would be interested in examples if you had any.

Fastest windup time, but its a bit buggy, work in progress

The flywheel calc is pretty much the exact same as Julia’s math, so any issues there will be the same here. Truthfully I do not understand physics as well as you two :slight_smile: I’m just a software engineer pressing some buttons. This project wasn’t necessarily focused on being the end all be all of calculators, more so a way to help people collaborate. If you discover any modeling techniques for that, I would be more than happy to work on adding it to ReCalc.

I appreciate this feedback, I will try to reword things a bit this week. I’m no mechanical engineer

I appreciate your feedback and your design calc was a big help.


The problem with how you’re doing the calculation now is that it ignores the rotor inertia (as did my calculator). The lowest reduction will always be the fastest, because the function you’re using to check this is monotonically increasing.

This was actually a brief topic in a class I took specifically on motors. It turns out to minimize the spin-up time, the MOI of whatever you’re spinning up has to appear to be (ratio * external MOI) the same MOI as the motor rotor. Without concrete data on the rotor inertia of FRC motors this will always return the smallest value you choose to test this graph on.

I chose to ignore the effect of the motor rotor on my own calculator because I didn’t have data on rotor MOI, and assumed there wouldn’t be any high reductions enough to make them appear as similar ranges, and so to just never give an answer for the “optimal reduction” because I knew I would be wrong.

1 Like

Thanks, that makes sense. Do you have any links on the web that may talk about this more? The closest I got to that was a very basic controls class that I didn’t exactly excel in.

For current limits, you limit the motor’s torque to the current limit times kT. For variable bus voltages, you multiply the motor constants by the voltage ratio.

In order to actually make the mechanism come to a stop you’d have to implement some kind of simulated closed-loop controller. That will definitely be pretty difficult. You’re probably better off putting a note somewhere on the page. I chose to only deal with mechanisms in steady-state (not transient) because of this and the inductance/voltage sag.

You’re going to have a similar problem here with closing the loop. To figure out the time it takes for the system to reach its free speed, the math is more or less the same as any DC motor accelerating a moment of inertia. It’s college level stuff, but overall not too complicated. There are plenty of resources online (though I can’t link to any right now). The problem comes when you want to stop accelerating below free speed, then you’ll need a feedback controller which brings along all of the same problems. And if you don’t slow down first and just speed past the target velocity, your spin-up time won’t be very accurate.

1 Like

I’m not aware of anything that specifically talks about minimizing spin-up, but it comes from the first-order DC motor equations:

V_{applied} = i R + K_e \omega
\tau = K_\tau i = J \dot{\omega}

and a bit of algebra+calculus. Here’s a writeup I did on this sort of problem. gearing.pdf (427.4 KB)

I pulled up my class notes and found that the problem I was referring to was about maximum power delivery instead of minimum spin-up time so that may not be as applicable. I don’t believe that finding an analytic solution for minimum spin-up time is possible in this framework at least.

And yes, as Ari noted, this is a physical minimum for your spin-up time. It requires a good feedback controller to get close to this, which isn’t as simple to model.


It should be possible, at least theoretically. If you gear too low, you’ll have too little torque to accelerate the load so it will take a long time to get to speed. If you gear too high, your free speed could be close to or even below your target speed so it will take a long time (or infinitely long) to reach the target. There should be a way of determining the ideal ratio, either analytically or through simulations.

Overall though, as I said before, I’m not sure how accurate it would be without taking into account a feedback controller, viscous friction, motor inductance, voltage sag, etc.

1 Like

I like to break things. I was able to enter a negative mass value in your calculator; I don’t know what that means. :slight_smile:


How else are you going to have a matter-antimatter reactor?

1 Like

This is done :slight_smile: thank you @Andrew_Schreiber for implementing it so quickly!

1 Like

Just so we’re clear - it’s only for inputs for now. If someone wants to take a pass at doing outputs it’s fairly simple and I’d be happy to walk someone through it.