Posted on

Lilly’s Status Report for 3/8/2025

Items done:

  1. Wrote/tested initial angle calculation + user calibration code for the ESP32. Changes in angles reported are broadly correct but a lot of refinement is needed to make this usable.
  2. Finished the design report, which ate up most of the week before break.

 

Unfortunately my progress is a bit behind schedule, as I had aimed to have written and tested a basic BLE script for sending data between the ESP32 and RPi by now, and have a more stable version of the angle calculation code as well. I think the angle calculation code shouldn’t take too long since I know what I want to implement to fix the drifting values, so I will likely have enough time this week to figure out the RPi communications after coming back from break and getting a midterm over with. I had also wanted to put in an order for the non-electronic hat parts before the break, but this will be done on Monday now. We may also use a random hat we have, and fabric from Techspark to prototype for now if these parts do not arrive soon.

 

Deliverables for next week!

  1. Add complementary filtering to the angle calculation algorithm, and try offsetting drift values in the code. Also see how much the data improves from averaging over two sensors to decide if this is worth doing.
  2. Write BLE script for the communication to the RPi and set up calibration flow in the code (need to work with Cora for UI parts).
  3. Order a hat and mesh fabric for the wearable parts.
Posted on

Team Status Report for 3/8/2025

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

The most significant risk is currently the integration between the sensors and the browser extension. Specifically, sending signals to and from the extension to the sensors, and this updating the workings of both accordingly. These risks are being managed by working on this integration early – the local hosted server is already set up and the requests to / from the sensors to the server have already been implemented. We plan on working this week on integration, and dealing with any challenges as they come up, specifically being able to pivot from the Node.js which we are currently using to flask if needed to ensure the integration works.

 

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

A change was made to how the sensors are interacting with the RPi. Due to a discrepancy found between the datasheet and the ADC parts, we found that we could not use 4 adcs are originally intended. Instead, we are using a 16:1 MUX and a singular adc, and selecting which input from the mux to read, then forwarding that to the ADC and then the Pi. This did not incur any costs, as one of the team members was able to scavenge this mux and therefore we did not need to order anything.

 

Provide an updated schedule if changes have occurred.

As of right now, no schedule changes are needed. 

 

Part A was written by Kaitlyn:

With consideration of global factors, StrainLess can impact people outside of Pittsburgh. Since the product can be easily reproduced, it can be used around the globe, not only at CMU. Anyone with access to Chrome is able to download our extension, and making / potentially buying the pressure mat which comes along with it is feasible. Even with people who are not technologically savvy, after having installed the browser extension they will have a very friendly user interface with charts and graphics which are easily understandable. As well, people who are not in an academic environment can still use our product, as it is meant for anyone who spends time at a desk – this could be office workers, gamers, or people who work from home.

 

Part B was written by Cora :

StrainLess will support the 9-5 work culture that exists in the United States by improving the quality of life of those who work at a desk. Being hard-working and self-sufficient are core beliefs held by people from the United States that many people feel define who they are and StrainLess will be conducive to this way of thinking by reducing the pain of these people that they likely feel they just need to deal with as part of their lives. StrainLess’s UI will be in English, but with intuitive controls and notifications so even if people do not speak English if they have a good idea of what the product does, they will still be able to use it. Regarding laws, StrainLess does not break any laws and in fact could improve workplace safety if implemented in an office setting.

 

Part C was written by Lilly: 

The main environmental goal that StrainLess supports is waste reduction by not having disposable parts in our final user product. While we also are designing our wearable parts to use low power, this is more for safety and functionality than environmental considerations since the magnitudes/scales for microcontroller power consumptions overall are very small. But, we have avoided the use of any disposable components in our product by using rechargeable batteries instead of single-use ones, making sure to include a charging port on the microcontroller board so the user does not have to acquire more materials to charge. All other components are powered by a wall/outlet supply or are just run on the user’s computer’s battery so they would not require any disposable power supplies either. Although LiPo battery recycling exists, it’s not available everywhere, and reduction of resource consumption in the first place tends to be more sustainable than recycling since the recycling process in itself is imperfect and takes up a lot of energy anyway. This reduces our product’s (negative) environmental impact by not requiring the user to have to dispose of batteries, which can be very toxic to the environment if done haphazardly. 

Posted on

Cora’s Status Report for 3/8/2025

This week I focused on getting the CV working with the web app. I’m able to get it working no longer using OpenCV but tensorflow, since there was a convenient npm package that I was able to download and use that had the functionality that we were looking for. Currently, the web app is ran locally and when ran counts the number of blinks the user performs in a 1 minute interval, which I think is a good demonstration of the functionality that we will need for our final product.

Next week, I would like to get the web app communicating with the browser extension and be able to display the blink count on the extension instead of just printing it to the console. I would also like to create and implement the screen dimming mechanism of the extension, which will automatically dim the tab that the user is currently on if they are in a dark environment. The primary thing I’m concerned with here is how I will get the ambient brightness data from the webcam and how accurate that data will be. I’m on time this week since I was able to figure out the CV and I anticipate the screen dimming will not take long so looking forward if I hope to get that done next week which leaves ample time for the integration with the Ras Pi server which I anticipate will take the most time.

Posted on

Kaitlyn’s Status Report for 3/8/2025

This past week, I continued work on the teams design report submission. I spent a considerable amount of time working on different parts of the report, formatting, and proofreading in order to ensure that our report met all necessary criteria and can carry over to the final report submission.

I also spent time working on the pressure sensor. I wrote all necessary code in order to connect the 16 sensors to the RPi. However, I then had to pivot in order to deal with the fact that there were only 2 addresses possible to be used with the ADCs instead of 4 as originally planned. In order to counteract this, I was able to find an analog 16-1 MUX, which I then attached to one pin of one ADC. Now, instead of using 16 different pins of the different ADC, I will be using one pin of the ADC, and using gpio outputs of the RPi as the select lines to the MUX, which will allow me to iterate through all 16 sensors. Furthermore, I began looking into the script necessary to send the data to the RPi server. In order to do this, I found that we could either use node or flask. Since Cora is more comfortable with node, and I do not have much experience with either, I have started writing the necessary http requests in order to send the data to the server. Our pivot plan in place is to switch to using flask if that leads to easier integration.

My progress is on schedule, as I used this break in order to catch up and finish up the preliminary work on the pressure sensor. After some more thorough testing to ensure it detects proper weight shift, I will sow up a mat in order to make it more movable / less obtrusive to the user.

This week, I hope to finish up testing of the pressure mat, and also work with Cora and Lilly to integrate sending the data to the server, so everyone can work with their necessary components of the project. I also hope to run some timing tests on the mat in order to ensure that it still meets latency requirements.