E19 Final Project Report Liquid Pong Simulation. E.A.Martin, X.D.Zhai

Transcription

1 E19 Final Project Report Liquid Pong Simulation E.A.Martin, X.D.Zhai December 22, 2012

2 Motivation and Goals Before embarking on this project, we decided to choose a project that extends the concepts learned in class and incorporates them into an interesting real world problem. In addition, we wanted to attempt building a Graphical User Interface (GUI) even though we are hard core engineers who wouldn t care about front end fanciness. Eventually the two ideas converged onto a design and simulation of a game of beer pong, or liquid pong for non-drinkers. The game is widely played on many college campuses around the country. It is easily played according to simple rules, and is thus a good final candidate for our project. At the end of the 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 aim for the cup. Some Theory The bare bones of this game is modeling a ball in flight in 3D, and modeling bounces off of surfaces. It inherits the basics directly from the 2D golf ball simulation and we wish to introduce 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 point individually and conducting testing before moving onto the next. This modular approach proves 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 cross product of the spin vector with the velocity vector as shown in Figure 1. where S is the magnus coefficient. F lift = Sω v 1

3 Figure 1: Illustration lift force in 3D There are several ways to model spin decay. We adopted the method of R.K.Adair, that the rate of decay is such, dω dt = 1 2I krρac Lv 2 where the I is the rotational inertia, 0 < k < 1 is the dimensionless constant, R is the radius of the ball, ρ is the density of the air, A is the cross-sectional area of the ball and C L is the lift coefficient. It is basically modeling the torque acting a distance kr from the center of the ball in the opposite direction as the spin with added parameters. Since the torque is analogous to force and angular velocity to linear velocity, then the rate of change in 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 the size 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 top radius of a solo cup is 10 cm, the bottom radius is 6 cm and the height is 12 cm. Ping pong balls are usually 4 cm in diameter, and weigh 2.7 grams. To model the table, we used meshgrid to create a plane and changed the FaceColor property into a wood texture picture of our choice. To model one cup, we created a cone with its FaceColor changed 1 2

4 E19 Final Project Report Liquid Pong Simulation Martin & Zhai Figure 2: Some Dimensions into pure red. Now it is a matter of trigonometry to figure out how the cup centers should be positioned so that all of them are touching each other. To make the math easier, we position the cup on the tip of the triangle at (0, 0) and calculated the rest accordingly. Then we 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 all the 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 appropriate, with a few changes for the aesthetics of the GUI. The virtual set up is seen in Figure 3. Figure 3: Virtual Setup 3

5 Bouncing In a game of pong, the ability to bounce the ball off of the table into the cups is very valuable, because it is worth two cups instead of one. We implemented bouncing off of the table assuming a completely elastic collision with the angle of incidence equal to the angle of reflection. In addition to bouncing off of the table, the ball often bounces off of the cupsusually 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 the ball s trajectory, we calculated the closest point of contact to the playing surface, P c. For the scenario where the ball bounces off the table, we assigned P c according to the following rule: if the ball is outside of the table surface, then P c is the point on the closest table edge. Thus everything outside of the table surface area snaps to the closest edge as shown in Figure 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 adopt a similar method. The only difference is that we have to use polar coordinates to classify P c, as shown in Figure 5. We first calculate P s coordinates in the w z θ polar frame where w is how far the ball is from the center axis of the cup, z is the height of the ball and θ is the angle of the ball from the center axis. Then we can decide which region the ball is in by calculating u, u = (P P a) (P b P a ) P b P c If u < 0, then we are in region d and P c = P a ; If u > 1, region is b and we choose P c = P b ; otherwise, we are in region c and P c = P a + u(p b P a ). As a last step, we have to transform 4

6 P c into cartesian coordinates by doing the following: w c cos θ P c = w c sin θ z c In addition, this point has to be transformed back to the table s frame before we can do a comparison. Figure 5: Bouncing off cup Suppose the distance between point P and P C is d. Every time the ball takes a step, we calculate a set of P c and d for both the table surface and all the cups 2. Then we decide if the ball is closer to the plane of the table or a cup by comparing the d values and picking the smaller one. Afterward, we calculate the normal to the surface: n = P c P P c P We use this quantity to calculate the dot product of the normal vector with the velocity vector which will tell us if the ball is falling downwards (n v < 0). The ball will bounce if d is less than the ball radius AND if it is falling downward. This second condition is important 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 after it bounces. We did it using the Househelder bouncing rule: v new = c r (I 2nn T )v old 2 Actually, not all the cups. To save computation time and make simulation fast, we only check the cups on the opposite of the table from the player who is throwing it. 5

7 E19 Final Project Report Liquid Pong Simulation Martin & Zhai GUI Design Once our back end functionality worked smoothly, we went to the drawing board to design our GUI. We modeled our system after the standard space mission control panel where control, flight trajectory and live flight statistics are displayed on separate panel for optimal clarity. Shown in Figure 6 is an artist s depiction of the control console where the interface is divided into three panels. On the left side is the virtual setup for the game. The upper right hand panel contains sliders and radio button for the user to choose flight parameters. The lower right hand panel displays in real time some of the essential flight and environmental statistics. 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 would automatically generate a.m file that includes callback functions for each button/output. The GUI includes a structure called handles where the handles for all the buttons and textboxes are stored. In addition, we could include global variables such as setup parameters in the structure to be called and passed to each callback function. For example, we included our back end simulation code in the launch button callback. Once the button is pressed, the 6

8 simulation code will grab relevant information from the handles such as which player s turn it 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 can bounce off the surface of the table, and the result of their turn is displayed. This worked well to 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 the ball fails to bounce off surfaces of cups. Figure 8 shows a successful cup bouncing and an unsuccessful one. In addition, the GUI is sluggish since we have lots of interactive button and information getting updated very frequently. To speed up the simulation, we are only plotting the position of the ball every 20 time steps and updating the flight statistics every 100 steps. Even with this compromise, the GUI performance is not ideal. When there are four plots to be updated and handles to be changed periodically, Matlab strains to keep up with the computational requirement and it crashes quite often. Shown in Figure 9 to Figure 12 is some trial runs of the GUI. 7

9 (a) Good bounce (b) Bad bounce Figure 8: A demonstration of bouncing results 8

10 Figure 9: Bounce off the side 9

11 Figure 10: Another example of bouncing off the side 10

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

13 Figure 12: Player 1 has scored 12

14 Future Goals and Conclusion In conclusion, we have met most of our goals for the project other than the developing a computer that can use minimization schemes to play the game intelligently with a human player. Through this project, we have learned and implemented how to simulate ball bouncing 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 our accomplishment. There are a few things we did not have time perfect and implement. For example, we ignored the effect of spin on bouncing and. We also did not pay much attention to check for rule violation such as if the bouncing happend on the legitimate side of the table. We also did 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 a player 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 redundancy and streamline process flow to make the simulation smoother, faster and less susceptible to crashing. Acknowledgments We would like to express our thanks to Prof. Zucker for his help in developing the algorithms for bouncing algorithms. In addition, we are grateful to Price and Chris for their insights on how to facilitate a faster simulation. 13