F20: Son of a Gun - Revision history

Proj user3 at 07:56, 18 December 2020

2020-12-18T07:56:30Z

Proj user3: /* Conclusion */

2020-12-18T07:55:11Z

‎Conclusion

Proj user3: /* Conclusion */

2020-12-18T07:47:01Z

‎Conclusion

Proj user3: /* Testing & Technical Challenges */

2020-12-18T07:40:26Z

‎Testing & Technical Challenges

Proj user3: /* Conclusion */

2020-12-18T07:40:07Z

‎Conclusion

Proj user3: /* */

2020-12-18T07:30:43Z

‎

Proj user3: /* Implementation */

2020-12-18T07:29:57Z

‎Implementation

Proj user3: /* Implementation */

2020-12-18T07:24:14Z

‎Implementation

Proj user3: /* Schedule */

2020-12-18T07:22:40Z

‎Schedule

Proj user3: /* Schedule */

2020-12-18T07:22:22Z

‎Schedule

← Older revision		Revision as of 07:56, 18 December 2020
Line 1:		Line 1:


−	~~[[File:SOG_Game.jpg\|\|330px\|caption\|right\|]]~~

−	~~[[File:Ezgif.com-gif-maker.gif\|\|330px\|caption\|right\|]]~~


		+	[[File:SOG_Game.jpg\|\|330px\|caption\|right\|]]

		+	[[File:Ezgif.com-gif-maker.gif\|\|330px\|caption\|right\|]]

@@ Line 741: / Line 741: @@
 Another critical aspect of gameplay was to incorporate objects which have multiple colors, when overlap each other, results in color mixing on the LED panel. To achieve that, we used virtual LED matrix planes and manipulated those using logical operations.
-To play multiple MP3 files in synchronization with gameplay is tricky as the MP3 decoder we used doesn't allow to play multiple files simultaneously. Therefore the MP3 file selections and changing the tracks with the gameplay requires some trials and errors approach.
+To play multiple MP3 files in synchronization with gameplay is tricky as the MP3 decoder, we used, doesn't allow to play multiple files simultaneously. Therefore the MP3 file selections and changing the tracks with the gameplay requires some trial and error approach.
 === Project Video ===

@@ Line 733: / Line 733: @@
 == Conclusion ==
-Project involved using different hardware and then integrating it with the controller to create the game. Creating API for various tasks involved in game flow, helps in modularization of design. This proves especially useful, during debugging, where the problematic API can be easily isolated and this reduces the scope of code review required for each debugging.
+The project involved using different hardware and then integrating it with the controller to create the game. Creating API for various tasks involved in gameplay helps in the modularization of design. This proves especially useful, during debugging, where the problematic API can be easily isolated and this reduces the scope of code review required for each debugging.
-Always test the hardware before it is incorporated into your project. however, there might be a case wherein, the API is not available to test the hardware. This become especially tricky, wherein, it becomes difficult to pinpoint issue on either hardware issue or bad code. A fault LED matrix resulted our team in a fortnight worth of time, initially trying to debug the issue, and then waiting for the new part to be shipped to us.
+Always test the hardware before it is incorporated into your project. However, there might be a case wherein, the API is not available to test the hardware. This becomes especially tricky, wherein, to pinpoint an issue is either related to hardware or software. A fault LED matrix resulted in our team in a fortnight's worth of time, initially trying to debug the issue, and then waiting for the new part to be shipped to us.
-When using wireless data communication modules, latency and packet overhead are important consideration to consider on choosing the best wireless communication module.
+While using wireless data communication modules, our main focus was to optimize latency, and frame packet overhead which leads us to try out multiple interface protocols and finally decided to go with SPI bus (3 Mbps).
-Objects which have multiple color, when overlap each other, results in color mixing on LED panel. This needs special attention.
+Another critical aspect of gameplay was to incorporate objects which have multiple colors, when overlap each other, results in color mixing on the LED panel. To achieve that, we used virtual LED matrix planes and manipulated those using logical operations.
 === Project Video ===

← Older revision		Revision as of 07:40, 18 December 2020
Line 721:		Line 721:

	== Testing & Technical Challenges ==		== Testing & Technical Challenges ==
−	~~Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again?~~
−	~~Make a smooth transition to testing section and described what it took to test your project.~~
−
−	~~Include sub-sections that list out a problem and solution, such as:~~

	1. Zigbee Drivers: We initially used UART communication(Max possible speed 115200bps)to interface the ZigBee controller to the master controller. With the overhead of size of the frame (21-22 bytes) to send just 2 bytes of data, we observed significantly delayed response at the receiver end. So, we had to change the interface to SPI communication (with a speed of 3 mbps), which being duplex with high speed helped to remove delayed response at the receiver end.		1. Zigbee Drivers: We initially used UART communication(Max possible speed 115200bps)to interface the ZigBee controller to the master controller. With the overhead of size of the frame (21-22 bytes) to send just 2 bytes of data, we observed significantly delayed response at the receiver end. So, we had to change the interface to SPI communication (with a speed of 3 mbps), which being duplex with high speed helped to remove delayed response at the receiver end.

