E19 Final Project Report Liquid Pong Simulation · E19 Final Project Report Liquid Pong Simulation...

E19 Final Project ReportLiquid Pong Simulation

E.A.Martin, X.D.Zhai

December 22, 2012

E19 Final Project Report Liquid Pong Simulation Martin & Zhai

Motivation and Goals

Before embarking on this project, we decided to choose a project that extends the conceptslearned in class and incorporates them into an interesting real world problem. In addition, wewanted to attempt building a Graphical User Interface (GUI) even though we are hard coreengineers who wouldn’t care about front end fanciness. Eventually the two ideas convergedonto a design and simulation of a game of beer pong, or liquid pong for non-drinkers. Thegame is widely played on many college campuses around the country. It is easily playedaccording to simple rules, and is thus a good final candidate for our project. At the end ofthe project, we wanted to achieve the following three goals.

• Fast and realistic 3D simulation.

• Intuitive and direct user interface.

• Can play against a human player or computer which uses minimization schemes to aimfor the cup.

Some Theory

The bare bones of this game is modeling a ball in flight in 3D, and modeling bounces offof surfaces. It inherits the basics directly from the 2D golf ball simulation and we wish tointroduce several realistic and game specific considerations into the simulation. They are:

• Spin, and thus lift, in 3D.

• Spin decay, and possibly procession of spin vector, due to air resistance.

• Realistic dimensions in game.

• Bouncing on table surface and off the side/edge of the cup.

• Computer intelligence at aiming for target in play v.s. computer mode.

We adopted a divide and conquer approach to tackle this project, addressing each pointindividually and conducting testing before moving onto the next. This modular approachproves to be very successful.

Spin and Spin Decay

In 3D, the magnus force is no longer simply in the y direction. More generally, it is the crossproduct of the spin vector with the velocity vector as shown in Figure 1.

Flift = Sω × v

where S is the magnus coefficient.

1


Figure 1: Illustration lift force in 3D

There are several ways to model spin decay. We adopted the method of R.K.Adair, that therate of decay is such,

dω

dt= − 1

2IkRρACLv

2

where the I is the rotational inertia, 0 < k < 1 is the dimensionless constant, R is theradius of the ball, ρ is the density of the air, A is the cross-sectional area of the ball andCL is the lift coefficient. It is basically modeling the torque acting a distance kR from thecenter of the ball in the opposite direction as the spin with added parameters. Since thetorque is analogous to force and angular velocity to linear velocity, then the rate of changein angular velocity has to be proportional to torque.

Realistic Dimensions and Plotting Props

There is ample literature on the proper dimensions of a pong table, though in practice thesize of the table may vary. Officially dimensions of the table are 2.75 meters by 1.48 meters,or approximately 9 feet by 4.5 feet as seen in Figure 2 1.

The size and type of cup used can also vary, but often a 16 oz. Solo cup is used. The topradius of a solo cup is 10 cm, the bottom radius is 6 cm and the height is 12 cm. Pingpong balls are usually 4 cm in diameter, and weigh 2.7 grams. To model the table, weused meshgrid to create a plane and changed the FaceColor property into a wood texturepicture of our choice. To model one cup, we created a cone with its FaceColor changed

1http://en.wikipedia.org/

2


Figure 2: Some Dimensions

into pure red. Now it is a matter of trigonometry to figure out how the cup centers shouldbe positioned so that all of them are touching each other. To make the math easier, weposition the cup on the tip of the triangle at (0, 0) and calculated the rest accordingly. Thenwe used a linear transformation to transform all the cup centers to the desired position.Since we want cups on both side of the table, we need to invert the x coordinates of allthe cup centers on the positive side of the table and it is a only a matter of linear algebra.In the end, our virtual table and cups are based on the official guidelines when appro-priate, with a few changes for the aesthetics of the GUI. The virtual set up is seen in Figure 3.

Figure 3: Virtual Setup

3


Bouncing

In a game of pong, the ability to bounce the ball off of the table into the cups is veryvaluable, because it is worth two cups instead of one. We implemented bouncing off of thetable assuming a completely elastic collision with the angle of incidence equal to the angleof reflection. In addition to bouncing off of the table, the ball often bounces off of the cups-usually the rim of the cup, or the side of the cups due to a short throw.

We approached both bouncing methods in a similar manner. At each point P along theball’s trajectory, we calculated the closest point of contact to the playing surface, Pc. Forthe scenario where the ball bounces off the table, we assigned Pc according to the followingrule: if the ball is outside of the table surface, then Pc is the point on the closest table edge.Thus everything outside of the table surface area “snaps” to the closest edge as shown inFigure 4.

(a) 3D view (b) Top view

Figure 4: Bouncing off table

For the scenario where the ball has to bounce off the surfaces of the cups, we have to adopta similar method. The only difference is that we have to use polar coordinates to classify Pc,as shown in Figure 5. We first calculate P ’s coordinates in the w− z − θ polar frame wherew is how far the ball is from the center axis of the cup, z is the height of the ball and θ isthe angle of the ball from the center axis. Then we can decide which region the ball is in bycalculating u,

u =(P − Pa) · (Pb − Pa)

