Swiss Army Engineer: Web-based, Transient-First JVNcalc

[ThaddeusMaximus]

This is a start to something… I wanted a JVN style calc sheet after seeing so many that didn’t do (everything) I wanted. Namely:

1. Emphasize the use of transient analysis / simulation as the primary method
2. Allow input of load equations, not just load numbers
3. Work on any computer without need of an office package
4. Maybe solve the over-proliferation of these things by using the power of git so we can merge things together

… And so rolling my own in vanilla javascript + google charting seemed to be a reasonable proposition.

Thusly, enjoy a first pass at such a tool: https://thaddeus-maximus.github.io/swissarmyengineer/

Go to the “Simple Mechanism”. This should encompass flywheels, drivetrains, arms, elevators… you name it!

If you have ideas and/or you want to implement them, github page is here: https://github.com/Thaddeus-Maximus/swissarmyengineer

There will be a lot more to come.

[Tom_Line]

But in all seriousness, cool!

[gerthworm]

I might be missing something here, but curious - why does increasing the motor count decrease the time scale?

Also, this is gonna be annoying but… with JVN’s spreadsheet as the “trusted result” for some of these numbers, has any back-to-back testing been run to show the results align? I could totally go do this myself too, but curious if anyone’s tried yet.

But, well done overall! As beautiful as excel can be, an online version is a big step forward in ease-of-use IMO.

[ThaddeusMaximus]

why does increasing the motor count decrease the time scale?

The simulation (an Adams-Bradforth DE solver) is ran until either 1000 timesteps are made, or the end condition (which by default, isn’t filled in) is met. There’s also crude auto-time-stepping (using initial acceleration and max speed), so increasing number of motors decreases timestep. Basically… just fill in an end condition (say, t>2 or omega>2000) and this weird behavior goes away.

Any additional validation is good. I ran through and checked if the numbers lined up on a couple cases to be safe (on unit conversions and silly misplaced things), but the underlying physics is the same and rather well established.

Needs english units…

[ThaddeusMaximus]

V0.1: MAJOR revamp

• Units are awesome. Everything has units, and you can switch between metric and english.
• Plots are all in SVGs, and generally feature probing because probing is awesome.
• Collapsible sections. Fancy!

• New beam tool. I’m not sure why I’ve never seen one of these before. Finite-element beam models are 100% analytically correct when you don’t have distributed loads or variant cross-sections.
  

  

• Shot trajectory analyzer. Includes a very crude worst-case scenario system to figure out shot accuracy given input accuracies.
  

  

Also a belt calculator. Because none of the belt calculators out there do everything I want them to (check vex/andymark for available belts, support non-vex/am belts, tell me what size C-C for a given belt…) in one spot. Also polycord and crossed belts because it’s just flipping a sign.

Next plans:

• Add obstacles to trajectory analyzer
• Seriously rethink my adiabatic cylinder model
• Prescribed displacements on beam calculator (not particularly useful, more of an academic exercise. It’s been years since I’ve written FEA software, it feels so nice)
• Make an o-ring calculator because that’s something I’d use and I don’t like a lot of the ones out there
• Catapult analyzer
• Flywheel shooter analyzer (obviously not very accurate, just a ‘start here’ type of analysis)

Help / advice / feedback wanted:

• I am not a webdev. I do basic CSS. I think it’s fine but you may disagree.
• Persistence of some sort, or good exports would be nice. Maybe a print layout? I’m not versed in that. I’m not sure what would be the most useful. Being able to save spreadsheets is definitely nice…

Edit: I’m going to quit being a terrible person and doing the ol’ haha git push origin master now that I have a release. Branches are cool; I’ll have those.

[ThaddeusMaximus]

V0.2: O rings and Belt Strength

• Calculation of belt strength as per gates’ catalog

• O ring calculator! Nothing fancy yet, just tells you the expected compression/stretch/volume fill given dimensions.
• Maybe a little less confusing to use than others out there (hover over the picture, dimensions get highlighted), and a “print page” feature gives me something I can paste into my design notebook for reference.

Getting comfier with SVG manipulation. I used to do this a decent amount when I actually did webdev. It’s been a hot minute. It’s amazing what you can do without libraries

[ThaddeusMaximus]

V0.3: Exporting

Whoa, a titlebar! Neat! What’s that “Export HTML” button? It goes through, grabs all referenced CSS/JS files and dumps them into the DOM, then exports the whole page to a new file for you. When that page is loaded, it’ll have all the same parameters you left off with. Useful for keeping records, or ‘going offline’.

Also, probably aiming to rename to “EveryCalc” as that seems less of a mouthful. can you edit a thread title?

V0.4: Shots Fired

Two new calculators: a hooded pitcher, and a dual-wheel pitcher. Interesting for playing around with parameters and seeing ‘in which direction would changing parameter X impact the design?’

Trajectory calculator now includes aerodynamic effects, and an optional obstacle to display.

• Lift and drag coefficients work with regard to projectile speed squared.
• Magnus coefficient works with regard to projectile speed times projectile spin. the coefficients required to make this work are very low (< 0.1). does anyone have a good reference on getting coefficients for this? Seems a bit of a mystery. Maybe we’ll get to do some empirical testing in the… off? on? season.

Next up: now that I’ve written a bunch of code, I’m going to clean it up and standardize it now that I understand what some reasonable design patterns would be.

[AriMB]

@ThaddeusMaximus

