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

Latest

Demo Day!

Today was demo day!  Here’s a video and some pics of the day.  Everyone seemed to enjoy the game and it worked great!

This was our setup. The projector with the webcam is on the left, and a laptop running the game is on the right.

Our game on the wall.

Our poster we had out on display.

Advertisements

Final Development Week: Part 2

CSE181A Winter 2011

Progress Report for Week #10 – Part 2 (3/10/2011 to 3/17/2011)

Project Title: Super Spray

As I write this on Thursday night, 3/10, it is our last chance to make improvements to our project before the expo on Friday.  The gun is completely build and working!  Wow what a long process it was.  I thought it was going to go relatively smooth, but I hit some hiccups on the way.  Our RapidTech enclosure for the LCD that hangs off the side of the gun had a design flaw that required us to cut off a corner.  Then I made some stupid mistakes running the LCD’s wires which delayed me and resulted in cutting and soldering and labeling more than I would have liked.  Wire management was overall a pain, it turned into a mess.  On top of that, the pump has wires that come out of it to the accelerometer.   Every time the player pulls the pump, the wires become tight inside the gun, and when they push it back, all of the wires have to have somewhere to go inside the gun.  The wires can’t get snagged on anything or it would be a recipe for disaster.  Enough talking, let these pictures speak for themselves.

I taped the microcontroller down for the first few wires so that it would stay in place.

Crystal added.

When things were neat and organized! Too bad it didn't stay this way. Lot of components in a fairly small space!

The accelerometers are soldered now too. (Top right pins)

Getting a feel for how all the components should go in.

My lower back was killing me because of this position right there. Note to self: use a work bench at the proper height when working for extended hours.

LCD is soldered in as well. (bottom right pins)

Perboard in place to get a feel for how much room I still have left to work with.

Once the LCD was introduced, it added 16 more wires to this mess, and made it difficult to manage.

During the gun building process, Adrian showed some frustration over a bug in the game's code.

A seperate, smaller perfboard was used to manage all of the power. Shown from left to right is a 5v voltage regulator, 3.3v voltage regulator, and a PMOS used to turn on our motors for vibration.

Another progress shot.

This is the LCD case we had printed by RapidTech and designed by Adrian's brother, Alvaro.

We did have a design flaw on our part with this case, we didn't allow for enough room for the wires to pass through. It would have been a simple fix and a reprint, but short on time we were forced to just cut out a portion. It turned out to be not that noticeable as you'll see later.

Drill out the decorative tank for the LCD to pass through.

Drilled through the actual body of the gun.

We hacked off the extra length of the LCD case's wire holder. We weren't sure how stable it would be, but it seemed good enough.

Getting ready to mount to the side.

Different angle.

Mostly everything ready to go in place.

Our smaller perfboard reserved for power. This thing got a lot of use! So many components needed power and ground. While I did piggy back a lot of wires to reduce clutter, there was still a lot going on here.

Near final pic after all wires are connected. Perfboard isn't secured with expanding foam yet.

Microcontroller inserted into the socket!

Final shot before enclosing. The decorative tank's other half has been put on to cover the microcontroller. Wire management is still a little out of control, but I did split-loom the cable that we can use to program the microcontroller. By default it is housed in the real tank in the back.

The 9v battery back is attached using velcro. It seems solid enough to withstand the shaking from the game.

This LED is lit when the bluetooth is connected to the game.

The LCD screen to serve as the player's "HUD"

To avoid burning out our laser, we added a button to turn it off and on in between games. This is nice because you don't have to powerdown the whole system, and in turn disconnect bluetooth.

Underside.

What the player sees as they look down the side.

And it's done!

And here is a video overview of the gun to give you a better idea of what it looks like and how it feels.

We will be updating our blog again soon with pictures and results from the senior design demo day!

Final Development Week: Part 1

CSE181A Winter 2011

Progress Report for Week #10 – Part 1 (3/2/2011 to 3/9/2011)

Project Title: Super Spray

