Pong Assist Final Paper

The final paper for my project (which includes developments not posted on the blog) can be found at this link:
https://drive.google.com/file/d/0ByVuWDiWkQUAME84S2g5cHNZblU/edit?usp=sharing
Because of it's size it can't be previewed, but it can be downloaded and viewed that way.
Enjoy!

Pong Assist Poster

Here is the poster I created for my project presentation:

Simulation Control

I have, at last, managed to develop an actual interface between my paddle and my Processing simulation. Moreover, it's a system in which the paddle is powered by a 5v wall wart, so that my motors aren't at risk of overpowering my Arduino or being affected by the interference that can be caused by sharing power. To actually communicate between the program and the hardware, I'm sending characters from Processing to Arduino via the serial port. I had intended to use a software package called Firmata that allows for Arduino code to be written directly in Processing, but I found that, so far as I could tell, the only way to stop continuous servos (like the ones I'm using) in Firmata is by writing the servo to its central, still position. This is an issue, because the stopping point of continuous servos varies not only by motor, but also based upon variable factors, such as temperature. As a result, the only way to ensure that the motors will actually stop when you tell them to is by actually detaching them (in code) from the digital pins to which they are connected. As this can't be done using Firmata, I had to resort to the less elegant, but equally functional, system that I referred to above. In any case, with all that said, the video is below. In the video I demonstrate only the newest features of the Processing simulation program--to see the other parts in action, please refer to previously posted videos.

Now, as is probably obvious, the system isn't exactly working in a stellar manner, but it's working nonetheless. One issue is that I'm finding the Legos I thought were so wonderful for prototyping are actually a little too flimsy for this project, as the force applied by the motor frequently pops them apart, particularly in the area surrounding the gears. This is unfortunate because gluing the Legos together isn't really an option, as there are so many moving parts. I have, as a result, decided to build a new model--hopefully using pieces from an erector set--which will allow me to form hinges using nuts and washers instead of small pieces of plastic not really designed for what I'm trying to make them do. This will, in turn, allow me to run better tests on my paddle system and work out some of the obvious kinks in movement. One of my plans for improvement is to add a hard-wired trip system that will be triggered when the paddle surface is level. This will allow me to always return the paddle to its level position after each alteration, thereby removing the error that would otherwise build up as a result of slight overwrights, underwrites or jostles during these alterations.

System of Equations for Ball Deflection

So I finally took the time to sit down and puzzle out the actual calculations that correspond to the diagram of ball deflection I created in Google Sketchup. It ended up producing a rather intimidating list of twenty-or-so functions which I intended to feed into Maple, so that I didn't have to try and work it out myself. Here is the list of equations:

I also verified that the results from the system of equations produce the same results as my Sketchup diagram, as shown in the calculations below:

The only problem with this system of equations is that it only works properly if ball θ = 0º which, obviously, it very rarely will. I realized this when I started making a new model to verify these equations for a different case in which ball θ = 34º. I also discovered that in my calculation of ψR was flawed, as I assumed it was supplementary to ψ when, in fact, the two angles were on slightly different planes. As a result of these two issues, I had to re-do the entire system of equations with respect to my new model, which can be downloaded from Sketchup's 3D warehouse by going to this link: http://sketchup.google.com/3dwarehouse/details?mid=c4c4c31557969355e370fe52ecbc42c&prevstart=0
In this model, ballθi = 34º, ballφi = 30º, paddleθ = 168º and paddleφ=15º. All other variables are labeled in the model. As with the previous model, this one can be stepped through using the layers menu (available under Window) and showing and hiding various layers. Included below is the system of equations that produces the values shown in the example. The system has, this time, been organized by step, which will hopefully make it easier to work through (you'll also notice red boxes outlining some of the equations. Feel free to ignore them completely; they're meaningless). Also below is a verification of my new system of equations,  in which I work through the various calculations and produce values that correspond to the model. Hopefully in the next week I will get a chance to test this system of equations with yet another model (these models are irritatingly time-consuming to make) in which paddleθ is more than 180º greater than ballθi. After I get the system of equations to work for that case, I'll enter them into Maple and produce a single, universal equation for ball deflection calculation that requires only ballθi, ballφi, paddleθ and paddleφ as input. In the near future, I also hope to make a video in which I go through the second model and system of equations step by step, but that's not terribly high-priority at the moment, so I'm not sure when I'll actually get it done.

UPDATED SYSTEM OF EQUATIONS

VERIFICATION USING MODEL VALUES 

