Posted on

Jasmine Yew’s Status Report for March 11

This week, I primarily worked on the design report and also began working on the web app after we made a decision to pivot from making a mobile app and doing a web app instead. So far, I’ve created the base layout for our log and feedback page. However, in order to complete the feedback page, I will need Rachel to finish the tracking page so I have the proper layout. In addition, this week I created the object models and forms necessary for our app to function.

Models we will be using in our implementation

Currently, I am on schedule because I already have most of my implementation of the feedback page done. However, the rest of the feedback page’s implementation does rely on the data read from the sensors and the completion of the rest of the web app. Hopefully, by next week, the sensors will have arrived so I can begin working on my algorithms. By next week, I also hope to have finished the implementation of the feedback page where I match the feedback to the exercise and also compile a list of different feedbacks we can give the user depending on how their set was.

A general layout of our home/log page
A general layout of our feedback page
Posted on

Jasmine Yew’s Status Report for Feb. 25

This week, I set up the team repository and have begun writing the feedback page. I am currently on schedule, however, I am slightly worried about the implementation of the mobile app since I am not the most familiar with Dart. In order to make up for my unfamiliarity with Flutter, I hope to spend most of my time during spring break experimenting with it and finishing my implementation of the app. My goal for next week is to complete the feedback page and the design report.

Posted on

Team Status Report for Feb 25

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.

Posted on

Sydney’s Status Report for Feb. 25

This week we placed the parts order from the budget / part list. I also assisted with making the teams design presentation this week, drawing up circuit/sensor schematics. As we are still waiting for parts to arrive, and as this is a heavy midterm/project week for me, I did not get a ton done. I briefly explored some arduino code that might be useful for interfacing with my desired parts. In particular, I am focusing on learning how to use the ICM-20948 Inertial Motion Units as those are more critical to our MVP, while the foot pressure is a nice to have.  In particular, I looked at this library and thought this code example might prove relavent: https://github.com/sparkfun/SparkFun_ICM-20948_ArduinoLibrary/blob/main/examples/Arduino/Example9_DMP_MultipleSensors/Example9_DMP_MultipleSensors.ino

Originally, I was planning on trying to write out some code for my use case, but I think it might be more worthwhile to just try and test one at a time, then build out from there. I also looked into how to use Bluetooth Low Energy on an arduino, as I am afraid that could prove problematic later on, and would rather at least learn a bit now. So I read this article on it. https://docs.arduino.cc/tutorials/nano-33-ble-sense/ble-device-to-device

 

Unfortunately, I feel like I learn best by doing, so for now I just gathered resources to use next week when the parts arrive and I have the opportunity to work through some of these tutorials.  I am a bit behind schedule as we were hoping to have the back sensing and weight sensing devices built by now. However, I think it will be okay, as I have done thorough research and planning, so once the parts arrive, assembly should not take long. My plan to catch back up is just to make sure the “ensure everything works together” part of my task list goes smoothly (which it should as I put in plenty of research into my part configurations beforehand)

So next week I am hoping my parts will arrive and I will be able to check off my assembly and data collection from device tasks.

Posted on

Jasmine Yew’s Status Report for Feb. 18

This week, I primarily worked on getting Flutter set up and learning Dart, the programming language required for Flutter, while also working on the design presentation slides. I also worked with my teammates to draw out the diagrams for the hardware components. Sydney and I have also begun thinking about how we will be implementing the back orientation and curvature algorithms.

Currently, the plan is to potentially use pre-existing Arduino Quartenion libraries that work with gyroscopes, accelerometers, and compasses (the sensors we will have in our device). With Quaternion, we can determine sensor orientation and potentially detect back curvature by checking that all sensors are oriented in a straight line. For the back orientation, I am thinking we can use physics to determine sensor positioning and apply this data to see if sensors are located at a consistent distance apart throughout the movement.

My thought process on how we can potentially determine back curvature