It is week 10 of Winter quarter 2011!  Our senior design project has to be demoed to the university’s senior design showcase on Friday, March 11th.  That means that this week we need to get everything wrapped up, working, bug free, and presentable.

One thing we have struggled with was how we detect our laser on the screen.  We were taking an image captured from our webcam, converting it from an RGB to an HSV image, and checking a range of values that was the color of our red laser and creating a binary image of that threshold, and detecting the points in that image.  This worked – when we got it right.  Using HSV values was really problematic, and basically guess and check.  It was also very sensitive to the room’s lighting conditions, and seemed to vary in its effectiveness day to day.  We did some optimization to that OpenCV code early in the week, and instead of converting to HSV, we left the image as RGB.  Then we took a screenshot of what our laser looks like on the wall to our webcam.  We opened the screenshot in Photoshop, and used the color dropper tool to get precisely what color our laser was on the wall.  We changed the range of values to reflect those values, and we got a MUCH better and more reliable threshold image.  We didn’t have to be nearly as careful as what was used in our game anymore either.  Before we couldn’t use too bright of colors, whites, or anything even close to red or even other colors that were bright.  Now we pick up the red laser, and only the red laser.  It’s so much better!  The only thing is if the laser is on a target, say a “green” target, the color that the camera sees from the laser is a mix of green and red and appears brown to the camera, so we no longer detect the laser.  We remedied this problem by having all of our targets be outlines only, so that the laser is always on a black background.

Even though we were detecting our laser correctly, we still had an issue calibrating the screen.  We were baffled as to what in the world our webcam was doing when capturing points… it just didn’t seem to make sense!  At first we thought that our points were being flipped horizontally because when we shot the left side and then the right side of the screen to calibrate, we noticed if we printed out those values that they weren’t correct.  After literally hours of debugging, printing the console, researching known OpenCV bugs with our webcam, we realized that the sample code from OpenCV that we used to start was constantly using a threshold image of the previous frame.  When running the sample code, in its own project and looking at the threshold image in real time, everything looked normal because of the high framerate, and we couldn’t tell that the image being displayed was one frame behind where our laser actually was.  As soon as we used our code, which only captures a frame when the trigger is pulled, the error became obvious.  So now, every time our trigger is pulled, we capture two frames, and just through away the first, and use the second.  This has solved our problem of getting incorrect coordinates.  Now our game is calibrated well, and the laser is detected perfect.  Our crosshair appears right where our laser is, and is very reliable.

 

A demo "game". The circles are dummy targets. The blue crosshair shows where the laser was last detected when the trigger was pulled. This works fantastic right now!

After that, the next step was to get the game running not off of our computer’s keyboard, but actually off of our bluetooth data sent from the microcontroller.  This code was finished about two weeks ago, and it was just a matter of integrating it in to the project.  We added a gluttimerfunc() in OpenGL, and poll for bluetooth data inside.  The fastest our microcontroller will ever send data is once every 100ms (the debounce for holding the trigger), so we check the incoming data bluetooth buffer at the nyquist rate of 50ms.  Merging the bluetooth code into the game proved to be pretty seamless.  We did add the ability to tell the microcontroller if we were calibrating the screen or playing a game, and changed the debounce time of the button accordingly.  We wouldn’t want a player to be trying to calibrate the screen and shoot once and have it pick more than 1 point without giving them a chance to re-aim.  Also, if the player is on the start screen, and wants to recalibrate the game, they can simply shake the gun and it will bring them back to the calibration screen.

 

Direct screenshot of what our calibration screen looks like. Note: this screenshot is taken at 1920 x 1080 PC monitors resolution, but when our game runs on a projector, it will be 800 x 600.

The actual calibrating process as tested in Jared's dorm room on a wall with a very makeshift projector screen.

Our "main menu". In the final game, this will show a high score list as well.

A direct screenshot of our "main menu". Note: this screenshot is taken at 1920 x 1080 PC monitors resolution, but when our game runs on a projector, it will be 800 x 600.

