Posted on

Team Status Report for 3/29/2025

After our work this week, we don’t have any notable risks on the software side, but we believe there may be some uncertainty with velocity calculations. Jason’s data reports a lot of drift, and while Meadow’s data does not, it has not been verified yet. Since this has been an area of concern from other sensor users, we suspected running trouble as well. We’re attempting to manage this risk by consulting sensor velocity documentation and pinpointing our issues through testing via serial plotter. Ensuring accurate velocity should not be too difficult, but we suspect keeping it that way is where things will become questionable. We will be keeping alert on ways to prolong its accuracy or tailor the time of a user’s lift to align with how long the velocity remains stable (but this is speculation).

Currently no changes have been made to the design.

Our overall schedule has not changed.

Posted on

Meadow’s Status Report for 3/29/2025

This week I wanted to work on the calibration (such that it doesn’t have to be recalibrated after disconnecting), investigating the velocity, and figure out how to plot the serial data. Jason offered to manage the plotting, so I focused on the first two tasks. I was able to generate velocity in all 3 directions, but due to the difficulty of plotting data, I have not yet verified their accuracy (but they seem close to reasonable). Figuring out how to save the calibration status has taken longer than I was hoping and I think I need to do some more reading on how calibration gets stored before success. But so far, I (at least suspect) can calibrate the sensor and load the new values into a register on the sensor, however, I haven’t been able to check that the values stay the same upon rebooting yet. So I think I’m halfway there. This shouldn’t be an issue for our upcoming demo since we can just keep the sensor connected and calibrating is a quick process. Next week I plan to work with Jason on integrating the plotting software and validating my values. I’m also hoping that in the coming few days I can figure out what I’m missing with saving calibration, but here is what my serial monitor has been looking like after the initial calibration.

First we see the sensor at rest (there are a few offsets that will be adjusted later):

And here we have with some random movements (i.e. up/down, side/side, figure 8’s):

Posted on

Jamshed’s Status Report for 3/29/2025

This week I spent time troubleshooting the tracking implementation. It seems like the tracking is accurate, and the inaccuracies/drifting I’m witnessing are due to some dimensional mismatches with the video display and the overlaid tracking result. SwiftUI seems to be a little inconsistent with the video sizing, so I’m now developing a Video Writer that will overlay the tracking results frame-by-frame into a new video file, which should more clearly demonstrate accuracy.

Progress is on schedule. I hope to finish my video writer, integrate with the barbell sensors, and start developing the UI for the app next week.

Posted on

Jason’s Status Report for 3/29/2025

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.

 

Posted on

Team Status Report for 3/22/2025

So far there is a slight risk with not being able to find an ample serial plotter to be able to properly validate and test our sensor data. This is trying to be managed by asking around and checking out as many softwares from Google as possible (haven’t found a good one yet). Worst case, our team is ready to try and code a simple application ourselves to visualize the real time data transmitted to a visual graph. Additionally, there is the mystery of velocity calculations. It’s possible this could be mitigated by calculating the velocity without using the sensor (i.e. through the camera or some other means) or being able to integrate acceleration successfully (but this has said to be hard and unreliable). Since this is a fairly new concern, not much research has been conducted yet, and hopefully next week’s status will have good findings.

Currently no changes have been made to the design.

Our overall schedule has not changed.

Posted on

Meadow’s Status Report for 3/22/2025

This week I learned more about how to interact with the BNO055 and the necessary code. I managed to calibrate the acceleration that was posing issues from last week and successfully configured the x, y, z acceleration and rotations about the x and y axis. The setup is stable and my output values are consistent every time. It seems easy to visually confirm the accuracy of the orientation angles, but I will confirm them with a protractor or something later. I’m unsure about the accuracy of the acceleration values because they seem to lag in changing (or not change at all) for a variety of short movements. However, this may just be an inability to comprehend what these values should be reporting. So far I’ve been analyzing this data straight through the Arudino IDE and using its serial plotter and monitor. These will not be sufficient to test against the ground truth (mostly because the plotter is pretty frugal),  so I was trying to find a reliable serial plotter software to run my experiments. But I couldn’t find one that works. Still looking for that fix. Unfortunately I was unable to test against ground truth for this reason and it will have to be postponed another week. But the sensor readings have made reassuring progress! Next week I want to implement the feature to save calibration status so I don’t have to redo it every time I want to test something and I want to figure out the plotting software situation to challenge the sensor accuracy. I also need to look into getting sensor velocity; I was under the impression this sensor calculated its own velocity (part of the reason we chose it), but we have yet to find documentation on this.

Posted on

Jason’s Status Report for 3/22/25

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.

Posted on

Jamshed’s Status Report 3/22/25

This week, I worked on the Ethics Assignment, Object Tracking Implementation, and initial UI for the IMU data visualization.

Object Tracking now processes full video before visualization, instead of frame by frame. Some issues are arising with the tracking drifting, I haven’t figured out if they’re due to image dimension mismatches or due to tracking implementation. The tracking is generally accurate, but tends to extend a bit past the edges of movement, especially for wide aspect ratio videos. Screenshots of both scenarios are below, as well as the initial UI for the data.

Progress is according to schedule.

Next week I hope to get some real data from the IMU to plot and play around with how I want to visualize the different data values we’re recording.

 

 

Posted on

Team Status Report 3/15/25

Currently, our main risk is not achieving sensor calibration that matches the ground truth model. As accurate data is critical for this project and we have had some setbacks with ensuring the validity of calibration, this could cost time and put us off schedule. However, there is extensive documentation on the BNO055 and, if this risk comes to life, we should be able to fix it once we sift through enough documentation to find the right solution. Naturally, we are actively making our way through the extensive documentation to learn more about its function as we progress through the project. And if the data output from the BNO055 becomes hopeless (though unlikely), we have additional sensors of a different model we can substitute into the design and work upon. Implementation of these backup sensors will be done somewhat in parallel to our priority work on the BNO055 sensors.

Furthermore, we haven’t made any changes to the existing design of the system, and our schedule hasn’t changed.

 

Posted on

Meadow’s Status Report for 3/15/2025

This week I validated the real time streaming from the sensors after our new wires came in. I worked on calibrating the sensor, but came across some difficulties on how to so based on the Adafruit documentation. However, I managed to find a way to calibrate them after research on the device and  looking through sample code. I managed to calibrate 3/4 metrics reported from the sensor, but was unable to calibrate the acceleration vector, thus was unable to compare readings to a ground truth context for now. I have since found a method that should work to calibrate acceleration from the BNO055 GitHub and will verify this in the coming week. For next week I plan to solidify the calibration status on the sensors and become more comfortable with how to program what we want the sensor to do. Then I will begin some initial tests comparing the sensor to ground truth.

I am slightly behind from figuring out the calibration issues and haven’t been able to test the sensors on a barbell yet, but aside from this, other aspects seem to be on schedule. However, testing the sensors on a barbell goes hand-in-hand to comparing the sensor data to the ground truth model, which is expected to be done next week.