Writing sensor values, PID errors, and motor data to an SD card lets you graph exactly what your robot did during a run — turning guesswork into evidence. The same technique used in aerospace, automotive, and robotics engineering.
1
Why Log
2
SD Setup
3
Code
// Section 01
Why Data Logging Beats Guessing
When PID tuning is not working, most teams adjust kP up or down based on what the robot looked like. Data logging replaces that with evidence — a graph of exactly what the motor did and when.
💡
The classic problem: you watch your robot overshoot during autonomous and say “kP is too high.” But is it overshoot from P, or windup from I, or oscillation from D being too low? Without data, you are guessing. With a logged CSV of position vs time, you can see exactly which phase of the PID response has the problem.
What to Log
PID tuning — target position, actual position, error, PID output every 10ms
Autonomous debugging — timestamp, X/Y from odometry or GPS, heading, each movement command
Motor health — temperature, current draw, velocity at regular intervals during Skills runs
Sensor validation — raw sensor readings before and after mechanism actions to verify sensors are reliable
✅
Logged data is notebook evidence. A graph of PID response curves with annotations showing tuning decisions is excellent Design Award documentation. It demonstrates quantitative testing methodology — exactly what judges look for.
1 / 3
// Section 02
SD Card Setup
Use a microSD card, formatted as FAT32 (not exFAT). Most standard SD cards work. 1GB or larger is more than enough.
Insert into the microSD slot on the front of the V5 Brain — the small slot below the USB port.
PROS provides pros::usd namespace functions for file I/O. The SD card appears as a filesystem root at /usd/.
⚠️
Format as FAT32, not exFAT. The V5 Brain does not support exFAT. If your SD card was formatted by a modern Windows or Mac machine, it may have been set to exFAT by default. Use the SD Card Formatter tool (sdcard.org) to reformat as FAT32 before use.
2 / 3
// Section 03
Complete Logging Implementation
src/main.cpp — PID data logger
// Open a CSV file at the start of autonomousFILE* logFile = nullptr;
voidlogOpen(constchar* name) {
logFile = fopen(name, "w");
if (logFile) {
fprintf(logFile, "time_ms,target,actual,error,output\n");
}
}
voidlogRow(int target, int actual, int error, double output) {
if (!logFile) return;
fprintf(logFile, "%lu,%d,%d,%d,%.3f\n",
pros::millis(), target, actual, error, output);
}
voidlogClose() {
if (logFile) { fclose(logFile); logFile = nullptr; }
}
// Usage in autonomous:voidautonomous() {
logOpen("/usd/run_data.csv");
chassis.pid_drive_set(24, 110);
while (chassis.drive_pid_task_running()) {
logRow(
chassis.drive_sensor_left(), // target (approx)
chassis.drive_sensor_right(), // actual
(int)chassis.drive_error(),
chassis.drive_output()
);
pros::delay(10);
}
logClose();
}
After the run, remove the SD card, open run_data.csv in Excel or Google Sheets, and insert a line chart. You will see exactly what the PID controller did over time — acceleration, overshoot, settling, oscillation — in precise quantitative terms.
✅
Name files with run numbers:/usd/run_001.csv, /usd/run_002.csv. This way you keep multiple run logs without overwriting, and can compare tuning changes between runs.
Data logging transforms robot tuning from trial-and-error into empirical engineering. When you graph PID error over time, the shape tells you exactly what to fix: exponential decay means kP is right but kI is needed; oscillating decay means kD is too low; steady-state offset means kI is missing entirely. This is diagnostic reasoning from data — the same method scientists use to distinguish hypotheses. A graph in your notebook with annotated observations is direct evidence of scientific thinking.
🎤 Interview line: “We use data logging to practice empirical iteration. After each PID change, we log motor current, velocity, and position error to the SD card and graph them. The shape of the error curve tells us which term to adjust — this is data-driven diagnosis, not guessing.”
🔬 Check for Understanding
Your data log shows the robot consistently reaching 34 inches on a 36-inch drive command, with the error flattening to a constant 2-inch offset. Which PID term most likely needs adjustment?
kP — the proportional term is too low
kD — the derivative term is causing premature stopping
kI — a steady-state constant error that kP cannot eliminate is exactly what the integral term is designed to correct
The drive distance value itself — add 2 inches to your command