Autonomous debugging

Reduce the failing routine#

Run only the first movement that fails. Check whether it starts, moves in the correct direction, reaches the target, and reports success. A later action can look wrong simply because an earlier movement timed out.

Keep the same starting mark and orientation between trials. Change one parameter at a time and record both successes and failures. An extra wait can hide a race or a settling problem without identifying it.

Display raw sensor readings#

This stationary test prints the drive encoders and inertial heading for ten seconds. Push or rotate the robot by hand and verify what changes. Trailing spaces clear digits from a previously longer value.

Screen output should be slower than the control loop. For longer tests, record timestamped values through a console or a logging system appropriate to the toolchain. The linked PROS debugging page illustrates serial diagnostics; PROS terminal commands do not apply to VEXcode.

void showDriveReadings() {
  Brain.Screen.setCursor(1, 1);
  Brain.Screen.print("left %.1f deg       ", leftDrive.position(degrees));
  Brain.Screen.setCursor(2, 1);
  Brain.Screen.print("right %.1f deg      ", rightDrive.position(degrees));
  Brain.Screen.setCursor(3, 1);
  Brain.Screen.print("heading %.1f deg    ", imu.heading(degrees));
  Brain.Screen.setCursor(4, 1);
  Brain.Screen.print("ready %d            ", sensorsReady);
}
void autonomous() {
  stopDrive();
  timer elapsed;
  elapsed.reset();
  while (elapsed.time(msec) < 10000) {
    showDriveReadings();
    wait(100, msec);
  }
}

References: VEX Robotics: Brain Screen — C++ API (opens in a new tab) · PROS: Debugging (opens in a new tab)

Match a symptom to a check#

References: LemLib: Configuration (opens in a new tab) · VEX Robotics: Motor and Motor Group — C++ API (opens in a new tab)

Record useful results#

For each trial, record the starting pose, requested movement, final measurement, elapsed time, and success/timeout result. Add battery state and relevant mechanical changes when they could explain a difference.

For a wall reset, log raw range, heading, candidate position, and whether the reset was accepted. For PID, log error and output together. A final position alone cannot tell you whether the robot overshot, stalled, or oscillated.

Before a competition run#

1. Verify the correct program slot and autonomous routine.
2. Check sensor connections, drive and mechanism directions, and the starting position.
3. Finish inertial calibration while the robot is stationary.
4. Reset pose and any mechanism reference at the expected physical starting configuration.
5. Test with the normal mechanism load and a realistic battery state.
6. Confirm timeouts stop motors and prevent dependent actions from continuing after a failed movement.