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.

More on Pong Assist Simulation

Here's another video of my simulation program, which has some updates (including a very classy intro screen, an ability to input ball approach angles, and the factoring-in of the ball's coefficient of restitution in resultant velocity) but which still lacks the ability to properly deflect the ball. I'm finding vector addition in three dimensions to be rather dicey (I'll be posting the rather long derivation I required just to determine velocity in the Z direction), but as soon as I get that figured out, the program will be well on its way to full functionality. All I'll have left to do is factor in initial paddle velocity, apply kinematics equations, and add additional views. Which is actually kind of a lot, but I'm optimistic!

Pong Assist Simulation Program *UPDATE*

For the last week or so, all I've really done is work on my simulation program. I hadn't really done much with processing up until now, so I've been kind of feeling my way through it, but I'm really happy with what I've gotten done so far, so I decided to post an update. A few features I'm really proud of:
    - Window is re-sizable (though text isn't, for some reason)
    - Motor angle indicators gently fade from full-color to white depending on severity of angle (very classy-looking)
    - Ball launches at the same speed (in m/s) regardless of a computer's processing power, as its relative velocity in the program is calculated taking into account the frame-rate the Processing program is running at.

These exciting new features and many more can be seen in the video below!

My intended next step is to get a ball rebound that corresponds to the angle of the paddle, then began taking additional factors (such as initial angle, paddle velocity and the ball's coefficient of restitution) into account. Finally, I'll begin working on additional views, though I think I may organize them differently than I originally intended to.

Pong Assist Graphic Representation

So, it occurred to me, after watching the velocity-tracking program I wrote spit out endless values at me, that it might be useful to have a computer animation of the ball, Pong Assist paddle, and starting and ending trajectories, so that, in the future, I can differentiate between hardware problems and programming problems. As a result, I've begun work on a Processing program that will produce a visual of the intended interaction of paddle and ball. Below, I've posted a drawing of what I want the representation to resemble eventually and a video of what I have so far. Needless to say, there's a long way to go, but I'm pretty happy with how things look so far.

Intended Visual Representation Layout:

Progress So Far (loooong way to go)

Ping Pong Ball Velocity Program (Video)

Ping Pong Ball Velocity Program

So, with the lag in Kinect imaging finally sorted out, and with a program (thanks to Making Things See by Greg Boorenstein) that successfully tracks the point closest to the Kinect I decided it was time to create a program capable of tracking the velocity of that closest point. The first step in doing so was to compensate for the fact that the closest-point program I'm using tracks x and y-values based upon pixels. Obviously, a movement of 5 pixels three feet from the Kinect is smaller than a movement of 5 pixels twenty feet from the Kinect, so some sort of calibration was necessary to attain consistent velocity values. To accomplish this calibration, I first determined the field of view of the Kinect by taking specs. I found online and expanding upon them with some trig. functions, as shown below:

Field of View Calculations

Next, I needed to write an algorithm that would take those field of vision calculations, as well as the Kinect's generated depth values (ranging from 0 to 2048), and determine the ball's velocity based upon them. Below is a picture of the calculations I used, as well as an explanation of variable and my procedure.

Velocity Algorithm Calculations

- First, delta x and delta y (the difference between the Kinect's horizontal and vertical fields of view at 6m and at .7m) were computed.

- Delta x and y were then divided by 2048 (the maximum depth value the Kinect returns) to determine the x-constant (Xc) and y-constant (Yc)--the amount in meters that the horizontal and vertical fields of vision of the Kinect grow by for each unit of depth.

- Xc was then multiplied by D (the depth value of the closest point as returned by the Kinect). The resulting product was then added to the minimum horizontal field of view (.7601m) to determine the size of the horizontal field of view at depth D. The resulting sum was then divided by 640 (the number of pixels making up the horizontal field of view) to yield the value Ux (the distance in meters between each pixel at a given depth D in the x-dimension).

- The same process was undertaken to determine Uy, though a different value (.5515m) was used for the minimum field of view and a different number of pixels (480) was used as a divisor, in accordance with the y-field's smaller size.

- Next, the velocity in the x direction (Vx), was determined by multiplying Ux by delta pixelsx (the change in x value (in pixels) from one Kinect measurement to the next) and by 24 (the number of Kinect measurements (as determined by Kinect frame rate) per second). By multiplying by 24 in this manner, the Vx value returned is in m/s, rather than in m/((1/24)s), which would be a really irritating unit to have to deal with.

- The velocity in the y direction (Vy) was determined in the same manner.

 

At this point, I realized that I'd forgotten I needed the ball's velocity in the z-direction as well, so I began another set of similar calculations:

  

- First, delta z was determined by subtracting the minimum functioning Kinect distance from the maximum (6m-.7m).

- This value was then divided by 2048 (the max depth value returned by the Kinect) to determine a z-constant (Zc)

-  Zc was then multiplied by D (the depth value). The resulting product was then added to the minimum depth (.7m) to determine the true depth at returned depth D. The resulting sum was then divided by 2048 (the max depth value) to yield the value Uz.

- Uz was then multiplied by delta D (the change in depth from one Kinect measurement to the next) and multiplied by 24 to yield Vz in m/s.

FINAL VELOCITY CALCULATION:

With these myriad values determined, I then needed to calculate the overall velocity:

- The magnitude of the overall velocity (Mv) was calculated by taking the square root of (Vz)^2 + (Vx)^2 + (Vy)^2.

- The angle of the overall velocity (with respect to the z-axis) was then determined by taking arcsin(Vx/Mv)

This algorithm has been used to produce a functional Processing program in conjunction with the Kinect. A video of this program in action will be uploaded in the near future (ie. as soon as I find a program that allows me to take video of what's happening on my computer screen)