||Pb − Pc||If u < 0, then we are in region d and Pc = Pa; If u > 1, region is b and we choose Pc = Pb;otherwise, we are in region c and Pc = Pa+u(Pb−Pa). As a last step, we have to transform

4


Pc into cartesian coordinates by doing the following:

Pc =

wc cos θwc sin θ

zc

In addition, this point has to be transformed back to the table’s frame before we can do acomparison.

Figure 5: Bouncing off cup

Suppose the distance between point P and PC is d. Every time the ball takes a step, wecalculate a set of Pc and d for both the table surface and all the cups 2. Then we decide ifthe ball is closer to the plane of the table or a cup by comparing the d values and pickingthe smaller one. Afterward, we calculate the normal to the surface:

n =Pc − P

||Pc − P ||We use this quantity to calculate the dot product of the normal vector with the velocityvector which will tell us if the ball is falling downwards (n · v < 0). The ball will bounceif d is less than the ball radius AND if it is falling downward. This second condition isimportant to distinguish whether the ball is approaching versus just leaving the surface.Having determined when to bounce, we need to calculate the new velocity of the ball afterit bounces. We did it using the Househelder bouncing rule:

vnew = cr(I − 2nnT )vold

2Actually, not all the cups. To save computation time and make simulation fast, we only check the cupson the opposite of the table from the player who is throwing it.

5


GUI Design

Once our back end functionality worked smoothly, we went to the drawing board to designour GUI. We modeled our system after the standard space mission control panel wherecontrol, flight trajectory and live flight statistics are displayed on separate panel for optimalclarity. Shown in Figure 6 is an artist’s depiction of the control console where the interface isdivided into three panels. On the left side is the virtual setup for the game. The upper righthand panel contains sliders and radio button for the user to choose flight parameters. Thelower right hand panel displays in real time some of the essential flight and environmentalstatistics.

Figure 6: Illustration GUI drawing board

To create a GUI in Matlab, we used the built-in GUI creator guide, shown in Figure 7,which will allow us to layout whatever text, buttons and axis on the front end and it wouldautomatically generate a .m file that includes callback functions for each button/output. TheGUI includes a structure called handles where the handles for all the buttons and textboxesare stored. In addition, we could include global variables such as setup parameters in thestructure to be called and passed to each callback function. For example, we included ourback end simulation code in the launch button callback. Once the button is pressed, the

6


simulation code will grab relevant information from the handles such as which player’s turnit is and what is the initial velocity that the user has chosen.

Figure 7: Our first version of the GUI under construction in guide,

Results

In the end we successfully created a pong simulation that can be played by two players.We display real time flight statistics such as position and velocity on the GUI. The ball canbounce off the surface of the table, and the result of their turn is displayed. This worked wellto a large extent though we did not have time to conduct thorough testing to discover all bugs.In addition, we did not successfully score a cup to test the algorithm that checks for winning.

For example, the ball bounces off table without fail. However, there are times when theball fails to bounce off surfaces of cups. Figure 8 shows a successful cup bouncing and anunsuccessful one. In addition, the GUI is sluggish since we have lots of interactive buttonand information getting updated very frequently. To speed up the simulation, we are onlyplotting the position of the ball every 20 time steps and updating the flight statistics every100 steps. Even with this compromise, the GUI performance is not ideal. When there arefour plots to be updated and handles to be changed periodically, Matlab strains to keep upwith the computational requirement and it crashes quite often. Shown in Figure 9 to Figure12 is some trial runs of the GUI.

7


(a) Good bounce

(b) Bad bounce

Figure 8: A demonstration of bouncing results

8


Figure 9: Bounce off the side

9


Figure 10: Another example of bouncing off the side

10


Figure 11: A lucky incidence where the ball bounces of the edge of cup

11


Figure 12: Player 1 has scored

12


Future Goals and Conclusion

In conclusion, we have met most of our goals for the project other than the developing acomputer that can use minimization schemes to play the game intelligently with a humanplayer. Through this project, we have learned and implemented how to simulate ballbouncing off surfaces that are not exclusively horizontal or vertical. For the first time,we designed and built a GUI to facilitate better user interface and we are proud of ouraccomplishment.

There are a few things we did not have time perfect and implement. For example, weignored the effect of spin on bouncing and. We also did not pay much attention to check forrule violation such as if the bouncing happend on the legitimate side of the table. We alsodid not figure out how to clear all the figures in the GUI once the reset button is pressed.For the future, we would like to program a computer that can aim at cups and play with aplayer so the game can be played both by two human players as well as against a computer.In addition, we would like to test the current program more thoroughly, reduce redundancyand streamline process flow to make the simulation smoother, faster and less susceptible tocrashing.

Acknowledgments

We would like to express our thanks to Prof. Zucker for his help in developing the algorithmsfor bouncing algorithms. In addition, we are grateful to Price and Chris for their insightson how to facilitate a faster simulation.

13

E19 Final Project Report Liquid Pong Simulation · E19 Final Project Report Liquid Pong Simulation...

Documents

Transcript of E19 Final Project Report Liquid Pong Simulation · E19 Final Project Report Liquid Pong Simulation...