[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.