Software Gotchas: Inverted Drives, Scheduler Stalls, and Reading the RioLog
The handful of code mistakes that break nearly every rookie's first program, and how to read the logs that reveal them.
Sign in to track progress, earn XP, and save lessons.
Most rookie software bugs are not subtle algorithm errors — they are a short list of the same gotchas, repeated every year. Recognize them on sight.
1. The robot spins instead of driving straight. One side is not inverted. Your two gearboxes face opposite directions, so a positive command drives them apart. Call setInverted(true) on one side (usually the right). If the robot drives backward when you push forward, you negated the wrong stick — remember Xbox stick-forward is negative Y, so arcadeDrive wants -getLeftY().
2. The robot looks dead but Robot Code is green. In command-based, you forgot CommandScheduler.getInstance().run() in robotPeriodic(). Without it, the scheduler never ticks — no default commands, no button bindings, nothing. This is the single most common command-based bug.
3. A mechanism fires once and never again, or a command never ends. Your command has no isFinished() end condition, or an autonomous step lacks withTimeout. A command that never finishes holds its subsystem forever and blocks every later command that requires it. Either return true from isFinished() when done, or wrap it in .withTimeout(seconds).
4. 'Loop time overrun' warnings. Your periodic code is taking longer than the 20ms loop. The usual culprits: System.out.println spam every loop, or blocking calls. Print sparingly and move heavy work out of the periodic loop.
Read the RioLog like a pro. The RioLog (or Driver Station console) is your primary debugger. After every deploy, watch for 'Robot program starting'. A Java stack trace there means an uncaught exception — read the top line of the trace for the exception type (e.g. NullPointerException) and the line number in your file, not WPILib's. A NullPointerException in your constructor often means a device failed to construct (sometimes a CAN ID typo) and your code crashed before teleop.
Instrument with telemetry. Push values to NetworkTables and watch them live in Glass or AdvantageScope — both are programmer debugging tools (not driver dashboards). Plot a stick value, a motor output, and a sensor reading on a graph; if the stick moves but the output is flat, you have isolated the bug to your command logic rather than wiring. AdvantageScope can also replay a saved WPILib data log after a match so you can debug a problem you couldn't reproduce in the pit. Logging beats guessing every time.
Key takeaways
- Robot spins not drives = a drive side needs setInverted; drives backward = wrong stick sign (Xbox forward is negative Y)
- Robot dead but code green = missing CommandScheduler.getInstance().run() in robotPeriodic
- Read the RioLog top stack-trace line for the exception type and YOUR file's line number; use Glass/AdvantageScope to plot stick vs output and isolate the bug
Lesson quiz
RequiredAnswer all 3 questions correctly to complete this lesson.
1.Your tank/differential drivetrain spins in a circle instead of driving straight. What is the typical software fix?
2.In the WPILib command-based framework, what happens when you schedule a command that requires a subsystem already in use by a non-interruptible command?
3.Which tool lets you view print statements and stack traces streamed from the robot program to help debug software gotchas?
Answer every question to submit.