For our ECE4760 final design project, we designed and built a two player game system for rock-paper-scissors.

Our implementation involved the use of two sensor gloves (one for each player) that tracked bends in the users fingers, to determine the symbol put out by each player, as well as hand acceleration, to track the start and end of each game. The game system connected to a computer through the use of a USB serial connection to print game data and game statistics to the computer screen. An additional feature was implemented to ensure that both players displayed their symbols at the same time and kept the same pace to prevent cheating.

High Level Design

Game Rules
Rock-paper-scissors is a game typically played with 2 players in which each player must display either the symbol for rock, paper, or scissors. The following list describes the hand positions for each symbol:

Rock: represented by making a fist Paper: represented by an open hand, with the fingers kept together Scissors: represented by extending and separating only the index and middle fingers

To begin a game of rock-paper-scissors, both players make a fist with one hand and hit it against their other hand which is open with the palm facing up (hand hit). After the players have completed three hand hits together, they each display one of the three symbols. The following rules are then used to determine the winner:

Rock defeats Scissors Scissors defeats Paper Paper defeats Rock

The rules for winning are also displayed in the following chart:

Rock-paper-scissors rules for winning. (Borrowed from Wikipedia) The Wikipedia article for rock-paper-scissors can be found here for more details of the game.

Rationale
The idea of exploring new ways to interact with computerized systems led us to the idea of designing some kind of device that would be able to use human motion as an input. Since the hands and hand gestures often serve as a means of communication and emphasis, we believed that implementing a sensor glove would be an interesting way to capture human motion and to control a system. The rock-paper-scissors game provided us with the opportunity to capture several aspects of hand motion including finger bends and hand acceleration in an interactive system. Our original interest in hand movement tracking and sensor gloves stemmed from a description given in lecture of a previous years project that dealt with using hand gestures and movements to control a computer. We immediately began thinking of different applications of sensor gloves as well as interesting and fun ways to demonstrate their functionality. After much thought, we eventually landed on the rock-paper-scissors game.

When going through the list of previous years projects, we discovered that another group had implemented their own version of rock-paper-scissors that used CMOS cameras to determine the symbol put out by the player. While both projects had the same end goal, our method of actively tracking finger bends with acceleration with hand sensors was significantly different then their method of capturing an image of the players hand. In addition, our system also focused on the interaction between two human players which introduced issues of timing between the two players symbol displays to keep the game fair and ensure all game rules were followed. As such, we believed our project was significantly different from any previous project and was a worthwhile pursuit.

Logical Structure
Our project was structured so that the two sensor gloves were completely independent of each other and interchangeable. As such, the hardware for each glove was kept separate from the other. We found this organization to be extremely important as it allowed for easy tracking of hardware problems to a specific glove as well as simpler circuit layout, construction, and system setup. Each glove consisted of an accelerometer and two finger flex sensors directly attached to the glove as well as three comparators on the base unit which served as analog to digital converters for each of these components. Thus, each glove required three connections to the microcontroller to send the hand motion data for analysis. Each glove was set up to attach to a different port on the Mega644 microcontroller as each glove required the use of an external interrupt to count the hand hits (the motion required to start the game). In addition, this also helped when setting up the system for use as the sensor input pins for each player were on different ends of the prototype board. The signals from the two gloves were interpreted and analyzed in software. The microcontrollers hardware timer0 was used to count milliseconds to serve as a reference time for the system. All timing constraints and scheduling used software timers based off of the millisecond count of timer0. The ISR for each accelerometer was triggered on each hand hit and set up to track the number of times each player performed that motion (3 were required by each player before the symbols were determined). The finger flex sensor signals were read off the microcontroller ports after the system had detected the starting sequence of three hand hits. The code was then responsible for determining the winner and sending the results via serial connection to the computer to be printed in PuTTY. The flowchart below shows the flow between subsystems in the design:

Project subsystem flow. [Full-size as PDF (96KB)]

Hardware/Software Tradeoff
Originally, we had decided to purchase variable resistive flex sensors in order to track the finger positions of each player. However, due to the high price, we could not afford to put five flex sensors into each sensor glove. As such, we determined that at a minimum, we needed only two flex sensors, one for the index finger and one for the ring finger. By tracking just those fingers, we could detect any of the three symbols involved in the game, assuming the user actually displays one of the real symbols. Since the system does not track the thumb,

