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.)
Caleb’s Status Report for 4/25
I have completed most of the hardware debugging and finishing the digital audio conversion on the hardware. Furthermore, the debouncing achieves a 94% accuracy on no erroneous double hit registers. So I am just planning to meet with the software side for one final run before integrating the system fully and recording the video. There are some difficulties in powering on each pad so I will try to augment the current design to make space for it later which was a shortcoming on my end as the designer. Otherwise we are looking pretty good in terms of integration and hardware capabilities.
I am mostly on schedule and am going to focus on adding the hardware details to the poster and the final design report. For future steps we could have been faster on the overall system wide integration to be able to pinpoint small bugs earlier; however, I feel like our unit testing on each of our own ends helped to make the transition as seamless as possible.
Rishabh’s Status Report for 4/25
This week I was able to fully get the networking aspect of the game working with the hosting and joining pages fully working. Additionally, this week, I completed several of the utility pages such as the intro page and a summary page at the end of the song. I also added back buttons on several of the pages so that a user doesn’t have to keep relaunching the program to play a new song. The addition of both of these features significantly improved the UI/UX of the game.
On the integration side, this week we confirmed that both the networking 2 player changes work with the hardware changes made by Caleb, and after some debugging, we got the integration to be successful.
With this being the final week, my goal for this week is to fully complete the software side of our product. This primarily includes cleaning up the UI of the game and also improving the learning aspect of the game such as evaluating the difficult of songs and suggesting new songs based on the score achieved on the previous song.
Abishek’s Status Report for 4/25
This week, I worked on upgrading some of the UI elements. For example, adding a more interactive tutorial page that makes the user exp more enjoyable for the public demos. I also worked on fixing a graphics rendering bug that would sometimes cause the game to need to be restarted. Overall, I would say we are on track for the public demo.
Unit tests: end to end network latency, end to end drum pad to daisy seed voltage reading latency, double hit rate
System testing: overall user testing
Team’s Status Report for 4/18
After our interim demo we met up again to consolidate our next step goals because we were a little ahead of schedule and moved on to integrate the multiplayer aspect of our games. We have 2 daisy seeds which allows us to split up our hardware of 6 pads into 3 pads for each player. There were some set backs in setting up the client server conection and communication while staying true to the latency of the game. Furthermore, on the hardware side I found some optimizations by reducing the size of our hit data packets which allows us to increase the transmission speed without suffering too much packet loss from 128kb to 256kb packages reducing our perceived latency.
Overall, we are on schedule and have the remaining few weeks to debug any problems that arise with our final implementation and we have the last few weeks to touch up on our presentation and continue to test for any hidden bugs.
Some next steps would be more on the software implementation side to be able to make the interactive gameplay more beginner friendly by adding checkpoints and a normalized scorebar to create more incentive to keep combos of hits going.
Abishek’s Status Report for 4/18
This week, I mostly worked on preparing for the final presentation. Part of this included flushing out the unit tests which I reported on in class.
The biggest new tool to get used was definitely the Bevy game engine. I had to spend a lot of time on the Bevy official docs page to get up to speed and be able to make changes to the code. My main learning strategy was to “learn by doing”. I would jump into the code and consult the docs as I went when I was confused.
Caleb’s Status Report for 4/18
I just went over all the code within the hardware to make sure they had the most updated versions and did not register erroneous double hits. In the test/validation I described in the team status report I achieved a 97.3% no double hit rate on all pads by increasing the debouncing window between hits and slightly increasing the threshold of the hit activations.
Center hits are classified by having all piezo sensors reading within 1% margin of error from each other. Rimshot hits are classified as having 1 or 2 sensors being greater than 1 V and 1.5 V. An edge hit is classified as at most one sensor being greater than or equal to 1.5V
For center hit: set at 100 bpm we achieved 100% no double hit rate, set at 140 bpm we achieved 92% no double hit rate but 4% missed hits, set at 85 bpm we achieved 100% no double hit rate.
For rimshots: set at 100 bpm we achieved 92% no double hit rate, set at 140 bpm we achieved 88% double hit rate, set at 85 bpm we achieved 100% no double hit rate.
For edge shots: set at 100 bpm we achieved 88% no double hit rate, set at 140 bpm we achieved 83% no double hit rate, set at 85 bpm we achieved 96% no double hit rate.
We hit the target rates (<8% double hit rate) for center hits and rimshots but could not hit it on the edge shots which makes sense because I was not able to procure rubber stoppers in time for the final presentation so when you hit the edge of the drum casing, the vibrations are still preserved rather than being dampened and cause the piezos to pick up twice.
I finished up adding additional functionality to the central hub where it intakes keyboard inputs to set the mode to freeplay (audio generated by daisy seed on its own but needs a 5V 150 mA power supply), interactive game mode (interim demo but having the pads interface via bluetooth to the computer as inputs to a guitar hero-esque game), or multiplayer (a networked multiplayer game where 3 pads are split among the 2 players, each with their own central hub and laptop seeing the same game).
Overall, I would say I got a lot more comfortable looking at documentation especially on github repos and forums for open source resources. It also really consolidated my embedded understanding of nRF32L01+ protocols while trying to find a bandwidth of 2.4GHz WiFi that wasn’t too convoluted or noisy. Lastly, it also really helped with the overall design process; I feel like I practiced the idea of iterative designs well especially for the development of the pads which helped me to really streamline the process and get it done early so that I could focus on other features of the central hub. Also this helped consolidate my interpersonal skills when trying to meet deliverable deadlines as a team and gave me experience in being able to divvy up the work and trust my partners.
In terms of the schedule I am on schedule and have enough slack time to be able to debug anything that arises in final presentation day in time for the actual final presentation for capstone. For next steps, I will try to stress test the hardware to uncover any bugs that I may not be expecting.
Rishabh’s Status Report for 4/18
This week I was able to get a good start on the networking/multiplayer part of the software side of our product, but there are still some bugs/architectural issues that I’m running into which are preventing me from fully completing the 2 player functionality. Here’s what the current interface looks like (in the image, you can see that the connection between the host and the client has been made and now the host has the option to select some song [which is where some of the issues are arising]):
I’ve also made some minor UI improvements such as making it clearer when there is a well timed hit or not.
My goal for next week is to get the multiplayer functionality fully working so that we can start the integration testing with the full set of pads and the 2 players functionality. Also, during this week, I would like to get some people to start testing out our product so that we can see if there are any ways that we can quality of life improvements that we can make.
Abishek’s Status Report for 4/11
This week I’ve been working on making significant improvements to the game engine to make the experience a lot better for the users. This will help us during the final demo to keep the audience engaged. The changes involved adding a tutorial to explain the basic mechanics of the game, adding predetermined levels 1 and 2 for easy and medium difficulty, and adding a delete button to delete user added songs.
I also want to explore allowing a user to upload mp3 files as well as .wav files since mp3 is more common (right now we only support .wav)
Screenshots of the main UI changes:
Tutorial:
The main next steps are to get multiplayer working via networking. I would also like to do more user testing to figure out what more improvements can be made to the UI and game experience to make the demo more interesting.