Driver Station Logs Lesson

Driver Station Logs: The Robot's Voice

The Driver Station logs are a real-time record of what your robot is thinking. They are your window into the robot's brain and the first place you should look whenever something isn't working as expected.

The Three Voices of the Robot

The robot uses different ways to speak to us through the logs. Understanding the difference is crucial for effective troubleshooting.

1. Standard Output (`System.out.println`)

This is the simplest form of logging. Any `System.out.println()` statement in your code is sent directly to the Driver Station logs as an `INFO` message. This is great for temporary, real-time debugging.

// In a command's execute() method:
System.out.println("Arm Angle: " + m_arm.getAngle());

2. Driver Station Messages

WPILib provides specific methods for sending more formal, color-coded messages. These are more effective for permanent debugging messages you might leave in your code.

`DriverStation.reportError(...)`: For major, unexpected problems that prevent code from running correctly. Shows up as red.
`DriverStation.reportWarning(...)`: For minor issues that don't crash the code but should be investigated. Shows up as yellow/orange.

if (isSensorDisconnected) {
    DriverStation.reportWarning("Arm encoder is disconnected!");
}

The Stack Trace: Your Troubleshooting Map

This is the most important log entry you will ever see. When a runtime error (an "exception") occurs, the robot prints a detailed message called a stack trace. It tells you exactly where in your code the error happened.

How to Read a Stack Trace

A stack trace can look intimidating, but it's a map that leads you directly to the bug. To find the problem, you must read the trace from the bottom up until you find the first line that references your team's code.


Error at frc.robot.subsystems.IntakeSubsystem.run(IntakeSubsystem.java:42): 
java.lang.NullPointerException: Cannot invoke "edu.wpi.first.wpilibj.motorcontrol.Spark.set(double)" because "this.m_intakeMotor" is null
    at frc.robot.subsystems.IntakeSubsystem.run(IntakeSubsystem.java:42)
    at frc.robot.commands.IntakeCommand.execute(IntakeCommand.java:25)
    at edu.wpi.first.wpilibj2.command.CommandScheduler.run(CommandScheduler.java:225)
    ...
    at frc.robot.Robot.robotPeriodic(Robot.java:30)
    ...
    at frc.robot.Main.main(Main.java:23)

Decoding the Clues

The "What": The first line tells you the type of error. Here, it's a `NullPointerException`.
The "Why": The message explains the cause: we tried to call the `.set()` method on an `m_intakeMotor` variable that was `null`.
The "Where": Reading from the bottom, the first line that starts with `frc.robot` is `at frc.robot.commands.IntakeCommand.execute(IntakeCommand.java:25)`. This is the most likely source of the bug! It tells you the error occurred in the `execute` method of your `IntakeCommand`, on line 25.

Test Your Knowledge

Question: When a `NullPointerException` occurs and a stack trace is printed to the Driver Station logs, what is the most effective first step to finding the bug?