middle, or pinky fingers, the system may detect a legal symbol when the user does not actually display one. In the end, we decided not to purchase the resistive flex sensors but to make our own. We still decided, however, to stick with using only two flex sensors per hand in order to simplify the design. Using a smaller number of sensors allows for easy repair and replacement of the flex sensors. This, in turn, also simplified the software symbol detection engine as only two fingers had to be analyzed to determine the symbol displayed by each player During the planning stages of the project, we realized that the sensor components that we wanted to use in the sensor glove all contained analog outputs. As such, we needed a way to convert all the sensor output signals into digital signals that could be used by the microcontroller. Since each glove consisted of two flex sensors and an accelerometer, we needed 6 total (3 for each glove) analog to digital converters. However, the Mega644 only contains one dedicated analog to digital converter. Instead of using the built-in ADC, we instead had to build 6 external ADCs using op amp comparators. We could have used the microcontroller's internal ADC to read the flex sensor signals. However, it would have been more difficult to have an adjustable threshold voltage when the device was in use outside of the lab environment. As such, we decided to implement the comparison in external hardware.

Standards
Our game implementation required a serial connection via RS232 in order to print game data to the computer. The provided UART library and code from the course website handled all issues related to this standard.

Patents, Copyrights, Trademarks

Microsoft Corporation holds a patent on a type of gesture detection system. In the patent description, a rock paper scissors game is described. However, their detection system is different from ours because their system uses gesture input from an optical and touch sensitive device, while ours uses a glove with flex sensors. This patent can be reviewed here. To the best of our knowledge, there are no other directly relevant patents, copyrights, or trademarks related to our implementation of our rock-paper-scissors game or sensor gloves.

Software

Program Description
The program portion of the project was divided up into three main stages: (1) preparing the system for game play, (2) detecting the starting sequence of hand hits, and (3) reading the players symbols and determining the winner. The flow through the game sequence is shown in the flow chart below:

Game flow diagram. [Full-size as PDF (53KB)] 1. Preparing the system for game play The preparation stage of the program was responsible for initializing all of the software timers and game variables. The initialization statements involved in this portion of the code were all grouped together in a function called resetGame() which would be called the first time the system was turned on as well as after each round of the game. The organization into a single reset function allowed for better organization of the code and was very convenient as the reset function is called in multiple places throughout the code. The game variables that kept track of the total number of wins for each player were not in this reset function as we wanted to preserve these values for the entire time the system was on. The system setup stage also involved setting up hardware timer0. In the program, timer0 was used to create a 1 millisecond timer which served as the source to all of the software timers in the program. As such, timer0 was set up with a prescalar to divide by 64 and to trigger an ISR and clear when its count reached 249 (corresponding to 1 millisecond). The timer0 compare match ISR was used to update all software timers that were currently operating. These timers will be discussed in the subsequent sections. Finally, the preparation code set up two external interrupts, one on int0 and the other on int2, for the detection of the starting sequence and initialized the UART. The UART was used for printing the results for each game to PuTTY on the computer. 2. Detecting the starting sequence of hand hits The accelerometer from each players glove was connected to a comparator which returned +5V when the glove was hit against the hand for the starting sequence and 0V otherwise. The output from player 1s comparator was connected to external interrupt int0 (pin D.2) and the output from player 2s was connected to external interrupt int2 (pin B.2). Both external interrupts were set to trigger on the rising edge. As such, an ISR was triggered whenever a player completed a hand hit. Before the symbols could be evaluated for each player, each player needed to have completed three hand hits. There were several rules that dictated how the players could increase their hand hit counts in order to complete the game:

No players count can be more than 1 greater than the others. This was to prevent

one player from getting too far ahead of the other.

No players count can be greater than the others for 400 milliseconds otherwise the game will timeout.This was to ensure the game was fair by making sure that the

players were on approximately on the same playing pace. This also prevented a player from waiting to see the other players symbol before completing their set of hand hits and displaying their symbol.

No player can increment his count within 50 milliseconds of a previous increment. This was to prevent any double triggering caused by the accelerometer.