Magnus coefficient works with regard to projectile speed times projectile spin. the coefficients required to make this work are very low (< 0.1). does anyone have a good reference on getting coefficients for this? Seems a bit of a mystery. Maybe we’ll get to do some empirical testing in the… off? on? season.

Here’s what I have, though as I said in the post I’m not 100% confident in it

AMB Design Spreadsheet v5

I’ll be honest: I’m not 100% confident in the equation the current version uses to calculate Magnus force. Tldr: I’m looking for someone experienced with advanced fluid dynamics to let me know if it’s right or not. The current calculation is based on this paper by the University of Illinois Physics Department quantifying the Magnus effect on baseballs. Basically they determined that the force could be expressed as: F_M = \frac{1}{2} C_L \rho A_c v^2 This formula matches that in @Ether’s whit…

 
I’d also like to see the equations you’re using in your calculators to compare them to mine. A white paper like I have would be very informative, and could also be a good teaching tool.

[ThaddeusMaximus]

Slick. I’ll try implementing that. Maybe even just add a ‘build your own lift/drag function’ since aerodynamics are… uh… special.

Here’s the docs: https://thaddeus-maximus.github.io/swissarmyengineer/docs
May not have everything. The general mechanism calculator is notably absent (although the physics are pretty standard). You can also trowel through the raw code in the HTML files, of course… look for a function called “compute” and maybe “run_sim_xxx” functions. I’ll (hopefully) be cleaning those up in the coming week…

[Monochron]

This looks really really interesting. And being web based means it’s easily accessible.

My current problem is . . . I’m not a great teacher. And this tool takes some teaching to use. Explaining the calculations isn’t all that bad, but the “how” of interacting with the tool is the part that gets complicated fast. Would you have any brief “how to” descriptions that I could use to convince my students that learning this is worthwhile? Or maybe just suggestions of how to convince them, haha.
Most of them area already believers in JVN, I think I’ll need to convince them that the complexity of this interface is worth it.

[ThaddeusMaximus]

Sure. I’m seeing that I’ll need to do that for my team as well.

I’m sure that a lot of that is probably work on my end; e.g. “make a better product”. I’m a big believer in this xkcd:

Ideas:

1. Maybe a walkthrough mode ("hey, I see its your first time here… click on these things… and you’re done!) would be helpful.
2. More collapsing sections, collapsed by default (most of the information that is displayed is could be on more of a ‘need-to-know’ basis)
3. Pictures that highlight on selection (like on the o-ring calculator). Maybe even pictures that you can click on and the fields show up there (at risk of making it feel too much like Microsoft Bob).

As for arguments of “why do I use transient analysis versus steady-state”, just go to the logical extremes of what steady-state analysis tells you for a drivetrain: build a robot with a really high top speed… but that doesn’t work in practice. Why?

This is the form of the velocity curve of a robot that’s accelerating.

If you’re spending a lot of time on the end, sure, steady-state is a valid assumption. But in the majority of cases getting there requires a lot of time or a lot of gear ratio, both of which are not what you want!

And that is why you need to consider the transient effects- you’re not on the highway, cruising, but on a racetrack, mashing gas and brakes. The important thing isn’t getting a sweet top speed, because that number is (almost) meaningless. The important thing is time-to-target. Set goals that are based on what you care about, then analyze to meet those goals rather than things that are loosely correlated.

Oh, also, I’m sure taking some time to make things look prettier than flat-on-flat could also help (if anyone is actually okay at webdev and is bored…)

[Amicus1]

Don’t the FRC manuals start with a “How to read this manual”?

@ThaddeusMaximus

I’m a big believer in this xkcd:

[ThaddeusMaximus]

Yup, and the whole premise of the manuals is to create a problem for you to solve

[ThaddeusMaximus]

V0.5 “Elegant Eagle”

• Blown up codebase, rewritten for further expansability. Should be easier to get into if you wanted to fork the repo and start writing add-ons or improvements.

• Created documentation for general mechanism calculator and trajectory calculation. Added information about validation to all documentation. Everything should be whitepapered.

• Added a number of minor features:

• JVN adjusted speed calculation in general mechanism
• Custom motor input allowed
• Removed view of “adjusted” motor parameters to clean things up
• Length correction factor cooked into the belt calculator
• Computational bugs found and fixed during validation against other tools

• Removed equal axes option on trajectory calculator (maybe that can be added back later).

[Monochron]

The tutorial is fantastic. Really great way to introduce someone to the simulation inputs.

Right now I think my students could definitely use it, but only with the help of an engineer or very experienced student. As an example, this tooltip (GREAT way to passively instruct by the way) requires the user to understand what a moment of inertia is and how to obtain it for their system. A description of how to do that, or possibly a link to a page describing how to calculate it, would go a long way toward helping educate.

Obviously it isn’t this tool’s job to entirely educate its users, and I know I’m just asking for features here. But I think this one’s like this would be particularly helpful.

[ThaddeusMaximus]

Thanks! You can also submit ideas and features to the GitHub. The more there are, the more chance there is I’ll pick one and do it when I’m bored.

It’s definitely a balance. On one hand, it would be awesome to provide a tool that any monkey can use, but on the other hand, at the end of the day, using it wisely requires some intuitive understanding of the subject matter.

Maybe it’s also wise to make more ‘specific use case’ pages that hide particular inputs and/or change them (so you select “rotary mechanism” and the input changes to a MOI input only). Pictures are good too.