Posted on

Stephen’s Status Report for 4/30

The last task I need to finish before the public demo is the completion of the central module for our project, which will isolate the ESP32 and supporting circuitry from the user while they play the game. I spent several hours trimming down some wire headers and soldering them to a general-purpose through-hole breadboard which will help reduce the over size of the circuitry and also fix the connections in place so they cannot be jostled loose. Currently, I’m about 70% of the way done with this soldering, and this video shows the current functionality of that board:

Other than this, all I need to do is 3D print a small housing for the board once I’ve finished soldering it. This box shouldn’t be very expensive compared to the drums, as it doesn’t need to withstand any significant forces, which permits the use of thin walls. I’m expecting this module to cost around ~$15 when printed.

Regarding where I am in regards to completing these tasks, I’m confident I’ll be able to wrap everything up every next week. Most of my classes finished up this recent week with their last exam or a final project, so I have little else to work on other than these tasks, as well as the final report due at the end of next week.

Posted on

George’s Update for 4/23

This week I worked on the following things:

  1. Conducting playtesting sessions
  2. Fixing a new drum input bug that was discovered during playtesting
  3. Adding visual feedback to user input
  4. Changing colors of game lanes
  5. Preparing for the final presentation

This week we conducted 2 playtesting sessions on Wednesday. We had 8 people play our game and provide feedback to us on our feedback form. A lot of their feedback was related to the visuals of the game, and I had to make some tweaks based on their feedback. Here is what the game looks like now:

Next week we will be adding the finishing touches to the game and giving our final presentation to class on Zoom. I will be cleaning up the gameplay a little bit more, tweaking the main menu, and refining some of the colors.

Posted on

Shreya’s Update for 4/23

This week, I was focused primarily on testing for the presentation and report for next week. I am running a script right now for the timing portions of my model about determining the average time it takes to run for certain lengths of times (one of my user requirements).

The second user requirement is harder to talk about. I have a few metrics that I I am considering which is comparison to a commonly known beat tracker without regarding false positives or negatives. This is because I included the melody tracking and the commonly used package does not. I was also considering submitting graphs of the areas in an audio file where the algorithm would place a beat to see if we can draw some comparisons for that. I have the wav files created, so having the intensity analysis graphs created should be pretty fast.

Lastly, I think we can incorporate the user feedback and the results we received from play testing.

I do actually have a bug currently in my code which suggests its outputting the wrong time stamps. I am working on trying to fix it, but I am unsure if I can get to it this week. I may have to look more into it next week and focus on the testing analysis for this weekend.

Posted on

Team Status Report for 4/23

This week was primarily spent performing our testing and making any last minute improvements that would be needed going into the final presentation. Each of our group members spent time improving/testing their individual portions of the project, but we also had a user feedback session Wednesday night with CMU’s Game Creation Society so that we could get user input into the state of our game.

During this session, users play-tested the game in a fashion similar to how the final product would be used and gave their opinions on what they felt could be improved on. Some examples of feedback included user’s feeling specific drums were less responsive and that the scroll speed/note density of the game was too much for the average (or even experienced) rhythm gamer.

Receiving user feedback in this fashion was also needed for some of our specific use case requirement tests, such as the set-up time of the game, so we gathered that information as well so that it could be presented during the final presentation next week.

Following the final presentation next week, the majority of the changes we still need to make to our game are just improvements or to already implemented features (such as the game’s graphics and drum-game communication), many of which are aesthetic in nature. As such, we should be on pace to finish this project by the upcoming final demo.

Posted on

Stephen’s Status Report for 4/23

The majority of this week was spent on finishing the 4 drum modules and starting my testing in preparation for the final presentation on Monday. The following video shows the current state of the drum setup:

The main takeaways from this demo are that all 4 drums have had their PCBs soldered, and are situated within the drum modules. Furthermore, the wooden bases and rubber pads on top of the modules have been placed as well (although I have opted to only secure the bases in place with tape for now in case I need to disassemble and repair anything inside).

One thing I’d like to highlight is that the rubber pads do not depress heavily when pressure is applied, which is important for maintaining a good “bounce” when the drums are hit by the user.

Additionally, the other primary task for this last week was performing the testing needing for out final presentation this upcoming week. Between the user feedback session we held on Wednesday and specification testing I’ve performed on my own, I have almost all the data I need for the report. To recap, the 4 categories of testing related to the drums are user set-up time, compactness, latency, and recognition accuracy.

The user-setup time and compactness tests had good results, however I did have some issues regarding drum recognition and latency. Regarding recognition, some of the drums were noticeably less responsive than others (which was feedback I received during our user testing session) and to remedy this I placed small paper squares in the main force bearing column of the drum.

