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.
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.
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.
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.
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
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?
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.
Here’s what I have, though as I said in the post I’m not 100% confident in it
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.
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…
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.
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:
Maybe a walkthrough mode ("hey, I see its your first time here… click on these things… and you’re done!) would be helpful.
More collapsing sections, collapsed by default (most of the information that is displayed is could be on more of a ‘need-to-know’ basis)
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…)
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).
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.
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.
Created “Walkthrough mode” (as previously alluded to); hit the “tutorial” button in the top right!
Made a tool for computing ISO fits. Because all of the online calculators I’ve found want to tell you all sorts of BS stuff that doesn’t matter, and insist on spreading it over a whole bloody page, and still don’t compute symmetric tolerance zones that machinists actually like to look at. Now you have no excuse for not getting your slip/press fits right with ISO tolerance zones.
Made a tool for computing the strength of gearboxes- custom or COTS. There’s a lot going on here. I don’t love that, but I don’t see a way around it right now.
Sidebar for help: if any student/mentor likes JS/HTML/CSS stuff, or UX design in general, and wants to help re-do a frontend, I think that’s my next focus before I go too much further with adding technical features. That transmission calculator is egregious.