The purpose of this thread is to compile a list of things your team does that may seem small, but really give you a distinct advantage either on or off the field. These can include things your team does, or things you’ve seen other teams do.
Send sponsors thank you letters and include a team picture with the robot. A small gesture but it goes a long way.
Have all team members have input on the Chairman’s Award essay and study the final version. You never know who will end up talking to a judge at an event.
Remember that FIRST and CD get a ton of new rookies every year. Think hard about the little things your team may do and don’t take anything for granted.
There is no situation in FRC where you can safely say “well, I guess we don’t need a pick list”.
Don’t fix mechanical problems with software, ever.
Keep your robot and your strategy simple and you won’t have to worry nearly as much about almost every problem that plagues FRC robots (weight, CG, reliability, system integration, etc)
Great teams with great software have control loops. Clever teams without software have pneumatics.
Pre-match checklists and pre-flight tests are always necessary. It doesn’t matter how well your robot ran in the last match, check everything again. This goes the same for post-match checks.
Driver training can never be overvalued, and is very commonly undervalued.
Never stop learning. There is something you can learn from every team, every student, every mentor, you talk to.
“Custom” does not always mean “better”.
Every student should be knowledgable on every part of the robot. A software student should be able to explain any mechanical part on the robot as well as a mechanical student can explain any other part.
Take time and design something right the first time. Tweaking should be done to improve, not to make something work.
The most important part of the robot, regardless of the game, is the drivetrain.
MAKE SURE THE BATTERY DOES NOT FALL OUT
Design things to be much stronger than you think they need to be. When something goes wrong (your robot falls off 2 second level of the pyramid), and your robot doesn’t break, it’s very impressive to watch
Don’t get too attached to an idea. Your first idea is never the best, and 99.99% of the time, there’s somebody who can help you make it better. (as JVN says, design is all about iteration.)
At a competition, doing well is not an excuse for not testing the robot. This is why you don’t tell your drivers the team’s rank until its time for alliance selection.
I would add to you checklists to check if the driver station is charged. If your battery is suspect, get a replacement. You don’t need the driver station to die.
Test setup your pit before an event, keep it the same from event to event, it will really speed up repairs if you know where things are.
Save all your team documents in one place (Dropbox, Google Drive, another cloud or server solution). It’s far easier to find something you already have than it is to remake it.
Standardize your hole sizes and fasteners. We use 3/16" rivets and 10-24 bolts in 13/64" holes, it may not be a perfect solution but it works very well for most FRC robots.
Limit your building materials: we try to only use a few select standard building materials to actually stock that way we if we need to remake something at competition we have the spare material to build it from. Our list includes 1x1x1/16" square and angle aluminum, 1x1x1/8" angle aluminum, 1/16" polycarb, and .09 sheet aluminum. A few other things creep in but for the most part everything is made from those items.
Don’t use set screws to transfer torque or loads. I even try to avoid them in no load applications such as encoders. Outside of FIRST I only use them in very low load situations, low vibration settings.
This is in reference to in the 2013 manual. Standard practice for many teams, including mine, is to apply hot glue to PWM connections. Was this disallowed at any events this year?
Don’t implement software changes just before a match, especially if that software has a chance to be stuck in an infinite loop.
Always check your batteries before a match if possible. CTRE sells a great battery checker if you’re willing to shell out $125.
Rule #34 of Chief Delphi: if a question regarding FIRST robotics exists, there is a thread about it on Chief Delphi.
*]Keep track of all students going to a regional, especially when it is out of the country. Use some kind of head-count or buddy-system. If it is out-of-country, make sure that all students have their passports with them.
Abiding by the rules is a necessity. None of them are optional; they are all strict design constraints that MUST be met in order to compete. Although a good shooter may be more of a differentiating factor between good and bad robots than good bumpers, existing and legal bumpers are more of a necessity to be on the field than an existing shooter is.
As for technical stuff: avoid shoulders, grooves or other features on live shafts that concentrate stress between the driving torque and the load. Putting a snap ring groove between a driving sprocket and arm hub is asking for the shaft to fail where a spacer would do perfectly fine.
-This has been discussed before and there are multiple views, but I believe that crimps are better than soldering. You don’t have to wait for irons to heat up(bad during elims) and is hard to mess up. We switched to all crimps this year and have had so many less problems with electrical.
We don’t have access to a CNC machine, or a waterjet, or plasma cutter, or a welder. But we do have a laser cutter capable of cutting plastic, so you will see tons of ABS plastic on our robot.
**Any code with 10 minutes of driver practice is better than PID-controlled omni-directional speed-curved code without driver practice. **That being said, leftmotor = joystick1.y and rightmotor = joystick2.y should be the starting point, not the ending point for drive code.
Don’t be ashamed to switch to an easier strategy. For example: this year, if you were scoring less than 50% (which many teams were) in the 3-point goal, switch to the 2-point goal.
Never leave a competition before alliance selections have finished.
Don’t cause silly penalties.
Make sure that at least 2 programmers understand any given section of code.