Andymark Churros

[Nathan Streeter]

Originally Posted by hrench

I also want to weigh-in on the 'build it and see if it breaks' philosphy that's being encouraged here.


That is NOT SCIENCE. What Science IS is using previous observation to determine what will happen deductively. The reason we engineers make books of statistics about materials and books of equations about stresses is because science works. If we design something that will work because we've used science, we've taught the kids the value of STEM.

if we design something with the guess that it might break or might not, then we didn't teach math, we didn't teach use of historical empirical statistics and instead we've taught 'trial and error.'

Not a good way to be an engineer.

I'm also going to agree and disagree...

I agree that good engineering inherently should involve calculations/FEA/CFD/'running the numbers,' and that if we shield our students from that entire side, we're giving a poor image of what good engineering is.

However, we'll also be very poorly teaching students if we hand students a single equation for torsion or bending and a table of material properties. In FRC, far more dangerous than testing something (being unsure of failure or success) is the attitude that the equation or FEA is a magic box that spits out a highly accurate solution. Quite frankly, Mechanics/Fatigue/Failure/Stress Analysis are complicated and tedious enough that if we took the time to truly 'run the numbers' for 5% of the bearings, shafts, gears, keyways, fasteners, and frame members we'd be entirely out of time! Much of my Mechanical Design class was spent doing just these calculations for a single loaded axle with gears, bearings, keyways, and fasteners... accounting for the impact of keyways, stress concentrations, cyclic loading, reliability, factor of safety, etc. is very tedious, generally requires iterative calculations, and even then fails to really include the effect of heavy impacts.

Quite simply, it's best to teach students some mechanics of materials, materials science, and mechanical design, but it's also good to teach them that Engineering is saving time with some simple calculations, understanding the significant short-comings to theoretical tests, setting up a good physical test, predicting the success of a component from prior experiences, and knowing when to 'just try it.'

[Nathan Streeter]

Originally Posted by FrankJ

Like when you press the "fire" button on your lunar lander & hope it will take off and mate up with your command capsule somewhere in orbit?

Absolutely! However, I'd never climb into a Lunar Lander if it was based simply on the best calculations, FEA, and CFD without any prototypes or prior iterations.

How many times did we send stuff up into space, to orbit the moon, to even land on the moon, or to return to Earth before Apollo 11? Dozens, at least, and excluding those I'm sure there were many mock-ups, prototypes, and tests completed in advance!

All that said, NASA and FRC are at about opposite ends of the spectrum in terms of cost of failure vs Cost of Development. If you guess wrong on the shaft material of your FRC robot, at worst case you'll be dead in the water for a couple matches and may be ruled out from reaching your potential at an event. If you guess wrong on your manned trip in space, not only do you likely lose human life, but you may also shut down an entire program or limit future funding.

[BBray_T1296]

There is a reason that the Soviet Union was able to develop a closed cycle rocket engine deemed by American rocket scientists to be impossible. That reason? Iterative testing, failure, fixing that problem, discovering a new one. Rinse and repeat.

Sure their specific methods may be dirty or whatever, but they still produced an engine ~10% more efficient than anything we could come up with as of the early 90s.

Sure, doing the math and everything is a good way to get stuff done, but at some point it becomes more cost effective (time = money!) to simply do it twice then spend three times as long doing it once.

Lives are not on the line in, failure is always an option. It makes a great learning experience too

[llamadon]

Originally Posted by tim-tim

You also have the option of using AndyMark 1/2 Hex that made from 7075, although not sure if it is -O, -T6, or something else.

Really? I always thought AndyMark did not carry their own hex shaft for some reason, I would look on their site and never be able to find it. Obviously I did not look hard enough

[FrankJ]

All that said, NASA and FRC are at about opposite ends of the spectrum in terms of cost of failure vs Cost of Development. If you guess wrong on the shaft material of your FRC robot, at worst case you'll be dead in the water for a couple matches and may be ruled out from reaching your potential at an event. If you guess wrong on your manned trip in space, not only do you likely lose human life, but you may also shut down an entire program or limit future funding.

Like lets use this O-Ring stuff to seal a solid rocket joint even though experience shows joint rotates in an unpredictable manner under pressure & the O-ring takes a set when it is cold? (Challenger for you young people. )

FEA really didn't exist in today's terms in the 60's. 640 K ram (kilobytes) was a lot back then. Apollo more so than Challenger.

[Michael Hill]

Originally Posted by FrankJ

Like lets use this O-Ring stuff to seal a solid rocket joint even though experience shows joint rotates in an unpredictable manner under pressure & the O-ring takes a set when it is cold? (Challenger for you young people. )

FEA really didn't exist in today's terms in the 60's. 640 K ram (kilobytes) was a lot back then.

Don't blame the O-ring. Blame the people that knew it was a problem but forced the launch anyway.

[FrankJ]

Originally Posted by Michael Hill

Don't blame the O-ring. Blame the people that knew it was a problem but forced the launch anyway.

Precisely.

[Oblarg]

Often (especially in FRC) we have complicated systems that you can mock up really easily, for which it is far easier to tune a prototype than it is to work it out the behavior theoretically. There is also the fact that FRC is a high-school competition, and tuning a prototype is something most high school students can do and understand a lot better than a lot of the math required to correctly model many of the things we deal with in FRC (for example, how many high school students are realistically going to understand continuum mechanics?).

