Posted on

Team Status Report for April 29

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.

Posted on

Jasmine Yew’s Status Report for April 29

This week, I worked on the algorithm of our app. I’ve decided that the only way our algorithm would work effectively would be if we had a calibration period, so I’ve implemented and added a calibration page to our app.

A general idea of our back device’s algorithm

I am currently on schedule and hope to have tested our algorithm by the end of this week while also working on the final poster and report.

Posted on

Sydney’s Status Report for April 29

This week I mainly worked on figuring out how to turn our rudimentary visualization into something much cleaner looking using THREE.js. So far , I have not had much luck, as this is an area I have little to no experience in. I was eventually able to find a good example that I think I will model my code after. https://threejs.org/docs/scenes/bones-browser.html

The idea being that I will represent the spine as a cylinder, then have each quaternion apply a rotation to some points on that cylinder, such that we can see the bend / movement of the spine.

I also started to assist Rachel with the bluetooth this week. Unfortunately, I was not able to accomplish much due to other final projects being due, but I am hopeful that next week I will be able to realize my visualization goal. I am a bit behind schedule, as I was hoping to have the visualization done today, but I am confident that as my schedule clears up, I will definitely be able to get it done by early next week.

Posted on

Sydney’s Status Report for April 22

This week I finished implementing and testing the bluetooth. We made sure that it read the correct data, and started/stopped reading data at the correct times(when the user starts / stops  a set). I also worked on our final presentation slides. I also tested to make sure that our device works with the battery(it does, yay!) and it  can run for at least an hour, which meets our battery life requirements. I also finally got the visualization partially working on the website, as Jasmine was able to help me with transfering the data between pages. A picture of a visualization of the orientation of a single sensor is shown below. My next steps will be to create a visualization that represents the entire spine well. Via testing Iw as able to confirm that the visualization displayed matches the physical orientation of the sensor.

I would consider myself on track to be done by the final demo. This coming week I am going to continue refining the visualization and testing to make sure that it matches our expectations.

 

Posted on

Team Status Report for April 1

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.

Our updated schedule
Posted on

Sydney’s Status Report for April 1

This week I mainly worked on optimizing our libraries so we could both use the onboard DMP processing to get quaternions as well as the arduino BLE library. This was a real problem as our program as previously written was using 120% of the program memory space. Unfortunately due to problems around that we have yet to fully test the bluetooth integration(but this will hopefully happen tomorrow before the interim demo). But after spending a couple hours better understanding the libraries and removing functionality unused by our application I was able to get our program memory usage down to 99%. This progress is visible on our github. I also worked with Rachel a bit to decide on how to sew the devices together and make sure it matches our vision. We are just barely behind as we were hoping to have the data read to the web server by now, but I think after tomorrow that will be done, and then next week I will dive into working on the foot sensors and assisting Jasmine as needed on getting the detection algorithms working.

Posted on

Team Status Report for March 25

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.

Posted on

Sydney’s Status Report for March 25

This week I primarily worked on getting the IMUs working with the mux. I ran into a lot of problems with the IMU’s not being detectable once connected to the MUX, but after troubleshooting for several hours, realized that for whatever reason with the MUX, I was only able to read the sensor data if I decreased the clock speed for I2C to 100kHz. So I am officially ‘done’ with getting the back device working / reading data. My main goal for the upcoming week is going to be getting the bluetooth from the arduino to our webapp working so that the users’ data can actually be displayed / processed. Luckily, I am actually mostly caught up now. I still haven’t made any progress on the foot device, but after working with Jasmine to get bluetooth working I will get started on that. We were also able to get a bluetooth example working, so I am hopeful that converting the example to our application specific use case won’t take significant time.  Unfortunately because of the issues with the MUX, our placing sensors onto fabrics was delayed(as we wanted to make sure everything was working before committing to them), but that should happen without much problem next week) So in effect next week I am hoping to get the sensor data communicated via BLE to our webapp, and I am going to work with Rachel to get the sensors attached to fabrics so that it can be ready for the demo. I will likely also experiment with making sure the batteries we got provide sufficient power to our device.

Posted on

Team Status Report for March 18

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.

Our updated schedule
Posted on

Sydney’s Status Report for March 11

This week I primarily worked on the Design Review Report. This was helpful in forcing me to think even more about our design. I also placed the order for our batteries as well as the fabrics we are going to put the device on this week. Outside of the design report, I wasn’t able to get much done because I am still waiting for the parts to arrive. I am starting to get pretty concerned about this.  I am not sure that we have any back up plans for if the parts take much longer to arrive. Finishing this up at the end of spring break, they are still not in, so we will begin reaching out to the appropriate resources and potentially looking at ordering from a different vendor with rush shipping on Monday. We are falling behind schedule, but this week I will work on connecting the arduinos to the web app as we don’t have the IMU’s yet, which will let us get rid of some interfacing time at the end(hopefully).