Josh Sirkin - Rich Rothman

Our project takes a classic video game and adds a twist with a handheld, gesture based controller. IT'S SUPER TERRIFIC AMAZING TETRIS EXTREEEEEEEEEEEME!!!!!!!

We decided to undertake this project because the idea of combining the massive coding required for the Tetris game with the elegance of coordinating the processes of a wearable controller made for an impressive final hurrah in ECE 476. Creating the game from the building blocks of video generation that we learned in lab was a challenge. It took a lot of trial and error, as well as taking great care regarding timing, to get the game functioning well. To make our project stand out, we decided to make the controls for the game similar to how you would move the Tetris blocks in the real world, grabbing them, rotating them and so on.

The Game

Tetris is a game that was developed in the 80s. It became very popular when it was released on the Nintendo Gameboy. The point of Tetris is to create a solid horizontal line of blocks. When this is done, the line is cleared and all the previous block that were above the line move down by one line. You lose the game if the stack of blocks reaches the tope of the screen. Tetris is made up of 7 different blocks referred to as I,J,L,Z,S,T, and O based on their shape. Each block is made up of 4 smaller blocks arranged in a specific shape. The standard Tetris screen is 10 blocks wide by 20 blocks high.

High Level Design

Background Math

We didn’t require any serious math to accomplish our goals. The averaging used in the glove to interpret the accelerometer data is a plain averager, adding five samples at a time and dividing by five.

Logical Structure

We implemented our Tetris on a standard black and white television using an area of 100 pixels high by 50 pixels wide. Each smaller block is made up of a 5by5 pixel square. Our design is based on the idea that the program does not need to know where all the blocks are. Once they are done moving, they are found again by reading the pixels on the screen. There is no array that stores the location of all the blocks. Each block is made up of 4 smaller blocks that move together. What is tracked is the falling block. The program keeps track of the top left x and y position of each block, the x and y coordinates of the sides and bottom of each block. The sides and bottom coordinates are used to make sure the block does not go through other blocks from the side and to make sure that the falling block stops when it hits another. The program also has methods that define how the block rotates from one position to another. Each object orientation contains its own boundary values.

The Program

The timing for the blocks falling is based on the 231 line refresh for the televisions. There is a counter that increments every 231 lines and compares the value to the variable ‘speed’. Blocks only fall down one line when this value is reached. The falling of the blocks can be sped up by decreasing this number.

Before integrating the glove into the game, the game was controlled with buttons for clockwise/counterclockwise rotation, left/right movement, and slam-down operation. This actually lent itself well to integration with the glove because it used flags to make sure values were only sent once which makes it so the glove can wirelessly send one command.

On each button press, before the block moves, the position of where the block will move to is checked. On move left and move right buttons, the program calls the move_left() method and move_right() method which go through the left_side and right_side arrays (lefts and rights stores the number of left side and right side blocks to check) to check if the block is already against the wall using the video_set method. This method checks the screen array to see if there is a pixel at that location. For the two rotate operations, the program calls the check_can_rotate() method to make sure that the block does not rotate into blocks that were already on the screen. If the next position would interfere with something, the block won’t rotate. The slam_down operation takes advantage of the ‘speed’ variable that is used to control the block fall speed. When slam_down is activated, the speed variable is lowered to 1, so that the block falls by 5 pixels every 231 lines. It is then set back to its original value when the block hits another.

Our program randomizes which block it chooses. By randomizing the next block one block earlier, we are able to display the upcoming block on the left side of the screen. Since there is no actual time on the cpu, we use the clock and take the value from when the user presses a button to start the game. This makes it so that the randomizer always seeds with a different value. The hardest part of the program was the line clears. In Tetris, when a player makes a complete line of blocks from one side to the other, the line disappears and all of the blocks above it move down one line. To do the line clear successfully, each line is checked and/or replace in its own cycle. This helps to avoid artifacts but could result in the program needing up to 20 cycles to move all lines down, about 1/3 of a second per line that is cleared. To make things more complicated, it is possible for a player to get multiple line clears in one turn. Our code handles this in the check_line method by first scanning up to 4 lines, one for each different y value of the most recent block to land. This is taken from the left_sidey array. The only possible lines that could have been completed are the lines where the block just landed. This saves us the trouble of having to check every single line. We also then only check from left to right for x positions from 50 to 100 (our screen width) every 5th value. Because the blocks are 5 pixels wide, there is no reason to check every value. After the cleared line is found, the method gets more complicated. The check_line method calls the move_line_down() method. This method starts from where the complete line was found and works its way up the screen copying what is on the line 5 pixels above it (either a square starting there, or no square). By only doing one line each screen refresh, artifacts are avoided and the processor can easily handle the task.

