Logging

Both calls go at the top of the Robot constructor, which is empty on the branch. Logging then runs from the first loop to the last.

1import org.wpilib.driverstation.DriverStation;
2import org.wpilib.system.DataLogManager;
3 
4public Robot() {
5  DataLogManager.start();
6  DriverStation.startDataLog(DataLogManager.getLog());
7 
8  // Always-on bindings, if you add any, go below.
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 game piece goes through.

1import static org.wpilib.units.Units.Rotations;
2 
3import org.wpilib.telemetry.Telemetry;
4import org.wpilib.telemetry.TelemetryTable;
5 
6private void record() {
7  TelemetryTable table = Telemetry.getTable(getName());
8 
9  table.log("PositionRot", getPosition().in(Rotations));
10  table.log("TargetRot", getTargetPosition().in(Rotations));
11  table.log("AppliedVolts", motor.getMotorVoltage().getValueAsDouble());
12}

1import static org.wpilib.units.Units.RotationsPerSecond;
2 
3import org.wpilib.telemetry.Telemetry;
4import org.wpilib.telemetry.TelemetryTable;
5 
6private void record() {
7  TelemetryTable table = Telemetry.getTable(getName());
8 
9  table.log("VelocityRPS", getVelocity().in(RotationsPerSecond));
10  table.log("TargetRPS", getTargetVelocity().in(RotationsPerSecond));
11  table.log("AppliedVolts", motor.getMotorVoltage().getValueAsDouble());
12}

Nothing calls record yet. Register it once, as the last line of the ArmFlywheel constructor. The scheduler then runs it every loop while the robot has power. Add import org.wpilib.command3.Scheduler; with it.

1public Arm() {
2  // ... the pasted config, unchanged
3  motor.getConfigurator().apply(talonFXCfg);
4  Scheduler.getDefault().addPeriodic(() -> record());
5}

1public Flywheel() {
2  // ... the pasted config, unchanged
3  motor.getConfigurator().apply(talonFXCfg);
4  Scheduler.getDefault().addPeriodic(() -> record());
5}

Do not call record from inside a command instead. A command logs only while it runs, so the trace stops the moment a button comes up.

Whoever opens the log at an event may not have written the code. The name in the tree is all 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.
• Let the table do the grouping. Everything logged to the Arm table arrives together in the viewer, next to Flywheel and Drivetrain. Do not write the prefix into the signal name as well.
• One writer per fact. Two classes logging PositionRot to the same table give you a trace that flickers between them, and no way to tell which is which.
• 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 now, on a run whose answer you already know. Then the first log you open is not one you need in a hurry.

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 and expand NT:/Telemetry/Arm. Put PositionRot and TargetRot on one graph, and AppliedVolts on a second.
6. Open it in AdvantageScope and expand NT:/Telemetry/Flywheel. Put VelocityRPS and TargetRPS on one graph, and 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.

A trace that holds one value is not always a bug. Telemetry writes an entry only when the value changes, so an arm that is genuinely still records one sample and then nothing until it moves. The rest of the file tells you which you have. Every signal stopping at the same instant means the logging stopped. One flat signal among live ones means the thing it measures was flat.

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.