# paper: Calculating for Requirements: a Systems Engineer's Mechanical Calculator

Thread created automatically to discuss a document in CD-Media.

Calculating for Requirements: a Systems Engineer’s Mechanical Calculator
by: JesseK

A complex, but powerful, calculator

Ever hear
“You’re going to power the lift with THAT little thing?”
“Why did you choose that ratio?”
“Gear it for speed, we can slow it down in software.”
–or my favorite from my fellow mentors in 2008, prior to Atlanta–
“It’s ok to take 2 CIMs off of the drive train and put them on our lift”
???

Well I’ve heard it. Simple calculators and “experience” hasn’t been enough to convince some of my fellow mentors to some things I’d seen work before. Even I had quite the case of foot-in-mouth this season because it just didn’t seem feasible for a small object to climb a pole in under 2 seconds using the crappy motors we had. I’m not a mechanical guy, and this stuff doesn’t come naturally. So I was driven to find answers, backed by data that is reasonably accurate. Thus I present my calculator. As for accuracy … well, it’s reasonably accurate to the many videos I’ve watched, anecdotes from here on CD, and all of the robots I’ve helped develop.

It’s complicated, and will take some time to learn every ‘feature’ it has. However, it has 4 major purposes:

1.) Make the calculator Print friendly. Only a specific area of each worksheet will print. This is for communication purposes.
2.) Show outputs that are from the perspective of the strategy requirement, Time.
3.) Have a way to annotate boundary conditions and decisions into the worksheet. Notes, shapes, and built-in graph features facilitate decision-making AND traceability.
4.) Serve as a teaching tool in the Fall. Over the summer I’ll add an equations sheet that shows the derivations of the equations.

Hope someone finds it useful, somewhere. Enjoy!

Wishlist:
“Drag Race” of historical robots
Create a trajectory sheet
Create a total power draw (mAh) estimate sheet

Revision History:
Version 1.1, 3/18/11: Fixed an issue with the minibot’s moment of inertia that wasn’t using the proper radius for the “wheel diameter” chart. Updated minibot motor specs that were found via dynamometer data.

Version 2.0, 4/14/2011: Uses Ether’s incredible insights into Minibot physics to properly model every aspect of our robot with respect to Time.

Version 3.0 12/12/2011: Derives a few extra charts based upon the physics equations from V2.0, and plots them versus gearing for the drive train tab.

JesseK Calcs For Requirements 2011.xlsx (443 KB)
JesseK_Calcs_V3.xlsx (561 KB)

whew. That’s downright impressive. Good work! Not only does it look good, but that is a phenomenal system you developed.
One thing (cosmetic only) - some pages you forgot to change the title…but it doesn’t take away a single bit from the awesomeness!

Updated to reflect a proper analysis using Wolfram Alpha with Ether’s equations to solve for Time as a function of distance to goal, gearing, mass, and radius. The new file size is reduced by 80%!

The goal for this new revision is to get the final #'s within 10% of what’s seen on the field while also exposing designs that may burn a motor out over the duration of a competition. It will also serve as the foundation of an extension to Karthik’s strategy presentation for DC-area teams.

Note – the product log function winds up being so negligible in good designs that I don’t bother with Newton’s method to calculate it. It does expose bad designs, yet there are also other indicators of ‘bad design’ that will become apparent in the graphs.

John, here’s your proverbial idiot button

Wow this is amazing!!

I just had 1 quick (and hopefully easy) question. How long is a match?

Typically tele-operated period is 120 seconds. Autonomous varies from year to year (15-30s).

so if i say it does the objective 10 times in a match, the calculator does it 10 times in 120 seconds? I’m trying to use the calculator to see how much battery I need. I need my robot to run for 45 min