The Hardware

Our glove is built onto a rollerblading wrist guard. This is intentional to limit wrist movement up and down and to give us a sturdy base to mount all of the components onto. Our glove consists of two accelerometers, an x/y accelerometer and a z axis accelerometer. The z axis accelerometer runs off of 5V which we were able to draw right off of the MCU. The x/y accelerometer however, runs off of roughly 3V. We were able to get a consistent 3.15 V for the accelerometer by using 3 diodes and a 1K resistor to drop down the voltage.

The reason that we could not do sensing of left right movement is due to the fact that the acceleration of gravity is so strong that any slight rotation of the accelerometers greatly changes the acceleration during left and right movement. Rotation on the other hand can be accurately measured. We use two buttons to differentiate the diferent motions. When no button is depressed, moving the glove does nothing. This is the simulation of not holding onto the block. Depressing the button on the finger alone allows left and right motion with a twist of the wrist. Depressing both buttons, accompanied with twisting the wrist rotates the block. Holding down just the on-glove button, accompanied with a rapid downward acceleration slams the block down to the bottom of the screen.

The glove takes advantage of averaging, to pass along a single value of rotate left or right, move left or right, or slam down. This works perfect with the Tetris code that was designed to look for a single button press signal.

To make the glove more robust, we gave the user the option of either using it with wireless or a tethered connection. This allows the user to use wireless if they are in a situation where wired would be uncomfortable or annoying or to use wired if they are in an area with large amounts of interference. Our system takes advantage of wireless using 433 Mhz radio. To do wireless, we also decided to use a third Mega32 board. We use this third board as a node to receive the wireless signal and to port it onto the input pin of the board running the Tetris.

Wireless Communication

The protocol we used for wireless communication was largely borrowed from Meghan Desai’s wireless project page on the course website. His project used the Radiotronix RCT-433-AS transmitter and the Radiotronix RCR-433-RP receiver, which we were able to get from Professor Land. We used Meghan’s code, very slightly modified. The communication tool for this protocol was the chip’s USART communicator. The packet structure that his code called for was a bit longer than was necessary for us, but we felt it was alright to leave it the way it was because we might find need for some of the extra functions at a later time. For instance, we only transmit one byte of data in every transmission, so a byte of length data is not necessary at this time. Also, we were able to transmit a sufficient number of packets per time period without trimming the packet structure.

One minor change to the code we referenced was the BAUD of the transmission. We increased ours from 4000 to 4800. The transmitter and receiver datasheets said that this transmission rate was appropriate, and the more often we transmit, the more accurate our game motions will be.

At first, wireless communication seemed out of reach because of the strict timing restrictions of video production code. Once we realized that we were not going to have budgetary problems, we decided to simply use a third MCU to help shuffle data back and forth. This “middle” board was programmed to receive the serial wireless data and send it to the video MCU via port to port communication. This way the video board could read the port whenever it wanted. Our code was already set up to handle the issue of multiple readings of the same data. We had planned ahead to transmit pulses of changes, as opposed to transmitting the hard data. For instance, we transmit “rotate right once” as opposed to “in the left rotated position”, and “move right one” as opposed to “at the fourth location from the left”.

We started using the wireless as our primary communication tool about a week and a half before the end of the project, and we always experienced a problem with interference. Other students were transmitting at the same frequency in the lab. When the glove was the closest transmitter, we had a small amount of interference, but it was still unpleasant. We decided to add the feature of having both wired and wireless communication. We can easily switch between them with just the change of one cable. It goes either directly to the glove MCU, or to the wireless receiver.

