Integrating software & hardware in a way that is nothing short of perfection.

UART Data Transfer and Laser Install

CSE181A Winter 2011

Progress Report for Week #7 (2/9/2011 to 2/16/2011)

Project Title: Super Spray

Wow!  We’re done with week 6, and into week 7.  That means we have just over two weeks left to have Super Spray up and playable.  This week one more part was carefully placed into the gun – the laser.  The hole in the plastic used to be used for the hose that sprayed water.  That was removed so that the laser could be inserted.  However, the hole needed to be widened.  This was tricky given that this was a part of the gun right where the two halves of the casing came together.  We drilled it out a little bit bigger, and again used expanding foam to fill some space and hold the laser firm.  It had to also not extend out from the front of the gun so that the orange cap which helps hold everything together could still be screwed on without having to cut it.  Here’s some pictures of the mounting.

The two halves of the gun frame, and the hole drilled out where the laser is to be mounted.

The laser fits! (inserted backwards just for size testing)

Laser mounted in the expanding foam. This was tough to align straight.

When the orange end cap is screwed in, the laser is right in the middle and not blocked.

Overhead shot.

We were able to find a UART C++ library for use to interface our game’s software with our hardware gun controller.  The library uses a header file and a cpp file to interface with the COM port that we specify.  Here is a link to the information about the library.  As it stands, we have successfully sent data to and from the microcontroller and PC.  The way that data is interpreted however, is interesting.  For example, if we send a char ‘p’ from the microcontroller to the console of our C++ program and print it, it will print a character ‘p’.  As expected, if we send a ‘p’ from the PC to the microcontroller, and print it on our LCD, it will print a ‘p’.  Now, here’s where it is interesting.  Most of the data we’ll send from the PC to the microcontroller would be integers, and most likely over 255 (more than 8 bits).  So, if we send say, the value ‘109’ from the PC to the microcontroller and print it, it will still print its character representation, in this case an ‘m’.  The data is still there for us to use as an integer, but if we wanted to print a current score value of say, 1250, we would have some problems.  One, thats more than 8 bits, (greater than 255) and so it would need to be sent in chunks, and also each digit would have to be cut and printed as a char, to our LCD so we could display the high score.  This is partially a UART problem, and partially an LCD problem.  We almost have to create an API for our LCD to be able to pass in an int value, and peel off each digit and convert them to chars to print it on the screen.  But at the same time, we can’t even pass a numerical value greater than 255 since that’s the limits of UART.  Of course, we can and will have to break up the data transmission into fragments.

We created a method for bluetooth data transfer that is sort of it’s own protocol in a way.  You see, our microcontroller sends very simple commands to the computer to tell it what’s going on.  It will send a char ‘p’ when the trigger is pulled, an ‘e’ when the trigger is pulled with no ammo, and other simple one byte (one unsigned char) data transfers.  The computer will do the same.  The problem is as follows:  Lets say we want to send the player’s current score over bluetooth, which is 112.  When that is sent, how are we to know if it is a ‘p’ being sent, since the ASCII value of ‘p’ is 112?  We cannot determine this.  So, this is where our protocol comes in.  We have written a method for the PC side that when sending data over one byte’s worth, (an int, as an example) it will break up the data into three bytes and send them.  However, we have to have a start and stop byte so that our microcontroller knows to think of that data not as a character, but as an int so it can reassemble it on its own.  So to send a 3 byte piece of data, 5 bytes are transferred.  We appropriately chose the ASCII value 123 and 125 as our start and stop bytes, which are the characters ‘{‘ and ‘}’ respectively.  The maximum size value we can send is 999,999.  Here is an example call:

// convert a score of 125,475 to be sent PC –> microcontroller to be displayed on the gun’s LCD
unsigned char currentScore[] = convertForSend(125475)

If we were to print the output of each element in currentScore[], it would read out as follows:

currentScore[0] = 123 // ASCII value of ‘{‘
currentScore[1] = 12
currentScore[2] = 54
currentScore[3] = 75
currentScore[4] = 125 ASCII value of ‘}’

On the software side this week, we focused on getting the calibration screen fully functional, but proved to be somewhat problematic to get there. First, the graphics were laid out and drawn, which currently only include text and an arrow pointer. The arrow proved to be easy enough. The text, however, was not. OpenGL does not include a robust font displaying system in it’s core framework. It had to be constructed from scratch with all of OpenGL’s other functionalities. Getting the letters to display was fine, which can be easily done with a call to glutBitmapCharacter(). It was actually moving the text around the screen and getting a whole string to be displayed using a char method that provided issues. The limitations of not fully understanding C++ was actually the result of a couple of the problems that we were experiencing with the text display methods. Throughout this process, we have been slowly learning more and more about the C/C++ framework and have been using what we have learned to optimize our program. However, “strings” and pointers are somethings we still do not yet have a grasp on. We know that they are handled differently then how Java would handle “Strings”. However, we were able to solve our issue by simply passing in our string as a char array. This allowed us to print each character in the string character by character using the above OpenGL method. The other issue we experienced dealt with was with moving the text around. Initially, I tried moving the text by using “glTranslated()”, which is what I use to move any other graphic on the screen. However, this function does nothing to the text that I displayed. It eventually took some researching online to find that “glRasterPos2f()” is used instead to be able to move text generated through “glutBitmapCharacter()”.

The other issue I experienced dealt with the actual calibration of the screen. Getting the graphics to display correctly to point where the user should aim to calibrate the screen proved harder than expected. It took getting the width and height of the screen once again to move the arrows to their correct positions on the screen. Still don’t fully understand it (Currently researching) but for some reason “glutget(GLUT_SCREEN_WIDTH)” and “glutget(GLUT_SCREEN_HEIGHT)”can only be stored in a “#DEFINE WIDTH” and “#DEFINE HEIGHT” call. Simply storing them in, for example, “const double WIDTH” does not work. Doing it this way only makes the variable store 0. Currently it is set to the working version, but am looking into better ways to accomplish this.

Goals for Hardware This Week

  • Write the receiving end on the microcontroller side of the function above.
  • Be able to take the individual bytes, carve up that further into one digit at a time, and correctly display onto the LCD.
  • Flesh out what data exactly needs to be transferred from PC to microcontroller and vice versa.
  • Merge this serial code in with the actual game code.

Goals for Software This Week

  • Add sound to the project. We are currently researching into Microsoft’s PlaySound function or fmod (which is known to be the go to framework for adding sound to games).
  • Work on and finish the start screen, which in turn adds our high scores implementation to the game.
  • Add scoring to the game. Hitting targets increase the score and gets added to the high scores chart in the end if the score is high enough.

Last week we installed the accelerometer in our pump, and we shot a quick video showing that in action.  We also have the second accelerometer wired up to detect the difference in the entire gun assembly moving, versus only the pump.  Watch below.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s