Programming · Debugging
Debug faster, lose fewer matches
Telemetry, Logcat, crash triage, and timing checks to keep OpModes stable.
What this is
- Minimal toolkit to see what the robot and code are doing.
- Steps to debug crashes and timing stalls.
- Habits that prevent surprises on the field.
When you need it
- OpMode stops responding or exits unexpectedly.
- Robot lags or input feels delayed.
- Need to diagnose field-only issues quickly.
How it works
- Telemetry: send key values each loop (state, powers, sensor readings, loop time).
- Logcat: capture stack traces; filter by your package; look for fatal exceptions.
- Timing: measure loop duration; avoid blocking calls (sleep inside loop) and heavy allocations.
- Recovery: guard hardware access with try/catch; fail soft with reduced functionality when possible.
Common mistakes
- Too much telemetry per loop → bandwidth lag; send only essentials.
- Blocking in loop (sleep, network, vision) → watchdog resets or sluggish control.
- Ignoring stack traces; rerunning without reading the crash log.
- No null checks on hardware map or sensor reads.
How to test it
- Print loop time; keep it comfortably under 20ms for responsive TeleOp.
- Force a sensor disconnect to verify code fails gracefully.
- Run vision + drive; ensure control stays responsive and no ANRs occur.
- Review Logcat after a match run; fix any warnings/errors you see.
Related problems
- OpMode crash on start → check init code, hardware names, and annotations.
- Laggy controls → reduce telemetry, move heavy work off the main loop.
- Random stops → watch battery sag and brownout logs; secure wiring.