Difference between revisions of "F24: Jardinains"

Revision as of 23:13, 19 December 2024

Grading Criteria

Project Title

Jardinaiins

Abstract

Prepare for endless bouncing, breaking, and gnome-busting excitement! Jardinaiins reinvents classic brick-breaking gameplay with a delightful twist. Dive into vibrant, garden-themed levels filled with challenging obstacles, quirky gnome antics, and thrilling power-ups. Smash through barriers, outsmart mischievous gnomes, and uncover surprises as you progress in this fun and addictive adventure!

Objectives & Introduction

• Interface the SJ2 board with the Waveshare 64x64 RGB LED Matrix Panel to display dynamic text, colorful images, and animations. The onboard GPIOs of the SJ2 microcontroller will drive the LED panel, and its chainable design will be utilized to facilitate scalability for larger displays. • Use the MMA845XQ accelerometer onboard the SJ2 board as the player controller, mapping tilt and motion inputs to control animations, select media, or interact with displayed content on the LED matrix. • Integrate the HiLetgo GD3300 UART Control Serial MP3 Music Player Module to enable digital audio output by leveraging the SJ2 board’s UART protocol. The system will send serial commands for operations like play, pause, track selection, and volume control. • Utilize the General Purpose Direct Memory Access (GPDMA) controller on the SJ2 board for memory-to-memory transfers, reducing delays during video buffer updates for the LED matrix. • Leverage the DMA controller's memory-to-peripheral function to minimize frequent I2S interrupts while loading digital audio content to the MP3 module, optimizing system performance. • Implement an SD card peripheral driver on the SJ2 board to facilitate reading and writing of multimedia data, enabling seamless storage and retrieval of audio and visual content for playback and display.

Team Members & Responsibilities

• Dev Hitesh Malkan
• Nidhi Sharma
• Sunny Shah
• Navya

Sure! Here is the updated table with your provided data in the requested format:

Schedule

Parts List & Cost

Give a simple list of the cost of your project broken down by components. Do not write long stories here.

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Discuss your hardware design here. Show detailed schematics, and the interface here.

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

Software Design

Controller The accelerometer on the SJ2 board manages paddle movement by sampling the y-axis magnitude 17 times over a 17-millisecond period and calculating the average. This value is capped at a maximum of 700 within a range of 1000. To make it simpler, the tilt value is divided by 31, producing 32 possible readings, which correspond to 5 bits of data. Each time there is a change in magnitude or a button press, the controller transmits a single byte of data to the console. This byte encapsulates all the necessary information for controlling the on-screen paddle. The first two bits indicate button input, with 0 representing no input and 1 indicating input detection. The third bit specifies the tilt direction, where 0 means left and 1 means right. The remaining five bits represent the accelerometer's magnitude.

Audio Sound effects are added using MP3 Serial Decoder HiLetgo GD3300, source code was written on our own.

Implementation

Paddle Movement The paddle movement is driven by accelerometer data wirelessly transmitted from the SJ-Two board to the LPC4088 board. This data is mapped to 63 possible positions for the paddle. Initially, the paddle would instantly move to the position corresponding to the accelerometer input. However, this approach was refined by introducing an algorithm that allows for a smoother transition between positions. The algorithm calculates paddle velocity based on the "current desired position" and the previous position. Parameters of the algorithm were fine-tuned iteratively to achieve a smooth and responsive paddle movement. Paddle-Ball Collision Logic The ball's position is updated each frame by adding delta_x and delta_y to its current x and y coordinates. If the ball's next y-position crosses the paddle's y-position, a paddle collision check is performed. To do this, the ball's movement is modeled as a slope derived from delta_x and delta_y. Using this slope, along with the ball's current position and one pixel above the paddle's y-position, a point-slope equation (y2−y1)=m(x2−x1)(y_2 - y_1) = m(x_2 - x_1)(y2​−y1​)=m(x2​−x1​) is used to calculate the x-position of the ball at the time it reaches that y-coordinate. Once the expected collision point is determined, the ball's collision magnitude and its next position's magnitude are calculated. By comparing these magnitudes, a time fraction for the frame is derived to estimate when the ball might have collided with the paddle. Using the paddle's current position and velocity, the paddle's previous position is estimated to determine how far it moved during this time fraction. By multiplying the time fraction by the paddle's x-position change, it is possible to check whether the paddle was underneath the ball at the moment it reached the pixel above the paddle's y-position.

