This is the android Video of the Music player applicaiton

Latest Flash UI changes

Final preparations for tomorrow's big show!
We added :

• sounds in our application, allowing user to get auditive feedback
• background and confirmation for hit sounds for improving the User Experience, creating an immersive experience who tries to transpose the user into the real wood atmosphere
• self generating levels, allowing users to improve themselves beyond our ideas about their possibilities: the user gets 60 seconds levels in which he has to hit more and more animals as he becomes better in targeting ( and in ball retrieval :-) )
• changed the aspect ratio of the game from 4:3 to 16:9 to better use the whiteboard's surface
• we dropped a lower right sensor from our latest setup to improve the quality of sensor reading. The reason is that wooden board conducts very well the sound. Thus, too close sensors can receive same signal in almost the same moment, given false positive responses.
  

After some live tests with our entire platform configured, we noticed that sometimes the software interface between Arduino's serial port and Flash application freezes. Hope we'll not encounter this tomorrow!

Bellow is the final version of the application.

Arduino-Flash communication

This week, we worked on connecting Arduino with Adobe Flash CS3 as well. Arduino cannot directly communicate with Flash. A communication protocol is needed which can create sockets for communication and can translate messages between the two. "Serial Proxy" is used for creating sockets. It is basically an XMLSocket server, a small program that runs
on pc and keeps a live connection between the serial port and Flash. This serial porxy server can be found at http://www.arduino.cc/en/Main/Software. A library of routines provides a wrapper around XMLSocket for making the communication code cleaner (More information can be found at http://www.arduino.cc/playground/Interfacing/Flash). Communication between Flash and Arduino takes place on virtual serial port COM3 with port number 5333. Strings can be transmitted back and forth between Arduino and Flash. For our case, we are transmitting the sensor number as string -- the sensor which is hit by the ball. This string is converted to integer in Flash porgram and is utilized to kill an animal.

Enhancement to the hit detection

Earlier we had problem sensing the values from knock sensor correctly. Vibrations transmitted along the medium to which the sensors were attached (white board of lecture hall in BIT) were making it difficult for us to accurately determine the sensor which was hit by the ball. The estimation was 70-85% correct. However, we needed more accurate results for the game, since it would not be a fun game if an accurate hit is treated as a miss. We needed more than 95% accuracy. This week we changed the placement strategy of sensors and provided enough insulation among sensors. A thick layer of tissue papers was placed between sensor and the white board to absorb the transmission of vibrations from one sensor to another. This decoupling worked well and accurate estimation of hits became possible.

Moreover, we determined the criteria of exactly detecting the knock on the sensor. If the hit is in diameter of about 15 cm around the sensor, the values from other sensors are exactly 0. If hit is made somewhere between two sensors (outside this diameter), the nearest sensor gets highest value. The other neighboring sensors receive a value normally less than 10. This helped us in determining the hit accurately to about 98% of the time.

The figure shows a screen-shot depicting four sensors attached to the artificial wall.

Flash UI changes

Since last week the Flash application changed- I added support for numerical keys for hitting. We mapped the numerical keys 1 to 6 to the 6 animals positions that can be hit. This way, it is enough to press a key to simulate the throw of a ball.
The reason behind this application architectural change is that we needed an smart way to simulate the sensors that were hit, without actually having the entire setup in our workplace.
Also, a nice tweak in the application's ActionScript behind code allows it to easily be connected to an Arduino board.

Here is the new version:

Artifical Wall testing

Here is a video describe and document our testing process that we did before the exams for the artificial wall that we had built .

The User Interface

This week we work also on the User Interface - the Flash GUI. It was challenging since neither me nor Loredana had previous experience in creating games under this application.
Because of this fact, we searched for some advices on the net and after quite a long trial and errors we found something interesting here . Even that it didn't met all requirements, this tutorial was what we needed to get a quick start.

The animal images are free clip arts taken from http://www.free-clipart-pictures.net/animal_clipart.html.

After following the steps and understood the concepts,we modified the application to :

1. Change the resolution, as it has to run on a projector
2. Redesign the entire scene graphics, but keeping basic elements like scoring and timer.
3. Change the game's AI from
• how many simultaneously balloons you can hit in a specific period of time to
• having only one target available at one time and you can get another one only if you hit the current one
4. Remove the old targets and create 6 new ones more appealing.
5. Implement the Arduino interface classes taken from here.

After all this modifications, we present our visual part of the extraneous game (the resolution here was reduced to 400x300):

The application creates 4 spots in the bottom of the scene and 2 in the top to show randomly an new animal each time one is hit. This areas are hit areas designed to respond to phisical sensors placed on the back of the board on which the Flash Game will be projected.
Thus, the game will respond to user input (when he hits the board in a specific spot) by showing another random animal in a random spot.
For easy of testing, we kept also mouse interaction.

