Thursday, July 2, 2009

Hardware/Software Tradeoffs

There were many trade-offs that had to be made in our design, many of which we discovered while debugging and testing. One major trade-off was the rotary encoders we used to determine wheel velocity. There are two major classes of encoders, optical and mechanical. Optical encoders offer significantly higher accuracy, can offer much faster maximum rotational speeds and most importantly for this project, must higher pulses per revolution (easily exceeding 128 ppr). The greater the pulses per revolution, the quicker the response, and/or the more accurate the velocity reading. Unfortunately these encoders are priced outside of our budget and we were forced to use a mechanical encoder with 16 pulses per rotation. This means that we would require two full rotations of the wheel to gather as much data as 1/4 revolution of a fairly common optical encoder. The additional information could help the effectiveness of a traction control system on two accounts. First we could detect a slip quicker, apply a duty cycle change, and check the effectiveness of that change in a much shorter time frame and more importantly, a much smaller wheel rotation. Or, if there are inaccuracies in our time readings (as we see with our current encoders) we could average 16 readings in 1/8 revolution with the optical and a maximum of two readings with the mechanical encoder. We can easily see the disadvantage of so few pulses in our prototype as it takes multiple revolutions to reach the desired speed.

We also encountered tradeoffs that had to be made within the design of our software. We started out designing an edge triggered interrupt to accurately detect a phase change on the encoder signal and get an accurate time reading. Since the Mega644 only has one comparator we had to combine the pulses from the four wheels onto 1 signal wire. We found a hardware solution to implement this (by XORing the previously read data points and ORing the XOR’s outputs). But this required us to allow our edge-triggered interrupt to be interrupted. Another difficulty with our edge triggered interrupt was the significant switch bounce seen on the encoders during a phase change. This problem is described in greater detail in the software section. The combination of our re-entrant interrupt and significant bounce noise required us to switch to polling the encoders. This gives us much less accurate timing, but is significantly easier to implement.

No comments:

Post a Comment