Do's and Dont's

Other Chit-Chat
#6

Do not: Assume that a sub-team that works away from school a lot is getting as much done as they say.

Do: Get second, third, and fourth opinions on how long something will take.

Do: Have a backup plan ready and waiting.

Do: Monitor chiefdelphi during build. You never know when an interesting solution will pop up there.

Do Not: Assume that because someone has been with the team for a long time, they are the best person for the job.

Do Not: Underestimate freshmen. Ever.

Do Not: forget to include the 4x4s in your new crate dimensions. LOOONG monday night…

#7

Do keep an eye on your robot’s weight throughout the season, instead of only weighing it for the first time four days before you crate up.

Don’t let bored people mess around with your power tools.

#8

Do let programmers mess around with power tools (do laptops count?) : sometimes they are the best person for the job.

Do trust people even if you don’t like them as a person. If they’re on the team, they usually know enough to be helpful and want to be there.

Don’t let personality conflicts harm a season.

#9

Don’t make fun of an advisor by saying he likes a paticular song.

#10

Do NOT play “What is Love?” on repeat on the team speaker system.

People WILL get shot.

#11

Hey! I’m a freshman, and I’m the lead programmer… and the robot works pretty well…

Do: Be open to suggestions

Don’t: Forget to eat

#12

Do not test autonomous for the first time in a building surrounded by windows. (The robot was not the only thing broken)

#13

It sounds like you guys had a lot go wrong? Is the robot ok now?

Don’t leave a lot of flooring pieces on a cart that you think is stronger then it is in reality. Always ends bad.

#14

…SO FAR.

Sorry, nothing personal, I just like heckling freshman.(yes, I do know they are often qualified)

For mentors/coaches:

Don’t do the work for the students.
Do make sure the student you give a task, can do the task.(regardless of what they say.)

#15

This is mainly for small teams (<15 or so)

Do NOT take most of the team on your lunch break during competition at a restaurant where the line is out the door, an hour and a half is too ling for the remaining three members to take care of the robot without food or backup.

DO remember to pack extra IFI traction wheels- the rivets can break.

#16

DON’T have someone on the drive team who doesn’t have an understanding of at least the rules that pertain to his/her position. So many penalties in Week 1were because the PS’s made mistakes that they might/might not have thought were fine.

#17

Or, even worse, coaches touching the controls. In the short time I was watching Midwest, I saw no fewer than three DQs for it. If you see me do it on the field this season, please take the time to kick me in the butt.

Also, don’t ever write off a team. Ever.

#18

Don’t forget to check nuts, bolts, and screw before you send the robot back out. Just because they were tight earlier doesn’t mean they are now.

Don’t let three people from a ten person team program in a room during week two instead of finalizing a design.

#19

If you’re a freshman, don’t be really obnoxious and not do anything. The upper-classmen will resent you for it, and they’re already inclined to harass you because you’re freshmen already. If you ARE an annoying freshman, work hard and share food with people. People will still be annoyed, but you’re less likely to get strangled by the end of week 4 of build.
We saw both sides of this on our team, mostly with the freshman guys. We had 3 freshman guys. 1 showed up maybe twice, CADed a side of the crate, and then goofed off the rest of the time instead of doing his work, all the while cursing up a storm and giving people lip. The other two goofed off a bit and would make inappropriate comments, but they CADed up the entire robot and brought food. The girls were much more pleasant to work with. So yes, I am talking from experience.

Also, I’m not calling all freshman annoying or obnoxious, just calling out those who are. This applies to older guys too, but the newbies on the team are much less likely to call you on it if you’re twice their size, at least in my experience so far.

#20

Do practice driving. Our driver was ok, but definitely could have improved with more practice.

Do update your firmware LONG before you go on the field. You need time to make sure the code redownloads properly and fix problems if it doesn’t.

Do not expect a design will flesh itself out; unlike in CAD, parts do not hang in midair just because they have been placed there.

Do not give the coach badge to the programmer, or let them take it themself. If they have to clarify something to the driver, it’s important they be able to touch the controls in order to do so. Our programmer was wearing the coach badge during our first practice match, and grabbed the controls in the middle. facepalm

Do know what the coach badge means, especially if you put it on!

Do not spend time making changes to the robot at competition if the problem lies with strategy (or lack thereof).

#21

NEVER… No, ALWAYS have somebody with their hand on the disable switch when testing code you’re unsure of, especially when the operation of your robot could damage itself or others.

#22

Do not forget to eat and drink even if you are really busy at the New Jersey regional trying to finnish your robot. (learned that one the hard way)

Do not trust your flaky faculty advisor with the shipping papers. She will forget them in her classroom

#23

Don’t “just get something driving” without any design phase for a superstructure. It wastes a lot of time when you have to go back and switch to a wide base.

I have this problem with everything – debate, robotics, even just being home alone. Once I’m in college… I’ll have to learn to eat?

#24

Do not have your robot hit the head ref with an orbit ball. They will not be happy. Oops :slight_smile:

#25