Results of the Design

Our project had many aspects that each had their own set of difficulties to overcome. Even with all of these, our final game is definitely robust enough to be considered “playable”. The reaction of the glove is not perfect, but it is good for the few and inexpensive components that compose it. The averaging was tested at different amounts to determine how much delay is acceptable. The same was done with transmission rates for the wireless. With a steady hand, it is definitely accurate enough to play the game successfully. This also adds to the challenge of the traditional form of Tetris. It requires not only being able to solve the game in your head, but quickly coordinate your movements also.

The video code does show some mild jitter, but artifacts are very rare. The video MCU doesn’t need to do any heavy calculation, but it does have a lot of movement to do on the screen, and without actually knowing where blocks are, this can take quite a bit of computing time.

Our project does not have any safety issues. We do not use any high voltage sources and all of the circuitry is on top of the glove, safe from the user.

As we learned in the many hours in lab, when several groups are transmitting over the same frequency at the same time, it is quite troublesome. Although the packet design we are using contains an ID in it, so as to know you are reading the right data, when everyone transmits over each other, the signals get corrupted. This usually happened because most groups try and transmit as rapidly as they can to maximize the data flow. If the glove is the closest transmitter to our receiver, which it almost always is, we can play the game with little interference. We still make sure that we are the only ones transmitting on our frequency when playing.

The glove is a generic “large” and can be used by a decent variety of hand sizes. With more appropriate materials, time, and tools we might have been able to have a more accommodating user input device.

Program/Hardware Design

The first code writing roadblock came with A/D conversion and learning how to stagger two of them. This involved a bit of trial and error, learning which variables need to be set before waiting a little while and starting a conversion. We settled on a small switch statement which ran through sampling two of the accelerometer axes, but waiting for both of them to be updated before calculating anything.

Another challenge was defining the conditions for different motions of the glove. The accelerometers are very sensitive to small changes, so they need to be debounced in a sense. Averaging takes care of some of this, but many “if” statements were required to define, as accurately as we could, what constitutes a rotation, a move, or a throwdown.

The Tetris game code also proved very tricky. Using just inputs from the glove, and the current condition of the screen we had to interpret what state the game was in. Very extensive definition of each block was required, including defining which rotated state it is in, the positions of all the edges around it, and what spot it would rotate into next.

Our hardware in itself was not very unique. The way we incorporated some different disciplines and techniques was what gave us the biggest challenge. Our hardware would be very easy to recreate. The video circuit is the classic one used in the video game lab from this year, consisting of just three resistors. There is no hardware between the receiver MCU and the video MCU. The hardware on the receiver itself is straight from Meghan’s project page. It consists of a small inductor, a capacitor, an inverter, and one extra capacitor that the Radiotronix datasheet recommends.

The hardware of the glove consists of two accelerometers which feed directly into Port A, the MCU, a battery, and a small PC board. On the PC board is the transmitter hardware, also from Meghan’s page. It also consists of a small inductor, a capacitor, and an inverter. On the board is also our three diode network which drops 5V down to ~3V, because the X-Y accelerometer is designed to run on 3V while the Z accelerometer is designed to run on 5V.

We heavily relied on borrowed code for two main parts of our project. We used the video code functions provided for us from the video game lab of this semester. Also, as mentioned before, we used Meghan Desai’s wireless protocol code.

The biggest failed idea was the concept of calculating absolute left and right motion of the glove using the Euler method from data from a single accelerometer reading. After working on this concept for the first week or two, we abandoned is as unnecessarily difficult and changed to a rotating motion with an extra button for differentiation from a rotation of the block. Our original intention for the glove was to be able to have the user grab the block and move it left or right, rotate the glove to rotate the block, and to be able to accelerate their hand downwards to slam the block down. We were able to accomplish most of this except for the one concession.

Hardware/Software Tradeoffs

Most of our tradeoffs were made involving the glove and transmitter circuit. We knew what the game had to do, so it was just a matter of playing with the code until it did. The transmitter on the other hand took a lot of guesswork. It is a judgment call as to how accurate is accurate enough.