Wii Nunchuk Application?

I was browsing through Make Magazine, volume 33 when I came across an article talking about how easy it was to link the Wii Nunchuk with an Arduino, using a software found here: http://www.gabrielbianconi.com/projects/arduinonunchuk. I followed the steps in the magazine, downloaded the software, and am now getting what appear to be accurate readings from a Wii Nunchuk. I'm really excited about this, because I knew I'd need to get an accelerometer at some point (to determine the incoming speed and angle of the Pong Assist paddle and factor them into deflection calculations), and now I've found one that is inexpensive, easy to use, and already within my possession. You don't even have to strip the wires on the Nunchuk to hook it up! The software pulls z, x, and y acceleration data (which is what I'm really interested in) as well as x and y analog information (from the joystick). It also keeps track of whether the c and z buttons on the Nunchuk are being pressed. I don't have a clear idea yet of how I might use this x and y analog or c and z button information, but it's exciting to know I have it just in case a use for it should appear. I plan on sorting through this info in the near future, but because of all the work that still needs to be done with my simulation program, as well as with the motor shield (which is still waiting for additional parts that are taking forever to get), it might be a little while before I work out anything terribly concrete. It's still exciting, though!

Figured Out Ball Deflection!

I'm pretty certain, to my extreme excitement, that I've figured out how a ball will deflect when it hits the paddle face. I built a model of the set-up in SketchUp and I've uploaded it to the SketchUp "3D Warehouse" online. It can be found at this url: http://sketchup.google.com/3dwarehouse/details?mid=7ba4f58e1e339f475e370fe52ecbc42c&prevstart=0. To navigate the model (unfortunately you need to have SketchUp to do so, but it's a free program and great to have anyway), access the model's layers (found under "window") and turn layers on and off as desired to view different steps of the calculation process. I should point out that the model doesn't apply to all velocity calculations that might eventually have to be done, it's just a representation of how deflection would be calculated in a single case. I'm still working on developing a system of equations for determining resultant ball angle from initial ball angle. Once I have that system of equations, I'll run it through Maple 13 (a handy algebra tool I just got and am still learning to use) and (hopefully) derive a single equation that I can then program into my Processing simulation.

Explanation of Model Variables:
Because of the 3D nature of these calculations, the variables used in this model correspond to the spherical coordinate system, a method suggested to me by the teacher of the class I'm doing this for, and a quick description of which can be found here: http://www.youtube.com/watch?v=hLqexFPSV-w

Specifically, the variables I use are:

 - initial ball theta (θb): the angle to the x-axis at which the ball encounters the paddle
 - initial ball phi (b): the angle to the z-axis at which the ball encounters the paddle
 - paddle theta (θp): the angle to the x-axis at which the paddle tilts
 - paddle phi (p): the angle to the z-axis at which the paddle tilts
 - mu (μ): the complimentary angle to b
 - final ball theta (θbf): the angle to the x-axis of the ball, with respect to the paddle normal
 - final ball phi (bf): the angle to the paddle normal of the ball
 - NOTE: the resultant θ and of the ball after collision, with respect to the paddle, are indicated to be equal to θbf and bf, with the assumption that angle of incidence equals angle of reflection
 - resultant ball theta (θbR): the angle to the x-axis of the ball after collision with the paddle
 - resultant ball phi (bR): the angle to the z-axis of the ball after collision with the paddle

In this model, the values for these variables are:
 - bθ = 0º
 - b = 20º
 - pθ = 90º
 - p = 20º
 - μ = 70º
 - θbf = 45º
 - bf = 27º
 - θbR = 119º
 - bR = 43º

The lengths of certain lines are also labeled based upon their length in  pixels. They were labeled in pixels and not in cm because pixels are the standard unit for distance in my simulation program.

I also plan to upload a video of my model with an explanation of how it works in the near future, so that it isn't necessary to download SketchUp. However, in the mean time, this is what I've got.

Paddle Simulation 3D Model

In an attempt to gain some sort of handle on the math that needs to be done to calculate the trajectory and velocity of the ping pong ball after it strikes the paddle, I used Google SketchUp to creat this 3D diagram of the setup used by my simulation program (you'll notice that the axes of the diagram are all labeled in pixels). I haven't gotten a chance to use it much yet, but hopefully it'll help. In terms of the actual math, I'm currently researching spherical coordinates, because I think they're the only way I'm going to be able to account for the three-dimensional nature of the ball deflection. More on that adventure to follow.