Posted on

Caleb’s Status Report for 3/21

This past week I was able to get the multiceiver functionality to work completely and able to register “simultaneous” hits to the drum pads. I also worked on developing the framing of the drums to make it look nice but also secure. I also finished the overall design including the foam dampeners added to the underside of the impact plate which greatly improved overall reading of the pad and isolation of signals from the pad. I also soldered extra wires onto these pads to improve signal integrity as well as the connection between pad and the breadboard.

We are on track for being able to show a somewhat viable demo by interim demo and I am on track to develop more pads for the final. Might have to tweak the 3D printing iterations to make a larger rim to secure the pad.

My next goals will be to create the housing as well as the digital sound output from the central hub processor itself. I was held up debugging the wireless multiceiver communication protocol.

This communication protocol can only support up to a max of 6 simultaneous mailboxes and then we can later tackle networking and being able to play across different location if time permits. But the immediate goal is to be able to create 6 pads and have it create a fault-proof end-to-end system by demo.

Posted on

Rishabh’s Status Report for 3/21

This week, I’ve worked a lot on the software integration to properly connect with the interface that Caleb’s hardware model presented. My software model is currently able to read the inputs from hitting the pads, then parse the information from the Daisy Seed and identify both which pad and where on the pad the hit was made. There is currently some issues that are going on with inconsistencies in the data that I receive from the Daisy Seed that we might try to fix in software.

Additionally, this week I’ve fully gotten the Omnizart ML model working and so we’re able to parse a wider range of drum sounds.

By next week, our combined goal is to get our end to end product working with a relatively high accuracy so that we can begin more thorough validation and user based testing.

Posted on

Abishek’s Status Report for 3/14

This week I worked on both the hardware and software components of the project. On the hardware side, I spent time in the lab assembling and testing the drum pad system, helping ensure the pads were correctly wired and able to send hit signals through the transmitter to the central hub. I also helped with initial calibration and testing to verify that hits were being detected reliably without excessive noise. On the software side, I continued developing the game and learning platform, including improving the user interface and working on the note identification pipeline. This included integrating new components into the software stack and beginning to connect the parsing system with the gameplay logic. Overall, I spent a significant amount of time this week working across both sides of the system to move us closer to full hardware–software integration.

Posted on

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.

Posted on

Rishabh’s Status Report for 3/14

This last week, I’ve spent my time debugging my build infrastructure to get Omnizart (the ML model that we’re planning on moving our note identification module to) build within our existing software design. After a few hours of parsing some incredibly dense error messages, I finally got Omnizart to build.

After messing around with Omnizart, I’ve started to move our current note identification to using Omnizart, but I haven’t gotten this new pipeline to fully work yet.

Another thing I’ve been working on is improving the user experience for the learning platform by creating a home page and a page for users to upload new songs to get parse. Additionally, some of these steps were taking to begin the integration with hardware.

On that note, it seems like Caleb is largely ready to begin integrating hardware and software together, so a large part of our work in the next weeks will be to start integrating these two components together and get an end-to-end design working. Also, specifically for me, I want to continue trying to get Omnizart fully working as that will improve our accuracy and note types.

Posted on

Caleb’s Status Report for 3/14

In this week I was able to link the pad system to the transmitter and then have it transmit the correct hit levels to the central hub. I am still calibrating the sensitivity and I will most likely have to increase the voltage threshold for the sending to make sure that noise is not caught. Currently it’s at 50 mV but will bring it up to 80 mV as most soft hits are around 100 mV on its first peak. I have started implementing the Multiceiver functionality of the Nordic nRF24L01+ where it can bin incoming messages to make it seem as if they come simultaneously and allow the receiver to hear on multiple channels. Also have started working on the DSP to make sure the audio is produced and heard on the user end.

I would say I am a little behind in terms of the schedule so I will definitely be in the lab this week to finish up these last few features and connect it with the software side. However, I feel as though this will not be too much of an issue as the synchronization can be made up with a sliding window of 5 ms to make sure that the hits are registered on time for the game.

I also have to measure end to end latency and notify the team so that they can create a game with enough of a leeway to accommodate for the delay.

Posted on

Rishabh’s Status Report for 3/7

