| Software | ||
 Wilt prepares to take a shot In designing Wilt's software, we paid close attention to the tasks which he would have to do. Through this process, we found that Wilt's actions were very pre-determined, that is, the robot just needed to follow the same routine over and over again. There were no events which would suddenly send it down an entirely different path from where it was at the moment. In the latter case, a state-machine would have been an optimal design. But in our case, since there was only one asynchronous event (the carousel sensor hitting a patch of tape), it was actually easiest to write the software to flow like a standard program. The one caveat was that we had to keep an eye on the carousel sensor at all times -- that is to say whenever we wanted to block (enter a loop) while waiting for some condition, we have to poll the carousel sensor periodically. While this requirement may sound tedious, in reality it is very easy to do by writing low-level primitives to do most of the blocking (ie waiting, driving, etc.) and making sure to call the event checker in its loop. Then, the actual logic of the code can leverage these correctly-written lower level functions, and the event checking becomes almost transparent. This is the same model found in many single-threaded GUI toolkits -- MacOS and Windows' MFC to name two -- if you want to have the OS seem responsive while preparing a print job (for example), the programmer must periodically call PumpEvents() to give the GUI some time to handle its events. Likewise with our carousel. The machine always keeps track of which basket it is firing at. This is so when the robot is at the far-right basket, it will only turn to the left to find the next basket. And it does the opposite when at the left basket. When re-aiming at a basket, it will turn to the left, and then re-scan to the right to re-acquire the strongest signal and attempt to make the shot. Here are our source files: CANNON.C |