Turning detection and location finite state machine

5/5/2010

Our turning detection algorithm took the average of the last 15 measured steering duty cycles taken at every Hall sensor pulse and checked to see whether it was below or above set values. For example, if the average steering duty cycle was below a certain value (we initially guessed halfway between completely left and center, between 0.108 and 0.126) then we would make a note that the car was “in a turn”. The reason for averaging was so that we could account for “wobbling” of the car as it corrected itself on straightaways, and be certain that when we thought the car was in a turn it was actually in a turn. After the average of the steering fraction would go back close enough to center, we would note that the car had “completed a turn” and use this knowledge for our finite state machine for determining location.

Another feature of the turning detection algorithm was that it would store the number of “post-turn” hall ticks it counted until the next turn. There were two reasons for doing so: the first was to control for noise. If a car was coming out of a turn so that the average went back close to center but then immediately “wobbled” there was a chance that the average would have been thrown off again, so we would only count turns which were made after a short number of post-hall ticks had been completed (we decided on 5). One concern of ours was that this might have interfered with one part of “C” on the track were there are turns very close to each other, but the threshold was high enough to stop noise and low enough so that it detected each of these individual turns. The second reason for counting post-turn ticks was for use in our finite state machine, for detecting long straightaways.

5/6/2010

After testing the turning detection for the first time it didn't seem to work, but we noticed that it thought that it would immediately turn left. Debugging through serial by outputting the mean values of the steering fraction at every hall tick showed very small initial values and we deduced that we forgot to initially the array to all center values of 0.126 (they were automatically initialized to 0 so the algorithm though it started out very very left). After fixing this we tested it and it was a success with a few minor glitches due to us simply guessing where to put the bounds. The plot below shows the turning duty cycles output at every hall tick, and we recalibrated the bounds based on this plot to have left turns be below 0.112 and right turns be above 0.140 and then the turning detection worked great.

Plot of the steering fraction (multiplied by 1000) vs. hall tick count

 

 

5/5/2010

The finite state machine we used to determine the location of the car is posted below. Once it reaches a “stop state” with a letter on it, it transitions to a second state machine which simply follows the order of the track according to the turns the car is supposed to make. If the car ever performs an unexpected maneuver (if for example a turn is not detected when the car turns, throwing off the state machine), it returns to the start state of the original state machine. The state machine below is for the car turning counter-clockwise and the pieces of the track are defined in an image on the next page.

In addition to the finite state machine, we measured the total number of ticks which the car made in a single loop around the track by outputting each tick to serial and programmed in twice that number so the car would stop after two loops around the track.

In the state machine, L stands for a detected left turn, R is a detected right turn and S is a long straight, measured by a large number of post-hall ticks