Lesson 39: Robot Project Structure

A full robot project grows quickly. Project structure is how you keep that growth from turning into a pile of mystery files.

Common Folders and Classes

Teams organize projects differently, but a readable Java robot project often has these ideas:

• Robot: the main entry point.
• RobotContainer: creates subsystems, commands, and button bindings.
• subsystems: mechanism classes that own hardware.
• commands: reusable robot actions.
• Constants or Wiring: ports, CAN IDs, and calibration values.
• util: small helpers that do not belong to one subsystem.

One Owner Per Device

Each motor, solenoid, or sensor should have one owner. If three classes can set the same motor, debugging becomes guesswork. A subsystem should own the hardware, and other code should call methods on that subsystem.

Split Constants by Meaning

Putting every number in one giant list gets hard to read. Group constants by subsystem or by purpose.

public class DriveConstants {
    public static final int LEFT_MOTOR_ID = 1;
    public static final int RIGHT_MOTOR_ID = 2;
    public static final double MAX_SPEED = 0.8;
}

Keep Names Boring and Clear

A good file name should tell a new student what lives inside. Names like Shooter, RunIntake, and DriveConstants are better than names that only make sense to the original author.

Practice

Draw the folder structure for your next robot before writing code. Then write down which class owns each motor and sensor.