Another exciting thing that happened this week was that we received a finished rendering of our case for our LCD that will be used to hold the LCD to our gun.  Alvaro (Adrian’s twin brother) really did us a favor by designing this and it looks great.  Below are pictures of the case.  It is two pieces, a top and the bottom, which will be held together with four screws.

This is the bottom. We'll lay the LCD here, put on the top, and screw it in. The pole on the right side will go into our gun and be clamped on the inside.

The top portion of our case. Has the engraving "Super Spray" at the top and room in the housing for wires.

Coming up in the next 2-3 days we have to finish 100%.  Middle Earth is an undergraduate student housing complex at UCI, and we are both on staff.  Jared is the RA of the dorm “Evenstar” and Adrian is a Middle Earth attendant and works at various facilities around the complex.  We both live in Evenstar and plan on letting the residents test our game before Friday as a last chance for us to find any bugs and take criticism from an audience.  We’ll be back with pictures and video from that experience as well.

Gun Nears Completion

CSE181A Winter 2011

Progress Report for Week #9 (2/23/2011 to 3/2/2011)

Project Title: Super Spray

Since it is week 9, we were totally swamped with projects for other classes, and so there’s not a whole lot of major progress this week on the hardware front.  The gun continued to get prepared for the permanent soldering of the parts onto perfboard.  We can’t take all of our hardware components off of the board and put them into the gun until we know our game works on the breadboard, in case we need to make any hardware changes.  Our game isn’t in a running state right now, so we can’t do that yet.  One thing we wanted to do to give our project more flexibility was to make it so that even when the microcontroller was mounted in the gun, that it could still be reprogrammed, in case of any bugs or feature additions.  Our AVRisp mkII programmer has six pins: GND, Vdd, MOSI, MISO, SCK, and the reset pin.  So, we picked up a cable used to connect power supplies to motherboards in computers.  It is an 8 pin EPS12v power  extension cable, so there was enough pins for us to use.  I cut the extension cable in half, and extended the wires.  One end will go to the microcontroller’s respective ports, and the other end will go into the AVRisp mkII programmer’s plug.  Here’s some pictures illustrating the process.

This is the cable and connectors. On the right is the male end, and is what will be coming from our micocontroller.

This is the cable as it will be coming out of the back of the gun. The cable will be in the back tank when it is in normal use. If it needs to be reprogrammed, we can unscrew the back tank, grab the cable, and plug it into our programmer, and write a new hex file to the microcontroller.

The microcontroller is going to be housed in what looks like from the outside to be a dummy water tank.  It’s just a plastic sphere with two halves that can be unscrewed.  It takes up a lot of space, so we decided to use it to house components.  In order to be able to use the microcontroller inside, we cut our perfboard to fit in the sphere.  Wires obviously need to escape from this housing, so we cut holes, 4 total, 2 on each side to be able to route wires to either the back of the gun or the front of the gun.

The perfboard that our microcontroller will be on is shown here inside of the green sphere. The other perfboard will house any other components as needed.

These are the holes in the microcontroller housing for wires going to the front of the gun.

These are the holes in the microcontroller housing for wires going to the back of the gun.

We’re still trying to get a case made for our LCD so that it looks clean, and so that it has something we can use to mount it to the gun.  We’re looking to have RapidTech, which is located at in Engineering Tower here at UCI, 3D print our modeled case.  We will most likely have it made with ABS plastic.  Adrian’s twin brother, Alvaro, is an Architecture major at the University of California, Berkeley and graciously made this design for our case.  Thank you Alvaro!

This is 3D render of the LCD case. Note the screw holes. It will be two pieces, front and back so that the LCD can be inserted. The wires from the LCD will have room in the bottom.

Here is a wireframe model of the case.

