Rookie Mistakes: Principles

Here are some common mistakes that teams make in the high-level design and strategic planning stages.



Do everything at once

  • Robot becomes half-baked

  • Cannot excel in one area

Perfect one objective first

  • Robot is highly optimized

  • Consistently excels in one area


  • More time needed to iterate

  • Less reliable


  • Best designs are usually simplest

  • Less moving parts

Score-first design

  • Neglect proper principles

  • Often wildly inconsistent

Design for consistency

  • Usually reliability > scoring ability

  • Great plus for alliance selection

Build haphazardly

  • Build with subpar materials

  • Inadequate support structure

Build for reliability

  • Remove unneeded moving parts

  • Eliminate single points of failure

Fret about design

  • Wastes testing time

  • Design alone is not enough

Focus on execution

  • Make a decision, then stick to it

  • Execution often beats design

Doing Everything At Once to → Perfecting One Objective First

Consistency is king.


A common pitfall for first year teams is trying to accomplish all the game objectives at once, especially in tele-op and endgame.

This is highly discouraged because oftentimes new teams do not have the experience to do so. It is no small achievement to have a consistent robot that completes all objectives in competition, even at the higher levels.

Too often, we see teams bring half-baked robots that will attempt to do everything in a match, but excel at nothing. Even if they succeed, it is often by thin margins and cannot be repeated. This robot could be much more successful if the team spent their time to perfect one mechanism first.

Teams should always remember the principle that a robot that can complete one thing consistently will likely be more competitive than the robot that does everything inconsistently. We recommend teams focus on one objective during tele-op/endgame and perfect it.


Typically, teams which have a solid autonomous and consistent endgame can be competitive at the Qualifier level. This is a recommended goal for new teams.

Overcomplex → Simple


Another common trap that teams fall into is to overcomplicate needlessly. Simplifying your robot simplifies possible headaches later.

While some robots are very complicated, keep in mind that those teams are generally experienced, have some sort of machining capability, and fully design their robot in CAD. However, many world-class teams often build designs that are ingenious yet ridiculously simple.

Some advantages to simplicity are that the robot has less points of failure, given that the robot has less moving parts. Additionally, it takes much less time to iterate through and perfect a simple mechanism as opposed to a complicated one. The reasoning is that a complicated system has many more variables that need to be adjusted/could cause problems.

Keeping things simple can be practically achieved through a couple of ways.

  1. Limit the degrees of motion that the mechanism operates in. For example, a linear slide goes in and out in a straight line, as opposed to an arm, which rotates along an axis. Doing so will serve to eliminate forces that otherwise could adversely affect the mechanism.

  2. Another way to simplify is to build for the shortest travel distance. Obviously, the shortest distance from A to B is in a straight line, so teams should strive to keep the game elements approximately within a reasonably straight line. This can help in solving possible problems if the game elements need to change direction too many times.

Score-first Designing → Designing for Consistency


Teams should prioritize consistency over scoring ability.

The tortoise beats the rabbit. An overused parable, but it still holds a kernel of truth. Why? Because the tortoise, which plodded along consistently, beat the rabbit, which had hot and cold streaks.

A hallmark of any successful team is consistency and reliability throughout the competition season and even across seasons. Sports dynasties are dynasties for the reason that they compete at a high level not for a couple games, but for multiple seasons. Without the power of consistency, it will be nearly impossible to win games, let alone a tournament.

Too many teams fall into the pit of prioritizing scoring ability more than anything else, which is a grave error. In keeping with the first tip, to perfect one objective first, this practice will serve to increase consistency.


While scoring ability should be a priority and objective when designing mechanisms, it is not everything in this game. We advise being consistent at low and medium scoring levels than inconsistently scoring at a high level.

Focus on being able to do that one thing every single time throughout your matches, and you will begin to see how important consistency is. This tip is equally as important during alliance selections. Top teams will prioritize teams that are consistent far more than scoring ability. They are not afraid to look at teams who can’t score much, but can contribute every time to the alliance score, rather than selecting a boom-or-bust pick.

Building haphazardly → Building for reliability


Build for the worst case scenario, not the best case scenario. When building, teams often overlook a key principle: build for reliability. All too often, teams skimp on the quality of construction as well as materials, which leads to one of the most common reasons for unsuccessful tournaments: part failure.

Teams also do not take into account the rigors of competition and build as if the robot will not encounter opposing robots. Sufficient driver practice will be able to better simulate in-game conditions and test the reliability of the robot. To remedy this problem, refer to the Materials Guide to gain a better understanding of what materials are recommended for use.

If possible, teams should build with redundancy in mind. For example, if one set of linear slides fails due to a wire snapping, having a second set will still allow the robot to operate instead of sitting dead in the water. Practically, doubling mechanisms, motors, and servos is a common method to build for redundancy.

In addition, teams often forget to account for twisting or compression forces that may occur upon the mechanism.

While we cannot give any specific recommendations, do keep in mind what forces the support structure of your mechanism must bear along the full range of motion, and account for what occurs when it might hit another robot/field wall/field. Building more robustly is always worth the time spent. However, it is good to think about the extra weight that results.

Furthermore, a common cause of robot disconnect is wiring issues. Refer to the Wiring section for more information; in short, make sure to plan ahead and leave space for wires, and use strain relief whenever possible.

All these tips combined will help your robot become more reliable, a key characteristic of all world-level robots.

Fretting about Design → Focusing on Execution


A good execution of a bad design will beat a bad execution of good design.


FTC is all about how well you execute in both the mechanical aspect and the driver aspect. If your goal is winning, then how mechanically beautiful your robot is doesn’t matter. Your goal is less of impressing the judges but performing the best you possibly can on the field.

It is very possible to take a bad design, execute it well, and still be competitive at a high level. Even though not many teams are able to do so, it still goes to show that the method of implementation is very important. When brainstorming designs, try not to get hung up on small details if possible.

It is important to discuss different designs and debate the pros & cons, but after a design has been picked, stay with it unless there are major flaws that were originally overlooked. Changing designs will throw away the time spent on the original design, when teams could have kept improving it or practiced more. It is possible to rebuild your robot mid-season, and many top teams have done so to great success.

However, this is not recommended for rookie and new teams due to the general lack of experience. Realistically, expect to spend 50-100+ hours to rebuild a robot from the ground up. Focus on how you can iterate your current design to be as effective, efficient, and refined as possible.