The User Interface

A game should not have only a great idea, but also nice graphical interface. For this, we created an immersive forest environment where the user to be able to 'hunt' some animals.

Underneath is the background of the application:

Week3

Build the artificial wall

During the last week , we started building the wall that contains Piezo sensors ,theses sensors are subjected to sense shake or knock actions by generating voltage.


we tried to use simple kind of walls like the white board on the lecture hall , the wooden wall of the lecture hall, during the first experiments , we tried to identify the sensors values that means for example :
Sensor 1 was clicked
or an object hit some place around sensor 1
or sensor 1 was not hit .

unfortunately , experiments showed that almost 70 % of the readings that we got from the sensors through the arduino device was right, so we considered using another alternative,where we put an isloator between this piezo sensor and the wall ,just to eliminate the propogation of shake effect , thus getting a better readings , using this technique enhance the decision correctness,but still not more that 80-85 %.

this image shows the sensors set on the wall of the lecture hall,we tried here to analyize and study what should be the size of the object depending on how much the shake will propagate throw the wall.and still during our analysis , we were having unconvienience values that varies between 5 - 15 % of the overall test that we made.

Now, we are trying to find a new technique that provide us with reliable results ,these technique may include another sensors , or create simple one for this specific application.

We're going on Arduino

From the last lab we had a week of accomplishments:

• we set our hardware to Arduino platform
• completed on Monday a little programming and testing of the hardware platform
• decided the final idea of the game
• and also set Adobe Flash as our interface and display application

The idea of the game remains as presented a week ago. We will have a screen acting as a pressure sensor (composed from at least 9 sensors to be more precise about the user's hit point).
The Arduino board will be linked with the sensors and will provide via USB the signals to the serial port. Flash will be on top, acting as a mix of a Controller of the user's input gathered by the interface and providing the data for the View, thus creating a fully ModelViewController implementation.
The advantages of the MVC will enable us to quickly create an application, easy bug removal and improved User Experience by easy customization of the View.

Brainstorming 2

In a previous post I explained the facts that forced us to re-think our project idea. Basically, our cool idea of an iPhone tied to a skateboard to create a exertion game require too much programming time. So we searched another idea who is required to be simpler and easy to be implemented in the remaining time.

So we got us a round table (the ones in BIT cafeteria are the best!) and put our minds to work.

First step : Use the Initial Design Techniques - Brainstorming (as learned in DIS I)

Our goal: collect as many ideas of exertion game as we can
Defer judgment, no criticism, no rejection of ideas
Include all ideas, allow also the leapfrog ideas

Result:
1. Virtual basket
2. Ping-pong game to the wall
3. Squash
4. Throw a ball to a target
5. Boxing
6. Throwing paper balls to garbage - fun in offices

After some debate we agreed to pursue in implementing the 4th idea. We will try to create an exertion game which will be composed from:

• a board which will act like a hit sensitive projection screen,
• a projector to display the target on the screen
• the software behind to calculate:
  
  • hit points,
  • decide if user hit the target
  • scoring and level finishing

To have a clear idea of our game we created also a small storyboard:

Changing the idea of the project

In the last meeting, our tutors, Mr. Heller and Mr. Karrer, shared with us some of their experience using the sensors which made us reconsider the project idea.

The idea
Because of the new introduction in iPhone programming and the rich set of sensors of this device, our project envisioned an iPhone attached to the board in order to track the skateboard movements. The data pulled out by the iPhone is the initial acceleration (the one when the user starts riding with the board), and lateral or up-down acceleration when he does turns or jumps with the board.

First, the iPhone accelerometer won't do the trick of getting all the information needed from the board. As it outputs acceleration, we would have to integrate once to get the velocity and twice to get the position. This gets us into a lot of approximations which aren't suited for movements in a few meters range.

Secondly, the iPhone sensor is not design to get an industrial-scale precision and accuracy in an outdoor activity, but more for fun activities like sensing shakes or directional changes.
Thus, combined with the above observation implies the fact that our data readed from an iPhone attached to a board would not be as accurate we need (also the integration introduces approximations first to the velocity vector and again when computing position). It also it contains a lot of noise because of the environment (the skateboard goes on the rough and bumpy surfaces).

The solution
Given the facts, our team agrees with the tutors that this project would have needed too much time in order to develop some sophisticated algorithms, compensating the noise and the two integrations approximations, hardly near impossible to be done in the time span allocated for this project.

The upper side of this discussion is that our knowledge about sensors and in particular iPhone sensors has improved thanks to our tutors. Our suggestion is that for the next lab a similar discussion and sensor presentation should be held in the first laboratory meeting, in order to guide the students even faster to concrete results.