As for the software, progress has been going at a steady pace. This week was spent on optimizing the code that was already written. The reason for this is because we ran into a technical issue this week that we are in the middle of correcting. The problem we have deals with the webcam failing to correctly find the red laser on the wall when the projector is also on. When we tried our initial testing, we  had the webcam detect our laser without the use of the projector. This provided us with great results in the laser detection. However, when testing with a projector, our detection results become really unreliable. The coordinates move all over the place. Ultimately, we decided to go back to our code and see if the issue could first be corrected there before actually modifying the design of our game in order to obtain a greater result from the detection.

Programming the game code has also been going well. No problems have arose here so far. The main accomplishment of the week so far was combining the Highscores class we created with our Start Screen code, so that users will be able to see who is on the highscores list while they are on the main menu. It lays the framework for creating a score item that will be attached to the current user when starting a game session. This will essentially map the player’s actions to their score and keep track of it until the end of their session, at which point will add to the high scores table if it is high enough.

Hardware Goals for This Week

  • FINISH!  The gun has to completely done.  Parts need to be taken off the breadboard, soldered in, bluetooth mounted, the accelerometer needs to be mounted, the pump inserted, the LCD needs to be attached, etc.

Software Goals for This Week

  • Fix the technical issue. This is of the upmost priority right now. If we have this done, we will be in a position to showcase a running demo of our project.
  • Continue working on the game code.

Bringing the Gun and Game Together

CSE181A Winter 2011

Progress Report for Week #8 (2/16/2011 to 2/23/2011)

Project Title: Super Spray

This was a pretty exciting week for our project.  Our major, Computer Science and Engineering, according to the Donald Bren School of Information and Computer Science is “designed to provide students with the fundamentals of computer science, both hardware and software, and the application of engineering concepts, techniques and methods to both computer systems engineering and software system design.”  This week, that statement became a reality for us.  I literally had two IDE’s open, one developing the PC client side of bluetooth data transfer, and the other programming the microcontroller directly and working with how data transfer is managed on the hardware end.

When we envisioned our system for how the game would work, we knew the proper engineering approach was to have the microcontroller simply read the sensors, send the PC the data, and have the PC make the decisions for what happened in the game.  This is the most flexible solution, because once the hardware portion is complete, any changes that might need to be made after testing the game can be done on the software side, rather than re-programming a microcontroller.  In practice however, we weren’t sure if this was possible.  Having never worked with serial communication before, we were not sure if it would be possible to send this magnitude of data at high speeds to keep the gun and game in sync with each other.  Things continued to look bleak when we couldn’t get the bluetooth working for a while.

Once bluetooth was working, we wanted to just get a rudimentary implementation of our game up and running.  In order to do this, we made it so the microcontroller simply sent one signal to the computer, the character ‘P’ for when the trigger was pulled.  This ended up consisting of the microcontroller doing a whole lot of game data processing that we didn’t really want it to do, including keeping counts for how much ammo was left, the score, and other things that really should have been handled by the game’s code itself.  It didn’t make sense to have portions of the game scattered between hardware and software.

This week, we got our hands dirty with the Bluetooth communication and refined our hardware’s code, and wrote a clean set of C++ code for the computer that links the two together very well.  Now, our gun sends data to the computer, and the computer decides what happens, and constantly updates the microcontroller as to what is going on.  Here is the breakdown below:

Data Sent from PC to Microcontroller

  • The score:  This is converted from an int into a char array and sent char by char (byte by byte) because the microcontroller has to display the score on the LCD in terms of characters.
  • The current ammo count: Instead of managing the ammo on the microcontroller, the microcontroller receives the ammo counter and stores it.  This is how it knows how much ammo is left for the LCD HUD.
  • Game start flag:  This resets all of the game’s values on the microcontroller to their default state and lets the gun get ready for a new game.
  • Game end flag:  Currently does nothing, but it may be needed depending on what we want on the LCD HUD when a game is not being played.

