Logging

Both calls go at the top of the Robot constructor, ahead of the mechanisms. Anything that happens during startup then lands in the same file as the rest of the run.

1import org.wpilib.driverstation.DriverStation;
2import org.wpilib.system.DataLogManager;
3 
4public Robot() {
5  DataLogManager.start();
6  DriverStation.startDataLog(DataLogManager.getLog());
7 
8  // Construct mechanisms and global bindings after logging is active.
9}

DataLogManager.start() opens the file and captures NetworkTables values and console output. DriverStation.startDataLog adds what NetworkTables never sees: enabled state, robot mode, which OpMode is running, and joystick positions. Skip the second call and you get numbers with no way to tell whether the robot was enabled when they happened.

Leave logging on in every mode and every build. A special logging build, deployed after the match that went wrong, records the next failure instead of the one you are trying to explain.

Three signals are enough for a first log, and they are read in pairs. Position against target says whether the arm arrived. Voltage next to either one says what the trip cost, and whether the motor was loaded the whole way.

1import org.wpilib.networktables.DoublePublisher;
2import org.wpilib.networktables.NetworkTableInstance;
3 
4private final DoublePublisher positionLog =
5    NetworkTableInstance.getDefault().getDoubleTopic("Arm/PositionRot").publish();
6private final DoublePublisher targetLog =
7    NetworkTableInstance.getDefault().getDoubleTopic("Arm/TargetRot").publish();
8private final DoublePublisher voltageLog =
9    NetworkTableInstance.getDefault().getDoubleTopic("Arm/AppliedVolts").publish();
10 
11private void record(double position, double target, double volts) {
12  positionLog.set(position);
13  targetLog.set(target);
14  voltageLog.set(volts);
15}

The three publishers are fields, built once when the arm is built. Build one inside a loop and the code opens a fresh handle fifty times a second, closing none of them.

Call record from whatever already refreshes those values: the runRepeatedly(...) command that holds the target, or a background task added with Scheduler.getDefault().addPeriodic(...). The command publishes only while it runs. The background task publishes for as long as the robot has power, and neither one is a new loop of yours.

The name is the whole interface to a log. Six weeks from now, at an event, someone who did not write this code will be reading it. The name in the tree is all the documentation they get.

• Put the unit in the name. Arm/Position makes the reader guess. Arm/PositionRot can share a project with degrees and radians without a collision.
• Group with a slash. Everything under Arm/ arrives together in the viewer, next to Flywheel/ and Drivetrain/.
• One publisher per fact. Two classes publishing Arm/PositionRot give you a trace that flickers between two sources, with nothing to say which one you are reading.
• Add a signal when you can name the question it answers. A hundred signals nobody plots is slower to search than twelve that get used.

Rename a signal later and the code still compiles. Every saved layout and every script that read the old name stops working. Spend the extra minute now.

Do this once, here, on a run whose answer you already know. The first log you ever open should not be one you need at eleven at night on an event floor.

1. Start the program with ./gradlew simulateJava and enable the OpMode that moves the arm. Send it to a target, let it settle, then send it back.
2. Disable, then stop the program, so the end of the file gets written out.
3. Find the newest .wpilog. The program ran on your laptop, so the file is in the project's logs folder.
4. Open it in AdvantageScope. Put Arm/PositionRot and Arm/TargetRot on one graph, and Arm/AppliedVolts on a second.
5. Line the enabled interval up against the motion. Position should move only while enabled, and voltage should drop off once the arm arrives.

Three things go wrong the first time, and they look like this.

Empty tree

Nothing published

The file exists and holds no Arm/ entries. Either the two constructor lines never ran, or record is never called from a loop.

Flat line

Stale signal

The trace freezes partway through and holds one value. The publishing code sits inside a command that finished, so nothing has called set since.

Wrong scale

Bad units

The shape looks right and the numbers are off by the gear ratio. Fix SensorToMechanismRatio on the motor, then log the run again.

You are finished when a file on your own laptop can tell you what the arm did, with nobody in the room narrating it.

Keep the file. Swerve calibration in Workshop 3 pulls a wheel radius and four module angles out of logs that look like this one.