Take, for example, the frisbee shooters in 2013. Those were complicated nonlinear systems that would be a nightmare to model. I don't know a single team that did any sort of theoretical modeling of the effects disk compression or motor speed or rail friction on the reliability of such a shooter. I don't know why anyone would even consider approaching the problem that way, when all of those things can be figured out empirically with a simple prototype. I don't think this is sloppy, nor do I think it builds bad habits.

[EricH]

Originally Posted by Oblarg

I don't know why anyone would even consider approaching the problem that way, when all of those things can be figured out empirically with a simple prototype. I don't think this is sloppy, nor do I think it builds bad habits.

Correct. In FRC, prototyping is probably the best method you can come up with for quickly getting to the answer. The math done around the prototype should be doing one of two things: It should either be giving you a ballpark setting for the prototype BEFORE you build it ("Hey, the best guess is that the prototype oughta be able to throw 15 feet if we do thus-and-so"), or it should be in use AFTER the prototype is used to see if there is any optimization that can be done and will actually be worth the effort ("Uh... guys, it threw 20 feet, but we can get an extra 5 feet by adding a whodijingle and if we also add a whatsit we get another foot on top of that, but if we just play with this-that-and-the-other we can get 3 feet extra").

Where the bad habits set in are when nobody does even ballpark numbers. That's something that could cost a lot of time and money down the line for somebody.


True story: I've seen what happened when a prototype didn't work as planned, and then it was modified so that it would, but somebody forgot to re-run the numbers for a critical piece. That R/C aircraft was really, really squirrelly to fly. The critical piece? The control surfaces weren't resized after the wing area was increased.

Personally, I really like to set up MathCad (or Excel) with the equations, and see what happens if I monkey with one or two numbers. If I monkeyed with the right numbers in the right way, I get better output numbers. Otherwise... guess I gotta take 10 seconds and re-enter that number and see if my output did what I wanted it to this time.

[MechEng83]

I'll preface by saying I feel like this topic has strayed too far from the original post and may warrant a new thread over the value of prototyping vs doing theoretical calculations.

Now, my day job involves doing FEA (finite element analysis) all day, every day. So I have a personal stake and I feel it's a disservice to teach the kids that analysis is wasted time and you should just build and try it out. I also recognize that the analysis can become so complex and take too long to solve that you'd be better off getting empirical data from a prototype.
Analysis and calculations are tools. Some tools work better in certain situations than others.

One of my work leaders has a saying that I think provides good insight in to how design/analysis should be conducted: "All models are wrong. Some models are useful." The complexities of the physics involved in most of the systems are well beyond high school, undergraduate, and even some graduate courses. But there are simplified models that have the capability of giving you a ballpark estimate of "will this work?"

I often tell my kids to "Do the math. If it works in theory, it might work in reality. If it doesn't work in theory, it probably won't work in reality"
Before some of you jump on this and provide counter-examples about things that work even though theory says they shouldn't, know that this is useful as sorting tool. It helps in the decision making process.

Running numbers using college level mechanics and playing with the numbers allowed my team to come up with a "perfect" elastic counterbalance for a rotating arm. In implementation, it wasn't exact, but it worked well enough to make a system which was effective for the game challenge that year. Don't forget the I in FIRST. Showing my students what was possible with math inspired some of them to learn about it when they got to college.

Relating this back to the original post, If you pulled out the formula for torsional strength, plugged in the numbers and found out you needed 30 ft-lbs, but your system "theoretically" could only take 10 ft-lbs, then you go explore other options, rather than waste time doing the experiment.

[s_forbes]

It's neat that this thread is still alive, I guess "do the math" vs "just test it" can be a hot topic. Relevant:



If we have the ability to test something quickly, I encourage it so we get something done. If it requires more analysis first, then we do that. Teams will vary depending on resources. Folks who manage to do both all the time are awesome.


Re: original post - did you test them? If so, what did you find?

[hrench]

[quote=MechEng83;1408152]
One of my work leaders has a saying that I think provides good insight in to how design/analysis should be conducted: "All models are wrong. Some models are useful."
I often tell my kids to "Do the math. If it works in theory, it might work in reality. If it doesn't work in theory, it probably won't work in reality"
QUOTE]

Really like what this guy said.

I realize that axle loading can be a complex equation if you add the cantilever load, maybe some thrust loading, maybe even some torsional resonance (which can destroy systems). Actually, each axle sees different loading based on where on the 'bot it is. Not what I was talking about.

The equation for a churro in torsion has already been posted. That's the math that this thread started out talking about. Other posters have already shown with math that they don't take torsion well.

Simpler math that we can teach kids. So they can learn STEM, not trial and error.

[MechEng83]

Originally Posted by s_forbes

It's neat that this thread is still alive, I guess "do the math" vs "just test it" can be a hot topic. Relevant:

A bit creepy that this is actually the most recent XKCD...

[FrankJ]

Originally Posted by MechEng83

A bit creepy that this is actually the most recent XKCD...

You do know that Randal is a Firster from way back?

[MechEng83]

Originally Posted by FrankJ

You do know that Randal is a Firster from way back?

Yes.