No players count can be greater than 3. Since only three hand hits are required for

each game, there is no reason to count any higher. Each time a players hand hit ISR was triggered, a variable holding their total number of hand hits in the current game was increment unless one of the above rules was violated. After each registered hand hit for each player, a 50 millisecond timer would be started. During this 50 millisecond period following a players hand hit, that player would not be able to register another hand hit. This timer prevented multiple triggerings of the accelerometer comparator on one hand hit from registering multiple times. Since this time was small compared to human hand movement speed, it would most likely not be noticed by the players. This timer was controlled in the timer 0 compare match ISR which was run every millisecond. Whenever the timer count was greater than 0, it would be decremented every millisecond. Once the timer had reached 0, the hand hit could be incremented once again. To start the timer again, the timer count variable would simply be reset back to 50. A variable was used to track when the hand hit counts of the players were equal (evenCount). This variable would indicate when one player was ahead of the other in the game. In addition, on the first hand hit (by either player), a flag variable was set to indicate that the game had started. When the counts were not equal, the 400 millisecond game timeout timer was started. If the counts were not even after 400 milliseconds, the game would end. When the counts were even, the timer would be reset. The timeout timer was controlled in the timer0 compare match ISR which was run every millisecond. If the game started flag was set and the count was marked as being uneven, the timeout timer variable would be decremented. Once this timer reached 0, a flag would be set to indicate that the game should be ended with no winner and the timer would be reset for the next game. After this flag had been set, the reset function would be called and the flag variable reset in preparation for the next game. A timeout error would also be printed to PuTTY. 3. Reading the players symbols and determining the winner

After both players had reached a hand hit count of 3, the system could proceed with symbol recognition. Upon the hand hit counts for both players reaching 3, a 200 millisecond counter was started. This time period gave time for the flex sensors to stabilize on the players selected symbol. When the timer reached 0, the outputs from the flex sensors were read in from the microcontrollers ports. Player 1s index and ring finger flex sensor readings were on pins D.3 and D.4 respectively, and Player 2s index and ring finger flex sensor readings were on pins B.3 and B.4 respectively. The two bits corresponding to each players flex sensor readings were extracted and sent to the function determineWinner() to determine the winner of the game. The process of determining the winner was handled through a series of if statements which covered all possible combinations of flex sensor outputs. After the symbol was determined for each player, the users symbol choice would be printed to PuTTY. The following table details the outcome of a game given the flex sensor outputs for each player:
Player 1 Index Ring Symbol Index Player 2 Ring Symbol Winner

0 0 0 0 0 0 0 0 1 1 1 1 1 1

0 0 0 0 1 1 1 1 0 0 0 0 1 1

Rock Rock Rock Rock INVALID INVALID INVALID INVALID Scissors Scissors Scissors Scissors Paper Paper

0 0 1 1 0 0 1 1 0 0 1 1 0 0

0 1 0 1 0 1 0 1 0 1 0 1 0 1

Rock INVALID Scissors Paper Rock INVALID Scissors Paper Rock INVALID Scissors Paper Rock INVALID

Tie NONE P1 P2 NONE NONE NONE NONE P2 NONE Tie P1 P1 NONE

1 1

1 1

Paper Paper

1 1

0 1

Scissors Paper

P2 Tie

(NOTE: the flex sensors are active low, meaning that a 0 corresponds to a finger being bent and a 1 corresponds to a finger not being bent) The determine winner function returned a "0" to indicate a game error (no winner), a "1" to indicate that player 1 won, a "2" to indicate that player 2 won, or a "3" to indicate that the game was a tie. Based on these results, a message would be printed to PuTTY indicating the outcome of the game. Each player had a variable that contained the total number of wins for each player. If the game had a winner, the corresponding players win total would be updated. The total number of wins for each player would then be printed.

Program Troubleshooting
The most difficult part of the programming proved to be the coordination of the numerous software timers used to make sure both players play at the same pace, to give the sensors enough time to settle, and to prevent multiple triggerings of the accelerometer from a single hand hit from counting more than once. The frequent setting and resetting of the timers becomes difficult to trace throughout the program. The game rules and accuracy of the readings from the sensors depend on accurate control of the timers. Since there are numerous paths through the code that any given game could take, we need to trace out all of the paths to make sure all necessary timers were being adjusted at the appropriate times. We ran into a few problems due to software timer issues in which the system would be stuck in a given state because it was waiting for a certain timer that was implemented incorrectly.

