Category: Team Status Reports

This week, our team has been working on the foot device, visualizations, and algorithm for the back device. We are currently on schedule to be finished by next week. As stated in previous reports, our greatest risks involve the devices not working properly. To mitigate these risks, we have made sure to think carefully about the designs and tested the devices.

In terms of testing, our team has tested both the back device, foot device, and web app. For the back device, we did tests to ensure that the data we received was accurate and also did tests to make sure that the data sent to the web app matched the data sent from the Arduino. Initially, the values we had were different, however after looking over the code, we found and fixed the bug. We also created visualizations for each sensor and verified the results by comparing our generated visualization with our observations. Furthermore, to test the foot device, we placed different weights on the sensors and checked their resistance. While testing, we realized the weight threshold was too low, so we had to increase the resistance.

To test the entire system itself, we plan to wear both foot sensors and make sure that when applying equal or differentiating pressure, the read resistance values are equal to each other. In addition, we will continue testing the back devices and algorithm by wearing the back device and standing in different positions and then verifying the results match the feedback we want.

As stated in the previous status reports, our biggest risks are our algorithm not working correctly and our Bluetooth not communicating correct data. To mitigate these risks, we’ve been doing lots of testing to ensure the data read from our sensors is correct and researching quaternion libraries to help with our algorithms. There have been no changes to our design currently, however, some members seemed to encounter enormous difficulties when completing their tasks, so we are currently behind schedule. In order to account for this, we’ve decided to shorten the number of days allocated for testing, without reducing the total time spent and also re-assign some tasks. By doing this, we hope to still finish on time before the final presentations.

At this point in time, the biggest risk is that our device won’t fit nicely onto our fabrics, and that our algorithm does not work.  This is because at this point we have managed to get the IMUs working individually, as well as developing most of the individual website pages. We will be mostly on track for the interim demo once we get the sensors attached to the fabrics on Monday, as well as after we refine the bluetooth to web app connection. I don’t believe any changes were made to our system this week, we have mostly just all been working on our individual parts to get them ready for the demo in a week.  I think our goal for the interim demo will be to showcase the data collection from the back unit to the web application.

This week, we primarily worked on the website and getting the Arduino to connect. Since we recently decided to create a web app rather than a mobile app, we’ve had to look at different solutions for connecting our website to the device. One of the biggest risks currently is being able to properly receive large amounts of data sent from the Arduino on the web app. To mitigate these risks, we are looking into solutions where we read data in chunks of bytes. We are currently behind schedule because our parts only arrived this week and due to Rachel’s recent procedure, we have not been able to get as much progress done as planned. However, after shifting some tasks around and changing the amount of time for each, we should still be on time to finish our project by the final presentation.

This week as a team, we mostly spent time learning the applications / libraries /sensors that we are going to be using for our project.  Some significant risks are that all of us are taking on learning something new that we haven’t done before. That is Jasmine and Rachel have never used Flutter before, so there is a big risk that it might take them longer than expected to meet their initial deliverables. Our fallback plan here is that they both have experience with web app development, so if the app doesn’t work out we can fall back on a web application. All of us are currently a bit behind schedule, as learning Flutter was a bit more effort than originally anticipated. However, we have gotten to work setting up our team github, and will hopefully have a couple of pages ready to go by next week. No changes have been made to our design over the past week, and things are only delayed by a couple days in our schedule so they can simply get merged into the next week of work, or completed over Spring Break if absolutely necessary.

With regards to teaming, we are all taking on something a bit new. We are managing this by giving each other grace in the time it takes to learn these new applications. We have also paired Jasmine and Rachel together in Flutter development so that they can help eachother out in overcoming any major hurdles, as well as holding eachother accountable. To handle unanticipated design challenges, we are

1. sharing any new realizations about the difficulty of an problem as they occur
2. creating a list of resources as we find them to fall back on, and so another team member could read up and get up to speed quickly to fill in for another
3. writing good documentation on our design process and thoughts in code or schematics

With this list, we hope that if one teammember falls short or can’t meet a deadline, that another person can get up to speed quickly and help with that requirement. It also helps us to be able to debug for one another if we make clear documentation of what everything should be doing.

This week, we primarily worked on finalizing our designs for the device and software. We also decided to add a new device to our project where users will wear ankle straps with pressure sensors hooked onto them that they place under their foot in the shoe. This new addition allows us to measure the weight the user is carrying such that we can help them better track their progress. Since we will be building and testing an additional device, our schedule has been modified. The main risk for this project is getting our devices to work and being able to correctly determine back positioning. To manage this issue, we did thorough research to ensure the components are compatible. In addition, we have also begun discussing and researching which libraries we will be using to develop our algorithms on back orientation and curvature. Currently, we are looking into Quartenion libraries to get proper positioning values of the sensors.

With our research conducted last week on use case requirements and stakeholders, we were able to apply different engineering principles to design our devices and software. To design the weight detection device and back orientation and curvature device, we had to use hardware design principles where we had to figure out what we wanted our system to do, what we need for it to carry out its function, and how we will connect them together. When it comes to the designing of hardware systems, lots of research was put into gathering necessary components, such as sensors, and ensuring they were compatible with other components. In addition, we incorporated mobile design principles for our frontend design, such as Lund’s Usability Maxims, to ensure we have a simple and well-designed user interface. For the backend of our software, we used object-oriented design principles to understand the components we will need and then define the solution.

Our project includes considerations for public health and safety.  By helping people feel more confident about their gym form, we promote personal health and prevent injuries during workouts. We focused on prototyping our design interface. We made two drafts: a paper prototype, a digital one, and a block diagram to show the general flow of the software. Since we spent most of the lecture time reviewing the proposal presentation of other groups during the lecture period, we decided to meet as a group to discuss the initial design. The biggest risk of this project is sensor compatibility, and we are managing this risk by making thorough research on a variety of sensors. We are currently on schedule and our plan for next week is to finalize the sensors that we found this week.