Team’s Status Report for 4/25
Mostly this week we were focused on changing our debouncing logic on the hardware to avoid double hits and making sure the networking implementation is spotless and able to work under strenuous conditions. Finally, we also focused on making the design presentation and unit testing to make sure our system implementation meets our use case requirements.
HARDWARE UNIT TESTS:
Debouncing: In our default setting for 80 ms debouncing window and 60 mV activation threshold we found our erroneous double hit rate to reach around 27% for every 25 hits we played on the pad.
Therefore, Caleb ran a series of tests with 50 hits on each pad with 27% erroneous double hit rate as our baseline and control group to improve from.
Caleb worked with different activation thresholds from 100 mV to 200 mV because on preliminary testing on their pad we found that soft hits to register they reach around 100 mV and 60 mV is very similar boundary wise to hits from the environment. Changing this decreased the erroneous hit rate to about 23% showing it contributed to the problem but was not the root cause.
Then Caleb sweeped the debouncing time windows from 80 ms to 120 ms. Finding that overall erroneous inputs reach 6% and plateus around 110/115 ms thus he chose the 115 ms to be safe on the debouncing window.
Hit profiling: Overall we achieved a 81% accuracy on the hit profiling but we got it to the 93% in our final presentation slides by switching our radius calculation equations.
Previously we used the below equation which was limited in the scope that we assumed that the sensors were placed perfect 120° apart and using sensor 0 as a reference point. While it did most of the general calculations correctly, we needed to get higher location pinpointing to make the system feel better for the user and thus we switched our equations to be a weighted function of the cosine of their angle offsets.
We swept each of the weights for the sensors using a series of tests with a ball on a meter stick and locations marked within the center radius, middle radius, and edge radius (1.5 in, 3 in, 4.5 in) to measure the hit profiling and accuracy every 50 hits. We found for most of the pads, the weights to W0=0.92, W1 = 1.02, W2 = 0.90. (These results were arbitrary to the positioning of the sensors on the pads and their connections to the arduino but for the most part we needed to reduce the weights of 2 sensors because they were closer to each other than the other.)
Rishabh’s Status Report for 4/4
This week I completed most of the goals I had laid out from last week. Specifically, I improved much of the UI for the game by adding hit indicators and also visuals indicating how accurate any given hit was (similar to how Just Dance uses words like “Perfect!”, “Nice!”, or “Miss”).
Additionally, I started working on the summary page and completed the page for uploading songs (although there are still some graphical improvements that I would like to make to this page).
As for the networking part of the game, this is something that I’ve also spent the last week thinking through and planning. I do anticipate that it will require a relatively significant code rewrite process, so it’s something that I plan start making progress in this week.
Specifically, this coming week, I would like to finalize the single player UI with the game looking very professional and clean. Then, I would also like to make progress with the multiplayer networking part with the goal of finishing the preliminary version in the week after that.
Abishek’s Status Report for 3/21
This week I helped on both the software and hardware side of the system. On the software side, I helped with integrating the hardware interface to process inputs from the drum pads and integrate with the game logic. I also helped with getting the Omnizart model working for drum transcription.
On the hardware side, I helped debug the pad system to get more reliable readings.
We have a rough end to end game working, and now the goal is to have it be more refined. This involves scaling up the number of pads we have, making the pad casing more aesthetic, syncing the music properly in the game, and improving the game UI so that players have a more enjoyable experience.
Team’s Status Report for 3/14
This week our team made progress on both the software and hardware components of the project. On the software side, significant time was spent debugging the build infrastructure to successfully integrate Omnizart, the machine learning model we plan to use for note identification, into our existing system. After resolving several complex build issues, Omnizart was successfully compiled, and work has begun on transitioning our current note identification pipeline to use this model, though the full pipeline is not operational yet. We also improved the user experience for the learning platform by creating a home page and a page that allows users to upload songs to be parsed, which also begins to support future hardware integration. On the hardware side, the drum pad system has been successfully linked to the transmitter and is now able to send hit intensity levels to the central hub. Sensitivity calibration is currently being performed, and the voltage threshold will likely be increased from 50 mV to around 80 mV to prevent noise from being interpreted as hits. Work has also begun on implementing the Multiceiver functionality of the Nordic nRF24L01+ to allow the receiver to handle messages from multiple pads simultaneously, as well as initial development of the DSP pipeline so audio feedback can be heard by the user. While some hardware work is slightly behind schedule, additional lab time this week should allow us to complete calibration, measure end-to-end latency, and begin integrating the hardware and software systems together.
Abishek’s Status Report for 2/14
This week, my primary focus shifted toward refining the overall system and game design, as well as contributing to the design presentation to better articulate how users will interact with the platform. Rather than implementing features directly, I spent time thinking through the structure of the learning experience and how gameplay mechanics can meaningfully support skill development for beginner and intermediate drummers.
Specifically, I designed a level-based learning system in which users progress through increasingly difficult stages (easy, medium, and hard). Each level consists of a song that the user plays along with, while the system tracks performance by comparing expected drum hits against the detected input from the pads. A “miss” can be defined as either failing to hit a required note within a fixed timing window or hitting an incorrect pad. At the end of each song, the user is presented with a performance summary showing the number of correct hits versus missed notes, along with an overall accuracy percentage. If the user achieves greater than 95% accuracy, they are allowed to advance to the next difficulty level. This structure provides clear, measurable feedback while still keeping the experience game-like and motivating.
In addition to the core progression system, I also thought through extensibility of the platform. One important design goal is to allow users to upload their own .wav files so they can practice with songs they enjoy, rather than being limited to a predefined library. This introduces additional challenges around difficulty classification and timing extraction, which will need to be addressed in future weeks, but it aligns well with the project’s emphasis on flexibility and personalization.
Because my efforts this week were primarily focused on design and planning rather than implementation, I am slightly behind in terms of direct software development. However, I believe this time was well spent, as it clarified the requirements for the game logic and will make future implementation more structured and efficient.
My next steps will be to help decide and curate which songs belong in the easy, medium, and hard categories, and to begin translating this game design into a minimal interactive prototype. This will involve defining the exact criteria for hits and misses, implementing basic game state transitions, and preparing the interface to accept timing and sound information from the drum detection pipeline once integration begins.