The Robot Is a System, Not a Pile of Parts

An FRC robot is an electromechanical system built to perform game tasks under rules, time pressure, inspection requirements, and other robots trying to do the same thing. The frame matters. The code matters. The wiring matters. None of them wins a match by itself.

A useful way to understand the machine is to stop naming parts for a minute and follow jobs.

A competition robot has to receive energy, make decisions, communicate, sense state, create motion, and interact with the field. Different teams use different hardware, but those jobs remain recognizable.

Six jobs inside the machine

Notice what is missing from the table: a category called “the robot.” That is the point. The robot is the relationship among these jobs.

A drivetrain motor that is mechanically perfect but has no power path does nothing. A sensor can report a value, but the value matters only if software reads it and some decision uses it. A command can be correct while the mechanism still fails because the chain between command and motion is broken somewhere else.

A subsystem is a boundary

Teams often divide the robot into subsystems such as drivetrain, intake, elevator, shooter, or climber. A subsystem is more useful than a parts list because it gives a group of components one responsibility.

Consider an elevator:

driver button
    ↓
robot command
    ↓
elevator subsystem
    ↓
motor controller
    ↓
motor + gearbox
    ↓
chain/belt/rope mechanism
    ↓
carriage moves
    ↑
encoder reports position

This diagram is already more useful for troubleshooting than “the elevator has two motors and an encoder.” It shows dependencies.

Worked example: the intake does not run

Suppose the driver presses the intake button and nothing moves.

A weak diagnosis is: “the motor is broken.”

A stronger first model is:

1. Did the Driver Station register the input?
2. Did the trigger schedule the intended command?
3. Did the subsystem request motor output?
4. Did the controller receive power and a valid control signal?
5. Did the motor produce motion?
6. Did the mechanism jam or disconnect mechanically?

The symptom is at the end of the chain. The cause can be almost anywhere before it.

That distinction matters throughout this course. A visible failure is not automatically the location of the fault.

Your system map

Choose a real FRC robot you can inspect, a team robot photo with labeled components, or a supplied/simulated robot architecture. Identify at least:

• one source of electrical power;
• the main computing device;
• one communication path;
• two actuators;
• two sensors or feedback sources;
• one mechanism; and
• one place where software connects to hardware.

Draw arrows. Label what crosses each arrow: power, command, sensor data, or mechanical motion.

The goal is not artistic quality. The goal is to make dependencies visible.

Check your model

Your map is strong enough when another learner can answer these questions without guessing:

• What powers the mechanism?
• What software owns it?
• What device actually switches power to the motor?
• What feedback can confirm motion?
• Where would you inspect first if the mechanism stopped responding?

If those answers are unclear, the diagram is incomplete.

Common failure in thinking

Rookies often learn the robot as a vocabulary list: battery, roboRIO, Spark, encoder, gearbox. That helps with identification, but it does not explain behavior. Systems thinking begins when you can say what depends on what.

Keep your map. You will revise it in Unit 2 after we add the full architecture.