Debugging

Hook

The arm won’t go to 90°. It stops at around 60° every time.

You check the code. The logic looks right. You check the wiring. The motor is spinning. You check the sensor — and there it is. Someone plugged the encoder into port 2 instead of port 1. The robot is reading the wrong sensor.

Half the bugs in robot code aren’t in the code at all — they’re in the gap between what the code assumes and what the hardware is actually doing. Debugging is the skill of closing that gap systematically.

Core concept

Walk-through

The debugging process:

1. Describe the symptom precisely. “It doesn’t work” is not a bug report. “The arm stops at 60° when commanded to 90°, and the motor stops receiving power” is.

2. Form a hypothesis. What could cause that symptom? List two or three candidates.

3. Gather evidence. Log the relevant values. Don’t change code yet.

4. Rule out hypotheses one at a time. Start with the most likely or easiest to verify.

5. Fix, verify, and commit. Don’t “fix” multiple things at once — you won’t know which one worked.

Tool 1: System.out.println

The fastest way to see what a variable actually contains at runtime:

void periodic() {
    double target = 90.0;
    double current = encoder.getAngle();
    double error = target - current;
    System.out.println("target=" + target + " current=" + current + " error=" + error);
    // …
}

Run the robot and watch the Driver Station console. If current is stuck at 60.0 while the arm is clearly moving, the encoder is wrong. If error is always positive but the motor doesn’t run, check the motor output logic.

Tool 2: AdvantageScope

SmartDashboard and Shuffleboard push values to the network you can watch in real time. AdvantageScope gives you graphs, timelines, and replays.

SmartDashboard.putNumber("Arm/current", encoder.getAngle());
SmartDashboard.putNumber("Arm/target",  targetAngle);
SmartDashboard.putNumber("Arm/error",   error);
SmartDashboard.putBoolean("Arm/atTarget", Math.abs(error) < 2.0);

Rule of thumb: log more than you think you need. Storage is cheap; a mystery crash at competition is not.

Classifying bugs:

Interactive demo

A student’s arm code has a bug. Trace through and spot it:

Try it yourself

error = target - current;  // 90 - 95 = -5
if (error > 0) motorPower = +0.4;
motor.set(motorPower);

Key takeaways

• Debugging is a systematic process: describe, hypothesize, gather evidence, rule out, fix.
• Print the values you assume are correct. Your assumption is often wrong.
• Log target, current, and error for every control loop — always.
• Classify the bug first: is it hardware, wiring, sensor direction, units, or logic?
• Fix one thing at a time. Changing two things means you don’t know which one worked.

Common confusions

“I added prints but the console is too fast to read.” Add a counter and only print every 50 cycles: if (count++ % 50 == 0) System.out.println(...). Or use SmartDashboard — it throttles automatically.

“The bug disappears when I add print statements.” Timing-sensitive bugs (race conditions) can shift when you add logging. This usually means there’s a threading issue or a sensor read that takes longer than you think.

Challenge

What’s next

You’ve now covered the full foundation: programs, state, decisions, loops, functions, and debugging. Robot Code Lesson 01 is next — how WPILib structures a robot program and where your code fits into the framework.