Data Sent from Microcontroller to PC

  • Trigger state:  When the trigger is pulled, we send a ‘P’ to the PC.
  • Reload flags: The microcontroller is constantly polling the accelerometers and checking to see if the player is reloading.  If the threshold is reached, it sends an ‘R’ to the PC, and the PC then increments the ammo counter.  This, in turn, is sent back to the microcontroller so that it’s data is updated.
  • Gun movement flags:  Like the reloading, the accelerometers are also outputting data to the microntroller regarding the other axis’ of orientation.  This way we can detect if the gun is being shaken up, down, left, or right.  The microcontroller sends a signal ‘X’ or ‘Z’ alerting the PC alerting it of those actions.

In our game code, the pollForBluetoothData() is placed in a timer function and is constantly being checked.  If there is data, it processes it accordingly and updates all of the values as necessary, namely the ammo, score, trigger state, reload flags, etc.  These values can then be accessed seamlessly with methods to set() and get() each of those components.  When the values change on the PC side, it sends the new values to the microcontroller so that the two are always in sync.

As for our game structure, we finally have a working state of our entire game in our development branch. After having moved around from task to task, It was really nice to finally put it all together and see it run. The entire code structure has been modified such keeping track of the shots fired is a lot better. As for our start screen, we finally have a nice looking splash animation in which you can see in the embedded youtube page below. So far, this screen takes you straight to a running game when you fire a shot. However, we will eventually modify it such that the user will be able to see the top 10 scores for the day listed on it as well as go back to the calibration screen so that if they errored in calibrating, they can recalibrate it without having to restart the entire game.

These two windows were the main focus for the week and below is a quick youtube click showing you a run through from turning on our game to actually starting a round. I apologize for the choppy framerate in the video. I was recording the screen through quicktime and I guess my graphics card or something couldn’t handle recording it seamlessly. Do not be fooled, the game actually runs a lot smoother than the video shows. Alright, here it is…

Another big project for the week was actually establishing a Git repository and utilizing the program to greatly increase the productivity of our work. It took a little bit of a trial and error to learn the small differences between Git and the normal subversion programs that we were used to. However, after working with Git, we were surprised at how good of a program it is. We were even able to create a Github account online so that everybody on the team could easily work on it without never having the need to work right beside everyone else. It is an amazing program, and we are fully glad to be using it in our senior design project.

If you are interested, are code is availaible to look at in the following URL:

https://github.com/indieknite/Super-Spray

We also had to make our poster for demo day this week!  It was was kind of a bummer we had to make it so early, because we wished we had more pictures and information that reflected a finished product, but what can you do.  You’ll all be seeing it in two weeks!

Hardware Goals For This Week

  • Exhaustive testing of the bluetooth communication.  See if any data is being lost, correct any bugs if found.
  • Try to get the game playable to the point where we’re not using the PC’s keyboard to shoot, but actually the button on the microcontroller.
  • Hopefully begin a more serious installation of parts into the gun, it’s crunch time.
  • Considering making a makeshift cable that would allow us to still program the microcontroller even when it’s in the gun.  Considering using a molex-like connector with 6 pins, which is the bumber of pins the ATmega32’s programmer uses.

Software Goals For This Week

  • Finally actually get sound working in our project, its been something we’ve been pushing back for way too long.
  • Fine tune the Start and Calibration screens, adding the highscores list and ability to recalculate the screen.
  • Begin coding game sctructure, like when hitting a target causes the players score to go up.
  • Perfectly merge the hardware code, now that it is in a testable state, with the game code.

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.

 

Bluetooth Working, Gun Under Construction

CSE181A Winter 2011

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

Project Title: Super Spray

Wow, this is great!  This week we have successfully brought our bluetooth modem to life.  I still am not sure 100% what the problem was, but we’re connected, and that’s all I care about.  Originally our receive() method was polling with a while loop, waiting for the buffer to have data in it before returning anything.  This turned out to not be the implementation we were looking for, because we need to do other things rather than just wait on bluetooth transmissions like processing the accelerometer, and printing to the LCD, as well as transmitting bluetooth signals when our trigger is pulled.  The solution was an interrupt driven receive(), and that is working.  Even while the trigger button is held down, it will successfully receive and resume transmitting a trigger signal.  Now the quest is to get our game program to read it with bluetooth.  Hopefully there’s some C++ library to make that relatively easy, but so far no luck finding anything of that sort.  Once the computer is receiving and processing information sent via bluetooth from the accelerometer, and sending to the accelerometer, the rest is all game design coding.  We’re on our way!

