Posted on

Tushhar’s Status Report for 02/26

This week, I worked on two tasks in particular. The first task was to divide up what needed to be done for the report and make some progress on it. We divided up the necessary sections amongst us, and I am taking the parts with Architecture and System Implementation. I have already started working on some of its content in order for it to be ready by Wednesday’s deadline.

The second task that I accomplished was testing the long force sensitive resistor. First, I will present my data and circuit. Then, I will talk more about how this information will be used to further our project.

While trying to test the sensor at my home, I realized that I didn’t have a way to measure weights of objects. Therefore, ‘force applied’ and ‘sensitivity’ columns are blank for now. I will measure the objects I used later in lab.

  • FSR is finnicky at smaller amounts of force. However, we don’t need to worry about that for our application which will have comparatively larger forces.
  • Small movements change the values by <100. This is most likely due to weak connections on the breadboard. These errors can be eliminated when we solder the sensor.
  • The sensor needs to be as flat as possible for reliable results.
  • As shown in the data, smaller resistor results in lower measured values. This will be ideal for the big forces like a person’s weight.
  • It is not foldable in the circle shape. Z shape might be possible but can end up damaging the component.
  • I will discuss this more with my team, and we will probably end up using more and smaller sensors per square. This will also mean that we use the digital pins of the Arduino and set threshold using the appropriate resistors rather than on the software.

I will gather more testing data with people stepping on it in the future. This will probably be done after the switch to the other smaller sensors. For next week, I will figure out how Arduino should send data to python. So far, I am on track with my schedule.

 

Posted on

Caio’s Status Report for 02/26

For this week, I had many small goals to work towards. First, there were tasks leftover from last week: deciding an operating system for the Raspberry Pi and researching how other DDR-like games encode their song tracks. For the OS, I was looking for a barebones Linux with a GUI good enough to run Pygame. I did not find exactly what I wanted, but I believe the Raspberry Pi OS (formerly Raspbian) will be the best. It boots quickly and runs python natively. It also has tons of documentation since it is the official OS distributed by Raspberry Pi. The other option I was considering was the Raspberry Pi OS Lite, but that is meant for headless setups with no visual interface, so unfortunately it does not fit our purposes. My one concern with using Raspberry PI OS is that if our game crashes, which won’t allow the user to turn off the Pi from the game, the user will be stuck in the desktop screen without an option to turn the system off aside from pulling the plug, which isn’t great for their experience.

I also did some research into how other rhythm games encode their tracks. During this search, I found a game called Stepmania, which is essentially a free DDR that allows users to create their own custom tracks. This was super helpful, since I could download one of those custom files and just inspect it through Notepad. The key part of this file was a bar-by-bar description of the notes in the song. Inspired by this format, I came up with the idea of writing a bar-by-bar description of the arrows, i.e. which arrow should be hit at that point in the bar. Although this means it will be arduous to create choreographies for songs, music sheets are widely available, so it should be easy enough to find where arrows should be. Combined with some more parameters about the song such as BPM, we can have our game predict when an arrow should be clicked, and make it appear soon enough that it reaches the top at the right time.

Furthermore, Spandan and I had a meeting to align which parts of the code each of us is working on. At this moment, our goal is to keep the meat of the game in the game_components.py so that we can work individually on the components for the screen each one of us is building. Then, main.py checks for pygame events, calls update functions, and draws the current screen.

Finally, I also worked on the Design Review Report deliverables. I took up the “summary” sections like abstract, introduction, and the actual summary, as well as the testing section. I haven’t finished all of these yet, but I hope to be done by Wednesday, regardless of whether the deadline changes or not.

I managed to catch up with my schedule this past week. Sadly no pictures for this week though 🙁 For the upcoming week, I will start working on my game components for the game screen, and given the chance, I plan to test how it runs in the Raspberry Pi. I have a Raspberry Pi 4 at home, so I might also do some testing during Spring Break.

Posted on

Spandan’s status report for 2/19

For this week, according to the Gantt’s chart, I had to design the interface for the game. And I did exactly that. I followed the design process and designed a grayscale version of the game interface for Flex Dance:

 

After getting feedback on these designs from my teammates, I tried to go back to the basics and design a normal wireframe for the interfaces:

I am now currently trying to bring these wireframes to life by design hi-fidelity prototypes:

They are not done yet but I will be done with the design presentation slides as well as the design presentation by early morning tomorrow. So beginning this week, I will be on schedule.

Posted on

Team Status Report for 02/19

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.

Posted on

Tushhar’s Status Report for 02/19

This week, most of my time and focus was spent on two tasks. The first task was the Design Review presentation. We worked on a document together to write down everything we needed for this design review including notes from the peer reviews and the helpful meeting with the professor and TA. A lot of individual time was spent by each of us filling out this document. We designed our presentation based off this document. I particularly took the responsibility of the slides related to the use case, use case requirements and implementation plan. I will also be the one presenting this following week. Therefore, I have already started preparing notes for what I will talk about during the presentation. I will rehearse it a couple of times alone and in front of my group mates to get feedback tomorrow (Sunday).

