From Project to Robot Loop

WPILib is the standard software library used by FRC teams to write robot code. It provides access to the control system, sensors, motor controllers, Driver Station state, simulation tools, and higher-level robot patterns.

The important idea is not memorizing every class. It is understanding when code runs and who owns hardware behavior.

A robot program lives through modes

Competition robots operate in states such as disabled, autonomous, and teleoperated. Your code must behave correctly when the robot moves between them.

A simple mental model is:

startup
  ↓
disabled
  ↓
autonomous
  ↓
disabled
  ↓
teleop
  ↓
disabled

Real event flow contains more detail, but the state transitions matter.

Software that assumes “the robot just starts driving” ignores the control system around it.

Hardware objects represent real devices

Robot code often constructs software objects that correspond to hardware:

• motor controllers;
• encoders;
• gyros;
• digital inputs;
• pneumatics;
• cameras;
• dashboards.

Configuration errors can make valid code control the wrong device.

That is why IDs, ports, inversion, units, and subsystem ownership are architecture information, not minor setup details.

Minimal behavior example

This pseudocode shows the layers without tying the lesson to one vendor API:

if (driverWantsIntake) {
    intakeMotor.set(0.55);
} else {
    intakeMotor.set(0.0);
}

The syntax is not the interesting part.

The important questions are:

• Where did driverWantsIntake come from?
• Which physical motor does intakeMotor represent?
• What does 0.55 mean in this control context?
• What stops the mechanism?
• What evidence confirms the game piece actually moved?

Simulation changes the workflow

WPILib supports simulation for many robot-programming workflows. Simulation does not reproduce every electrical or mechanical detail, but it lets you test structure and state transitions without risking a physical robot.

A disciplined programming loop is:

change code
→ build
→ simulate or run controlled test
→ observe logs/state
→ compare with expected behavior
→ change one thing

Save a working point before major changes.

Project map

Open an FRC project, an example project, or a supplied code sample.

Identify:

• main robot entry point;
• where hardware objects are created;
• where operator controls are bound;
• one subsystem or mechanism class;
• one autonomous entry point;
• one place where telemetry/logging is produced.

Create a one-page software map showing those relationships.

Failure mode: code compiles, therefore robot works

Compilation proves the language and type rules were satisfied. It does not prove:

• the right device ID was used;
• motor direction is correct;
• units match;
• the mechanism is safe;
• logic schedules at the right time;
• sensors are calibrated;
• the robot behaves under load.

Build success is one piece of evidence. Keep going.