"My Code's Crashing" - A Robot Debugging Story

An anecdote about software debugging and incorrect assumptions
2 min read

As some readers might know - I’m a mentor for a local high school robotics team. This past season, I had one team come to me with a problem that I thought was interesting enough to share.

The Problem

They were working on an autonomous program for their robot in which they performed some tasks as part of the 2023-2024 Vex Game, and then would elevate their robot by hanging from a horizontal bar mounted on the field. But each time they ran it - the code would “crash” and the robot would fall back down.

They ran the program for me - and sure enough, the code ran all the way through, and the robot pulled itself on the hanging bar. Then the program stopped, and the robot fell back down as the power was removed from the motors. They talked me and another mentor through the code, and we couldn’t see anything wrong. They tried rerunning it, and it “crashed” in the same spot.

We asked: what if it’s not a software problem? What if there’s some sort of hardware problem?

The Cause

As they discovered - the mechanism that held the robot up worked great. Then, when the robot was elevated, some wires would get caught in between it and the robot’s microcontroller. Those wires would then push the microcontroller’s power button, exiting the program. Once they realized this and rewired things, their program worked correctly.


The lesson here is that sometimes if you have a problem that just isn’t making sense, check your assumptions. If your base assumptions about the problem are incorrect, any conclusions you draw will be incorrect.

In this case, the assumption was that the code was crashing - when in reality the code was exiting itself by way of accidently pressing the exit button on the microcontroller.

Change Log

  • 6/12/2024 - Initial Revision

Found a typo or technical problem? file an issue!