Posted on

Elliot’s Status Report for 9/28

This week, I was tasked with establishing a basis for communicating with the ESP32 boards and their corresponding MPU-6050 accelerometers. I spent some time looking into the BLE stack to determine the complexity needed for our GATT services and characteristics–the available options were the native ESP IoT Dev Framework, the Arduino IDE, and a MicroPython-based firmware. I concluded that while the ESP-IDF would give us the most control over the pipeline we implement, since our main purpose is to simply transmit the accelerometer data and its timestamp, the service complexity does not call for any fine tuning. Between the Arduino framework and MicroPython, it would be be best to use a compiled language rather than an interpreted one for the purpose of lower latency. Therefore, I started developing some of the C++ code we’ll eventually be flashing to our microcontrollers; to test functionality, I worked on an ESP simulator on Wokwi to set up a bluetooth connection and send accelerometer data to notified clients. Some libraries necessary for the arduino framework include Wire.h for I2C, BLEUtils for initializing the advertising and notifications, and the MPU6050 device driver.

I also practiced my presentation approach for Monday, where I’ll be talking about how our bluetooth, computer vision, and web server modules interact. I emphasized time spent on identifying why we chose the components we chose, as well as developing concrete requirements to link back to our product use case requirements.

For next week, my plan is to:

  1. Hopefully receive our hardware and begin testing the accelerometer thresholds. I’ll set up communication over bluetooth to relay data, and based on our drum hits, we’ll then look at what signal spikes would indicate an adequate hit.
  2. Test bluetooth latency and packet loss. Once we have the ESP32’s wired up, I can insert packet misses to determine adequate rates, as well as measure the latency of our transmissions with timestamps. This is especially important to us, given the fact that we’ll be using two transmission devices in a low latency environment.
Posted on

Elliot’s Status Report for 9/21

This past week, I helped in finalizing the parts list we would request for purchase and for reservation from existing inventory. I spoke with Professor Mukherjee and our team’s TA, Tjun Jet, about some of the components and their purposes. I also worked on the slide deck for the upcoming design presentation and covered a few solutions regarding the interconnectivity of our components–I began researching how to interface with the accelerometers using the ESP32 MCUs as well as the bluetooth stack we’ll be using to relay data back to the host device. I also helped establish our fallback plans in case any given module from our block diagram does not work as expected. Overall, the team is currently aligned with the schedule we laid out in our Gantt chart, but there is still a considerable amount of research needed before I can confidently outline our technical design to the class. This upcoming week, I plan to do the following in preparation for the design submission:

  1. Look into our options for BLE abstraction libraries to easily communicate with the microcontroller. My hope is that Python will have an existing API available for the ESP32, but if not, I am prepared to read the documentation for our device’s Bluetooth module and initialize the advertising, connection, and packet transactions manually.
  2. Similarly, I need to find a way to accept accelerometer data through the MCU. I looked at a few datasheets for the ESP, and it doesn’t use the Cortex M-series microprocessors I’m most familiar with, so I’m not sure if I’ll have to manually write a device driver for the I2C peripheral to communicate with the MPU-6050. Again, hopefully Python has some level of abstraction available for us to use.
  3. Belle will be mostly working on the repository code for the OpenCV, but I plan to also help with the CV code so that I can get a full understanding of our algorithm’s capabilities before we actually enter testing. It will also help me familiarize myself with the repo we’ll be working in, where we plan to put together Ben’s front and backend implementations, the CV code, and the Bluetooth interface for collecting accelerometer data. 
  4. Prepare slides and practice verbal delivery. Once all of the above details are established, I can describe our technical strategies in greater detail and identify appropriate visuals to include in order to communicate our project vision clearly.