Introduction
This project simulates 9 holes of a minigolf course using the TV to display the course (top down view), an anchored plastic ball containing two accelerometers, and a putter. Summary
We used a hollow plastic ball containing two accelerometers for each planar axis with the ground, and anchored it to an object above it so it would swing in a pendulum motion when hit, eventually settling back into the same position it started out with. The accelerometers were hooked up to the ADC converter on the prototype board and interpreted with a single Mega32. A different Mega32 would be used to control video output, displaying a top down view of the current course the user was playing, along with a ball. The Mega32 programmed with the ADC converter would constantly communicate with the video Mega32. 
The ADC converter would detect drastic changes in the voltage output from the accelerometers, and use that output to determine the speed at which the ball will travel from its resting location. A stronger putt will result in a greater acceleration, resulting in a greater output from the accelerometer, which translates to a faster moving ball on screen. The magnitude of the accelerometers will also determine the direction in which the user hit the ball, creating a velocity vector using the readings from the two. We chose to do this project because we wanted design some sort of video game using the microcontroller. After discussion, we felt that this particular project integrated a good bit of software design with some hardware design â the combination we wanted. II. High Level Design Our idea came from a brainstorm session, but the initial concept was to use lasers in sequence that would detect the velocity and direction of the swing. This would allow driving and other higher power swings that might otherwise damage or destroy a set of accelerometers. However, due to the unanticipated high cost of lasers and sensors, the idea was eventually scrapped in favor of limiting the game to mini-golf, which doesnât require as powerful of swings, so that we could use the accelerometers instead. The math behind this was fairly simple, using the concept that a force is an acceleration, which translates to a velocity. Other math involved included collision physics for the ball colliding with the course walls. Our courses consisted of horizontal, vertical, and perfectly 45 degree diagonal walls. This would result in collisions where the x or y velocity vectors would be reversed (with vertical and horizontal walls) or the x and y velocity vectors would be reversed and switched (with diagonal walls). However, the accelerometers only reacted to changes in its alignment in a certain direction. We tethered the ball containing the accelerometers to a string so movement in a direction would give it a pendulum motion in which the internal accelerometersâ alignment would change. We then oriented the two accelerometers in two different directions so one accelerometer would react to changes in alignment in one direction while the other in the other direction. When the program starts, the first course is displayed on the screen to the user. The program waits for the user to strike the ball. This is monitored by the Mega32 on the protoboard. The inputs are sent over the ports to the STK 500 Mega32 and the velocity of the ball is computed. The user is then showed the ball moving on the screen until drag forces stop it. The total number of shots are displayed on the screen and is incremented each time the user shoots. When the ball stops moving, the user can shoot again. Once the ball moves over the cup, the user moves on to the next hole. The hole is displayed on the screen and the procedure repeats. Once the user completes the last level, it shows the userâs score and the current low score. The user is told if they have the all-time low score on the course. III. Program/Hardware Design Program Details
For the ADC converter, we had to design the program so that it would alternate between the two accelerometers on each read. The program would then constantly take two running averages of the previous ten values that were read from each accelerometer. Once there was a value read that was greater or less than a certain threshold from the average, then the program would go into âhitâ mode and begin recording either the min or the max value that the accelerometer achieves and gather the reading from the other accelerometer at that point. The program will continue to do this until the accelerometer returns to close to the previous resting average value. Up until this point the ADC polling program was constantly outputting the resting averages through a port for each accelerometer, which would be read by the other Mega32 that was writing video code to the TV. Once âhitâ mode is completed and the max or min value has been gathered, the program will then output these gathered values through those same ports (C from protoboard to C on STK500 and D from protoboard to A on STK500). The other Mega32 is rendering video to the TV. It is rendering a top-down view of the putt-putt courses featured in the game, as well as a pixel representing the golf ballâs position in the course. This program is also reading in the accelerometer values from the other Mega32. Once it detects a great change in the readings, which is when the other program will start outputting its gathered reading due to a hit, it will take these values and convert them to velocity vectors. This will in turn affect the ball on screen, moving it in the direction of the velocity vectors. There is also a drag factor that affects the velocity, slowing the ball down over time. For collisions, when the ballâs next (x,y) position coincides with a colored pixel, which would be part of a wall, then the program looks for pixels around the collision pixel. This corresponds to a vertical (pixels directly above and below), a horizontal (left and right), or diagonal (offset above and below). The program will then change the velocity accordingly. Once the velocity of the ball goes back to zero due to drag forces, than this Mega32 will output a signal to the other Mega32 signaling it is ready for another hit. The other Mega32 will then begin gathering a running average for the resting value again and wait for another drastic change in the accelerometer readings, signaling another hit. Now that the ball can be moved based upon hardware input, it must interact with the course. The course is composed of horizontal, vertical, and 45 degree lines. The code checks the current pixel location of the ball and its surrounding 8 pixel neighbors. For instance, when the ball intersects a horizontal line, the western and eastern pixels relative to the current ball location will also be colored in by the line. This works well for horizontal and vertical lines, but diagonal lines turned out to be difficult. That is one reason we decided to do only 45 degree lines. There are only a few cases that we need to check with 45 degree lines. We handle the intersections of lines on a course by course basis. We found this to be the easiest way to deal with the few corner cases that arose on each level. Hardware Details We used an STK500 and a protoboard each mounted with a Mega32, along with several connectors to connect ports together so the Mega32âs can communicate with each other. We used two accelerometers (Freescale â part no. MMA1260D) and mounted them inside two hollow plastic hemispheres which we then glued together to form a ball. We then ran wires out of the ball connected to the vital pins in each accelerometer and connected them to the protoboard that housed the Mega32 that would be used for ADC. The other Mega32 used Port D and a set of resistors to output a signal to the television to render the courses and the ball. We originally tried to keep the ADC and the video rendering on the same Mega32, but that meant that we could only gather values from the accelerometer through the ADC at the framerate that the video code was outputting to the screen (or else tearing would occur). This proved to be too slow to reliably read values from the accelerometer, so we opted to use another Mega32 to purely read values from the ADC as fast as it can switch between the two accelerometers. Discarded Ideas We had many different ideas on how to input the swing from the user. As was mentioned earlier in this document, we were going to try to use lasers to time the velocity of the swing and its angle. However, after ordering a couple laser diodes and examining how we wanted to get the project to work, this idea had to be thrown out because of cost. These parts still contribute almost $15 to our overall total cost that we are not using. A second idea was to use pressure sensors on either end of the club head to determine how hard each side of the club was struck. In this manner, we thought we could determine the relative angle at which the ball should move and its velocity fairly well. However, we did not have the correct pressure sensors in lab, and these would also have been costly to order. This led us to use the Freescale accelerometers donated to the lab to sense the motion of the ball. As stated before, two 1-axis accelerometers still do not provide us with great accuracy.
Borrowed Code / Ideas
Video code used in this lab was based upon code provided by Professor Bruce Land in this document. The code to output to the screen and interact with output that has been placed in the buffer to the screen are his. Also, he designed the character sets that output to the screen. Our code uses this base to output our courses and text / data to the screen.
 Parts List:
For more detail: Mini-Golf Simulator Using Atmega32
