Dino-Nils Project Description

---

Introduction

This project is based off of Google's no wifi game that involves a cartoon dinosaur running in the desert and the player using either the up arrow or spacebar to hop over cacti and the down arrow to duck under birds. To reach the original chrome game, type chrome://dino into the chrome browser. Our take on it replaces the dino with a picture of Professor Nils Napp and the cacti with various obstacles we faced in this class. However, instead of using the keyboard to control Dino-Nils, we use the accelerometer on the freedom board, with a twist forward triggering jump and a twist backward triggering duck. We also used one of the on-board buttons to restart the game.

During this project we learned how to use and access data from the on-board accelerometer, how to use the on-board push buttons, and how to use serial communication, more specifically the I2C and UART protocols to get data from sensors to a USB port on a laptop. Tools that we learned in class to enable use to accomplish these goals include, polling, interrupts and interrupt handlers, and concurrency.

System Overview

System Description

In our main file, raw data from the on-board accelormeter is read via polling, which is a while loop that runs indefinetely. This gives us an x, y, and z component. For this game, if the x component is greater than 1800, or when someone tilts the board ~90 degrees forward, we consider that as a "jump". Likewise, if the x component is less than -1800, or the board is tilted ~90 degrees backwards, we consider that a "duck".

To send these commands to the front-end GUI, serial is used. We specifically use the UART protocol to send strings from the board to the game GUI. The string "FORWARD" was sent to signal a jump and "BACKWARD" was sent to signal a duck. Because serial is a bit by bit communication protocol we sent each message char by char. All UART communication was sent from the board to a USB port.

In the Python GUI, we used the PySerial library to read input data over USB and initialized serial communciation with the proper port. In our case, we used COM14 with baud rate 9600.

The last control we added was to set up one of the push buttons on the board, SW2, to signal restarting the game so we didn't need to restart the Python GUI everytime we collided with an obstacle. The push button, SW2, acts as an interrupt, meaning that whenever the button is pushed, the main program stops what it is doing and enters the PortA_IRQHandler. In the PortA_IRQHandler, we send the string "RESTART" over UART to the GUI and we toggle the Red LED on the board to signal that the game has restarted.

In addition, when the accelormeter first starts polling, it concurrently blinks the blue LED five times to signal to the user the controller is working.

For the GUI, we used the python library, PyGame, which is a popular libary for simple GUIs. Within the GUI, we created three separate classes for the obstacles (for small obstacles, bigger obstacles, and for the aerial obstacles). We made sure to randomize the spacing between each obstacle to make each round different. We also keep track of the score and the highest score. The highest score is kept for each session no matter how many times you restart, but is locally saved so once you kill the python script it is lost.

One problem we ran into was the debouncing of the accelerometer data and the fact that the rate that we poll from the accelerometer is not nearly as quick as the GUI frames per second. This meant that initially, our movements were very glitchy when we tried to jump or duck. Everytime we tried to control Dino-Nils, the movements wouldn't be continuous or fluid, and the entire game lagged. To solve this, we set up another interrupt for the jumps/duck. Each jump/duck is around 1/4th of second, so this interrupt counts, using the PITTimer, to 1/4th of a second. Every time it hits 1/4th of a second it toggles an unsigned int from 0 to 1 or vice versa. Once the board has sent "FORWARD" or "BACKWARD" it must wait for the unsinged int to toggle for it to start polling again, which slows down the jump/duck signals to a reasonable pace and effectively debounces the controls.

Testing

The first step we took with this project was to work on the GUI. Before integrating the entire game with the FRDM board, we made sure that our game was fully functional with simple keyboard inputs to ensure this section was solid before integrating with FRDM board input.

As for the accelerometer data, we tested the correct jump and duck thresholds by printing the raw accelormeter data onto the Putty Terminal. The thresholds for the jumps and the ducks were determined qualitatively; we looked at the raw data as we tilted the board and then decided what tilt angle was sufficient. We then tested our threshold and the button interrupt individually by verfiying through printing on the Putty terminal that "BACKWARD", "FORWARD", and "RESTART" were being sent at the correct times.

The final test involved integrating the board and the GUI together and playing the game ourselves!

Resources

The Uart, I2C, and acceloremeter code was given by the TA's.

The restart button code was written by referencing a post in the ARM community discussion site linked here.

The PyGame Library was used and documentation can be found here.

Resource used to get vertically centered columns on the website here.

Work Distribution

This project was done using peer programming, where we worked on one laptop with one person coding and the other person providing input and feedback. We tried to split up the work as much as possible, and used Zoom to screenshare so we could work together effectively.

When things did not work properly, both members of the group worked on debugging. The code and design and testing were all done together. The website was split in half -- we delegated different sections to each member to ensure that we had an even work distribution.