Hardware
Sensor Glove
The sensor glove was designed to be worn on the right hand of a player and track the acceleration of the hand as well as the movement of the index and ring fingers. As such, each glove consisted of an accelerometer and two flex sensors. A cloth pocket was stitched along the ring and index fingers on the glove to hold the two flex sensors in place on the fingers. A small piece of solder board was also stitched to the back of the hand on the glove to attach the accelerometer. Long wires terminating in header pins were then connected to the flex sensors, and accelerometer outputs, as well as +5V and ground. These wires were then run to a base unit which contained filters and comparators for the signals from the glove.

Rock symbol displayed on sensor glove. [Full-size]

Paper symbol displayed on sensor glove. [Full-size]

Scissors symbol displayed on sensor glove. [Full-size]

Accelerometers

Oscilloscope output from accelerometer and comparator. [Full-size] The voltage on the output pin of the Motorola MMA3201D accelerometer was proportional to the acceleration experienced by the chip. At zero G, the output would be equal to 2.5 V (when Vdd is connected to +5V and Vss is connected to ground). When the acceleration became positive (an acceleration in the y direction), the voltage on the output would increase above 2.5 V. The datasheet for the device recommended a passive low pass filter using a 1 k resistor and a 10 nF capacitor to reduce clock noise. The output from this filter was connected to the non-inverting input terminal of an lm358 op-amp which was used to make a comparator to serve as an analog to digital converter. To produce a reference voltage for the comparator, a 10 k potentiometer was used. We originally connected the two sides of the potentiometer to +5 V and ground. However, because the accelerometer was rated at 40g, it produced very small voltage changes under low accelerations. This made fine tuned voltage adjustment with the potentiometer difficult. To reduce the range of voltages across the potentiometer, and to increase precision, a 10 k resistor was inserted from +5 V to one side, and from ground to the other side (see high level circuit diagram). This effectively lowered the range of voltages the potentiometer could produce, but it significantly increased the precision. The potentiometers range was now between 1.66 and 3.33, which meant that sliding the wiper all the way across would only amount to a change in 1.66 V, where previously it would have been 5 V. With this increased control, it was significantly easier to set a threshold voltage for the comparator to trigger on. The wiper terminal of the potentiometer was connected to the inverting terminal of the opamp to provide the reference voltage to the comparator. The output of the accelerometer comparator was sent to an external interrupt pin on the Mega644 to be used in counting the hand hits for a given player.

The equations below show the calculations to find the range of voltages offered by the potentiometer:

5*(10/30) = 1.66 5*(20/30) = 3.33

Flex Sensors
The flex sensors that we built had a range of 200 k when straight to around 5 when bent at 90 degrees. To produce a variable voltage from this variable resistance, the sensor was put in series with a 10 k resistor to create a voltage divider (see high level circuit diagram). The output voltage from this configuration had a range of 0 to +5 V. When a finger was extended, the voltage was around 5 V, and when completely bent, the voltage was almost 0 V. The voltage dropped relatively linearly as the finger bent, but after one joint on the finger had been bent more than 80 degrees, there was a sharp cutoff. The video below shows the signal off of the flex sensor (upper signal on scope) and the flex sensor comparator (lower signal on scope) when the finger is bent and extended: A 100nF capacitor was connected between the voltage divider output and ground, in order to reduce high frequency noise. This node was then connected to the non-inverting terminal of an lm358 op-amp which was used as a comparator to convert the analog signal to a digital signal. To produce an adjustable reference voltage to compare against, a 10k potentiometer was used, with one end connected to +5 V and the other to ground. The control of the reference voltage with this setup was sufficient. The range of 0 to 5 V was necessary, because of the large range of the signal produced by the flex sensor. The output of the comparator was configured to drive an LED whenever the flex sensor was bent. This output was also directly connected to the input terminals of the Mega644 to provide finger data to the program. The potentiometers allowed for the comparators to be tuned based on the users preferences. Setting a high reference voltage would mean that the finger would only need to be slightly bent for the comparator to trigger. Setting a low reference voltage would mean the finger would need to be bent all the way for the comparator to trigger. As the sensors get bumped around, their resistive characteristics can change. Adjusting the potentiometer made it easy to correct for these changes. Having the LEDs turn on whenever the comparator triggered made it very easy and convenient to tune the device, since it was possible to set the exact angles at

