The Engineering Design Process in FRC

Design starts with the game, not the software

Every season begins at Kickoff, when FIRST releases the game. Good teams resist the urge to start CADing immediately. Instead they follow a structured engineering design process. The version used by FRC 1511 Rolling Thunder is a representative 10-step example:

1. Identify the need or problem. Read and re-read the game manual. Understand how points are scored, the field layout, and the penalties.
2. Identify criteria and constraints. List what the robot must do (functional requirements) and the hard limits it must respect (size, weight, rules like the 2026 R104 envelope).
3. Rank specifications. Use a weighted objective table to decide which capabilities matter most. You cannot do everything well; prioritize.
4. Brainstorm concepts. Generate many ideas through sketching and discussion. Quantity first, judgment later.
5. Construct a prototype. Build quick test models from wood, scrap metal, or 3D prints to see what actually works. Prototyping de-risks the design before you commit to CAD.
6. Select an approach. Evaluate prototypes against your ranked criteria and choose a direction.
7. Detailed design (CAD). Model the chosen design precisely, resolving how every subsystem integrates.
8. Manufacture and assemble. Build the robot from your drawings and BOM.
9. Analyze the results. Test the real robot and compare against expectations.
10. Refine the design. Iterate — fix, improve, or rethink. (FRC 1511 notes steps 4 and 5 can be swapped, and most teams prototype several designs in parallel.)

CAD lives in the middle and never really stops

Notice that CAD (step 7) comes after strategy and prototyping. Designing a beautiful model of the wrong mechanism is wasted effort. CAD's job is to take a proven concept and make it real and integrated.

But the process is not a one-way street. It is a loop. Prototypes teach you things that change the CAD. CAD reveals packaging problems that send you back to prototyping. Testing the built robot generates a list of fixes that become version 2 of the design. Veteran teams often run multiple prototypes in parallel to compress this loop into the short season.

Requirements drive everything

The single most useful habit is writing down requirements before modeling: 'The intake must pick up the game piece from the floor in under 1 second and hand it off to the scorer.' Clear requirements let you evaluate designs objectively and give design reviews something concrete to check against.

Subsystems: divide and conquer

FRC robots are organized into subsystems — drivetrain, intake, scorer/shooter, climber, and so on — mirroring how the software team organizes code. Each subsystem can be designed, prototyped, and reviewed semi-independently, then integrated in the main robot assembly. This division lets several designers work in parallel.

Learn this process and you will avoid the classic rookie mistake: building a polished robot that does not actually win matches.