Author: jbotros

A majority of my work this week was spent with Jamshed completing the integration of the sensor with the iOS application.  We spent a decent amount of time figuring out how we wanted to send the mean concentric velocity (MCV) during the user’s rep into the app for them to see. We decided on sending the MCV at the very top of a rep with our movement detection but we found some difficulty doing this after testing on a barbell during the week. We are currently in the stage of troubleshooting this feature but hope to be able to have it figured out by tomorrow. I also spent some time this week integrating Meadow and I’s code as I focused on the Bluetooth setup and protocol with the iOS application while Meadow focused on the calibration of the sensor and saving its calibration status. I was able to integrate the two but we also found some issues with this while testing this week. We decided to have it so that the sensor and esp32 do not begin Bluetooth streaming until the IMU device is fully calibrated. I have also been working on a version that only detects and send the MCV at the top of the rep but does not send any eccentric movement as the sensor has been very sensitive to positve (concentric movement) leading to overcorrection in velocity data which is negative which has complicated the concentric/eccentric logic of the sensor detectection within a rep.  Nonetheless, I am still optimistic that we will be on track for the demo on Thursday as we will continue testing all week until demo day.

After specifying and discussing the communication protocol with Jamshed last week, this week I spent the first part of my time implementing said protocol. This was done entirely in the Arduino code for the ESP32 so that it communicates directly with Jamshed’s iOS platform without a Python script acting as a middleman. This protocol specified how the data would be sent and in what time interval it would be sent.  We also decided on an external start command for the ESP32 to wait for in order to begin transmitting data from the BNO IMU sensor it is connected to. This is separate from the internal start logic that I implemented, which solely depended on a threshold of velocity to be exceeded. We tested this communication protocol out during class time on Wednesday, after I had finished implementing it and we were able to successfully integrate the two parts together, with communication working on Jamshed’s phone while testing. The only setback we had was the data accuracy, particularly of the velocity metric. I then spent the rest of the week trying to fix this data discrepancy, which required some further research into sensor fusion and Kalman filters. I also am rewriting my python script which has to be updated based on the new communication protocol, but will use this as a method of less-complex testing in order to simulate communication with the phone with a focus on checking velocity data accuracy since we know that the devices’ communication integration should already be good to go for demo day. I believe we are on track once I finish up fine-tuning the velocity data accuracy, and should be good to begin filming our demo video within the week.

This week I spent some time researching how we would like to attach the actual hardware component to the barbell (clips). Although this did not take much time I find it important enough to update that we decided on industrial velcro as a strong enough adhesive to attach our hardware component to the barbell and will use this method unless it appears unfit after further testing. Apart from that, I worked with Jamshed this week for the rest of my time spent on the hardware components this week to properly integrate the data from the IMU with the software iOS platform that Jamshed has been working on. We discussed some protocol that I updated the arduino script based off of and am also working on updating the python script to further support this protocol in which the sensor will wait for a start signal from the software platform to begin transmitting data. Furthermore, Jamshed also mentioned that he wanted me to implement some sort of method of diserning the concentric from the eccentric motion for the plots to be grouped individually based on the sorted data (movement). I will pursue implementing this by monitoring the z-axis and its data from user motion. I hope to have this done by midweek so that Jamshed and I can test these new updates and hope to be further along the integration process. Nonetheless, I think we are on track for the final demo in three weeks or so.

This week I spent half of my time dealing with the newly setup WT901BLEMPU9250 and half of my time with the previous BNO055 IMU sensor. After setting up the WT901 from last week our team sought to find a method to plot the acceleration and gyro values for our own testing purposes but also in a manner that would be plotted later on in our mobile software platform for the user to see a graphical trend of their movements in terms of the data captured by the IMU. I explored this in both avenues of the IMU sensors and found that the BNO055 was easier to deal with in terms of data extraction, particularly because of the binary mode nature of the WT901 that required an extra layer of extraction and processing of data that the BNO055 did not require. On top of this, our team found a customized ESP32 PCB on Adafruit that has a digital interface that also has a specific port for the Li-Poly battery and BNO055 STEMMA pins to connect to the sensor. Therefore, I continued work and gave full dedication to the serial plotting script and data extraction of the BNO055 for the rest of the week and will recommend to my teammates to continue the project with a focus on using this sensor. In terms of where we are on track, I was able to finish up the serial plotting software and fix some of the Bluetooth advertising issues with the BNO055 code where it would stop advertising after the initial code upload. I also wrote some code on the python script to graph not only the acceleration and gyroscope metrics, but also the velocity metrics via integration, despite having noticeable drift. I have attached a screenshot of these graphs that are generated using bleak library in the python script. I a still trying to mitigate the drift in the velocity calculations but we are on track as of now as I have also been able to extract the data to csv files to be sent to the software platform. Nonetheless, I feel we are in a good spot for the demo next week and are on track based on our schedule.

This week I spent a majority of my time trying to setup the fully integrated MCU that we bought as another option for the data metric collection of the data points we want to collect regarding barbell movements. As mentioned last week, it is 1/10th the size of the current BNO055 IMU sensor that we have already setup. Now that the new MCU is setup with built in BLE and an IMU we will likely have to make a decision between which sensor we plan on using and plan to outside as an avenue for our hardware solution for the rest of our project. By next week I would expect to have this decision made with a reasonable explanation behind it and for integration with the software iOS platform to be stable enough for the mini demo coming up. Nonetheless, we are on track with our schedule and hope to remain so.

This week I spent a majority of my time reading through the datasheet of the new MCU we got delivered this week. We are planning on setting it up the same way we set up the ESP32 Dev board with the BNO055 IMU sensor to transmit the IMU sensor readings via BLE as the new MCU we received is fully integrated and contains and IMU as well as a Bluetooth module. It is also 1/10th the size of the ESP32 and IMU we already have so exploring this avenue is something we want to pursue as it could potential be very effective for our product. I also spent a decent amount of time writing some of the Kalmann filter and low-pass filters for the existing code we have to smooth the data we are receiving currently from the BNO055 IMU sensor in order to have more accessible and fused code. This will be portable for any future code that may need to be written onto the new MCU we received if we decide to switch gears and pursue the product with the MCU.

We are on track regarding our timeline and I hope to have the new MCU fully setup by next week with the same functionality as the current IMU+ESP32 for data to be transmitted via BLE as well as the filters I worked on this week to be added on top of that.

This status report period was spent half of the time completing the design report document and half of the time completing the goals for what I set last status report. Regarding the status report, I spent ample time completing the system implementation sections as well as the testing and validation sections. On top of this, the Design Trade Study section was split up amongst my teammates, which I also spent a decent amount of time on. For each section that I was responsible for, I backtracked on our prior research while also refining how we wanted to carve the rest of our project planning.

In regards to meeting our prior goals in the prior status report, the rest of my time was spent converting the IMU sensor + ESP32 hardware setup to support BLE. This came after the realization that it was not being recognized as a peripheral device on the software platform. This debugging required some changes to the firmware but after it was accomplished, we were able to successfully integrate the IMU sensor data with the mobile software platform, which Jamshed has been working on, and fully extracted said data. Our goals for the week after next (the next status report period timeframe) are to reduce noise and implement a smoothing function/low pass filter to refine the data extraction as well as possibly implement the mentioned Kalman filter to significantly improve the accuracy of the IMU sensor data. Nonetheless, we are on track with our goals in terms of both hardware and software setups and integration and hope to remain on track by completing the mentioned goals for next week.