which a finger must bend to trigger the comparator. The video below shows the functionality of the LEDs when the player bends their index and ring fingers:

Flex Sensor Construction

While we originally had planned to purchase variable resistive flex sensors, their high price inspired us to build our own. An internet search on resistive flex sensors led us to this website. Using the instructions we found at this website as a guide, we made our own flex sensors.

Assembly of flex sensor. A strip of ESD foam is sandwiched between 2 strips of copper tape. [Full-size] Each flex sensor consisted of 2 strips of copper tape (5 inches long by 0.25 inches wide), 1 strip of electrostatic discharge (ESD) foam, 1 piece of heat shrink tubing (5 inches long with a diameter of about 0.25 inches), 2 pieces of copper wire (6 inches long), and electrical tape. The 2 pieces of copper wire were then stripped on either end, and 1 wire was soldered to the end of each of the strips of copper tape. We then reinforced the solder joints by wrapping them in electrical tape. To put the flex sensor together, we put the piece of ESD foam in between the two pieces of copper tape with the copper sides both facing in toward the foam and the ends with the attached wires on the same side. The layers were then connected together with a piece of electrical tape on the end without the wires. This piece was then inserted into the heat shrink tubing which provided a tight fit. The flex sensor operated under the observation that the strip of ESD foam will conduct when compressed. Therefore when the strip of ESD foam is put between the pieces of copper tape and the combination is flexed or bent, a current can be passed between the two copper strips. The more the sensor is bent, the greater the area of compressed foam and the lower the resistance between the copper strips. The final flex sensor provided a resistance measure of around 200 k with no bend and around 5 when bent at 90 degrees. This variable resistance

of the flex sensor allowed us to tune the flex sensor comparator to trigger at different degrees of bend. Another notable property of the flex sensor is that the sensor will also respond to pressure as any force applied to the sensor will compress the ESD foam and lower the resistance. During our initial attempts to make flex sensors, we tried to use strips of a conductive poly bag in between the pieces of copper as recommended by the tutorial we found. However, we were unable to get the sensor to work using that material, and instead switched to using ESD foam. The ESD foam not only provided reliable results, but was easy to find in the lab.

Base Unit
The 6 op-amp comparators with adjustable thresholds along with the LED circuits for the flex sensors were all placed together on a solder board. This board served as the base unit and the interface between the sensor glove and the microcontroller. The base unit was set up with header socket pins for all inputs and outputs. This allowed for the sensor gloves and the prototype board to be easily plugged into the base board.

The back of our base unit board. [Full-size]

The front of our base unit board. [Full-size]

Prototype Board

Our prototype board [Full-size] In order to make our project portable, we decided to use the printed circuit board (PCB) provided by Professor Bruce Land in our final implementation. On our board we put a Mega644 microcontroller, a 16 MHz crystal, and an RS232 chip with USB connection. We also decided to use header pins for all port connections to the microcontroller to allow for easy connections

using jumper wires. The RS232 chip and USB connection provided the necessary serial connection for sending data to the computer to be printed in PuTTY. The LED on the board was extremely useful for debugging and testing the functionality of the board after all soldering was complete. The on-board regulator was also helpful for testing as we were able to use other power supplies from home to power the board and test the functionality of our program outside of the lab.

We hope that the descriptions and schematics will make it possible for other enthusiasts (geeks) to replicate our design, to potentially explore further possibilities with this technology.

The final product. [Full-size]

Results
Speed of Execution
During the design and construction process, we did not encounter any problems due to the speed of our system. The microcontroller was able to handle all of the required operations, interrupts, and timers required by our device. Delays were built in to the program to give the sensors a chance to settle and prevent errors, but these delays are not very noticeable to human users.

Accuracy

