The various engineering industries seem to each have their own set of rules of thumb, collected from great minds and scraped from millenia of collective experience. Sometimes tongue-in-cheek, these are all about overcoming unique technical and nontechnical challenges. Occasionally they veer into the specific, but viewed as a whole, they can be seen as a set of philosophies for developing systems that consistently produce working designs.
Conveniently, building a high-functioning FRC team is also about developing systems that consistently produce working designs. As such, many of these rules are applicable to FRC.
Kelly Johnson, famed Lockheed systems and aeronautical engineer, developed his 14 Rules of management which he used to run Skunk Works for decades:
A very simple drawing and drawing release system with great flexibility for making changes must be provided.
There must be a minimum number of reports required, but important work must be recorded thoroughly.
Push more basic inspection responsibility back to [the people making the parts]. Don’t duplicate so much inspection.
In particle accelerator design, there’s the Gospel According to Bill Brobeck. I’ll repeat the entire thing here because it’s a rare find out in the wild:
Thy bolt holes shall straddle thy center lines.
Thou shalt look askance at gunks, glues, and potting compounds.
When confronted with two solutions, both of which appear impossible, thou shalt choose the least expensive.
Thou shalt not be misled when thy boss says, “I don’t know much about this, but…”.
Thou shalt not use 1/4 inch bolts when one inch bolts will do.
If thou canst step upon it, thou shalt design it strong enough so that all men may step upon it.
Thou shalt bear in mind that welding is merely the casting of steel in the worst possible circumstances.
Thou shalt design assemblies such that parts thereof may be placed in a funnel and come out assembled on the other side.
Thou shalt stay with it until it works.
Thou shalt not form ride pools.
In spacecraft design, there’s Akin’s Laws, now infamous because they were so widely circulated in the early days of the internet:
Engineering is done with numbers. Analysis without numbers is only an opinion.
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.
In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.
Design is based on requirements. There’s no justification for designing something one bit “better” than the requirements dictate.
For years, I’ve wondered why spacecraft occasionally disintegrate, but I’ve never head of a particle accelerator disintegration. Now I know why. ::safety::
FIRST rules and lessons learned over the past 5 years (sometimes the hard way):
Setscrews are not power transmission devices. They are evil. They fail when you need them, and damage parts when used correctly.
Never set down a tool. It either goes in your tool pouch or the toolbox.
No one leaves until the shop is clean. I am not your mommy or daddy and I shouldn’t have to stay late to clean up your messes.
4.a) Planning for wiring and electronics is one of the most important design tasks on the robot.
4.b) Neatness and quality of wiring is a strong indicator of a quality robot.
The proper sized clearance hole for a fastener is the size of the fastener. If you need to drill larger holes to make something fit, you messed up somewhere.
On your prototypes and practice bot, match drill everything. On your competition bot, match drill nothing.
CAD is a tool, not an end product. Model what you need to, and nothing more.
A slide show is not a video.
9.a) Matches are won and lost in the pit.
9.b) Bring a spare for every COTS actuator and sensor on your robot.
9.c) The most important job on the pit crew is Ambassador. They keep others from distracting the hands-on workers.
Neatness counts in your shop, in your pit, in your storeroom. If you can’t find something quickly, you might as well not even have it.
11.a) During build season, time is your most valuable resource. If a student is not working, they are not contributing. If a student is distracting others, they are actively hurting the team.
11.b) Mentors cannot effectively mentor more than 4 students at once.
Summer is for development projects (including drivetrain). Fall is for new student skills development and robot build practice. Build season is for execution.
If there’s no video, it didn’t happen.
14.a) Planning is easy. Execution is hard.
14.b) On CD, don’t talk about what you plan to do. Demonstrate what you have done.
Don’t spend time making something if you can buy it. (unless it saves you a ton of money on your BOM)
16.a) Use COTs parts whenever possible. They don’t count against your withholding allowance.
16.b) Pre-purchase COTs drivetrain parts. FIRST does not enforce vendor part availability rules. FIRST vendors know this, and do not keep adequate stock.
It’s even more important to keep Gracious Professionalism in mind when you are doing good than when you are doing bad.
All threaded fasteners should either have a locknut or loctite.
Loctite destroys lexan.
Use flush cutters to trim off wire-ties, NOT diagonal cutters.
On the control panel, use switches for state functions (arm in/arm out) and buttons to initiate actions (shoot).
Drivers and operators should never need to take their eyes off the robot. Driver’s station displays are for troubleshooting, not operations.
Do not overwrite old code. Always keep previous versions, so you can go back to something that used to work.
No matter how many times your pit crew and drivers say they don’t need one, they both need pre-match checklists to be sure the robot is configured for a match.
Use hex shafts rather than round shafts with keys.
Don’t ask your match partners what they can do. Ask your scouts what they have done.
I agree with most of ToddF’s rules, and most of the ones I don’t are matters of taste. There is one, however that I shall rebut:
Talking about our plans on CD is a key part of our design process. I’d much rather share plans and have Ether tell me at the end of week 1 that we slipped a decimal point than get to robot testing in week 6 and find out the hard way.
Does anyone have a pre-match checklist they’re willing to share/ suggestions? This sounds like a really great idea. I can imagine what the pit one would look like/include- what about the one for drivers? Thanks:)
We have a whole series of checklists - one for each subsystem of the robot (drive, electronics, pneumatics, chassis/structural, manipulator 1, manipulator 2, etc.). The check lists are made each year specifically for each system. Two students are responsible for each check list. The use a “call/response” system:
Student 1 (reading from checklist notebook): “Chain at proper tension?”.
Student 2 (checks chain tension) “Chain at proper tension.”
Student 1 (Checks of item): “Chain at proper tension - check.”
Then they move on to the next item.
All the system checks are done immediately after the robot comes off the field. There is a final “list of lists” that is checked off to confirm that everything is done. There is a new list for every match.
Right before the match, there is a “Power up check” done the same way, but this actually tests the functionality of the robot (things like “lift runs up”, “upper limit switch operates”, etc.
It may seem like a lot, but that’s what the small swarm of students are doing around our robots holding all of those black notebooks. It has worked very well for us, finding things that could have been problems before they occur and (more often than I’d like to admit) finding that something that had failed had not actually been checked after the previous match - everything is initialed, so we can figure out how things go wrong.
The lists are best if they are made specifically for your robot and it’s functionality.
Our Ultimate Ascent robot was our most complex, and we did not have checklists. Every other match we had something not work that should have been on the checklist.
Another important thing for the in-queue checklist is to ensure that you’ve swapped over to radio-controlled mode rather than tethered, especially if you hit the practice field between matches.
::safety::