Things Learned During Build Season

[dictionaria13]

As a rookie, I know I've learned a ton, not all totally FIRST-related. For example:

I learned that zip ties make effective hair ties,
I learned that I rock at crimping connecters onto wires,
A girl on our team who immigrated from Vietnam about two years ago learned about the kind of strippers you don't use on wires (she turned bright red when a guy on the team demonstrated by dramatically peeling off his sweatshirt).

I know I can't be the only one who's learned stuff like this. Anyone else want to share what's happened to them?

[tsakshaug]

As a mentor, I learned that getting changed to second shift at work makes it nearly impossible to work with the team

[Anupam Goli]

Always design your robot to include wires and battery mounts. Also, don't give your head programmer 1 day to debug code. What he will do instead is write 40 lines of crap code just to do a unit test, and use the time between regionals to debug.... a very not so good idea.

[ChristopherSD]

Take "concept-freeze" day seriously.

[Chomper2013]

My team's learned that the most popular question is "Where is the Wago/Measuring Tape/ Punch?"

[Jakester9999]

Originally Posted by Chomper2013

My team's learned that the most popular question is "Where is the Wago/Measuring Tape/ Punch?"

I would also add, "Where is the 7/16" wrench?". Those will always be your go to wrench for FRC.

[Bill_B]

Originally Posted by Jakester9999

I would also add, "Where is the 7/16" wrench?". Those will always be your go to wrench for FRC.

Or you could down-size to "where's the 3/8ths" shifting to the lighter 10-32 screws and bolts.

This year learned that 3/16" rivets are over-kill. It will be 1/8 next year. and maybe thinner gussets too. Maybe even thinner-walled square tube. Who knows?

[shawnz]

Originally Posted by ChristopherSD

Take "concept-freeze" day seriously.

We learn this one every year.

[~Cory~]

As a programmer I learned that ~90% of all problems can be solved with this process: (Rather than guess/check or theoretical fixes)

1. Ping the Robot
2. Check the voltage (under load!!!)
3. Check and keep your documentation ACCURATE
4. Walk through your logic with sample data. Then have someone else walk through a psuedocode version. Numbers should match
5. If something works, save and create a backup
6. Sockets, Threading and Vision can be difficult. Split the work up
7. Use the debugger. Its there for a reason.
8. Read the output from netconsole or serial during startup. You can find many hidden errors there, such as defaulting to old code!

[TheAthlete]

Being an electrical lead for the first time, and now the official head driver, I now understand what 'real' stress is. I've only had 2 practice matches at a mini-regional (Sussex, WI) and a total of 30 minutes of pure driving. Now we've bagged and i won't be driving again until competition.

Needless to say, give your drive-team more time with the robot!

[Alan Anderson]

I learned that it's wrong to assume that poor decisions leading directly to difficult situations last year would not be repeated this year.

I learned that a pair of student programmers can do great things without supervision.

I learned that many people are unable to follow simple and explicit written directions, to answer simple direct questions, or to describe simple status indicators accurately. I have to learn that anew every year.

[Anupam Goli]

Originally Posted by Alan Anderson

I learned that it's wrong to assume that poor decisions leading directly to difficult situations last year would not be repeated this year.

I learned that a pair of student programmers can do great things without supervision.

I learned that many people are unable to follow simple and explicit written directions, to answer simple direct questions, or to describe simple status indicators accurately. I have to learn that anew every year.

Sounds like it was a rough year.... :\

[wireties]

Measure twice, punch then drill once - and that people tend to ignore this when under stress

[pyroslev]

I was out of it for three years, and come back into it, most things stay the same.

Whatever your team number is, that's how many designs you seem to go through and you still end up modifying it. (i.e. Design 1610, Version 7.)

That even students that are tag alongs or just there can be sucked into it.

Stopping for a meal break and sitting round a table with your team just goes to to show you Family is what you make it.

Decide where you want you electronics board EARLY so you don't have to redo it.

If you make your own frame (ex: Extruded Aluminum) Order it ahead of time so you don't loose a week.

That sometimes even when your behind or ahead, you can be the opposite.

And that you never get FIRST out of your blood.

[MathMaven]

Originally Posted by Wing

[D]on't give your head programmer 1 day to debug code. What he will do instead is write 40 lines of crap code just to do a unit test, and use the time between regionals to debug.... a very not so good idea.

A better one: Finish the robot early so that the programmers have time to PROGRAM. Seriously, we need time to write and, more importantly, to test our code. My two years so far were awful because of this, and year three likely will be stressful again.