Category: Team Status Reports

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.

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.

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.

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.