The accuracy of the flex sensors and accelerometer in detecting finger and hand movements was quite good once the system was set up and the comparator thresholds were adjusted. Typically when the system was first set up, adjustments in the flex sensor thresholds were necessary. However, we believe that this is mostly due to the storage of the gloves. When the gloves and their connected wires are wrapped up to be stored, the flex sensors frequently move around inside the glove. The sensors themselves are somewhat fragile and any pinching of the sensor may require the sensor to be adjusted before it will operate properly. However, once the sensors had been fully set up in a working state, we never had any problems with the detection accuracy of any of the sensors.

Safety
We took many steps during the design and construction of our device to ensure that it would be safe to use. To increase electrical safety, heat-shrink tubing was used to cover all exposed wires. This prevented shorts from being created, and prevented sharp wire ends from harming the user. In addition, the gloves were chosen to insure the users hands were protected from any exposed circuits, and were found to not cause discomfort to the user. The flex sensors were attached by sewing strips of a t-shirt onto the glove, ensuring that nothing sharp was exposed to the user. The cables were drawn together by zip-ties, to prevent tangling. Finally, the cable connections to the main circuit board were loose enough so if suddenly jerked, the cables would disconnect from the circuit to prevent the circuit board from becoming airborne. This would help protect both the user and the device if a user pulls on the cables accidentally.

Interference
Our Rock Paper Scissors System does not transmit any signals. As far as we can tell, it was not affected by noise from other nearby projects, nor did it produce interference for nearby projects.

Usability
The device is usable by anyone who is able to play a game of rock paper scissors ordinarily. For people with different sized fingers and hands, or people who are unable to fully bend or extend their fingers, the angle at which the device determines the finger is bent can be tuned by adjusting the potentiometers. The LEDs will turn on when the device detects that the respective finger is bent, allowing the user to set the level to their preference.

Video

The following video shows our project in action. It demonstrates how the device is used and the output returned to the computer after each game.

Conclusions
Expectations
Overall, our device met our expectations and fulfilled the goals outlined in our proposal. The system was able to successfully detect when the index and ring fingers were bent to determine the players displayed symbol and to detect the hand hit motion. We were very happy with how the gloves and controller circuits came out, and we believe the implementation was well organized, neat, and durable. We had originally hoped that we would be able to get a more consistent range of resistances on the flex sensors so that we would be able to track smaller and more precise movements of the fingers. However, the flex sensors we built ourselves far exceeded our initial expectations. While they appeared to be flimsy, they actually held together quite well and provided the necessary functionality for our rock-paper-scissors game. Due to small differences during the production of the sensors, each flex sensor turned out slightly different. The ability to tune the flex sensor comparators helped compensate for this variance. There were a few things that we would have liked to change if we were to redo this project. One main problem in our circuit is the manner in which the sensor gloves connect to the base unit containing the comparators. Long wires terminating in header pins run from the gloves and plug in to individual pin sockets scattered over the base unit board. While all of the wires are labeled to indicate which socket they must go in, there is a fair amount of crisscrossing of wires. This makes the gloves more difficult to plug in than we wanted. In addition, having individual pin sockets on the base unit board proved somewhat problematic as they were easily bent and disconnected from the board. If we were to have had the outputs of the sensors plug into one section of the board, the single pin weakness could be avoided as a longer, connected string of socket pins could be used. If we were to expand on this project in the future, we would like to add more flex sensors to the sensor glove so that the bends in all 5 fingers could be tracked. Collecting position information on all of the fingers opens up more possibilities for application of the sensor glove. In addition, our current project treats a finger position as a binary value, either bent or not bent. If we were better able to capture the analog values coming off the flex sensors, we may be able to track the exact degree of bend in each finger. This, however, may require a more

complicated setup as the microcontroller only has 1 built in analog to digital converter which could be used to this affect.

Ethical Considerations
Throughout the course of the design project, we did our best to observe the IEEE Code of Ethics and conduct ourselves in an ethical manner. In terms of safety, we took many precautions to prevent as many user risks as possible. We covered all exposed wires and attempted to isolate the user from any direct contact with a material or device that could cause injury. When writing our report, we made sure to mention and credit the sources we used for design and construction ideas. These acknowledgements can be found throughout the report as well as in the acknowledgements section at the very bottom of the page. We attempted to be candid when evaluating the successes and failures of our design process. As we hope that in the future others may want to build on our findings, we tried to represent what we did accurately. We tried particularly hard to make sure that we followed the lab rules regarding lab materials and property. We always returned borrowed materials at the end of each lab period to ensure that other groups had access to these shared resources as well. Finally, during our work in the lab we attempted to seek honest opinions of our project design and well as provide our opinions to other groups that asked. In this manner, our class created an environment that was conducive to helpfulness and respect which we believed facilitated the many incredible and amazing projects we saw being built.

