Posted on

Meadow’s Status Report for 02/22/2025

This week I gained more understanding on the ESP32 and the BNO055 and its setup process, along with part characteristics through research, prior to Jason physically testing the sensor. Even though he got some readings out of it, I found that pairing the BNO055 with an ESP32 is not reliable, per a warning from Adafruit. I took to looking for other microcontrollers compatible with the sensor in case there’s a more efficient option that offers more of our requirements than an Arduino (which we initially planned to test with). A different IMU was ordered to see how it compares to our BNO055, which will be tested after it arrives. I ordered a part that should help make testing the sensor easier for next week and eliminate some human error. I’ve also been looking into how to make our testing more functional by creating a (very) basic prototype to attach on a real barbell.  Because we know that the sensor is outputting values and have a script ready for more testing, next week I plan to investigate the sensor readings and check accuracy/plan for calibration and potentially perform more dynamic testing to simulate our use case instead of basic hand movements, should we manage to create the necessary mobility.

Progress feels on time.

Posted on

Jamshed’s Status Report for 2/22/2025

Spent much of Sunday and Monday morning preparing for my presentation. I then took some more time playing with the iOS SDK until I was comfortable with the syntax and the XCode IDE. Developed some initial UI for the video playback feature using the Photos and Vision API. I plan to integrate an object tracker provided by the Vision API into this UI.

Now that I’ve found a solution for the object tracking using the Vision API, it’s taken a lot of the load off of the Computer Vision portion of the project, which will hopefully expedite the pathway towards integrating with the hardware.

Next week, I hope to have V1 of the object tracker working. Currently, I plan to have the user draw a bounding box around the barbell plate in their side view, so I have something to iterate on if I decide to later use a model to detect the plate automatically. I also hope to integrate with the hardware and be able to read data over Bluetooth.

Posted on

Team Status Report for 2/22/2025

In terms of the hardware side of things, at this point in the project after achieving the initial setup of the IMU sensor + Bluetooth microcontroller one concern and/or risk for the project is if the IMU’s data will be easy to process and send over to the actual software platform. Although the data was captured and extracted already, this was a continuous stream of data that was infinite. One risk is focusing on this data and the particular relevant data that we will have to achieve, and if not achieved, could risk the project’s success. This will be done mainly with the software platform and firmware as a means for managing this risk by including a manually integrated user-starting point through the software platform.

We also spent some time researching the iOS Photos and Vision APIs and developed an initial UI for the video playback portion of the iOS app. Ultimately, we want to integrate the object tracker (provided by Vision API) into this playback screen so the user can see their bar-path.

The only change that we have prepared for in terms of the hardware side of the design is using a fully integrated MCU for the IMU sensor + Bluetooth microcontroller. We have ordered the necessary MCUs for this but this week we simply worked on iterating on our original hardware design and its setup so that when we implement and setup the MCUs that we ordered, the firmware will already have been written and the setup will be seemless.

Below is some photos of the hardware sensor+bluetooth microcontroller progress that we made this week after completing initial sensor setup and Bluetooth integration as well as IMU data extraction:

 

Hardware setup:

IMU Data while calibrating:

IMU data while at rest (semi-suspended):

iOS app:

Posted on

Jason’s Status Report for 2/22/25

This week after completing the Design presentation I worked on the initial setup of the hardware flow we would be working on for the project. Although we were given the suggestion to use a fully integrated MCU, which we did indeed agree too, we still had the parts to the IMU + ESP32 hardware flow. Therefore, for skeletal setup, I worked on the initial hardware and software setup of these two parts as well as integrating them.

 

I was able to initialize the two from a hardware perspective by working in the Techspark lab for a few hours for the last two days of the week after acquiring the necessary hardware components. I then proceeded to install the necessary libraries in the Arduino IDE to set up the software necessary to use the ESP32’s Bluetooth capabilities. After doing so, I wrote the necessary firmware needed to properly extract the data from the IMU and its 9 degrees of freedom (DOF). I achieved this after much time debugging this initial setup. The values I extracted from the IMU in terms of the acceleration, gyroscope, and magnetometer readings seemed reasonable but will be tested next week for exact accuracy. We are currently on plan and on schedule with what we expect and hope to have this integrated with the software platform by the end of next week to report in the design doc.

Posted on

Team Status Report for 2/15/2025

 

Due to a better understanding of our project design implementation, we currently don’t identify any risks.

Our scheduling has not been changed, but we updated our Gantt chart:

The following is the link to the Gantt chart:

https://docs.google.com/spreadsheets/d/1n9OZ-xUqTf-gHWbgh1kk7MOH1vyjhkIM0hF98iU0UII/edit?gid=0#gid=0

Our design is mostly similar to that of the project proposal. However, we have decided that handling computation on the host device is ideal for user workflow, instead of cloud computation. As a result, we may not need to use any cloud services for our project. This change will not cost us any of our budget, as we were intending to use EC2 free tier. In terms of hardware, we haven’t made any specific changes to how we want to implement this portion, but have made advancements in what we know to look for and have created some additional requirements to follow when purchasing parts. Taking notice of these new requirements are obviously necessary to ensure the hardware is able to meet our original user requirements. This does not incur any extra cost.

 

