[Greg McKaskle]

I debugged a lagged robot at a scrimmage yesterday. We didn't get to the bottom of all the problems, but here is one easy thing to look for. The Watchdog function to delay and feed had a 1000 wired to it. The student read it as delaying 1000 ms. But of course the units to that function aren't ms, but s. So that explained why their solenoid didn't seem to run more than once.

Anyway, now is a great time of the season to do code reviews. Go screen by screen explaining the code to another person. Add comments to the code where you find yourself guessing, guessing again, and correcting yourself because you cannot even explain your own code without comments. Add comments when you find that what you are saying verbally is way more than what is in the code and you are explaining how this piece on another screen does something that this code depends on, etc.

Finally, if you are the other person with the code being read to them, ask lots of questions such as what units is that parameter or output in? How does that value get initialized? Let's go look at the configuration of that I/O and see if it matches how you are reading it. If what they said doesn't seem to match the logic or math in the code, ask them to explain it again with less hand-waving.

It is surprising how many issues you will find just by being forced to proofread the code for what is there versus what you meant to put there. With some practice, you'll find that you hardly need the other person there. You can learn to read the code with new eyes as if explaining it to another person, and you'll find yourself asking some of those same questions and fixing bugs without having to go through hours of robot observation.

Greg McKaskle