← Older revision		Revision as of 07:40, 18 December 2020
Line 736:		Line 736:

	== Conclusion ==		== Conclusion ==
−	Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

	Project involved using different hardware and then integrating it with the controller to create the game. Creating API for various tasks involved in game flow, helps in modularization of design. This proves especially useful, during debugging, where the problematic API can be easily isolated and this reduces the scope of code review required for each debugging.		Project involved using different hardware and then integrating it with the controller to create the game. Creating API for various tasks involved in game flow, helps in modularization of design. This proves especially useful, during debugging, where the problematic API can be easily isolated and this reduces the scope of code review required for each debugging.

@@ Line 730: / Line 730: @@
 . Sending button press response over Zigbee: We had implemented GPIO interrupt on GUN controller, which periodically reads accelerometer values and send calibrated values console, and semaphore waiting task to send button press response. The button press was causing occur interrupt to give a semaphore to the button press sender task and was disturbing the RTOS task of calibrating accelerometer values while sending to the game console. To remove this disturbance, we removed the semaphore waiting task on GPIO interrupt and instead used regular accelerometer parameter sender task to send button press signal.
-=== <Bug/issue name> ===
+=== Issues and Bugs Resolved ===
 . All the objects onscreen are tracked by using a structure file, which has co-ordinates of all the object, their status, shape, and other relevant information. When we call the draw function, the LED worked flawlessly for some time, after which the board would restart. This was because the structure would access out of bound value, which resulted in the board to restart.

@@ Line 706: / Line 706: @@
 === Implementation ===
-  The game involves the use of two controllers: one with a 2-axis joystick and the other with an onboard accelerometer. Apart from that, there is an MP3 decoder that is interfaced over UART.
+The game involves the use of two controllers: one with a 2-axis joystick and the other with an onboard accelerometer. Apart from that, there is an MP3 decoder that is interfaced over UART.
 The interfacing of 2 axis joystick is fairly easy. 2 ADCs and the job is done. For accelerometers too, getting values over I2C is a relatively easy task. The challenge to calibrate the motion of the aim cursor with the accelerometer indeed took some efforts to simulate a gun pointer. For the MP3 decoder, there are several MP3 files for various events such as a background theme song, gunshot, level-up sound effect, game-over sound effect etc. All these MP3 files were needed to be modified and the UART commands were synchronized with the corresponding events.
-. Challenge lies in using the Zigbee, with low latency. The serial was initially used, however, was later abandoned and SPI was used for lower latency.
+Challenge lies in using the Zigbee, with low latency. The serial was initially used, however, was later abandoned and SPI was used for lower latency. To use SPI for interfacing the Zigbee module with the master controller, Zigbee uses an additional pin name ''Attn'', which tells the master to start communication. This helps in speeding up the data transfer.
-. Tracking the object onscreen is challenging as the game involves shooting objects. 3 virtual planes are maintained other than the RGB planes, which maintains the greyscale image of objects. Eg: Friend objects are drawn in the friend plane, enemy in the enemy plane, and life objects in the life plane. An intersection of these planes gives the overlap if it exists. Once the intersection is available, the nearest position of the enemy/plane is extracted from the structure and requisite action is taken henceforth.
+'''Game Console:'''
-. Objects move on the screen on a pseudo-random pattern. The variability of the movement is dependent upon the gave level.
+Tracking the object onscreen is challenging as the game involves shooting objects. 3 virtual planes are maintained other than the RGB planes, which maintains the greyscale image of objects. Eg: Friend objects are drawn in the friend plane, enemy in the enemy plane, and life objects in the life plane. An intersection of these planes gives the overlap if it exists. Once the intersection is available, the nearest position of the enemy/plane is extracted from the structure and requisite action is taken henceforth.
-. Once life becomes over, the game reaches an end.
+Objects move on the screen on a pseudo-random pattern. The variability of the movement is dependent upon the gave level. Once the number of life becomes zero, the over state is called in the gameplay.
 == Testing & Technical Challenges ==

@@ Line 708: / Line 708: @@
    The game involves the use of two controllers: one with a 2-axis joystick and the other with an onboard accelerometer. Apart from that, there is an MP3 decoder that is interfaced over UART.
-'''Gameplay Controllers'''
+Gameplay Controllers
 The interfacing of 2 axis joystick is fairly easy. 2 ADCs and the job is done. For accelerometers too, getting values over I2C is a relatively easy task. The challenge to calibrate the motion of the aim cursor with the accelerometer indeed took some efforts to simulate a gun pointer. For the MP3 decoder, there are several MP3 files for various events such as a background theme song, gunshot, level-up sound effect, game-over sound effect etc. All these MP3 files were needed to be modified and the UART commands were synchronized with the corresponding events.

@@ Line 239: / Line 239: @@
 *<font color = "green"> Completed
 *<font color = "green"> Completed
-*<font color = "blue"> Completed
+*<font color = "green"> Completed
 *<font color = "green"> Completed
 *<font color = "green"> Completed