These paper squares bring the sensor and rubber pad ever so closer together, which increased the sensitivity greatly.

Regarding the latency, the main issue I encountered was not with the latency itself, but with measuring the output, as the serial monitor I used to check for messages from the drum only outputs results every 60 ms or so, which means I can’t reliable use it to check for latency around the 30 ms mark. I’m going to try a similar test using an oscilloscope tomorrow in the hopes that this will provide better results, however if that doesn’t pan out we may need to use a full latency test from drum to program instead of measuring the drum and program latencies in isolation.

Regarding where I am in the project, I feel confident in my ability to finish the product before the final demo, as most of the remaining tasks I have are mainly aesthetic improvements, such as gluing the drum bases on firmly and printing a module for the ESP32 to be placed in to isolate it from the user. Everything regarding the functionality of these drums is working, although I may be able to make some marginal improvements, and both of those tasks I mentioned earlier will be tackled next week.

Posted on

Team Status Report for 4/16

The semester is coming to a close! This week we worked on making additional improvements to the drums module, GUI, and beat tracking algorithm. We can now connect multiple drum modules to the computer at once rather than just 1 drum only. The beat tracking algorithm now more closely synchronizes with the music.

We will be conducting playtesting sessions next week.  During these sessions, we will take measurements to validate our design requirements. Here is a breakdown of the items that we will measure:

  • The time it takes for the user to take the drums out of the bag, connect to computer, open game
  • Record average frames per second (FPS) while users play game
  • Ask users to rate different aspects of the experience on a scale of 1 to 10
    • GUI
    • Ease of use
    • Fun

We are currently on track to meet the end of semester deadline. We will be using most of our time next week to make aethestic improvements to the game, conduct testing sessions, and to prepare for the final presentation.

Posted on

Shreya’s Update 4/16

Unfortunately, this week, I was pretty sick so I was absent from class.

However, I was able to make significant progress with the accuracy of the beat map creator. I ended up changing the energy calculation by making the window smaller than what it was before. I was calculating instantaneous energy in bins of 43 (recommended by the source I was using), but I ended up making the bin of length one instead. This also ended up being significantly faster. Currently, I am analyzing two frequency bands and splitting that into four buttons. I am analyzing the frequency bands separately and for a three and a half minute audio file, it takes about 112 seconds per frequency band to analyze. While that is slightly above my user requirement, tomorrow I plan to condense the algorithm into one loop so hopefully, it should take about 200 seconds total for a single audio file.

Also, as I mentioned last week, (George’s idea), I added a sound to indicate when my tracker found a beat. I have attached a few sound samples before. I have been creating a few additional beat maps as well for the testing phase of our game that we will be going through in a few weeks.

For the progress for the next week, I need to create a lot more files for testing as well as for verifying that my user requirements are met (or where they fall short). Furthermore, I need to create a main function to call everything instead of having to do it myself. This should only take a few hours because the code is pretty modular. Hopefully, I can have all of this done by Wednesday.

For scheduling, I should be on track. Everything is pretty much done, but I am working on some final touches.

NOTE: I’m having trouble uploading the files to the website because it says the maximum size of the files has been exceeded. I can show them later.

Posted on

Stephen’s Status Report for 4/16

The majority of this week was spent creating the 4 final drum modules, which included soldering each of the PCBs and 3D printing the drum housings. As of right now, all of the PCBs are soldered and (mostly) functional and I’ve printed 3 of the 4 total drums (the dremel printers in TechSpark were occupied most of this week so I’m printing the last one this weekend).

https://drive.google.com/file/d/1T9HWiaXTrl7rABxwUqzvM6yQnoAtga9A/view?usp=sharing

https://drive.google.com/file/d/1MaeZnkecdY8ms-ItmZ9qRBaB1ymTffSX/view?usp=sharing

Currently, 2 of the 4 PCBs I’ve soldered are operating perfectly, with all 4 LEDs receiving feedback from the ESP32.

https://drive.google.com/file/d/1JVWyY8zhrED-C6ImZAhHwnd7PPoJRTvZ/view?usp=sharing

https://drive.google.com/file/d/1JCIqvQrxr8q2foaXEXLrCToc0U5jX7bv/view?usp=sharing

 

However, the two other PCBs have minor soldering issues with some of their LEDs, so I haven’t trimmed their leads and placed them into drums yet, as I want to resolder their connections properly.

https://drive.google.com/file/d/1CVYEODAB1FGnWKjktggWexWcM0r705bB/view?usp=sharing

https://drive.google.com/file/d/1Js0cr5h1dcjLEnHlIN9yyXimBuaWOt4X/view?usp=sharing

