Speed Control Bugs Discovered during Project 4

5/4/2010
We discovered a few bugs that were causing the speed control to go haywire at certain points.  Originally, we set up a special microsecond timer that had double word precision to time the time between hall pulses on the wheel (used for speed sensing).  We needed to do this because 1 second in microseconds is 10⁶, which is beyond the range of a 2-byte word on this microprocessor.  To do this we created an overflow counter that counts 0.05 (twentieth) second intervals and had the regular counter that returned the rest of the time as a word.  The microsecond timer was reset each time a new twentieth of a second was counted.  So splitting it into twentieth second intervals and resetting the counter, we get the following:

word hallTime //The actual time read on the timer

word hall20thTime //The number of 20^th seconds that elapsed

dword actualTime = hallTime / 100 + hall20thTime * 500 //The time in “tenth milliseconds” (10 times finer resolution than a millisecond)

There were two bugs that came out of inconsistent use of this timer we set up:

1. When looking at the time between hall ticks, we calculated dt by returning the time in milliseconds from the clock (since we figured dt didn’t need to be as accurate).  But we forgot to count the 20^th timer when we did this, so we were simply getting the spillover from the timer.  The consequence was that if, for example, there was a time of about 1/20^th of a second between hall pulses, the program would think there was a time of roughly 0, which meant that it thought it was going much much faster than it actually was.  Since dt was so small, this sometimes caused the duty cycle to be set to full, so the car would speed off extremely quickly at times due to this bug.  Once it was fixed this speeding off to infinity went away.
2. Timing reads only occur on hall tick negative edges.  To make sure that the car didn’t halt, we gave the dutyCycle a jolt to 0.25 every time 1 second elapsed without seeing any hall pulses.  What we also did after one second (which was a mistake) was completely reset the timer (20^th seconds and actual timer).  This made it so that after the jolt when a hall pulse was seen again, a really small time would have been read since the timer was reset.  So if there was supposed to be 1.001 seconds between hall pulses after giving the jolt, the program would have seen only 0.001 seconds and thought once again that it was going too fast.  This would lead to another jolt being given, and the car would sort of jolt forward slowly once per second if it got into this state.  So we were screwed whenever the car got slowed down enough that it missed pulses for a second, because it could never get out of it.  Resetting the timer every 30 seconds (instead of every 1 second when we gave it the jolt) fixed this problem