Our first tradeoff was using the accelerometers already stocked in the lab because of convenience and price (free). A more accurate accelerometer might have aided accurate glove readings. Another issue was keeping the glove compact enough so that it is comfortable to wear. We achieved this quite well, putting only a prototype board, a small PC board, a battery, and two accelerometers.

The major tradeoff was always the amount of averaging. The more we averaged, the bigger delay there would be between new data, and the more misses in glove changes we will have. With less averaging, the amount of stutter and jitter of the block increases. We settled on averaging five A/D conversions for every new transmission.

Patents, Copyrights, and Trademarks

We drew on the game Tetris for our project, and we acknowledge that we were not the ones who invented this masterfully geometrical toy. We do not plan on patenting our creation, so we are not going to infringe on the creators of Tetris and their glory.

Conclusions

This project ended up meeting our original expectations. Going into the first week of our self-imposed project, we believed that if we were able to get a strong, but not perfect version of Tetris running, as well as a controller which was accurate enough to be fun to use, we would be successful. We chose our project idea because there was plenty of room for expansion. We were able to meet our basic goals as well as get a good amount of extra work done, such as implementing wireless communication, which was originally a farfetched dream. If we were to have another project like this, heavier research would have to be done beforehand. We wouldn’t have wasted so much time trying to use the Euler method to calculate left/right position if we had known that other engineers had faced the same problem in the past and deemed it an unnecessarily difficult task.

The budgetary restriction was one of the more crippling standards being enforced for this project. We used most of our budget making three prototype boards, each with its own Mega32 MCU because we wanted the project to be very compact, which we achieved. However, this came at the cost of using some parts that could have been upgraded to increase the game’s performance. For example, better accelerometers or wireless hardware could have helped glove accuracy.

As mentioned earlier, we give credit and our wholehearted thanks to the code and the coders we borrowed from, namely Meghan Desai with his wireless protocol, and David Rodgers who supplied video generation code for one of our labs this semester from “Procedural Elements of Computer Graphics”, 1985.

We reverse-engineered Tetris, but do not claim it was our invention and we do not plan on patenting our idea.

Code of Ethics

During the five weeks we spent on this project, we made dozens and dozens of decisions, becoming better engineers in the process. We always tried to abide by the IEEE Code of Ethics. We accepted the responsibility of making handheld electronics, and decided to use low voltage power supplies, as well as keep as much wiring as we could wrapped up and secluded from the user. Never did we claim that the idea for the game we were creating was our own. We were always honest in our borrowing of the classic game. Also, no bribes were accepted on our part. Going to lab for all these weeks with our fellow engineers and friends, wee often asked for, and provided advice and guidance to help further the technology being created all around us. We were always appreciative of the help our friends and teachers gave us, and we tried to return the favor, imparting any wisdom we could share. Also, discriminating against any fellow engineers for reasons such as race or gender was not a part of our project plan. Lastly, although it was made clear to us that we were in competition with every other project group in this class, we never considered giving false advice, or refusing to help fellow classmates when they asked for help, because in the end, we are all just here to learn from each other.

Legal Considerations

Our transmitter is not creating a signal strong enough to cause any harmful interference to anyone, save fellow students inside our lab who are transmitting on the same frequency. Nevertheless, we accept the restrictions the FCC places, such as the rule that we must accept interference from authorized radio stations.

Appendix A

Appendix B

Budget

Item	Quantity	Price
Mega32	3	$24.00
Custom PC board	3	$15.00
Large solder board	1	$2.50
Small solder board	1	$1.00
9V Battery	2	$4.00
B/W TV	1	$5.00
Transmitter RCT-433	1	$4.00
Receiver RCR-433	1	$4.00
DIP socket	3	$1.50
Header	13	$0.65
Project Box	1	$3.00
MMA6261Q Accelerometer	1	Sample
MMA1260D Accelerometer	1	Sample
Battery Connectors	1	Salvaged
Wrist Guard	1	Salvaged
Video cable	1	Salvaged
Buttons	2	Salvaged
	Total	$64.65