I am currently behind schedule for my feedback page on the app because I did not account for the Flutter learning phase when creating the schedule. This should not affect the final date we finish our project because the plan is to finish the app by the time we finish building our devices, and based on the newly updated schedule, there are still several weeks left. By next week, I hope to figure out which specific Arduino libraries we will be using to read the data from our sensors. In addition, I hope to have worked on part of the Feedback page of our app.

Block diagram of how we plan to process data read from Arduinos

The main courses that helped me incorporate design principles into this project were 18-349, 17-214, and 17-781. 18-349 allowed me to help Sydney with the hardware design process, while 17-214 helped me create and refine the object models I drew last week. Using the user design principles I learned from 17-781, I was able to design a user interface that users will hopefully find to be simple to use.

Posted on

Team Status Report for Feb. 18

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.

Posted on

Sydney’s Weekly Status Report Feb. 18

This week I worked primarily on finalizing the current design of our device. I am a bit behind schedule, in that I did not finish my design planning early enough to place the part order last week. I don’t think this will pose too much of an issue, as the order will hopefully go out next Tuesday, and I can use that lead time to start writing some arduino code to interface with the controllers such that as soon as they arrive I will be able to start testing. The ECE course that helped me to develop this design is primarily 18-220 and 18-100, which gave me basic knowledge around using sensors and arduinos, supplemented by reading lots of tutorials about inertial measurement units on the internet.

Aside from working on the hardware components, I also assisted with making slides / graphics for the design presentation. Next week I hope to get the parts in, and hopefully start testing by the end of the week, but if they don’t arrive in time, I will refine the design for the foot pressure sensing unit. This is because at this time, I was focused primarily on getting the more critical back unit done(as this is somewhat a blocker for Jasmine’s work on back orientation detection until we know what data we will be able to collect).

 

Here’s a link to the sheet I used to plan parts. https://docs.google.com/spreadsheets/d/19h7SsfZl7L6Hj6JMvvSDONWY2HEp8ZFq5vFqzvN0bgU/edit?usp=sharing

 

Posted on

Sydney’s Weekly Status Feb. 11

To start off the week, I spent a good deal of time practicing and preparing for my proposal presentation. I refined my talking points to make sure it would fit into 12 minutes, as it was originally sometimes 15!

Having given the presentation, I spent the rest of the week researching sensor options. In my sensor research, I learned that you can only hook up a single MPU6500 combined gyroscope accelerometer to a Arduino at a time(there is perhaps a way to communicate multiple over the bus, but this is beyond my current analog device knowledge). With this limitation in mind, I decided to start looking at bluetooth enabled sensor units instead. This led me to two options, the MBIENTLAB MotionRL sensor for $110 per unit, and the WITMOTION sensor at about $50. While the WITMOTION sensor is cheaper, the MBIENTLAB sensor has much better documentation, and has clearly been used in developing other applications. It also includes a magnetometer, which prevents angular velocity drift. I believe this will be helpful in limiting potential data collection errors later on.  It also provides a much larger range of support than the WITMOTION sensor, allowing for low power consumption modes, and a battery life of up to 14 days. For this reason, I currently believe it is the clear choice. I am not currently behind schedule. Next week, I intend to actually order the sensors, as well as begin writing some code to communicate with the sensors so that once they arrive I can immediately begin experimenting with their functionality.

 

Link to reseach doc:

https://docs.google.com/document/d/1jEEZFMm4V-nKgTUkH4GX_SufVJgoKhpiRbq81Mextvg/edit

 

Posted on

Jasmine Yew’s Status Report for Feb. 11

This week, I worked on the wireframes for the app, so we can get a general understanding of what the app would look like and the potential features. In addition, I began working on the domain model and object model for the software. This will help simplify the process  of writing the software later on when we begin writing the backend. Overall, my progress seems to be on schedule and by next week, I hope to begin working on the software side of the frontend and have part of the feedback page done.

General paper prototype wireframe of our app
Current domain model of our app
Current object model of our app
Posted on

Team Status Report for Feb. 11

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.