Applicable Standards
Since our code communicated game data to the computer via a serial connection, the UART needed to follow the standards for RS232 serial communication. However, the UART library and code provided on the course website handled this data communication for printing to PuTTY on the computer.

Intellectual Property
All code was designed and written by us with the exception of the UART library which was used to print game data to PuTTY on the computer. The UART implementation was written by Joerg Wunsch and was provided via the ECE 4760 course website. All components used to build our circuit and gloves were either available in the ECE 4760 lab or at the local hardware store. No products were sampled from companies.

Appendices

A. Source Code
Source files

RockPaperScissors.c (10KB) full game functionality uart.c (5KB) UART library

Header files

uart.h (1KB) UART library header file

Download all files: code.zip (6KB)

B. Schematics

Base Unit Board Layout [full-size layout as PDF (165KB)]

High Level Circuit Diagram [full-size circuit as PDF (116KB)].

Prototype Board PCB [ExpressPCB Design File (19KB)].

C. Parts List
Item Quantity Unit Cost Total Cost Notes Source

276-168B Solder Board Small Solder Boards Mega644

1 2 1

$2.50 $1.00 $8.00

$2.50 $2.00 $8.00 40 pins for accelerometers, 46 pins on the

ECE 4760 lab ECE 4760 lab ECE 4760 lab

Header/SIP Pin

100

$0.05

$5.00 target board, 14 pins on wires from gloves 40 sockets for accelerometers, 22 sockets

ECE 4760 lab

Header/SIP Socket

62

$0.05

$3.10 on the main board

ECE 4760 lab

Target Board RS232 Connector DIP socket 2 pin flat jumper cables Accelerometer Flex Sensors Gloves

1 1 7 8 2 4 2

$4.00 $1.00 $0.50 $1.00 $0.00 $0.00 $2.50

$4.00 $1.00 $3.50 $8.00 $0.00 $0.00 $5.00 Built from scratch materials in lab

ECE 4760 lab ECE 4760 lab ECE 4760 lab ECE 4760 lab ECE 4760 lab ECE 4760 lab Lowes

Power Supply 10 k resistor 1 k resistor 10 nF capacitor 100 nF capacitor LM358 dual op amp Green LED 10k pot Wire

1 10 6 2 4 4 4 6 30 Ft
Total Cost of Project:

$5.00 $0.00 $0.00 $0.00 $0.00 $0.00 $0.00 $0.00 $0.00

$5.00 $0.00 $0.00 $0.00 $0.00 $0.00 $0.00 $0.00 $0.00 $47.10

MCU power supply

ECE 4760 lab ECE 4760 lab ECE 4760 lab ECE 4760 lab ECE 4760 lab ECE 4760 lab ECE 4760 lab ECE 4760 lab ECE 4760 lab

D. Tasks
The following list details the tasks handled by a specific team member. All other tasks were completed together. David

Flex sensor assembly Prototype board soldering Software design - coding Base unit soldering Project website

Chris

Hardware schematics Sensor glove assembly Video editing White board prototyping

References
This section contains a listings of the relevant datasheets and backgroup websites used throughout the project.

Datasheets

ATmega644 (Microcontroller) LM358 (Op Amp) MMA3201D (Accelerometer)

Background Information

How to Make Bi-Directional Flex Sensors (For information about how to make flex sensors) Rock-paper-scissors (Wikipedia)

Acknowledgements
We want to acknowledge Professor Bruce Land for teaching a fun and interesting class. We greatly appreciated the extended lab hours and the time the TAs took out of their schedules to keep the lab open. Our TA, Jeff Yates, gave us useful advice and feedback about our design, and was helpful in keeping us on track. We also appreciated the help and advice we received from other project groups in the lab, which contributed toward the productive and exciting work environment.