(A) Public health, safety or welfare:
RiseVBT is a product focused on optimizing the efficiency of weightlifting, which we believe (and many academic studies) to be a direct link to a user’s general health and well being. Providing objective feedback bolstered by scientific evidence would surely improve a person’s ability to be proactive in their physical fitness, feel more confident and motivated in their routine, and ensure they’re improving over time. The concept also aims to increase gym safety by providing tips on form and making it easy to self-assess what a user is in range to lift, decreasing the chance of injury and making weightlifting a safer activity. Additionally, we believe taking care of one’s body through physical fitness is a basic need and strength training as a simple means of enhancing life longevity and anatomical health.

(B) Social:

The gym is a well known community where many seek confidence and self-improvement, but fear of judgment or making mistakes can pose a major barrier for new lifters. RiseVBT helps by providing guidance of weightlifting fundamentals by providing feedback to refine technique, all while ensuring safe progress. This support empowers users to become independent in the gym, while providing assurance that they are on the right track.

(C) Economic:

Current VBT devices are quite expensive, with average costs in the hundreds of dollars. We intend to bring the practice of velocity based training to the amateur athlete at a lower production cost. Our accompanying app is also free, and provides additional information through video analysis. Our device is small and practical, allowing for a seamless integration into any athlete’s workout regimen.

 

A was written by Meadow.

B was written by Jason.

C was written by Jamshed.

Posted on

Meadow’s Status Report for 2/15/2025

This week I dove more into IMU investigation and learning which specs to look out for to find a model that fit the requirements of our design. Jason and I ended up settling on an Adafruit BNO055 due to its accelerometer range and ease of orientation data collection. It seems to have all the tricks we’re looking for with a design that won’t compromise any of our needs. We placed an order for a few of them and aim to test their functionality after arrival. As these are meant mainly to get a feel of what to look out for in hardware implementation, I plan to look into a few more IMUs and begin researching more about complementary parts we’ll need for the BNO if we continue strictly with this model. Lastly, I dedicated time to collaborating with my group on the design presentation and fleshing out the content and delivery of our information. So far we are still on track from previous week’s expectations.

Posted on

Jason’s Status Report for 2/15/2025

I would estimate that at least 75% of my time this week was spent on researching how IMUs function, what they’re capacities are, how they integrate, and how raw data is taken from them and used for metrics like position and displacement. I lot of this led us to not only understand the flow of our hardware architecture but also the exact model of IMU we wanted to use. We settled on the BNO055 which has a decent data rate and operates at the data precision we were hoping for. The rest of my time was spent preparing for the design presentation and creating several spec charts and diagrams.

I would estimate that we are on track and not running behind schedule. We ordered our IMU sensors in the middle of the week and are hoping to get them in by early this week to begin novel implementation and data capturing with them in order to have a very novel integration phase with Jamshed and his software side via Bluetooth by the end of next week.

Posted on

Jamshed’s Status Report for 2/15/2025

Did lots of research for the design review presentation. Solidified which software stack I wanted to use, and decided on an overall design for the software architecture. Drew up some block diagrams. Spent some time with some iOS development online courses to begin my app design. Set up Django REST API.

Progress is on schedule. I plan to spend more time getting a basic iOS app up and running next week and start playing with the iOS SDK’s bluetooth API, so we can try to integrate with the sensors as soon as possible.

Posted on

Team Status Report for 2/8/2025

A significant hardware risk to the current status of the project is not being able to locate hardware that meets our use case requirements. However, we hope to mitigate this by: taking note of tech specs prior to purchase and ensuring they fit our scope, having backup individual parts instead of only fully integrated tools to promote customization/flexibility.

Since defining our abstract, a few changes have been made.

Sole velocity metric: We initially were set to focus on velocity as our core metric for providing data feedback on a lift, but have since expanded this to acceleration, displacement, balance, and torque. This change will allow for a more in depth analysis of a user’s performance and provide more information for improvement. It should also make data collection for app functionality easier. We will have to add more parts into our design to make this possible, but many products on the market seem to offer small device solutions to these metrics.

Metric app comparison: Due to limited research, we had planned to perform testing/verification on our data by cross referencing it with an existing product. However, we cannot believe another product’s information to be 100% accurate, and thus developed an automated pulley system to establish “ground truth” for our sensors so we can ensure a set of robustly correct data is available to cross reference after we calibrate the sensors.

No schedule changes have occurred.

Posted on

Meadow’s Status Report for 2/8/2025

As the first proper week working on our project after solidifying a concept, I spent time with my group brainstorming the necessary materials and requirements needed for our device. I aided in the research and design of our proposal presentation, making tweaks from the abstract and honing in on what we wanted our use case to accomplish. I worked with Jamshed to provide Jason mock-presentation feedback before the proposal presentation. A lot of the work time this week was spent generating a better idea of what our project seeks to accomplish and how we can implement it, which became clear in our proposal slide deck. On my own time I began reading up on devices on the market that provide the metrics we want to implement in the barbell sensors and if they should be feasible to integrate into our design.

In the coming week I hope to composite a list of IMUs and individual accelerometers, gyroscopes, etc. that compare their features and see which parts meet our use case requirements. After deciding and collaborating with Jason (as the other hardware member) I would like to place orders for the ones we deem best. Finally, since the design proposal is coming up I will collaborate with my group to develop a concrete plan with corresponding slides outlining what we plan to achieve.