26 Rules for FRC Design

[Jay Trzaskos]

I found an interesting list on Dave Akin's website last night that resonated fairly well within the FRC Community. Akin is currently a Professor of Aerospace Engineering at the University of Maryland, and was a Professor of Aerospace engineering at MIT prior to that. I've shortened and amended his original List, Akin's Laws of Spacecraft Design, to create a more succinct and relevant list of important FRC Design "rules." This is all meant in good fun, although there is a lot of truth in this list. I encourage everyone to take the time to read Akin's original list too, it's pretty spot on.

The 26 Rules for FRC Design

1. Engineering is done with numbers. Analysis without numbers is only an opinion.
2. To design a robot right takes an infinite amount of effort. That’s why it's a good idea to design them to operate when some things are wrong.
3. Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.
4. Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.
5. In nature, the optimum is almost always in the middle somewhere. Distrust conclusions that claim the optimum is at an extreme point.
6. Not having all the information you need is never a satisfactory excuse for not starting the analysis.
7. When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up when the real numbers come along.
8. Sometimes, the fastest way to get to the end is to throw everything out and start over.
9. There is never a single right solution, but there are always multiple wrong ones. Good design is having the forethought to distinguish these from the rest.
10. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.
11. (Edison's Law) "Better" is the enemy of "good".
12. The fact that an analysis appears in print/online has no relationship to the likelihood of its being correct.
13. Past experience is excellent for providing a reality check. Don’t let a poor experience doom an otherwise worthwhile design, though.
14. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up.
15. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.
16. Half of everything you hear on Chief Delphi is crap. Experience is figuring out which half is which.
17. The schedule you develop will seem like a complete work of fiction up until the time you have to bag the robot without meeting it.
18. It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.
19. (Montemerlo's Law) Don't do nuthin' dumb.
20. (Varsi's Law) Schedules only move in one direction.
21. (Law of Demonstrations) When the hardware is working perfectly, there are no scouts watching your match.
22. (Roosevelt's Law of Task Planning) Do what you can, where you are, with what you have.
23. (de Saint-Exupery's Law of Design) A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
24. Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.
25. Capabilities drive requirements, regardless of what the systems engineering textbooks say.
26. FRC is an unforgiving environment. If you screw up the engineering, it is impossible to succeed. (and there's no partial credit because you almost made it to Einstein...)

[DampRobot]

Thank you. I think I'm printing these out and putting them in the shop somewhere.

[Akash Rastogi]

Most of these sound like things I've learned from JVN, Adam Heard, and Cory McBride while reading CD!

Brilliant. For those don't have the required experience for #16: This isn't crap. This is the good stuff.

[Ian Curtis]

You missed the best one!

29. (von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.

16. Half of everything you hear on Chief Delphi is crap. Experience is figuring out which half is which.

Probably over 80% in actuality, but the remaining 20% is well worth sticking around for.

[safiq10]

love this

[s_forbes]

Originally Posted by Jay Trzaskos

24. Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.

Debatable, depending on your definition of the terms. Efficient and effective designs can be constructed from the many basic concepts that are taught in schools. Elegant designs require a certain imagination (not common to come by). IMHO.

I have no qualms with the other 25 points listed.

[Roger]

21. (Law of Demonstrations) When the hardware is working perfectly, there are no scouts watching your match.

The corollary is the robot will perform perfectly until the head mentor comes in the room to watch. We use this in programming all the time.

[BrendanB]

Originally Posted by Roger

The corollary is the robot will perform perfectly until the head mentor comes in the room to watch. We use this in programming all the time.

Hehe, ditto that.

[rachelholladay]

Originally Posted by Ian Curtis

You missed the best one!

29. (von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.

Whenever we'd ask for a estimate on the mechanical subsystems, the mechanicals would double their estimate and then tell our project manager, who would double and then tell myself, the software lead, and then I would double it. Still wasn't accurate enough a lot of the time.

[DampRobot]

Originally Posted by rachelholladay

Whenever we'd ask for a estimate on the mechanical subsystems, the mechanicals would double their estimate and then tell our project manager, who would double and then tell myself, the software lead, and then I would double it. Still wasn't accurate enough a lot of the time.

Then the mechanicals need to improve their estimation skills!

By the way, who comes up with these names ("de Saint-Exupery's Law of Design")? The fact that they seem so formal and establishment-sounding makes it so much funnier!

[MechEng83]

[Relevant background to my upcoming comment: My last name is Coulombe.]

My kids (especially the ones who have had physics) have begun keeping track of "sage" things I say during the year and have dubbed them "Coulombe's Laws"

#1 above is very close to a favorite of mine: "Do the math!"

[Ian Curtis]

Originally Posted by DampRobot

Then the mechanicals need to improve their estimation skills!

By the way, who comes up with these names ("de Saint-Exupery's Law of Design")? The fact that they seem so formal and establishment-sounding makes it so much funnier!

They are named after the rocket scientist that came up with them. Google them, they were smart people that did cool stuff.

[AllenGregoryIV]

Originally Posted by DampRobot

Then the mechanicals need to improve their estimation skills!

By the way, who comes up with these names ("de Saint-Exupery's Law of Design")? The fact that they seem so formal and establishment-sounding makes it so much funnier!

It's from a Antoine de Saint-Exupéry quote

"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupery

[Peter Matteson]

Originally Posted by Jay Trzaskos

8. Sometimes, the fastest way to get to the end is to throw everything out and start over.

I have difficulty believing the number of teams that refuse to do this.

Too many teams stick with the idea they came up with at kick-off and never know when to give up on something.

I've sawzalled our robots to start over more than I'm willing to admit, but I think you have to be willing to completely scrap your ideas once you know your ideas won't work and you see the right way to go.