This week our team took a closer look at planning and strategizing around the implementation process for building DrumLite. In preparation for the Design Presentation, we focused our energy on identifying design requirements and how they connect to the defined use case requirements as well as starting to nail down the specifics of how our components will interact.
We identified 4 main risks we foresee in the near future:
1.) Interfacing between the MPU-6050 accelerometer and the ESP32 Bluetooth transmitter
2.) Processing the data relayed from the accelerometer through the ESP32
3.) Inability to accurately detect the rings that define the drums location using OpenCV.
4.) Not being able to detect objects within frames fast or accurately enough given the field of view of the camera.
For each, we came up with mitigation strategies, all of which are outlined below:
1.) In the case that we can’t interface between the two devices mounted on the drumstick, our contingency plan is to completely back away from the use of the accelerometer and pivot to a new design using strictly computer vision. It is for this reason that we are currently in the process of ordering both a camera with depth sensing, and a standard webcam. The idea is that if we need to, we can resort to detecting a hit by determining the distance of the stick from the camera, knowing the distance of the camera from the desk. We don’t view this as a probable outcome as there is a lot of existing documentation we’ve seen involving the interconnectivity of the MPU-6050 and ESP32 .
2.) If we can’t figure out how to process the data relayed by the ESP32 via Bluetooth, our idea is to fall back on wiring. In this case, the wireless aspect of the project would be eliminated, but this would still stay within the parameters outline by the use case, namely portability and versatility.
3.) If we are unable to accurately determine the location of the rings using standard object such as with the HoughCircles library we were planning on using, the plan is to fall back on a convolutional neural network. Our concern with this is that using a model will introduce a lot of latency into the system, which again, goes against our use case requirements.
4.) In the case that we can’t detect the location of the stick’s tips accurately or fast enough we plan on enforcing a fixed camera height and angle, as well as a much smaller maximum layout size for the drum set. By enforcing that the camera needs to be directly above and downwards facing, capturing the exact shape, size, and location of the drum rings will be much easier and standardized.
In addition to this planning, we’ve also placed our order for all the hardware components well need, all of which were found on amazon at a reasonable price ($264). We’ve decided that in the coming week Elliot will be working on figuring out the interconnectivity of the accelerometer, ESP32, and the code required to receive and process the accelerometer data; Belle will look into figuring basic utilities in OpenCV and the effectiveness of the HoughCircle Library we plan on using for detecting the rings; Ben will be responsible for looking into how to create a REST API that runs locally and interfaces with a webserver for sending and receiving custom drum set layouts.