๐Ÿ’ป Programming ยท Engineer ยท Intermediate

Debugging Techniques for PROS

Five methods in order from easiest to most powerful. Open this when something is broken and you don't know why.

Debugging order: Start with Method 1. Only move to the next method if the previous one doesn't isolate the problem. Most bugs are caught by Brain screen or terminal output.
1 Brain Screen printf
Best for: seeing variable state in real time, no computer needed

Print any value to the Brain's 240ร—272px LCD while the robot runs. Perfect for checking sensor reads, variable values, and task state between matches.

// Clear screen + print multiple values
pros::lcd::initialize();    // in initialize()

// Anywhere in your code:
pros::lcd::set_text(1, "IMU: " + std::to_string(chassis.imu.get_heading()));
pros::lcd::set_text(2, "Motor temp: " + std::to_string(left_motors[0].get_temperature()));
pros::lcd::set_text(3, "Intake on: " + std::to_string(intakeOn));
2 VS Code Terminal Output
Best for: detailed logs, printing in sequences, post-run analysis with the cable attached

PROS routes printf() over USB to your VS Code terminal. Run pros terminal in the integrated terminal while the robot is connected.

// Print formatted output to terminal
printf("[auton] segment 2 start โ€” heading: %.2f\n", chassis.imu.get_heading());
printf("[intake] speed=%d temp=%.1f\n", intake.get_actual_velocity(), intake.get_temperature());

// Structured log: timestamp + label + value
printf("[%dms] motor_temp %.1f\n", pros::millis(), left_motors[0].get_temperature());
// Debug wrapper โ€” removes all prints in release build
#define DEBUG 1
#ifdef DEBUG
  #define LOG(fmt, ...) printf(fmt, ##__VA_ARGS__)
#else
  #define LOG(fmt, ...)
#endif
// Use LOG() instead of printf() everywhere
LOG("[auton] turn complete โ€” actual: %.2f\n", chassis.imu.get_heading());
3 LED Indicator Patterns
Best for: state machine debugging, diagnosing which branch code is in, no screen needed

When you can't read the Brain screen (robot is far away, or screen is obstructed), use the V5 Brain's built-in status LED or an indicator LED on a 3-wire port to show state.

// Flash an LED N times to indicate state
pros::ADIDigitalOut led('A');

void ledFlash(int n) {
  for (int i = 0; i < n; i++) {
    led.set_value(1); pros::delay(150);
    led.set_value(0); pros::delay(150);
  }
  pros::delay(400); // gap between sequences
}

// Flash 1 = step 1 reached, flash 2 = step 2, etc.
ledFlash(1); chassis.pid_drive_set(24, 110); chassis.pid_wait();
ledFlash(2); chassis.pid_turn_set(90, 90); chassis.pid_wait();
4 SD Card Data Logging
Best for: post-run analysis, logging during untethered runs, building a data record across sessions

Write data to a CSV on the Brain's microSD card. Insert a microSD into the Brain, then read the file on your laptop after the run.

#include <fstream>

void startLog() {
  std::ofstream log("/usd/run_log.csv", std::ios::app);
  log << "time,heading,left_vel,right_vel,temp\n";
  log.close();
}

void logRow() {
  std::ofstream log("/usd/run_log.csv", std::ios::app);
  log << pros::millis() << ","
      << chassis.imu.get_heading() << ","
      << chassis.left_motors[0].get_actual_velocity() << ","
      << chassis.right_motors[0].get_actual_velocity() << ","
      << chassis.left_motors[0].get_temperature() << "\n";
  log.close();
}
// Call logRow() every 50ms in a task for a full run record
5 pros monitor (Real-Time Dashboard)
Best for: watching motor states, port health, current draw in real time from VS Code

PROS ships a terminal dashboard that shows motor ports, temperatures, currents, and sensor values updated live. Run it while connected via USB.

# In VS Code integrated terminal
pros terminal
# Separate window for motor dashboard
pros monitor
๐Ÿ“‹ Which Method to Use
SituationMethod
No laptop, need to see sensor values now1 โ€” Brain screen
Auton fails at a specific step โ€” want to know which2 โ€” Terminal printf with labels
Robot is moving and you can't read the screen3 โ€” LED flash patterns
Intermittent failure, hard to reproduce, want to analyze after4 โ€” SD card log
Motor overheating or brownout โ€” not sure which port5 โ€” pros monitor
⚙ STEM Highlight Computer Science: Binary Search Debugging & Isolation Principles
Systematic debugging applies binary search as an algorithmic strategy: eliminate half the possible causes with each test, reducing worst-case debugging from O(n) to O(log n). The same principle applies to hardware-software systems — first isolate whether the failure is mechanical, electrical, or software; then binary search within that layer. Each isolation step removes an entire class of hypotheses without testing them individually.
🎤 Interview line: “We apply binary search to every debugging session. When auton fails, we first run a straight-line drive test — if that works, the bug is in higher-level code. We then halve the remaining autonomous commands and test. This approach cuts debugging time by 60% compared to checking each line sequentially. It is the same algorithm used in professional software debugging tools.”
Your robot drives straight in driver control but drifts left in autonomous. Same motors, same code logic. What is the most likely cause?
⬛ A motor is weaker on the left side — replace it
⬛ The autonomous initializes before the IMU finishes calibrating, so heading correction references a wrong baseline
⬛ The field slopes slightly to the left
📝
Notebook entry tip: Build & Program — Orange slide — Write a debugging session entry for any bug that takes more than 15 minutes to resolve: symptom, isolation steps, root cause, fix applied, and test that confirmed it. A debugging log with 5+ entries shows systematic software engineering — the same discipline professional developers demonstrate. Include before/after terminal output or constants.
← ALL GUIDES