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.

Three signals are enough for a first log, and they are read in pairs. Velocity against target says whether the wheel is up to speed. Voltage next to either one says what the spin-up cost, and what it takes to hold that speed once a note goes through.

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}

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

The three publishers are fields, built once when the armflywheel 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 WPILib: Hardware Sim Robot Code and enable the OpMode that moves the arm. Send it to a target, let it settle, then send it back.
2. Start the program with WPILib: Hardware Sim Robot Code and enable the OpMode that spins the flywheel. Take it to full, hold it there long enough to settle, then let it coast down.
3. Disable, then stop the program, so the end of the file gets written out.
4. Find the newest .wpilog. The program ran on your laptop, so the file is in the project's logs folder.
5. Open it in AdvantageScope. Put Arm/PositionRot and Arm/TargetRot on one graph, and Arm/AppliedVolts on a second.
6. Open it in AdvantageScope. Put Flywheel/VelocityRPS and Flywheel/TargetRPS on one graph, and Flywheel/AppliedVolts on a second.
7. Line the enabled interval up against the motion. Position should move only while enabled, and voltage should drop off once the arm arrives.
8. Line the enabled interval up against the motion. Velocity should climb only while enabled, and voltage should settle to a smaller steady number once the wheel is at speed.

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

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