The second accelerometer came this week, and the code that we prepared for when it came is working well.  We subtract the difference in the two accelerometer’s readings, and if they differ by a certain threshold amount, then activate a reload.  Other wise, do nothing.  This is nice because now the gun can be moving wildly and it doesn’t matter, because since both accelerometers are reading the same values, we know that it’s not a reload.  The key will be to mount the accelerometers in a way that they’re axis’ are aligned as close as possible, so that there’s not a lot of variance in the reads.

Speaking of mounting components in the gun, we have mounted our first few things.  The first thing we dropped into the gun’s casing is the button that is pressed when the trigger is pulled.  We think it is lined up well, and the only real worry now is how it will hold up during actual play testing.  The “Great Stuff” expanding foam worked perfect… it just is annoying because it has a long dry time (8 hours).  It was hard to get things to stay without us holding it so we could actually walk away from it.  We also mounted one of the 5v DC motors with a weight attached for vibration (these came from a PlayStation 1 controller).  We but the one with the smaller weight in the handle of the gun, so that it is right next to the player’s hand.  The other thing we get ready to go was the pump’s accelerometer.  This was a little tricky to install, because five wires (ground, Vcc, x, y, and z axis) all have to go from the end of the pump’s housing back into the body of the gun – cleanly.  We think we actually did a good job though.  We drilled out some hols at the end of the pump rod to let the wires through, and the accelerometer is mounted with the y axis aligned.  Below are some pictures of this progress.

Drilling the hole to run the wires through the pump's holder.

After running the wires through.

Wires run through the pump rod and pump casing, now ready to mount the accelerometer.

Drilled a hole through the end of the pump rod so the wires could have an exit.

The wires come out the center of the backside of the pump rod. Now the pump can slide freely in it's casing without the wires becoming an issue.

Lining up the accelerometer before mounting it in the foam.

Accelerometer mounted in the foam. The Y axis had to be parallel with the pump rod (horizontal in this photo) as that is the direction it will move to trigger a reload.

The button switch that will detect the trigger. It is mounted here in the expanding foam.

One of the motors taken from a PlayStation 1 controller to bring some vibration feedback into our gun's handle. This is the smaller of the two. This counterweight is small and is more of a high frequency "buzzing" feel, as opposed to a low rumble.

On the software side, the game is slowly coming together. With the basic code done for the targets, graphics, and scoring, what needed to be done next was the flow of the game. The graphics code framework has been modified to support this new feature and as a result, has been optimized to be extendable to allowing various transitions in the graphics being displayed. The basic code for the calibration, start, and play screens have been made. While creating the graphics for each of these screens, a couple of bumps were hit. The first was a weirding warping of the graphics that was essentially scaling our graphics a lot bigger than what we preset their sizes to be. After constant debugging, we found the problem to be how the Width and Height parameter was being passed around from file to file. These parameters essentially map the size of the display the game is being played on and maps the rest of the graphics to fit within these parameters. This allows us to display our graphics without ever going out of bounds of the display.

Hardware Goals for the Week

  • This is a hardware/software goal, and the beauty of CSE.  Now we need to get the bluetooth to send data back and forth, but within our game program code, which is in C++.  Right now we’re simply talking to the terminal, which is useless because our game can’t read that data.
  • Continue to put more parts in the gun.  Probably only the laser for now.
  • Add methods to recognize when the entire gun is being shaken (both accelerometers) so that we can detect when the player is shaking the whole gun.

Software Goals for the Week

  • Add sounds to the game.
  • Add support to draw letters on the screen.
  • Add basic code structure of when the game is running, like displaying the time left and the amount of score obtained so far.

And we leave you with a video of the switch in action when the trigger is pulled.