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