Category: Team’s Status Reports

With less than one week for our final demo, we believe that the biggest risk we face is our mat being unreliable during gameplay. We ran tests during this past week with a few students and it seemed that sometimes we failed to detect very obvious presses. Upon further inspection, it seemed that the readings from when our FSRs were not being pressed would increase after a few steps. We believe that the buttons arrive at some sort of equilibrium position after being stepped on a few times, which requires us to increase our thresholds for detection after dancing to one song or two. Our current plan to mitigate this issue is to implement a recalibration step in our Arduino code that is triggered every time a song ends, so we can refresh the thresholds. If it turns out that it is hard to detect when a song is over, we will simply add an extra input to the Arduino using a switch that once pressed will recalibrate the mat (i.e. set new thresholds for detecting steps).

Other than that, we are on time to have our setup complete by the demo according to the schedule from our final presentation.

This week, we made considerable progress in building the physical mat, as well as the game on Python.

All three of us spent a lot of time soldering the components this week. We soldered the FSRs to their corresponding length of wires based on their positions. We also labelled them for easy identification. We were able to successfully attach them to their corresponding plates as well. Later on in the week, we also soldered connections and female headers to the perfboard. This perfboard has all the necessary connections. We only need to plug the wires in for it to work. This way, we don’t have to worry about putting any other components under the mat and connecting them there. For rest of the mat, Spandan and Tushhar learnt how to use the sewing machine in Techspark. We consulted with the person who taught us sewing, and upon further discussion amongst the three of us, we were able to plan the proper dimensions, cuts and seams for the layers of the tarp. We even decided how the pockets for the plates will be implemented with velcro and sewing. This should help achieve one of our big goals, which is to have the entire mat ready by the end of this week.

In terms of the software, Caio was able to finish the crude game. The game should be playable, and the transitions between screens like game screen to pause screen or name input screen to menu screen should be working now. The high scores are also be saved and accessed properly now. Now, there are particularly 2 tasks remaining for the software. The first task is to add animations to make it feel more like a game. The second task is to modify the code to be able to handle more than 5 songs.

In terms of schedule, we were able to complete the crude game and the circuit layer for our mat. For the upcoming week, we aim to finish the mat and add some animations to the game. We will also be putting in a good amount of time towards making the final presentation.

For this week, we were each able to work on our individual tasks and then combine some subsystems to have it ready for our Interim demo.

Spandan worked on the menu screen and is almost finished with it. She also layered the Masonite plates with evafoam and worked with Tushhar to integrate a FSR to one of the plates. The Z-shape now has their corners cut off to let the FSR fold properly. The Z-shape also sandwiches the FSRs and is still responsive to footsteps. The plate is nice and firm to step on as well. This will be further demonstrated in the Interim demo.

On the other hand, Caio and Tushhar worked together to test and connect the plate to the game. The Arduino file was tested and modified to work properly with the game. One of the important issues we took care of was the button held down being read as several inputs together. This often messed up with the combo as even brief steps would register as multiple hits of the arrow button. This has been accounted for now. However, it may change if we consider adding holding down arrows as one of the game features.

According to our schedule, we will likely need at least 1 more week in the buffer period to construct the mat and make the pause screen + high score input screen. Caio and Spandan will also work on integrating their menu screen and game screen together.

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.

This week, we divided up the Design Report into sections amongst the 3 of us. We also made sure that we know and have all the content we need respectively to work on the report. We have been and will continue to work on our sections individually. Our aim is to finish it by Tuesday night. Then, we will combine and format the report on Wednesday in order to submit it before the midnight deadline.

We also are close to keeping up with the schedule, both individually and as a group. While working on the design review presentation, we made some changes to the schedule. While the majority of it still remains the same, we accounted for Spring Break and the tasks we have completed so far. Furthermore, the new Gantt Chart is much more readable and easy to understand. Of course, the tasks delve much deeper in contrast to the few words shown in the Gantt Chart.

Some important changes may come to our system in terms of what and how many FSRs we use. Based on our talk with the professor and TA as well as results reflected in Tushhar’s testing, our initial plan of using 2ft long FSR in a circle or Z-shape may fail. We do have a mitigation strategy for it where we use smaller but more numerous sensors per square. Further details will be discussed and flushed out in the week to come.

We also plan to finish our tentative Bill of Materials by next week, and so we will order parts for the construction of our mat within the next two weeks.

For this week, our main focus as a group was working on the Design Review presentation. Working on the design review also helped us clarify further details about our design. We spent some time making diagrams and prototyping the look of the game screens. We discussed the GUI and the sensors in the mat in depth. For now, we have a good idea of what the GUI will look like. The sensors for the mat is something we have to test. We do have mitigation plans for if the sensors don’t work the way we want it to. Moreover, we received some of the materials we ordered and anticipate that we will receive the rest by Monday or Wednesday. On a smaller note, we also created a public GitHub in which we can share resources and keep our code centralized. We will add a link to the GitHub to the website later.

We still believe the biggest risk our project faces at this current time is procrastination or poor time management. By now, all three of us have experienced a minor delay in our schedule in some way. Our contingency plan remains the same: holding each other accountable and asking each other for help when necessary.

During this upcoming week, since we will be testing our sensors, we imagine that other issues might rise, particularly with how we envisioned our mat coverage. We have heard that the sensor we bought doesn’t seem to be bendable in the shape of a circle as we had hoped, but we will be testing it this week. Should the sensor prove to not meet our expectations, we have plans of laying it out in a ‘Z’ or ‘N’ shape instead of a circle over each square.

In terms of design, we had one major change to our mat this week. We decided to add one extra button on the top left (or top right, we haven’t figured out which) to act as a pause button, since pausing mid-game was a hassle with only the four arrows. Adding this extra button also helps because it can double as a confirm button in menus in which pausing is not necessary. This change, however, has incurred no updates to our schedule, since it simply involves buying more sensors and investing a couple more minutes into building the mat.

At this moment, we have not identified any technical risks pertaining to this week in particular. We believe that, for these semester-long projects, one major challenge that people face in the beginning is the false belief that “the deadline is still far away, we have a lot of time”, which leads to procrastination. There are two main ways to tackle this issue, namely each one of us committing to a personal schedule to complete our tasks and all of us making sure we help each other stay on track. In case procrastination becomes an issue, we can each put more effort into holding each other accountable, and as a last resort we have our buffer time allocated in the schedule.

There were no changes made to the project this week. We used our time to order some of the necessary parts we need for testing next week.  Particularly, we are hoping to see how well the 2 feet sensor performs compared to alternatives, and how it works with the Arduino. Moreover, a good amount of time was also spent getting familiar with Pygame.

For the upcoming week, we are mostly planning to allocate our time to the Design Review presentation. We will start preparing the content for the slides on Monday and work on building the presentation throughout the rest of the week.