Difference between revisions of "F18: Goals of Glory"
Proj user17 (talk | contribs) (→Hardware Interface) |
Proj user17 (talk | contribs) (→Team Members) |
||
(172 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
+ | [[File:F18_GOGCoverPage.jpg||550x950px|right|Goals Of Glory]] | ||
== Project Title == | == Project Title == | ||
+ | |||
+ | |||
==== Goals of Glory ==== | ==== Goals of Glory ==== | ||
Line 33: | Line 36: | ||
* Prepare the entire system for demo purpose which includes gloves and mounting pads to mount hardware equipment | * Prepare the entire system for demo purpose which includes gloves and mounting pads to mount hardware equipment | ||
+ | ==== Team Members ==== | ||
+ | * [https://www.linkedin.com/in/aniket-phatak-8440ba43/ Aniket Phatak] | ||
+ | * [https://www.linkedin.com/in/bhargav-pandit-9600a78a/ Bhargav Shashidhara Pandit] | ||
+ | * [https://www.linkedin.com/in/harmeen-joshi-499973b7/ Harmeen Joshi] | ||
+ | * [https://www.linkedin.com/in/satyasdn/ Satya Sai Deepak. Naidu] | ||
+ | * [https://www.linkedin.com/in/tahirrawn/ Tahir Rawn] | ||
+ | |||
+ | ==== Responsibilities ==== | ||
+ | * '''Display(RGB LED Matrix) and Game Logic''' | ||
+ | **[https://www.linkedin.com/in/harmeen-joshi-499973b7/ Harmeen Joshi] | ||
+ | **[https://www.linkedin.com/in/tahirrawn/ Tahir Rawn] | ||
+ | **[https://www.linkedin.com/in/satyasdn/ Satya Sai Deepak. Naidu] | ||
− | |||
* '''Player Movements''' | * '''Player Movements''' | ||
− | **Aniket Phatak | + | **[https://www.linkedin.com/in/aniket-phatak-8440ba43/ Aniket Phatak] |
− | **Bhargav Shashidhara Pandit | + | **[https://www.linkedin.com/in/bhargav-pandit-9600a78a/ Bhargav Shashidhara Pandit] |
* '''Goalkeeper Movements''' | * '''Goalkeeper Movements''' | ||
− | **Tahir Rawn | + | **[https://www.linkedin.com/in/tahirrawn/ Tahir Rawn] |
− | **Harmeen Joshi | + | **[https://www.linkedin.com/in/harmeen-joshi-499973b7/ Harmeen Joshi] |
− | |||
− | |||
− | |||
− | |||
− | |||
* '''Wireless (Nordic)''' | * '''Wireless (Nordic)''' | ||
− | ** | + | **[https://www.linkedin.com/in/bhargav-pandit-9600a78a/ Bhargav Shashidhara Pandit] |
− | ** | + | **[https://www.linkedin.com/in/aniket-phatak-8440ba43/ Aniket Phatak] |
* '''PCB Design''' | * '''PCB Design''' | ||
− | **Satya Sai Deepak. Naidu | + | **[https://www.linkedin.com/in/satyasdn/ Satya Sai Deepak. Naidu] |
==== Game Stats: ==== | ==== Game Stats: ==== | ||
Line 179: | Line 188: | ||
* Final Demo | * Final Demo | ||
| | | | ||
− | * | + | * Completed |
|- | |- | ||
|} | |} | ||
Line 229: | Line 238: | ||
| 3 | | 3 | ||
| 24 | | 24 | ||
− | + | ||
− | |||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
! scope="row"| 8 | ! scope="row"| 8 | ||
Line 250: | Line 254: | ||
! scope="row"| 9 | ! scope="row"| 9 | ||
| Total | | Total | ||
− | | | + | | - |
− | | | + | | - |
− | | | + | | $418 |
|} | |} | ||
Line 260: | Line 264: | ||
=== Hardware Design === | === Hardware Design === | ||
− | The Hardware design for our project Goals of Glory involves usage of 3 SJone boards, a 64x64 LED matrix, MPU6050 gyroscope & accelerometer sensor, MMA8452Q accelerometer (onboard sensor) and Nordic wireless (nRF24L01+) | + | * The Hardware design for our project Goals of Glory involves usage of 3 SJone boards, a 64x64 LED matrix, MPU6050 gyroscope & accelerometer sensor, MMA8452Q accelerometer (onboard sensor) and Nordic wireless (nRF24L01+). |
+ | [[File:GoG_BlockDiagram.png|thumb|750x500px|center| Goals of Glory block diagram]] | ||
− | === Hardware Interface === | + | === LED Matrix === |
+ | A 64x64 RGB LED Matrix Panel is used as a display. It is divided into two 32x64 sections. Each LED can be independently addressed and controlled. The LED matrix display is constructed using a decoder to decode row address. The rows can be individually accessed using the A, B, C, D, and E address pins. At a time one row in each of the 32x64 sections is selected. Each bit in the shift register controls the corresponding column. On every falling edge of the clock pulse, the values at R1, B1, G1, R2, B2, and G2 pins are stored into the shift register and the register shifts the data by one bit. After this, the data on the shift register is passed onto the individual LED's when both OE and LE pins are set to high. The intensity of each pixel can be controlled by the rate of refresh of the individual LED. | ||
+ | |||
+ | <center> | ||
+ | <table> | ||
+ | <tr> | ||
+ | <td> | ||
+ | [[File:frontview.jpg|thumb|400x300px|right| LED Matrix front View]] | ||
+ | </td> | ||
+ | <td> | ||
+ | </td> | ||
+ | <td> | ||
+ | [[File:rearview.jpg|thumb|400x300px|left| LED Matrix rear View]] | ||
+ | </td> | ||
+ | </tr> | ||
+ | </table> | ||
+ | </center> | ||
+ | |||
+ | |||
+ | <center> | ||
+ | <table> | ||
+ | <tr> | ||
+ | <td> | ||
+ | LED matrix pins: | ||
+ | {| class="wikitable" | ||
+ | |- | ||
+ | ! align="center"|S.NO | ||
+ | ! align="center"|RGB LED pins | ||
+ | ! align="center"|SJone GPIO pins | ||
+ | |- | ||
+ | | scope="row" align="center"|1 | ||
+ | | scope="row" align="center"|R1 | ||
+ | | scope="row" align="center"|P1.20 | ||
+ | |- | ||
+ | | scope="row" align="center"|2 | ||
+ | | scope="row" align="center"|G1 | ||
+ | | scope="row" align="center"|P2.7 | ||
+ | |- | ||
+ | | scope="row" align="center"|3 | ||
+ | | scope="row" align="center"|B1 | ||
+ | | scope="row" align="center"|P1.22 | ||
+ | |- | ||
+ | | scope="row" align="center"|4 | ||
+ | | scope="row" align="center"|R2 | ||
+ | | scope="row" align="center"|P1.23 | ||
+ | |- | ||
+ | | scope="row" align="center"|5 | ||
+ | | scope="row" align="center"|G2 | ||
+ | | scope="row" align="center"|P2.6 | ||
+ | |- | ||
+ | | scope="row" align="center"|6 | ||
+ | | scope="row" align="center"|B2 | ||
+ | | scope="row" align="center"|P1.28 | ||
+ | |- | ||
+ | | scope="row" align="center"|7 | ||
+ | | scope="row" align="center"|A | ||
+ | | scope="row" align="center"|P1.29 | ||
+ | |- | ||
+ | | scope="row" align="center"|8 | ||
+ | | scope="row" align="center"|B | ||
+ | | scope="row" align="center"|P2.5 | ||
+ | |- | ||
+ | | scope="row" align="center"|9 | ||
+ | | scope="row" align="center"|C | ||
+ | | scope="row" align="center"|P2.0 | ||
+ | |- | ||
+ | | scope="row" align="center"|10 | ||
+ | | scope="row" align="center"|D | ||
+ | | scope="row" align="center"|P2.4 | ||
+ | |- | ||
+ | |- | ||
+ | | scope="row" align="center"|11 | ||
+ | | scope="row" align="center"|E | ||
+ | | scope="row" align="center"|P1.19 | ||
+ | |- | ||
+ | |||
+ | | scope="row" align="center"|12 | ||
+ | | scope="row" align="center"|CLK | ||
+ | | scope="row" align="center"|P2.1 | ||
+ | |- | ||
+ | | scope="row" align="center"|13 | ||
+ | | scope="row" align="center"|OE | ||
+ | | scope="row" align="center"|P2.2 | ||
+ | |- | ||
+ | | scope="row" align="center"|14 | ||
+ | | scope="row" align="center"|LAT | ||
+ | | scope="row" align="center"|P2.3 | ||
+ | |- | ||
+ | | scope="row" align="center"|15 | ||
+ | | scope="row" align="center"|VCC | ||
+ | | scope="row" align="center"|3.3V | ||
+ | |- | ||
+ | | scope="row" align="center"|16 | ||
+ | | scope="row" align="center"|GND | ||
+ | | scope="row" align="center"|GND | ||
+ | |- | ||
+ | |} | ||
+ | </td> | ||
+ | <td> | ||
+ | </td> | ||
+ | <td> | ||
+ | [[File:F18_LEDMatrixOrg.png|thumb|700x600px|left| LED Matrix Organisation]] | ||
+ | </td> | ||
+ | </tr> | ||
+ | </table> | ||
+ | </center> | ||
+ | |||
+ | ===== Accelerometer-SJone (for player movement) ===== | ||
+ | * 3-Axis, 12-bit/8-bit Digital Accelerometer | ||
+ | Accelerometers are electromechanical devices that sense either static or dynamic forces of acceleration. Static forces include gravity, while dynamic forces can include vibrations and movement. The measurements are on 3-axis and these values can be calibrated to find the desired values. | ||
+ | The MMA8452Q is a smart low-power, three-axis, capacitive micromachined accelerometer with 12 bits of resolution. This accelerometer is packed with embedded functions with flexible user programmable options, configurable to two interrupt pins. Embedded interrupt functions allow for overall power savings relieving the host processor from continuously polling data. The MMA8452Q has user selectable full scales of ±2g/±4g/±8g with high pass filtered data as well as non filtered data available real-time. The device can be configured to generate inertial wakeup interrupt signals from any combination of the configurable embedded functions allowing the MMA8452Q to monitor events and remain in a low power mode during periods of inactivity. The MMA8452Q is available in a 3 mm x 3 mm x 1 mm QFN package. | ||
+ | |||
+ | {| | ||
+ | |[[File:CMPE244_S18_SS_Accelerometer.PNG|300px|thumb|left|Accelerometer on board]] | ||
+ | |[[File:Accelerometer_Interface.PNG|500px|thumb|right|Accelerometer Intefaced With Microcontroller]] | ||
+ | |||
+ | |} | ||
+ | |||
+ | |||
+ | ''' MPU 6050 (Gyroscope and Accelerometer) ''' | ||
+ | MPU 6050 Six-Axis (Gyro + Accelerometer) MEMS Motiontracking device. | ||
+ | The MPU-6050 incorporates InvenSense’s MotionFusion™ and run-time calibration firmware that enables manufacturers to eliminate the costly and complex selection, qualification, and system level integration of discrete devices in motion-enabled products, guaranteeing that sensor fusion algorithms and calibration procedures deliver optimal performance for consumers. The MPU-6050 devices combine a 3-axis gyroscope and a 3-axis accelerometer on the same silicon die, together with an onboard Digital Motion Processor™ (DMP™), which processes complex 6-axis MotionFusion algorithms. The device can access external magnetometers or other sensors through an auxiliary master I²C bus, allowing the devices to gather a full set of sensor data without intervention from the system processor. The devices are offered in a 4 mm x 4 mm x 0.9 mm QFN package. | ||
+ | |||
+ | For precision tracking of both fast and slow motions, the parts feature a user-programmable gyro full-scale range of ±250, ±500, ±1000, and ±2000 °/sec (dps), and a user-programmable accelerometer full-scale range of ±2g, ±4g, ±8g, and ±16g. Additional features include an embedded temperature sensor and an on-chip oscillator with ±1% variation over the operating temperature range. | ||
+ | |||
+ | In Goals of Glory, the SJone board controlling the player uses the above mentioned MPU 6050 (Gyroscope and Accelerometer) to map direction and tilt. This is achieved using the yaw, pitch and roll values that we obtained by writing an extensive gyro driver. More importantly, we were able to achieve precise angle measurements such that appropriate data points are mapped for our application. | ||
+ | For the goalkeeper, we were able to achieve the left and right orientation using SJone onboard accelerometer. Using raw values of X,Y,Z we set up left, right, up and down directions for the goalkeeper to follow. | ||
+ | |||
+ | [[File:mpu1.jpg|thumb|400x300px|left| MPU 6050 IC]] | ||
+ | [[File:mpu3.png|thumb|400x300px|center| MPU connections]] | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==== Hardware Interface ==== | ||
+ | |||
''' Nordic Wireless ''' | ''' Nordic Wireless ''' | ||
− | + | The SJOne board(LPC1758) is interfaced with Nordic wireless (nRF24L01+) chip using SPI. | |
− | SJOne board is interfaced with Nordic wireless (nRF24L01+) using SPI. | ||
The nRF24L01+ is a single chip 2.4GHz transceiver with an embedded baseband protocol engine, suitable for ultra low power wireless applications. The nRF24L01+ is designed for operation in the frequency band of 2.400 - 2.483GHz. | The nRF24L01+ is a single chip 2.4GHz transceiver with an embedded baseband protocol engine, suitable for ultra low power wireless applications. The nRF24L01+ is designed for operation in the frequency band of 2.400 - 2.483GHz. | ||
+ | The register map, which is accessible through the SPI, contains all configuration registers in the nRF24L01+ and is accessible in all operation modes of the chip. The embedded baseband protocol engine (Enhanced ShockBurst™) is based on packet communication and supports various modes from manual operation to advanced autonomous protocol operation. Internal FIFOs ensure a smooth data flow between the radio front end and the system’s MCU. Enhanced ShockBurst™ | ||
+ | reduces system cost by handling all the high-speed link layer operations. nRF24L01+ supports an air data rate of 250 kbps, 1 Mbps and 2Mbps. The high air data rate combined with two power saving modes make the nRF24L01+ very suitable for ultra-low power designs. | ||
+ | In our project, we are employing three SJone boards each interfaced with a Nordic wireless chip. We use two boards for continuously transmitting direction data computed from the respective boards i.e player's and goalkeeper's movements. The third board receives the data transmitted from the other two boards. The three boards are uniquely identified based on their device ID (node address) as defined. In order for the boards to communicate smoothly without an interception, the communication has to occur on the same communication channel. This will prevent collision between two or more mesh networks. | ||
Line 279: | Line 421: | ||
The game uses a 64x64 LED Matrix which needs a 5v input supply. Since the board supplies 3.3v we level shift the voltage to 5v to avoid any unwanted flickering. So, we have decided to design a level shifter circuit. The design starts with the schematics and then designing the footprint. The design ends with creating the Gerber files and sending them to the manufacturing unit. | The game uses a 64x64 LED Matrix which needs a 5v input supply. Since the board supplies 3.3v we level shift the voltage to 5v to avoid any unwanted flickering. So, we have decided to design a level shifter circuit. The design starts with the schematics and then designing the footprint. The design ends with creating the Gerber files and sending them to the manufacturing unit. | ||
− | [[File:Level Shifter_schematics.jpg|thumb| | + | [[File:Level Shifter_schematics.jpg|thumb|750x500px|center| Schematics for the circuit]] |
'''Schematics:''' | '''Schematics:''' | ||
− | The design was made in Eagle PCB design software. In preparing your schematics we encountered few challenges with the selection of equipment dimensions and dimension terminology(units). The designer should be aware of the dimensions of equipment that are to be used. After getting the idea of equipment, add the library of that equipment to eagle through manage library option. Now, the designer can get that item schematic and add it to the design schematics. Complete the schematics based on the circuit that the designer wants to implement. | + | The design was made in Eagle PCB design software. In preparing your schematics we encountered few challenges with the selection of equipment dimensions and dimension terminology(units). The designer should be aware of the dimensions of equipment that are to be used. After getting the idea of equipment, add the library of that equipment to eagle through manage library option. Now, the designer can get that item schematic and add it to the design schematics. Complete the schematics based on the circuit that the designer wants to implement. The above figure shows the schematics for a level shifter circuit. |
− | + | [[File:Foot_Print.JPG|thumb|500x220px|left|Foot Print]] | |
+ | [[File:Final_Board.JPG|thumb|500x220px|right|Final Board]] | ||
− | |||
− | |||
− | |||
− | |||
'''Foot Print and Gerber Files:''' | '''Foot Print and Gerber Files:''' | ||
Line 296: | Line 435: | ||
The designer can select one or draw the traces manually( manual is mostly preferred for better results). The footprint of out circuit is shown in Figure.2. Now, continue with DRC(design real check ) to check the possible errors while manufacturing. Make sure that there are no errors. After all the errors are cleared create the Gerber files for manufacturing company to provide those files to the manufacturing machines. | The designer can select one or draw the traces manually( manual is mostly preferred for better results). The footprint of out circuit is shown in Figure.2. Now, continue with DRC(design real check ) to check the possible errors while manufacturing. Make sure that there are no errors. After all the errors are cleared create the Gerber files for manufacturing company to provide those files to the manufacturing machines. | ||
+ | '''''Few tips for schematics:''''' | ||
+ | |||
+ | • Make sure the dimensions of auxiliary equipment size match the equipment. For example, the supply port size is 4mm pitch 4 pins if I use 2mm pitch 4pins the circuit cannot be practically implemented. | ||
+ | |||
+ | • Have a clear idea of the equipment and their availability in the market before getting started. Sometimes your design may be correct, but you will not be getting appropriate equipment for installing on circuit board. | ||
+ | • Use Vcc and Gnd pins for reducing circuiting complexity. | ||
+ | |||
+ | === Software Design and Implementation === | ||
+ | == LED Matrix Display Driver: == | ||
+ | We have created four independent tasks to control different parts of the game at the same time. Those are as follows: | ||
+ | * Update Display Task | ||
+ | This task is dedicated to refreshing the LED matrix at on a periodic basis. We have configured it to refresh the display after every 2 milliseconds. | ||
+ | |||
+ | * Control Goalkeeper Task | ||
+ | The Control Goalkeeper Task keeps track of the data coming wirelessly from the accelerometer sensor device mounted on the defending player’s hand and updates the goalkeeper position accordingly. | ||
+ | * Control Game Task | ||
+ | The control game task is the task which controls the flow of the game this includes waiting for the gyro-sensor values before animating the ball, updating player1 and player2 scores, determining the end of the game and taking appropriate action for it. | ||
+ | * Select Player Task | ||
+ | The select player task is the task displays the start screen animation and the color select logic. | ||
+ | |||
+ | To solve the ungraceful transition of the ball from the first half of the matrix to the other( Refer point 1e in the Challenges faced and Solutions section for more details). We designed a draw pixel function which allows the users to pass the x, y and color coordinates without worrying about the two 32x64 sections and their different x coordinates this function takes the required 64x64 matrix coordinates, calculate the actual x (or ROW) coordinate value and the color value according to the 32x64 sections and draws the pixel at the desired location making addressing the exact required pixel easier. Following are the snippets of code that achieve this. | ||
+ | |||
+ | |||
+ | [[File:drawPixel.jpg||500x600px|left|Draw Pixel]] | ||
+ | [[File:CalculateMatrixPosition.jpg||600x700px|center|Calculate Matrix Position]] | ||
+ | |||
+ | ==== Goalkeeper driver ==== | ||
+ | The raw values from SJone's accelerometer are mapped to obtain left and right orientation values. The pseudo code given below illustrates this where the task GoalkeeperLocation has the calculation for left as well as the right direction. | ||
+ | |||
+ | <source lang="cpp"> | ||
+ | void GoalkeeperLocation(void *p) | ||
+ | |||
+ | { | ||
+ | float orientationAngle = 0; | ||
+ | int wireless_ret = -99; | ||
+ | int16_t x,y,z; | ||
+ | const char *data = ""; | ||
+ | |||
+ | while(1) | ||
+ | { | ||
+ | x = AS.getX(); // Get X-axis values | ||
+ | y = AS.getY(); // Get Y-axis values | ||
+ | z = AS.getZ(); // Get Z-axis values | ||
+ | //u0_dbg_printf("X: %d, Y: %d, Z: %d\n", x, y, z); | ||
+ | orientationAngle = sin(z/x); | ||
+ | // Left orientation | ||
+ | if ((orientationAngle > 0.025) && (x > 50)) | ||
+ | { | ||
+ | u0_dbg_printf("LEFT.\n"); | ||
+ | //wireless_ret=wireless_send(221,mesh_pkt_nack,"left",4,0); | ||
+ | data = "left"; | ||
+ | } | ||
+ | // Right orientation | ||
+ | else if ((orientationAngle < (-0.025)) && (x < 0)) | ||
+ | { | ||
+ | u0_dbg_printf("RIGHT.\n"); | ||
+ | //wireless_ret=wireless_send(221,mesh_pkt_nack,"right",5,0); | ||
+ | data = "right"; | ||
+ | } | ||
+ | |||
+ | |||
+ | </source> | ||
+ | |||
+ | ==== Player driver ==== | ||
+ | This module includes getting yaw, pitch, and roll which are obtained from 6 axes MPU 6050 i.e. 3 axes (X, Y, Z) gyroscope and 3 axes(X, Y, Z) accelerometer. | ||
+ | |||
+ | <source lang="cpp"> | ||
+ | void Gyro_Task(void *pvParameter) | ||
+ | { | ||
+ | const char* data = ""; | ||
+ | mesh_packet_t MasterRcvPkt; | ||
+ | float arx, ary, arz; | ||
+ | while(1) | ||
+ | { | ||
+ | accelX = MPU_SEN.ACCEL_XOUT(); | ||
+ | accelY = MPU_SEN.ACCEL_YOUT(); | ||
+ | accelZ = MPU_SEN.ACCEL_ZOUT(); | ||
+ | |||
+ | gyroX = MPU_SEN.GYRO_XOUT(); | ||
+ | gyroY = MPU_SEN.GYRO_YOUT(); | ||
+ | gyroZ = MPU_SEN.GYRO_ZOUT(); | ||
+ | |||
+ | accelX = accelX / 16384.0; | ||
+ | accelY = accelY / 16384.0; | ||
+ | accelZ = accelZ / 16384.0; | ||
+ | |||
+ | arx = (180/3.141592) * atan(accelX / sqrt(pow(accelY,2) + pow(accelZ,2))); | ||
+ | ary = (180/3.141592) * atan(accelY / sqrt(pow(accelX,2) + pow(accelZ,2))); | ||
+ | arz = (180/3.141592) * atan(sqrt(pow(accelY,2) + pow(accelX,2)) / accelZ); | ||
+ | |||
+ | |||
+ | </source> | ||
+ | |||
+ | * Getting yaw, pitch and roll: | ||
+ | |||
+ | <source lang="cpp"> | ||
+ | gyroX = gyroX / 131.0; | ||
+ | gyroY = gyroY / 131.0; | ||
+ | gyroZ = gyroZ / 131.0; | ||
+ | |||
+ | rollangle=atan2(accelY,accelZ)*180/PI; // FORMULA FOUND ON INTERNET | ||
+ | pitchangle=atan2(accelX,sqrt(accelY*accelY+accelZ*accelZ))*180/PI; //FORMULA FOUND ON INTERNET | ||
+ | |||
+ | //Using Complementary Filter | ||
+ | roll=A*(roll+gyroX*dt)+(1-A)*rollangle; | ||
+ | pitch=A*(pitch+gyroY*dt)+(1-A)*pitchangle; | ||
+ | |||
+ | yaw=gyroZ; | ||
+ | |||
+ | |||
+ | </source> | ||
− | |||
− | === | + | ===Testing=== |
− | + | * We followed rigorous testing standards to ensure that no bugs or issues are left unchecked especially when inter-dependent FreeRTOS tasks are running in real time. | |
+ | * Initially in our ball animation testing phase we were getting irregular ball movements along with false colors, which we later fixed using proper techniques. | ||
+ | * Similarly in our start screen, we initially had issues relating to color selection schemes that we have in our design. These were fixed by making sure that proper coding standards were followed along with extensive testing with respect to the color selection | ||
+ | {| | ||
+ | |[[File:F18_Startscreentesting.gif|thumb|470x370px|left|Start Screen Testing]] | ||
+ | |[[File:F18_GOGP2screentesting.jpg|thumb|275x225px|center|Player two Screen Testing]] | ||
+ | |[[File:F18_ballanimation.gif|thumb|225x270px|right|Ball animation ]] | ||
+ | |[[File:F18_tie.gif|thumb|200x250px|right|Match Tie ]] | ||
+ | |[[File:F18_p2win.gif|thumb|350x450px|right|Player 2 wins]] | ||
− | + | |} | |
− | |||
== Testing & Technical Challenges == | == Testing & Technical Challenges == | ||
Line 309: | Line 565: | ||
===Issues, Challenges and solutions to get past them=== | ===Issues, Challenges and solutions to get past them=== | ||
− | '''1. | + | '''1. RGB LED Matrix Display driver''' |
− | a) Writing the driver function on our own was a challenge. We were able to easily glow a single row in the matrix. However, the challenge lied in glowing a single pixel value at a specified location. And lack of datasheet made it even more difficult. Once we got the control over glowing a single LED (check updateDisplay function as shown above), we were able to implement various functions to draw lines, | + | a) Writing the driver function on our own was a challenge. We were able to easily glow a single row in the matrix. However, the challenge lied in glowing a single pixel value at a specified location. And lack of datasheet made it even more difficult. Once we got the control over glowing a single LED (check updateDisplay function as shown above), we were able to implement various functions to draw lines, digits, text, ball, and goalkeeper. |
− | b) Matrix flickering | + | b) Matrix flickering problem in which pixels on the screen weren't consistently bright when a particular animation was going on |
+ | *To solve this, we stopped clearing the whole display multiple times and cleared the specific pixels which mattered. Also, we were using a separate task, in which we were sending the data through the queue to control game task which was causing the task to wait on the queue till the data arrived which was causing flickering.So we removed this task and read the wireless data packet in controlGoalkeeper task and controlGame task separately | ||
− | c) Ball animation to swing | + | c) Ball animation to achieve swing |
* We wrote an algorithm to find the path of the ball from the start point to endpoint (goalpost) to appear as if it were swinging | * We wrote an algorithm to find the path of the ball from the start point to endpoint (goalpost) to appear as if it were swinging | ||
− | d) | + | d) Handling screen refresh issue in which when we light up an LED, that would fade away in a few milliseconds |
− | * | + | * The solution to this was creating an array of size 64x64 and a dedicated task to update the LED matrix. |
− | e) | + | e) The ungraceful transition of the ball from the one half of the LED matrix to the other half |
− | * | + | * The solution to this calculated the new X value and new color in drawPixel function. Here we are calling calculateMatrixposition fucntion which will calculate and return new x value and new color value. |
+ | '''2. Designing the Gyroscope and Accelerometer driver for goalkeeper and player movements''' | ||
− | + | a) Lose connection on MPU 6050 | |
+ | * The solution to this was hard wiring the MPU 6050 sensor to a general purpose PCB so that connection issues occur. Once this was done, we were able to successfully get the tilt. | ||
+ | b) Precision for getting accurate direction | ||
+ | * Since we have calculated five directions for ball movement, finding accurate gyroscope and accelerometer values with proper mapping was critical to our application. | ||
'''3. Designing the Wireless driver''' | '''3. Designing the Wireless driver''' | ||
+ | a) System freeze when no data sent | ||
+ | * We introduced a NACK to indicate that no data sent hence whenever this condition occurs it waits for the new data to be sent. | ||
'''4. Dimensions of power pins for the PCB design''' | '''4. Dimensions of power pins for the PCB design''' | ||
− | a) Accommodate the exact dimensions of 5V Power pin on the PCB design. | + | a) Accommodate the exact dimensions of the 5V Power pin on the PCB design. |
* Since there is no datasheet available for the 64x64 RGB LED Matrix, hence it was a difficult task. We used a basic approximation to determine the pin dimensions that would fit inside the PCB design such that it works just fine. | * Since there is no datasheet available for the 64x64 RGB LED Matrix, hence it was a difficult task. We used a basic approximation to determine the pin dimensions that would fit inside the PCB design such that it works just fine. | ||
− | === | + | == Conclusion == |
+ | We were successfully able to achieve gesture-based gaming capabilities via our game- Goals of Glory. Our project has been a huge success since we not only got it working but also optimizing it for user application. In terms of learning, we are happy that we got introduced to graphics design. We were able to develop a game where 2 players i.e. a player and goalkeeper are able to play wirelessly and corresponding game visuals are displayed on LED Matrix in real time. More importantly, as we moved along the project, we faced several issues while combining various modules and integrating them for our application. This included many software issues that we encountered which we solved part by part in a systematic sense. Thus this project helped us to work on different modules of an embedded system such as a display, wireless, gyroscope, an accelerometer and combine it into a ready-to-use hardware package. The project also improved our FreeRTOS skills which we learned in CMPE 244 class. Thus we were able to design an attractive and ready to use game console package encompassing gesture-based gaming | ||
+ | |||
+ | === Project Video === | ||
+ | * [https://www.youtube.com/watch?v=zId_HAEDWms Goals of Glory Demo Video] | ||
− | + | === Project Source Code === | |
+ | * [https://github.com/HarmeenJ/Goals_of_Glory Source Code Link] | ||
− | + | === Acknowledgement === | |
+ | First of all, we would like to thank professor Preetpal Kang for giving us an opportunity to push ourselves than we could have imagined. We would also like to thank the ISA team for their help with various issues that we faced related to our project and lab assignments. The MPU 6050 which we used in our project is actually a recommendation from one of the ISA members. Our project success also attributes to all 5 team members who worked tirelessly to complete this project in time. The amount of work put was well worth the effort since once the project was completed we realized that it was totally worth it spending many sleepless nights on it. | ||
− | + | === References Used === | |
+ | [1] [https://www.freertos.org/ FreeRTOS] | ||
− | + | [2] https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050 | |
− | + | [3] [https://www.sparkfun.com/sparkx/blog/2650 Everything You Didn't Want to Know About RGB Matrix Panels] | |
− | |||
− | + | [4] http://socialledge.com/sjsu/index.php/S18:_Death_Race | |
− | |||
− | + | [5] [https://github.com/adafruit/Adafruit-GFX-Library Adafruit Github Library] | |
− | |||
− | + | [6] https://www.invensense.com/products/motion-tracking/6-axis/mpu-6050/ | |
− | |||
− | |||
− | + | [7] [https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf Nordic Datasheet] | |
− | |||
− | + | [8] https://www.sparkfun.com/products/14824 | |
− |
Latest revision as of 11:18, 8 March 2019
Contents
Project Title
Goals of Glory
Abstract
Gesture-based gaming is getting tremendous adoption due to immersive gameplay and increased player engagement. Goals of Glory is a classic penalty shootout game where 2 players can play wirelessly, and the corresponding game visuals are displayed on the LED Matrix in real time. The logic for player movement is based on the output from a Gyroscope and an Accelerometer embedded on MPU 6050 whereas accelerometer on the SJone helps drive goalkeeper movements. Thus the motion of player leg movements to kick and hand movements of the goalkeeper to stop the ball is mapped and the corresponding game animations are displayed on 64x64 LED Matrix. The LED matrix is interfaced to the SJone board in such a way that the main SJone board controlling the LED Matrix receives commands wirelessly from hand and leg movements of each player via the Nordic wireless mesh network. Three display screens are developed for the game UI- Start screen, Game screen, and Result screen. Thus, by playing Goals of Glory, players can experience gesture-based gaming capabilities.
Objectives & Introduction
Introduction
Our project is divided into 4 modules
1) LED Module: The 64x64 LED matrix is driven by a Master SJone board which is responsible to map game visuals.
2) Wireless Module: Responsible for communication medium between the goalkeeper, player, and the main SJone board
3) Player Module: This module is responsible for getting the player movement that will be mapped to drive game visuals
4) Goalkeeper Module: This module is responsible for getting the goalkeeper movement that will be mapped to drive game visuals
Objectives
Our project involved a focused and rigorous approach to testing each module functionality and make necessary changes thereafter.
- Design power management PCB
- Developing game visuals for the penalty shootout game.
- Developing logic for display tasks such as curving the ball, selecting the player and ball color.
- Implement RGB LED matrix driver
- Perform RGB LED matrix pin layout with the SJone board and have a deep understanding of how a single or group of LED's are driven.
- Perform accelerometer driver
- Perform nordic wireless driver
- Have a proper synchronization between the player SJone board and goalkeeper SJone board
- Examine overall system and make necessary tweaks
- Prepare the entire system for demo purpose which includes gloves and mounting pads to mount hardware equipment
Team Members
Responsibilities
- Display(RGB LED Matrix) and Game Logic
- Player Movements
- Goalkeeper Movements
- Wireless (Nordic)
- PCB Design
Game Stats:
- 2-Player Penalty shootout Game
- 3-sec timer for each player to shoot
- Press switch on the main SJOne board to start
- Move the Goalkeeper SJone board left-right to have a corresponding movement of LED Matrix
- Control the ball movement via player SJone board to give direction i.e. left, right or straight
- Highest player to score wins and is displayed on the result screen
Schedule
Week# | Date | Task | Status |
---|---|---|---|
1 | 09/25 |
|
|
2 | 10/02 |
|
|
3 | 10/9 |
|
|
4 | 10/23 |
|
|
5 | 10/30 |
|
|
6 | 11/06 |
|
|
7 | 11/13 |
|
|
8 | 11/20 |
|
|
9 | 11/27 |
|
|
10 | 12/4 |
|
|
11 | 12/19 |
|
|
Parts List & Cost
Item# | Part Desciption | Vendor | Qty | Cost |
---|---|---|---|---|
1 | SJOne Boards | Preet | 3 | $240.00 |
2 | 64x64 RGB LED Matrix | Sparkfun | 1 | $75.00 |
3 | Power Adaptor Cable | Amazon | 1 | $9 |
4 | PCB | PCBWay [1] | 10 | $30 |
5 | MPU 6050 | Amazon | 2 | $11 |
6 | WiFi Antenna | Amazon | 3 | 24 |
8 | Power Bank | Amazon | 2 | $24 |
9 | Miscellaneous (Jumper wires, Connectors, SMD's) | CMPE Lab 294 | $5 | |
9 | Total | - | - | $418 |
Design & Implementation
In this section, we would be discussing the design considerations for our project - Goals of Glory which would be covered in the following sections. The hardware design gives a brief explanation of the hardware components used. This is followed by a hardware interface that is employed in our project in order to facilitate communication between the hardware devices. Finally, we discuss the software design aspects of the project and complete this section with the discussion of the implementation of the project.
Hardware Design
- The Hardware design for our project Goals of Glory involves usage of 3 SJone boards, a 64x64 LED matrix, MPU6050 gyroscope & accelerometer sensor, MMA8452Q accelerometer (onboard sensor) and Nordic wireless (nRF24L01+).
LED Matrix
A 64x64 RGB LED Matrix Panel is used as a display. It is divided into two 32x64 sections. Each LED can be independently addressed and controlled. The LED matrix display is constructed using a decoder to decode row address. The rows can be individually accessed using the A, B, C, D, and E address pins. At a time one row in each of the 32x64 sections is selected. Each bit in the shift register controls the corresponding column. On every falling edge of the clock pulse, the values at R1, B1, G1, R2, B2, and G2 pins are stored into the shift register and the register shifts the data by one bit. After this, the data on the shift register is passed onto the individual LED's when both OE and LE pins are set to high. The intensity of each pixel can be controlled by the rate of refresh of the individual LED.
LED matrix pins:
|
Accelerometer-SJone (for player movement)
- 3-Axis, 12-bit/8-bit Digital Accelerometer
Accelerometers are electromechanical devices that sense either static or dynamic forces of acceleration. Static forces include gravity, while dynamic forces can include vibrations and movement. The measurements are on 3-axis and these values can be calibrated to find the desired values. The MMA8452Q is a smart low-power, three-axis, capacitive micromachined accelerometer with 12 bits of resolution. This accelerometer is packed with embedded functions with flexible user programmable options, configurable to two interrupt pins. Embedded interrupt functions allow for overall power savings relieving the host processor from continuously polling data. The MMA8452Q has user selectable full scales of ±2g/±4g/±8g with high pass filtered data as well as non filtered data available real-time. The device can be configured to generate inertial wakeup interrupt signals from any combination of the configurable embedded functions allowing the MMA8452Q to monitor events and remain in a low power mode during periods of inactivity. The MMA8452Q is available in a 3 mm x 3 mm x 1 mm QFN package.
MPU 6050 (Gyroscope and Accelerometer)
MPU 6050 Six-Axis (Gyro + Accelerometer) MEMS Motiontracking device.
The MPU-6050 incorporates InvenSense’s MotionFusion™ and run-time calibration firmware that enables manufacturers to eliminate the costly and complex selection, qualification, and system level integration of discrete devices in motion-enabled products, guaranteeing that sensor fusion algorithms and calibration procedures deliver optimal performance for consumers. The MPU-6050 devices combine a 3-axis gyroscope and a 3-axis accelerometer on the same silicon die, together with an onboard Digital Motion Processor™ (DMP™), which processes complex 6-axis MotionFusion algorithms. The device can access external magnetometers or other sensors through an auxiliary master I²C bus, allowing the devices to gather a full set of sensor data without intervention from the system processor. The devices are offered in a 4 mm x 4 mm x 0.9 mm QFN package.
For precision tracking of both fast and slow motions, the parts feature a user-programmable gyro full-scale range of ±250, ±500, ±1000, and ±2000 °/sec (dps), and a user-programmable accelerometer full-scale range of ±2g, ±4g, ±8g, and ±16g. Additional features include an embedded temperature sensor and an on-chip oscillator with ±1% variation over the operating temperature range.
In Goals of Glory, the SJone board controlling the player uses the above mentioned MPU 6050 (Gyroscope and Accelerometer) to map direction and tilt. This is achieved using the yaw, pitch and roll values that we obtained by writing an extensive gyro driver. More importantly, we were able to achieve precise angle measurements such that appropriate data points are mapped for our application. For the goalkeeper, we were able to achieve the left and right orientation using SJone onboard accelerometer. Using raw values of X,Y,Z we set up left, right, up and down directions for the goalkeeper to follow.
Hardware Interface
Nordic Wireless
The SJOne board(LPC1758) is interfaced with Nordic wireless (nRF24L01+) chip using SPI.
The nRF24L01+ is a single chip 2.4GHz transceiver with an embedded baseband protocol engine, suitable for ultra low power wireless applications. The nRF24L01+ is designed for operation in the frequency band of 2.400 - 2.483GHz. The register map, which is accessible through the SPI, contains all configuration registers in the nRF24L01+ and is accessible in all operation modes of the chip. The embedded baseband protocol engine (Enhanced ShockBurst™) is based on packet communication and supports various modes from manual operation to advanced autonomous protocol operation. Internal FIFOs ensure a smooth data flow between the radio front end and the system’s MCU. Enhanced ShockBurst™ reduces system cost by handling all the high-speed link layer operations. nRF24L01+ supports an air data rate of 250 kbps, 1 Mbps and 2Mbps. The high air data rate combined with two power saving modes make the nRF24L01+ very suitable for ultra-low power designs.
In our project, we are employing three SJone boards each interfaced with a Nordic wireless chip. We use two boards for continuously transmitting direction data computed from the respective boards i.e player's and goalkeeper's movements. The third board receives the data transmitted from the other two boards. The three boards are uniquely identified based on their device ID (node address) as defined. In order for the boards to communicate smoothly without an interception, the communication has to occur on the same communication channel. This will prevent collision between two or more mesh networks.
Printed Circuit Board (PCB) Design
Introduction: The game uses a 64x64 LED Matrix which needs a 5v input supply. Since the board supplies 3.3v we level shift the voltage to 5v to avoid any unwanted flickering. So, we have decided to design a level shifter circuit. The design starts with the schematics and then designing the footprint. The design ends with creating the Gerber files and sending them to the manufacturing unit.
Schematics: The design was made in Eagle PCB design software. In preparing your schematics we encountered few challenges with the selection of equipment dimensions and dimension terminology(units). The designer should be aware of the dimensions of equipment that are to be used. After getting the idea of equipment, add the library of that equipment to eagle through manage library option. Now, the designer can get that item schematic and add it to the design schematics. Complete the schematics based on the circuit that the designer wants to implement. The above figure shows the schematics for a level shifter circuit.
Foot Print and Gerber Files:
After the schematics are done, you can see a BRD/SCH button i.e. schematic to board button. Using that button, the footprint page will be opened. Here you will be able to use some skills in designing a compact circuit. Selecting the trace width (in mils) accordingly based on your current ratings. We used a 2 layered 16 mils trace width for safer side to accommodate 4A flow of current. Place all your equipment in the square (board area) and can have positioned them upon the designers' will. Click on auto netlist button to run the simulations for possible tracing options
The designer can select one or draw the traces manually( manual is mostly preferred for better results). The footprint of out circuit is shown in Figure.2. Now, continue with DRC(design real check ) to check the possible errors while manufacturing. Make sure that there are no errors. After all the errors are cleared create the Gerber files for manufacturing company to provide those files to the manufacturing machines.
Few tips for schematics:
• Make sure the dimensions of auxiliary equipment size match the equipment. For example, the supply port size is 4mm pitch 4 pins if I use 2mm pitch 4pins the circuit cannot be practically implemented.
• Have a clear idea of the equipment and their availability in the market before getting started. Sometimes your design may be correct, but you will not be getting appropriate equipment for installing on circuit board. • Use Vcc and Gnd pins for reducing circuiting complexity.
Software Design and Implementation
LED Matrix Display Driver:
We have created four independent tasks to control different parts of the game at the same time. Those are as follows:
- Update Display Task
This task is dedicated to refreshing the LED matrix at on a periodic basis. We have configured it to refresh the display after every 2 milliseconds.
- Control Goalkeeper Task
The Control Goalkeeper Task keeps track of the data coming wirelessly from the accelerometer sensor device mounted on the defending player’s hand and updates the goalkeeper position accordingly.
- Control Game Task
The control game task is the task which controls the flow of the game this includes waiting for the gyro-sensor values before animating the ball, updating player1 and player2 scores, determining the end of the game and taking appropriate action for it.
- Select Player Task
The select player task is the task displays the start screen animation and the color select logic.
To solve the ungraceful transition of the ball from the first half of the matrix to the other( Refer point 1e in the Challenges faced and Solutions section for more details). We designed a draw pixel function which allows the users to pass the x, y and color coordinates without worrying about the two 32x64 sections and their different x coordinates this function takes the required 64x64 matrix coordinates, calculate the actual x (or ROW) coordinate value and the color value according to the 32x64 sections and draws the pixel at the desired location making addressing the exact required pixel easier. Following are the snippets of code that achieve this.
Goalkeeper driver
The raw values from SJone's accelerometer are mapped to obtain left and right orientation values. The pseudo code given below illustrates this where the task GoalkeeperLocation has the calculation for left as well as the right direction.
void GoalkeeperLocation(void *p)
{
float orientationAngle = 0;
int wireless_ret = -99;
int16_t x,y,z;
const char *data = "";
while(1)
{
x = AS.getX(); // Get X-axis values
y = AS.getY(); // Get Y-axis values
z = AS.getZ(); // Get Z-axis values
//u0_dbg_printf("X: %d, Y: %d, Z: %d\n", x, y, z);
orientationAngle = sin(z/x);
// Left orientation
if ((orientationAngle > 0.025) && (x > 50))
{
u0_dbg_printf("LEFT.\n");
//wireless_ret=wireless_send(221,mesh_pkt_nack,"left",4,0);
data = "left";
}
// Right orientation
else if ((orientationAngle < (-0.025)) && (x < 0))
{
u0_dbg_printf("RIGHT.\n");
//wireless_ret=wireless_send(221,mesh_pkt_nack,"right",5,0);
data = "right";
}
Player driver
This module includes getting yaw, pitch, and roll which are obtained from 6 axes MPU 6050 i.e. 3 axes (X, Y, Z) gyroscope and 3 axes(X, Y, Z) accelerometer.
void Gyro_Task(void *pvParameter)
{
const char* data = "";
mesh_packet_t MasterRcvPkt;
float arx, ary, arz;
while(1)
{
accelX = MPU_SEN.ACCEL_XOUT();
accelY = MPU_SEN.ACCEL_YOUT();
accelZ = MPU_SEN.ACCEL_ZOUT();
gyroX = MPU_SEN.GYRO_XOUT();
gyroY = MPU_SEN.GYRO_YOUT();
gyroZ = MPU_SEN.GYRO_ZOUT();
accelX = accelX / 16384.0;
accelY = accelY / 16384.0;
accelZ = accelZ / 16384.0;
arx = (180/3.141592) * atan(accelX / sqrt(pow(accelY,2) + pow(accelZ,2)));
ary = (180/3.141592) * atan(accelY / sqrt(pow(accelX,2) + pow(accelZ,2)));
arz = (180/3.141592) * atan(sqrt(pow(accelY,2) + pow(accelX,2)) / accelZ);
- Getting yaw, pitch and roll:
gyroX = gyroX / 131.0;
gyroY = gyroY / 131.0;
gyroZ = gyroZ / 131.0;
rollangle=atan2(accelY,accelZ)*180/PI; // FORMULA FOUND ON INTERNET
pitchangle=atan2(accelX,sqrt(accelY*accelY+accelZ*accelZ))*180/PI; //FORMULA FOUND ON INTERNET
//Using Complementary Filter
roll=A*(roll+gyroX*dt)+(1-A)*rollangle;
pitch=A*(pitch+gyroY*dt)+(1-A)*pitchangle;
yaw=gyroZ;
Testing
- We followed rigorous testing standards to ensure that no bugs or issues are left unchecked especially when inter-dependent FreeRTOS tasks are running in real time.
- Initially in our ball animation testing phase we were getting irregular ball movements along with false colors, which we later fixed using proper techniques.
- Similarly in our start screen, we initially had issues relating to color selection schemes that we have in our design. These were fixed by making sure that proper coding standards were followed along with extensive testing with respect to the color selection
Testing & Technical Challenges
Issues, Challenges and solutions to get past them
1. RGB LED Matrix Display driver
a) Writing the driver function on our own was a challenge. We were able to easily glow a single row in the matrix. However, the challenge lied in glowing a single pixel value at a specified location. And lack of datasheet made it even more difficult. Once we got the control over glowing a single LED (check updateDisplay function as shown above), we were able to implement various functions to draw lines, digits, text, ball, and goalkeeper.
b) Matrix flickering problem in which pixels on the screen weren't consistently bright when a particular animation was going on
- To solve this, we stopped clearing the whole display multiple times and cleared the specific pixels which mattered. Also, we were using a separate task, in which we were sending the data through the queue to control game task which was causing the task to wait on the queue till the data arrived which was causing flickering.So we removed this task and read the wireless data packet in controlGoalkeeper task and controlGame task separately
c) Ball animation to achieve swing
- We wrote an algorithm to find the path of the ball from the start point to endpoint (goalpost) to appear as if it were swinging
d) Handling screen refresh issue in which when we light up an LED, that would fade away in a few milliseconds
- The solution to this was creating an array of size 64x64 and a dedicated task to update the LED matrix.
e) The ungraceful transition of the ball from the one half of the LED matrix to the other half
- The solution to this calculated the new X value and new color in drawPixel function. Here we are calling calculateMatrixposition fucntion which will calculate and return new x value and new color value.
2. Designing the Gyroscope and Accelerometer driver for goalkeeper and player movements
a) Lose connection on MPU 6050
- The solution to this was hard wiring the MPU 6050 sensor to a general purpose PCB so that connection issues occur. Once this was done, we were able to successfully get the tilt.
b) Precision for getting accurate direction
- Since we have calculated five directions for ball movement, finding accurate gyroscope and accelerometer values with proper mapping was critical to our application.
3. Designing the Wireless driver a) System freeze when no data sent
- We introduced a NACK to indicate that no data sent hence whenever this condition occurs it waits for the new data to be sent.
4. Dimensions of power pins for the PCB design
a) Accommodate the exact dimensions of the 5V Power pin on the PCB design.
- Since there is no datasheet available for the 64x64 RGB LED Matrix, hence it was a difficult task. We used a basic approximation to determine the pin dimensions that would fit inside the PCB design such that it works just fine.
Conclusion
We were successfully able to achieve gesture-based gaming capabilities via our game- Goals of Glory. Our project has been a huge success since we not only got it working but also optimizing it for user application. In terms of learning, we are happy that we got introduced to graphics design. We were able to develop a game where 2 players i.e. a player and goalkeeper are able to play wirelessly and corresponding game visuals are displayed on LED Matrix in real time. More importantly, as we moved along the project, we faced several issues while combining various modules and integrating them for our application. This included many software issues that we encountered which we solved part by part in a systematic sense. Thus this project helped us to work on different modules of an embedded system such as a display, wireless, gyroscope, an accelerometer and combine it into a ready-to-use hardware package. The project also improved our FreeRTOS skills which we learned in CMPE 244 class. Thus we were able to design an attractive and ready to use game console package encompassing gesture-based gaming
Project Video
Project Source Code
Acknowledgement
First of all, we would like to thank professor Preetpal Kang for giving us an opportunity to push ourselves than we could have imagined. We would also like to thank the ISA team for their help with various issues that we faced related to our project and lab assignments. The MPU 6050 which we used in our project is actually a recommendation from one of the ISA members. Our project success also attributes to all 5 team members who worked tirelessly to complete this project in time. The amount of work put was well worth the effort since once the project was completed we realized that it was totally worth it spending many sleepless nights on it.
References Used
[1] FreeRTOS
[2] https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050
[3] Everything You Didn't Want to Know About RGB Matrix Panels
[4] http://socialledge.com/sjsu/index.php/S18:_Death_Race
[6] https://www.invensense.com/products/motion-tracking/6-axis/mpu-6050/
[7] Nordic Datasheet