Batting Simulator

Electrical Design

Gaming Controller

Pitching Algorithm

From our original goals, we were able to accomplish the following:

1. A player uses the joystick to move the bat up and down.
2. Pressing and holding the button results in increasing, then decreasing power. This can be thought of as winding up the bat.
3. Releasing the button locks in the power value, and the swing is initialized.

The bat position (determined by joystick position) is animated at all times. To do so, the drawBat() function is called, which animates both the bat and the batter's box. This function calls the get_bat_position() function which pulls the joysticks gpio value using the adc. This value is shifted (to high pass), normalized, and scaled by the height of the batters box. This ensures that the maximum joystick position corresponds to the top of the batter's box and that the minimum joystick position corresponds with the bottom of the box. This bat position (in world coordinates) is stored in the bat_position global float. The draw_bat() function is called once per animation frame.

Button Press Registering

Once the player presses the batting button to wind up their swing and generate power, an interrupt associated with the button’s falling edge state is called. This interrupt sets a holding_power_button boolean true, stores the time the button was pressed in the start_button_press variable, and sets an already_hit boolean true. The already_hit boolean prevents the player from being able to swing the bat multiple times for one pitch. The holding_power_button boolean guards the portion of code responsible for animating the power bar (seen in the bottom right corner of early and late swing figures).

Animating the power bar works as follows: The amount of time the button has been held is determined by subtracting start_button_press from the current time. This value is transformed into a value between 0 and 1. That transformed value then determines the width of the red rectangle to be drawn.

As the player watches the ball animate from the pitcher’s mound to the strike zone, they release the button to initiate their bat swing. This triggers an interrupt tied to the button’s rising edge. This interrupt sets the holding_power_button boolean to False, sets the bat_swung boolean to true, and captures the time the button was released into the release_button_press variable.

get_collision()

The main animation loop registers this bat_swung boolean and checks to see if the player successfully hit the baseball using the get_collision() function. The get_collision() function satisfies the goal of determining whether the player placed the bat in the correct location and if the player successfully timed their swing. Once both have been determined to be successful, the get_collision() function outputs the balls exit velocity in the x, y, and z directions.

To determine both the successful timing of the pitch and the exit angle between the z and x directions, the relative amount of time it takes for the ball and the bat to reach the plate is used. If it takes longer for the pitch to reach the z = 0 mark than the bat, then the batter swung early and the ball should go to the left. If the ball reaches the z = 0 mark before the bat, then the batter swung late and the ball should go to the right. If the difference in time between the ball and bat reaching the plate is sufficiently great, then the player missed the ball entirely. The miss threshold and amount of time it takes the ball to reach horizontal were determined to be 0.08 and 0.3 empirically.

To determine a positioning miss, the balls y position when it reaches the plate is compared to the bat’s active position. Essentially, it is checked whither the ball’s bottom edge is below the bat’s top edge and that the ball’s top edge is above the bat’s bottom edge. It is important to note that despite the bat being animated as 1 pixel thick, within game logic it is 20cm thick. This was done to make batting mechanics easier. A real life bat width 6.6cm width was prohibitively difficult.

Ball and Bat Overlap Trigonometry

Once it is determined that the player successfully timed their swing and placed their bat in an acceptable position, the exit angles and velocity are calculated. The angle between the z and y axis is determined using trigonometry, as seen above. The angle between the z and x axis is determined using the difference in the amount of time it takes for the bat and ball to reach the z = 0 mark. This value, delta_t_ball, is normalized on the bat_miss_threshold as it can be no larger in magnitude than the bat_miss_threshold. This normalized value is scaled by the maximum_ball_angle, a value empirically set to 20 degrees. Finally, the exit velocity is determined using classical momentum equations (m1v1 + m2v2 = …) and is scaled by a scale factor empirically set to 3. Finally, if the angle between the z and y axes is greater than 45 degrees, the velocity value is scaled such that it is more likely for the player to be able to see the full ball flight.

Once this computation is completed, the number of strikes and balls are set to zero and the run counter is incremented. If the player missed the ball, the number of strikes is incremented.

3D Graphics

#define scale_factor 0.5
vgaPoint convert_to_vga(float x, float y, float z) {
    int center_x = 320;
    int center_y = 225;
    float f = 500; // Focal length in pixels

    z = z + camera_to_plate;

    vgaPoint point = {0, 0, 0.0};

    // Protect against divide-by-zero
    point.vga_x = center_x + (int)((x * f) / (1 + z));
    point.vga_y = center_y + (int)(((y - camera_height) * f) / ((1 + z) * scale_factor));
    point.vga_z = f / z;

    return point;
}

Power Control

Power Button

The power button is controlled using an Interrupt Handler. When the button falls low, meaning it was pressed, the interrupt handler saves the current time of day. Once the button is pressed, the code continuously checks to see if button is low, and if so uses an intermediate value to hold the amount of time that has passed since the button was first pressed. This intermediate value is then used to calculate a power ratio of time held over 0.5 seconds. To enforce timing restraints on the user, if the player has held down the button for longer than 0.5 seconds, the power ratio is then calculated by the amount of time longer than .5 seconds that the user has held the button, with a minimum power of 0.2. This ratio is then sent to the updatePower() function to update the animation.