These last two I spent my time developing both the game and the note from music file generation. I’ve moved the game development towards being a 3D like UI to improve the user experience. Here’s what the game currently looks like:

I’ve also started moving the note generation towards using an ML model to allow for identifying more types of notes (outside the current Kick, Snare, Cymbals). This ML model is based on the Omnizart music platform.
The ML model is currently not working, and my plan for next week is to get the ML model working an to get the integration between the game, the ML model, and the hardware system working.

Posted on

Abishek’s Status Report for 3/7

This week I was mainly working on writing the design report. After meeting with HK, we also decided to move away from the ML solution from drum transcription in order to keep things simpler.

In writing the design report, I narrowed down the overall structure of the game, the pass thresholds, variables that will be tracked, songs that will be played, etc.

I’ve also gotten to work on building the game engine in Rust. Currently I have a basic Piano Tiles like set up which can move “tiles” down the screen every few seconds. The next steps would be timing this with the actual drum notes in our preloaded songs and also figuring out MIDI communication so that the game can interface with the hardware side Caleb has been working on.

Posted on

Team Status Report for 3/7

We are almost done with a very rough end-to-end system from pad hit detection all the way to gameplay. Recently, we received our hardware parts and got most of our communications and developments rolled out for testing and further synchronization. Receiving our hardware parts almost 1.5 weeks late does push our schedule back slightly but with some of the work we did over the break we would say that we are almost on track. We just have to handle the interfacing between the central hub and the computer with a standardized communication protocol using MIDI format to convey our notes.

Some changes that occurred, is that we had to switch our transmitter modules from the Ebyte E01ML01S to the Aidepeen nRF24L01+PA+LNA modules because of some shipment hiccups but we were able to circumvent any large disruptions because these chips are all from Nordic and thus their libraries are mostly similar. Besides that we were still wondering if we should outsource our audio generation to our computer interface or through the Daisy Seed which has onboard DAC as well as SDRAM for storing our wav files for our DSP.

Part A: The main global impact of this project is how it reduces the barrier to learning drums for beginners. Typically, you would need to buy an expensive drum kit, an expensive teacher, and know how to read sheet music, etc. With PadL1, all that is needed are the few pads and access to a personal computer, which makes learning drums much more accessible on a global scale.

Part A was written by Abishek

Part B: This project attempts to accommodate cultural factors by having the learning platform not use any specific language and instead using universally understandable symbols and colors. For example, we identify the pad that needs to be hit matching each pad with a given color and the timing is shown by a note falling towards a designated hit zone. Also, in the case a missed note, we use an audio “error note” to designate this mistake. All of these features are culture agnostic and thus allows people for all cultures to enjoy our product.

Part B was written by Rishabh

Part C: This project does require a bit of resources from the environment for the hardware development of the pads such as rubber sheets, acrylic sheets, foam dampeners, and plywood backings. But in the future, with access to industry standard materials, I feel like we can make our system a lot more compact and thus avoid all the excess materials from prototyping. However, our system does not require further natural resources and is pretty compact without releasing any emissions thus presenting not much of a threat on the environment itself.

Part C was written by Caleb

Posted on

Caleb’s Status Report for 3/7

In the past two weeks, I was able to successfully communicate between pad and central hub transceivers using the code with low latency on LPA mode (low power) meaning that it will most likely see an increase in throughput and decrease in lossy-ness if we increase the Power and transmission settings. Additionally, I was able to assist in developing our drum pad system with the voltage regulators. I am currently working on the MIDI format as well as the audio system playback from the central hub after being able to process the incoming packets.

Some things that are to note: On startup and flashing both the RX and the TX code need to be powered on and off otherwise it does not work correctly off of boot. I am trying to debug that currently but for now the simple fix is to disconnect the power source and reconnect it. It’s important to note that the TX circuitry requires and operates on 3.3V logic. I am still figuring out the Daisy Seed Library as it has a lot of documentation and capabilities for digital signal processing, audio output, and MIDI format outputs via USB.

I would say that I am pretty on schedule with my progress but could do a bit more research on the daisy seed to put our team ahead of schedule.

The Link Lost message printed because the transmitter only activates every second to send a packet and otherwise sleeps to save on battery prompting the loss of connection.