For the past two weeks, we did not do much work together other than ordering materials for the mat; we were all mostly working on our individual parts. We did, however, face a couple issues and made one change to our project.
The first issue was that Tushhar’s testing of the force-sensitive resistors showed that our initial idea of simply folding it into a Z shape hurt it’s sensitivity at any region after the first fold. Interestingly enough, further testing showed that folding each corner twice (so that the same side of the FSR faces up on all three sections) does not hurt the sensitivity of the areas after the first corner. Unfortunately, these double folds could be quite tolling on our FSRs and hurt our durability requirement. Should this prove to be the case eventually, we have changed our mat design to incorporate small, solid plates on top of each FSR so that we can lay the FSRs flat instead of folded and have the solid plate transfer force to the FSR when pressed anywhere. Furthermore, we have already tested the viability of such plates during testing. They provided reliable results as well.
The second issue was that when we were testing using an Arduino to double as a keyboard to simplify our input processing, we learned that the Arduino Uno we had for testing does not support the keyboard library. The good news is that the Arduino Leonardo that we first ordered should support the library, but the one we have at the moment is headerless, and thus not ideal for quick testing. Since we have a reasonable amount of budget left, we placed an order for a second Arduino Leonardo, but with headers this time.
As for the change, while Caio was implementing the song track parsing part of the game screen, we realized using a zipped archive to store a song’s data (MP3 file, icon file, and arrow sequence) was cumbersome. In order to work with these files in Python, we would have to extract them to a temporary location, and then delete the extracted versions after we were done operating on it. We compared the normal folder memory size to the zipped archive, and found a difference of only 30 kB. Each zip archive is around 4.28 Mb, which means that we need 4300 kB / 30 kB ~= 143 compressed songs to have enough saved space for an extra compressed song. Implementing that many songs is out of scope for our project, so we decided to drop the zipped archives for the sake of simplifying the file parsing process.
As noted in Caio’s report, we also forgot to decide who would implement the High Score screen, so we will discuss this on Monday. What we’ll likely do is assign Caio to work on the High Score screen since during the week of Mar 28th he does not have an individual task.
For this upcoming week, we hope to start making our (first) mat! We are all very excited, and by the next status report, we’ll have some pictures to brag about out hardware.