The next task that I worked upon was researching how circuits with the force-sensitive resistors and Arduino worked. I particularly found this website which gave clear instructions about what connections to make-

https://lastminuteengineers.com/fsr-arduino-tutorial/#:~:text=Force%20Sensing%20Resistors%20are%20also,pressure%2C%20squeeze%2C%20and%20weight.

I have already put some time into thinking about how I can modify the above circuit to fit our needs with the DDR mat, including adding a variable resistor to adjust the threshold. Unfortunately, the sensor that we ordered did not arrive yet so I was unable to test them. However, it should be here next week, and I will be able to test it with the modified plan.

If there are still issues with the sensor not being available next week, I plan to research more into how the Arduino would communicate with python and relay the necessary data.

Posted on

Caio’s Status Report for 02/19

For this week, I had three tasks to work on. The first one was designing the code structure for our project, namely what files hold which classes, what each class does, how they interact together, etc. Below is an image of the diagram I drew of the code structure:

The mat.ino file will be uploaded to our Arduino and is responsible for interpreting user input (i.e. stepping on an arrow) and sending it through USB to the Raspberry Pi. The mat_event_handler.py file reads the USB port of the Raspberry Pi for information from the Arduino and sets off a pygame event according to the input, if there were any. The components.py file implements the basic classes (and their subclasses) that make the game: Screen and Button. A Screen object has its own drawing and updating methods to make it simple to draw and update the game through main.py. A Button object has a method that does something (change a screen, update the current screen, update the score, etc.) according to which input is pressed when the button is selected. The song_reader.py file implements a class to read our custom track files (a zipped archive containing an mp3 file with the song and a text file describing the arrows for that song). The constants.py file sets all the constants needed for the game, such as FPS, sounds, icons, and colors. Finally, the main.py file runs the main loop of the game, updating and drawing the screen using objects from the previous files.

My second task for this week was to help with the Design Review presentation. I worked on my four slides, which mostly had to do with testing and implementing the software. Notably, a proper block diagram of the drawing above was included in the slides.

My last task was to research the music file format used by traditional rhythm games such as Dance Dance Revolution and Guitar Hero to create our custom track file format. However, I did not manage to finish this part. The Design Review presentation took more time than I expected, so I am a little behind schedule now.

My goal for next week was to start implementing the game, but I will have to make time to research the file format as well. Since I scheduled four weeks to work on programming the base game, I believe I can definitely set aside a few hours to look up how those other games implement these files and get back on track. I’m very excited to start working on the game code!

 

Posted on

Spandan’s Status Report for 02/12

For this week, my goal was to familiarize myself with Pygame. I used the official Pygame website for basic installation and setup, and then followed the same tutorials as Caio (tutorial 1 and tutorial2). I have created multiple games in the past in Python so I went and reviewed their implementation (Binary Bots and Leap Language).

This week, we ordered new parts and I researched which Raspberry Pi4 is more compatible with Pygame. The conclusion was RPi4 and so my group ordered that to ease our creation process of the game.

Lastly, I went through the design requirement and prepared for the upcoming week. I went through different options (such as Unity and Pygame for software creation and different fabrics such as simple cloth and tarp) and came up with pros and cons of the diverse options.

 

Posted on

Tushhar’s Status Report for 02/12

For this week, I was particularly involved with the ordering of our necessary parts. As per our Gantt chart, my tasks for the next two weeks will involve testing out the force-sensitive resistors with the Arduino, and finding a way for it to communicate the information to the raspberry pi and Pygame. Both these tasks required us to have the necessary components by the upcoming week. Therefore, a good amount of time was spent choosing the right Arduino board (without headers which we could solder wires to) and the right force-sensitive resistor.

For now, we have decided to go with Arduino Leonardo without headers and 2 feet long force-sensitive resistors (FSR). For the FSRs, I plan to utilize the IDEATE resources to test out other smaller FSRs they already have available. After researching for a bit, the ones I plan to test are:

0.5 inch round FSR available in IDEATE
1.5 inch square FSR I have to look around for
2 ft long FSR we ordered

As for Pygame, I am definitely behind schedule for learning it by this week. Although I am mostly involved with the circuits in the project, I still want to contribute to programming the interface towards the later half of the semester. As such, I have reorganized my schedule next week to completely devote couple of hours to understanding how Pygame works. I will mostly be using resources on Youtube and documentation on Pygame.

I am aware that the Design Review Presentation is due by the end of next week, and I will also be the one presenting. As this will take an ample of time, it may result in the delay of testing the sensors. I plan to make up for it in the following week by allocating more hours to it.

Posted on

Team Status Report for 02/12

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.