The issue which caused this is regarding the small solder beads depicted below, as all 4 LEDs on the PCBs worked immediately after soldering, but upon bringing them back to my dorm I realized that the LED leads were jostled in my backpack, which caused the hardened solder to break itself off from the PCB, ultimately disconnecting it from the circuit. To fix this, all I need to do is reheat the solder and form a better (more shock resistant) connection.

https://drive.google.com/file/d/1UG_pr4wPE5gjd6lG7UZG1uREZa2nyTdW/view?usp=sharing

Lastly, I also acquired some wooden bases and supports for the drum modules this week. These bases will be fixed to the bottom of the PCB and to the drum’s base, which will provide support and isolate users from the drum internals. Additionally, I opted to use wood for this purpose as it was cheaper than 3D printing these parts and by using wood the bases will have more friction with whatever surface they are placed on, which should help prevent them from sliding around as much.

https://drive.google.com/file/d/1WeOysxl3Cy4t8Gs_CMU4My-Iigs1XabT/view?usp=sharing

https://drive.google.com/file/d/16U3gzAclyG5kQM6xwUeATo90310gCExV/view?usp=sharing

Regarding where I am in regards to our schedule, I think I’ve caught back up on pace this week/weekend, as once I’ve finished printing the last drum and resoldering those PCBs, the drums themselves will be in their finished state (barring some aesthetic improvements possibly) which will allow me to perform some needed testing this week. I do also need make a housing for the ESP32, but that will be purely to isolate it from the user rather than having a major functional purpose, so all I really need to do there is fix the ESP32 in a small box with holes for it’s wires, which shouldn’t take much time.

Posted on

George’s Status Report for 4/16

49I did a lot of work on this capstone project last week (Week of April 3), and I had deadlines in 2 other classes this week, so this week I worked on this capstone project less than I typically do. That being said, I did make some progress this week:

  1. Fixed bug related to drums not being recognized sometimes
  2. Made preparations for playtesting next week

Earlier this week we were running into a serial message parsing issue with our gameplay code. I spent some time debugging this and I came to the conclusion that there was a mismatch between Stephen’s microcontroller serial code and my gameplay serial code. The issue was caused by an erroneous “\n” character being sent from the microcontroller. Once we removed the “\n” the issue fixed itself.

I also created a Google Form where people can sign up to playtest our game. We will be having multiple playtesting sessions next week. I will be present at all of these sessions because the game is being run on my computer.

I am on progress to meet the end of semester deadline. Our game is nearly complete; the remaining features are mainly cosmetic.

Next week I will conduct playtesting sessions, add some finishing touches to the gameplay GUI, and prepare for the final presentation.

Posted on

Stephen’s Status Report for 4/10

The majority of this week was spent preparing to print the final drum modules, as earlier this week the PCBs arrived from PCBway, and after soldering the components to verify that they perform as expected, I was ready to 3D print the final drum design. The only change I made from my recently posted drafts was to reduce the thickness of the top wall of the housing from 5 mm to 2 mm. This is mainly to allow the LEDs more room to stick through the holes in this layer, as I hadn’t originally accounted for how the stubs of the other through-holes components may prevent them from getting as close to the roof of the housing as the PCB would naturally allow.

The print had reduced scaffolding and height compared to the demo design, which brought the cost down from $56.50 previously to just $36.00 for this final version.

However, after clearing the scaffolding, I encountered an issue with the design’s size, as although both the drum’s internal cavity and the PCB measured 11 cm, the PCB was slightly too large to fit within the drum.

Since this size difference was less than a millimeter, I’ve been trying to sand down the interior of the drum enough to allow the PCB to fit. However, although the difference in size has shrunk from my efforts, the PCB is still unable to fit smoothly even after several hours of sanding.

I still believe this drum module is salvageable, as I was able to shorten the difference greatly, however I’ll need to dedicate more time to sanding or use a tool within TechSpark to assist me in doing so. Going forward, I plan on reducing the side walls of the housing from 5 mm to 3 mm for the other three drums, with all of the gained space going to the inside of the module. This may give me too much room on the drum’s inside, however it will be much easier to remove the additional space rather than to create more through sanding.

Regarding where I am in regards to our schedule, I am now slightly behind where I had hoped to be after carnival, as I was hoping to have a fully functional final module ready going into this week. However, This is not a major delay, as if I am able to perform a successful 3D print tomorrow with the new design I’ll only be a day behind where I expected to be. Other than that, the rest of this week will be focused on finalizing the drums and the Arduino code which communicates with them, so that hopefully I’ll be able to assist with other tasks going into the last few weeks.