The updatePower() function animates the power bar by first converting the current power level (a float between 0 and 1) into a string for display. It then updates the numerical value on screen and redraws the power bar by clearing the previous bar and filling a red rectangle proportional to the power level. This creates a smooth, responsive visual indicator of how much power the user has charged.

Game Play Logic

To take the physics and the VGA graphics and turn it into an actual game, we needed to add game logic. This included creating global booleans that kept track of whether or not the player was playing the game, a global counter to keep track of the number of strikes, a global counter to keep track of the number of outs, and a global counter to keep track of the number of balls.

Starting the Game

Start Screen

Upon starting the game, the player is greeted with the start screen. Pressing the button triggers the GPIO callback falling function as the button is pulled high until pressed. In the GPIO callback function, the program first checks to see if the player is already playing. If the user is not already playing, the global boolean playing is set to True and the game begins.

Counting Runs

To keep the game simple, we maintained a global integer counter for the number of runs that the player has hit. This number is incrememented whenever the player makes contact with the ball, no matter how far it goes.

Counting Strikes

Strike Out Screen

In baseball, a strike out is composed of 3 pitches that are inside of the batters box but the batter does not hit. To keep track of the number of strikes, we instantiated a global integer that was added to whenever batter swung at a pitch and missed or whenever the batter did not swing at a pitch and it landed in the batters box. In baseball, if the batter swings and misses the ball, even if the pitcher misses the batters box, it counts as a strike. Once the user gets to 3 strikes, they are out. This triggers the increment the global integer out counter and the strike out screen, which displays for 1 second upon strike out. The global strike counter is reset back to zero when the player is struck out.

Counting Balls

In correspondance with the rules of baseball, the pitcher is punished upon throwing 4 balls by allowing the batter to walk to first base. To ensure our game mimiced this same punishment for our randomized pitching algorithm, we instantiated a global integer counter to track the number of balls the pitcher has thrown that the player has not swung at. Once the pitcher reaches 4 balls, the player is awarded a run. The global integer ball counter is then reset back to zero. This value is also reset upon strike out to mimic the changing of players in a real baseball game who do not get to keep the balls awared to another player.

Counting Outs

A baseball inning is over when the team has achieved 3 outs. We elected to keep this as the number of outs that a player can achieve before the game is over. Similar to strikes, balls, and runs, the number of outs is maintained using a global integer counter. It is incremented when a player gets 3 strikes. Upon 3 outs, the Game Over screen is displayed, as shown below.

Game Over Screen

This screen is held for 2 seconds, and then the start screen is returned to. The number of runs that the player scored during the game is not reset until the player presses the button to start again. This was a design decision chosen to make it easier for the user to know what their final score was. The number of strikes and outs are reset upon the ending of the game.

Audio

The audio is controlled by PWM signals. To create the PWM signal, we used a Jupiter Notebook file we found online to convert the Take me out to the Ball Game wav file into a file that will be read into PWM signals [1]. Due to the limited memory on the RP2040, we restrained the number samples to be played to 100,000 samples. The PWM frequency values outputted from the Jupyter Notebook were then copied and pasted into a header file for easy access by the program.

To set up the PWM, we first set the PWM inputs to the defualt. To ensure the audio was nonblocking in our program, we use Interrupt Request Handling for the audio. We then used clk divide to set the interrupt rate. The base clock of the RP2040 is 176,000,000 Hz, which is then wrapped by 240. By further dividing it by 6.0f, we were able to achieve an upbeat faster tone that we wanted to put a good vibe to our game at about 15 KHz. In the Interrupt Handler, we check to make sure we are not at the end of the PWM values, and if we are we restart. This ensures that our game has audio running on a loop. The actual conversion of the PWM output signals to audible signal is handled using the hardware, making the software less complicated.

Results

From our original goals, we were able to accomplish:

1. Random Pitches
2. User times bat using a button
3. Joystick functionality
4. Ball's flight modeled using physics
5. Visually aesthetic and realistic graphics 6. Background track

From our original goals, we were unable to implement:

1. Pitching mode
2. Stick Figure Animation

Our final implementation was evaluated for performance, accuracy, safety, and usability.

• Execution Speed: The system responded with minimal hesitation or flicker during real-time interactions. VGA rendering and audio playback ran concurrently without noticeable lag, ensuring smooth animation and responsive controls.
• Accuracy: Numerical values such as ball velocity and power level were displayed with reliable precision. VGA timing was stable with no observable visual artifacts.
• Test Data: Internal test values such as joystick input, power calculations, and object positions were monitored to ensure consistent operation across different states of gameplay.
• Safety Enforcement: Software bounds checking was used to prevent overflow or invalid inputs (e.g., joystick values and power limits), and hardware pins were protected with current-limiting resistors to safeguard the board and peripherals.
• Usability: The system was tested by multiple users and was found to be intuitive and stable. The joystick offered smooth control of the bat, and the animated power bar gave clear visual feedback, making the interface easy to learn and operate.