|
Re: Programming goofs!
Oh, my team had a terrible goof this year. Our autonomous is based off of distance data from four encoders, one on each wheel. Our robot uses mecanum wheels, so we needed to write our own method for calculating the distance traveled based on each of the individual wheels. We also run a PID loop on each of our wheels to control the RPM at which each wheel turns. We often had to switch between speed control mode using PID loops and pure voltage mode, so one of our programmers decided to modify the code to allow easy switching from speed control mode and voltage mode using a boolean. However this code was written between bag and tag day and our first regional (NYC regional), so the code was untested.
When we got to the NYC regional, we found that that code was bad, so we removed it hastily. We were being stupid and decided to revert the changes manually rather than just reverting automatically using our version control system. So we missed a couple lines. First, we forgot to remove the declaration of the boolean, but deleted its assignment to a value. So now we had an uninitialized variable in our code. But then it turned out that other critical methods checked that boolean (including the method that gets the distance the robot has traveled). Those conditionals should have been removed, but since we were at competition and were time-constrained, we left those in. So that function would check an uninitialized variable, and therefore always return zero as the distance. Which means that while we thought that the robot was driving a defined number of inches, it would always drive forward until our timeout time of 6 or so seconds.
In short, what we thought was distance-based auton turned out to be time-based auton. We started out telling the robot to drive 192 inches. This wasn't enough, so we lowered it a bit. And a bit more. However that number actually didn't do anything; the robot would always just drive for 6 seconds and stop. By the time we were down to 175 inches at the end of our second regional (Hartford), we knew that something was up. We found out that that method always returned zero. By checking the code history, we discovered that distance-based auton didn't work at all in NYC either. The ironic thing was that our dead-reckoning 6 seconds forward auton worked well enough in Hartford that we didn't even notice something was up until the end. After the regional we reviewed the code, and came to the terrible realization that such a stupid error in our code led to us having a time-based auton for both of our regionals, and that all that shouting of "lower it by 3 inches!" on the practice field didn't mean anything. We fixed it after the Hartford regional, and we then had one of the most stable autonomous routines at Championships (when other robots weren't driving into us and jamming us up, which happened like 3 times in a row).
__________________
|