Soccermania video game using Atmel Atmega32


This ECE 476 Final project is an interactive soccer video game designed and built by Cornell students and soccer enthusiasts Ozan Mutluer and Erinc Tokluoglu. The game focuses on a penalty kick where the user is to enter the direction of the shoot by a keypad and the power and inclination of the shoot through hitting a real soccer ball. The ball is moves on the screen with the relative speed that the user hits the ball. The shoot is either a goal, an out or is saved by the goalkeeper. The goal keeper is designed to mimic an artificially intelligent unit. The game ends when the user succesfully scores 5 goals.
Soccermania video game using Atmel Atmega32

High Level Design

Rationale and sources of your project idea:
The main reason we decided to work on this video game as our final project, was to create a unique, life-like simulation of a physical sport which the game player can experience as closely as could be achieved by a processor-user interface. Our idea was to create a simulation of soccer, more specifically penalty kicking, that was as close to the real thing as possible. The consoles used in regular soccer games are all button based and nothing compares to the actual thrill of hitting the ball yourself and seeing it go into the net. To achieve this user-processor interaction to enable real life soccer playing experience, we decided to look for ways of interfacing a regular soccer ball, as a user input source, with the microcontroller. To achieve this, we decided to work on a novel hardware design, making use of sensors, which would enable the user to input initial ball velocities, through an accelerometer, to the microcontroller, that would be efficient, safe and accurate enough to be suitable for enjoyable game playing.
Background Mathematics and Physics:
Our soccer game, Soccermania!, employs some of the basic principle of Newtonian physics, namely momentum transfer and projectile motion. These notions are well known to all of us, probably from high school or freshman physics, but a basic review of these notions here, will help make clear the logical structure of the code we used for this simulation.
Impulse as you know is defined as the instantaneous change of momentum, given by:

As seen above impulse is given by the applied net force on an object, multiplied by the time of contact with the object, resulting in a change in the momentum vector of that object. Force and momentum are defined as below:

Applying these definitions to our initial impulse equation yields:

The above equation relates change in velocity to acceleration multiplied by a change in time. We can use this basic physical principle and an accelerometer that can yield results both in x and y axis, to calculate the initial velocities of the ball in the x and y planes and then determine its trajectory, through another basic equation of physics, the all too well known projectile motion equation given below:

Here p(t) represents the position of the ball as a vector in the x,y plane, with px(t)=Vxt determining its horizontal position and the expression py(t)=Vyt – (1/2)gt^2 determining the position of the ball in the y-axis. Hence if we manage to read acceleration values in 2 directions, we can pin point the position of the ball in time. The time we are especially concerned with is the time when the ball reaches the goal, given by:
t = X/Vx , where X is the distance to the goal and Vx is the speed parallel to the x-axis.
The Logical Structure:
The logical structure of the project can be summarized in three main categories. The 1st priority is to come up with a hardware set up, that can accurately detect changes in acceleration and allow accurate, efficient sampling, with safety notions nagging in our heads as we are kicking a real soccer ball in lab. This includes a basic setup for stabilizing the ball without significantly hindering its motion, positioning and orienting a two-axis accelerometer, and sampling 2 different readings from the accelerometer procedurally and simultaneously, trying to achieve a level of efficiency that allows simultaneous readings from both axis, without missing the peak readings of any of them. Our user interfacing also includes a keypad, which has a very simple scanning routine, which upon the pressing of two designated buttons changes the direction vector of the ball. The second priority is to use the data, to calculate or determine direction vectors, scalar speed values, pixel speed values and designated coordinates on the screen where the simulated ball is supposed to go. This has to be done in such a fashion, as will be discussed later, to compensate for slowness and memory considerations of floating point calculations, which require a lot of instruction cycles and memory, so that they can be done within our delicate timing limit of 60 lines per frame, using 16-bit fixed point macros which will be discussed when we refer to the details of our code. The 3rd priority is the game playing, drawing and erasing of figures and updating of images every frame. We have an elegant frame-timing setup that handles initializations, calculations, point settings, and image handling in separate frames, so as to maximize the allowable instruction time to prevent possible artifacts. This scheme is based on a game-playing state machine, with each state having a specific purpose. In fact we are proud to say, that the way our code is organized fully optimizes the microcontroller and is able to handle a good amount of image printing and calculation. The general setup of the user interface, namely the accelerometer and the keypad, interfaced with mcu with its output to video is provided below.
Hardware Software Tradeoffs:
Due to the positioning of our user ball controller, the accelerometer needs an amplification of at least 4 fold. One basic way of doing this was simply using 2 non-inverting op-amp based amplifiers. This notion, although trivial, would save us a 2 shifting instructions but due to its insignificance it was not carried out. We are not using the ADC in a differential mode that supports input gain, so required signal amplifications were carried out simply in software.
Relevant Patents:
Upon a little bit of internet surfing, we found a game that utilizes a similar notion of game play. The name of the product is Soccer-Penalty Shoot Out Game, for more information here is the link to a website where the game can be purchased online:

Program/Hardware Design

Hardware Details:
The hardware interfaced with the microcontroller in the input end consists of a keypad and an accelerometer. The keypad is used to determine vector direction of the ball. The accelerometer we used for velocity inputs was a MMA6261 XY-axis, 1.5g Acceleration Sensor from FreeScale.
Soccermania video game using Atmel Atmega32
The MMA6200 series accelerometers from FreeScale include 1-pole low pass filter for noise reduction and temperature compensation with an output current range up to 200Μa, also sustaining capacitive loads. At full swing it can measure accelerations up to 1.5 g in the two axis of the horizontal xy plane. It has a 2.7V to 3.6V low power operation. Here is the block diagram for suggested way of interfacing the accelerometer with a microcontroller:

Parts List:

For more detail: Soccermania video game using Atmel Atmega32

About The Author

Ibrar Ayyub

I am an experienced technical writer holding a Master's degree in computer science from BZU Multan, Pakistan University. With a background spanning various industries, particularly in home automation and engineering, I have honed my skills in crafting clear and concise content. Proficient in leveraging infographics and diagrams, I strive to simplify complex concepts for readers. My strength lies in thorough research and presenting information in a structured and logical format.

Follow Us:

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top