Testing & Technical Challenges

Ball-Collision Logic The initial ball collision logic relied on pixel values to detect when the ball entered a brick. However, this approach failed to handle cases where the ball entered a brick diagonally, requiring the logic to be completely reworked. In the updated version, the focus shifted to determining whether the ball was crossing into an area containing a brick. This was achieved by dividing the playing field into a grid representing the positions of the bricks. The new logic involved an initial check to see if the ball was crossing a boundary near a brick. If the ball crossed only the x-boundary, a collision check was performed to determine if it hit a brick. Similarly, if it crossed only the y-boundary, another collision check was conducted. In cases where the ball crossed both x- and y-boundaries, additional logic was applied to determine which boundary the ball crossed first. This updated method effectively handled diagonal collisions and improved the overall accuracy of the collision detection. This experience highlighted the value of abandoning ineffective solutions and adopting new approaches, as they can lead to better outcomes. Paddle Movement We encountered an issue where the paddle would slow down as it neared the walls. This happened because the difference between the "current desired paddle position" and the previous paddle position decreased near the walls, resulting in a reduced paddle velocity. To address this, we adjusted the logic so that whenever the accelerometer data mapped to the minimum or maximum paddle index, the "current desired paddle position" was extended. This adjustment ensured that the paddle velocity remained consistent, preventing the paddle from slowing down as it approached the walls. Paddle – Collision Logic During final integration and testing, one major issue we faced was a bug where the ball failed to detect collisions with the paddle, causing it to pass through instead of bouncing off. To troubleshoot this, we implemented a clever debugging method: changing the ball's colour during each collision check. This allowed us to visually confirm whether the collision logic was being executed. Through this approach, we discovered that the section of code responsible for checking paddle collisions was being skipped, even when the ball's next y-position had crossed the paddle's y-position. This debugging method proved invaluable in identifying and resolving the root cause of the issue.

<Bug/issue name>

Discuss the issue and resolution.

Conclusion

We thoroughly enjoyed the process of creating this project and gained a wealth of knowledge along the way. Our driver development skills were sharpened as we wrote drivers for various modules, including the LED matrix and MP3 decoder. Additionally, our understanding of the FreeRTOS API deepened, and we acquired fundamental game and graphics development skills through our work with the LED matrix. Throughout the project, we faced numerous challenges, such as getting the LED matrix driver to function properly, implementing collision detection with multiple game objects, and designing and maintaining a complex game logic state machine, among many others. Each obstacle provided valuable learning experiences and contributed to our growth as developers. By applying design principles and communication protocols learned in lectures, we successfully brought this project to life. Key concepts we utilized include UART, SPI, I2C, I2S, DMA, FreeRTOS mutexes, binary semaphores, queues, task creation, stack sizing, task scheduling, interrupt service routines, and bootloaders. Through countless hours of testing and verification, we learned the critical importance of allocating sufficient time for integration and debugging, as it greatly increases the likelihood of a successful outcome. Without this phase, the project might have faced significant issues upon delivery. We hope this project serves as a helpful resource for future engineers and wish you all great success and enjoyable development experiences ahead!

Project Video

Upload a video of your project and post the link here.

Project Source Code

• Sourceforge Source Code Link

References

Acknowledgement

Any acknowledgement that you may wish to provide can be included here.

References Used

List any references used in project.

Appendix

You can list the references you used.