Robot.java

1package first.robot;
2 
3import first.robot.mechanisms.Arm;
4import first.robot.mechanisms.Flywheel;
5import org.wpilib.command3.Scheduler;
6import org.wpilib.framework.OpModeRobot;
7 
8public class Robot extends OpModeRobot {
9  // One shared object for each physical mechanism.
10  public final Arm arm = new Arm();
11  public final Flywheel flywheel = new Flywheel();
12 
13  public Robot() {
14    // Start course-wide services and add truly global bindings here.
15  }
16 
17  @Override
18  public void robotPeriodic() {
19    Scheduler.getDefault().run();
20  }
21}

Two fields and one method. The fields are public so an OpMode handed a Robot can reach robot.arm directly. They are final so that one arm object serves the whole match.

A second new Arm() elsewhere in the project does not fail. It compiles and it runs. Now two objects configure the same motor, and the scheduler counts them as unrelated mechanisms, so two commands can drive one gearbox at once. Nothing warns you at build time. You find out when the arm fights itself on the bench.

Field initializers run before the constructor body, so both mechanisms already exist by the first line of Robot(). robotPeriodic() begins after that constructor returns, and it keeps being called in every mode, including while the robot is disabled.

The framework calls robotPeriodic() every 20 milliseconds, 50 times a second, for as long as the robot has power. The single line inside it gives the scheduler one pass. It checks the triggers, queues a default command for any mechanism with nothing to do, and gives every running command one step.

Delete that line and the build still passes. The mechanisms are still built. Nothing in the project ever moves again.

The middle row is the common one, and it hides well. A team debugging teleop adds a scheduler call to the teleop class, teleop starts working, and autonomous quietly stops advancing until the next match.

The constructor runs once, at startup, after the mechanism fields exist and before any mode is selected. It is the only place in the project that can set something up for every mode at once. Four kinds of thing earn a spot in it.

• Logging. DataLogManager.start() and the DriverStation log are two lines, and Logging covers what they record.
• A service that two mechanisms share. Build it here, then hand the same object to both of them.
• A safety binding that has to hold in every mode, not only in the one mode where a driver would notice it missing.
• Per-loop work that is not a command, registered with Scheduler.getDefault().addPeriodic(...). Registering it costs one line, and the work itself happens on later loops.

Keep the constructor short. Startup waits on it, and no command runs and no motor moves until it returns. Reading a file or waiting on a camera here delays the whole robot.

Other things get put in here by mistake, and each one already has a home. Driver buttons go in the teleop class. An autonomous routine goes in its own @Autonomous class. Motor IDs, inversions, and gains go in the mechanism. A one-off calibration control goes in a @Utility class.

The reason is the same every time. A binding made in this constructor is live in every mode. Put a calibration routine on a driver button and someone can start it mid-match.

Where a new field goes comes down to lifetime. Ask how long the object has to stay alive, and the answer names the file.

The controller is the field people get wrong. Both the controller object and its bindings belong to the teleop class. Bound in the Robot constructor instead, the same button still fires while an autonomous routine is running.

There is no button to press for this lesson, so prove the lifetime instead. Two print lines and one mode switch show it.

1. Run ./gradlew build and wait for BUILD SUCCESSFUL.
2. Search the whole project for getDefault().run. Exactly one hit, inside robotPeriodic(). Search for new Arm( and get one hit as well.
3. Add System.out.println("Robot built"); as the first line of the Robot constructor, and System.out.println("Teleop built"); as the first line of your teleop constructor.
4. Start the simulator with ./gradlew simulateJava. Watch the console while you pick teleop, switch to another mode, and pick teleop again.
5. Delete both print lines once the counts match.

A second Robot built line means something other than the framework is constructing a Robot. Two hits on new Arm( mean the arm is being built somewhere it should be borrowed instead. Fix that before Mechanisms, where every command you write reaches the hardware through these fields.