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.

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. 

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.

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.

Cora’s Status Report for 2/22/2025

This week I attempted to do the blink detection algorithm and browser extension integration. Last week I was able to get webcam access in the browser extension with the intention of just integrating the blink detection script into the JavaScript of the browser extension. I ran into some issues trying to make this work, specifically Chrome no longer allows remote script to be executed with the release of Manifest V3. I proceeded to install opencv.js locally and uploaded it with the browser extension files but still ran into issues since opencv.js uses eval which Chrome prevents from running even when calling local code. So I’ve abandoned the idea of running the blink detection algorithm via the extension and instead decided to get it up and working with a simple web app then once that is working properly have this web app store the data from the blink detection algorithm in a cookie in the user’s browser and then have the extension read the cookie and display the data.

I definitely wanted to be able to get the blink detection algorithm done this week, but don’t think this makes me behind quite yet. I think if I can’t figure it out next week I will consider myself behind. Ideally I also get the automated screen brightness adjustment feature of the extension done next week too since I should not run into security issues with this because it does not require installing a library like opencv.

Team Status Report for 2/22/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?

This week we received the sensors that we ordered and Kaitlyn and Lilly tested them each individually to ensure that they work. This upcoming week we are beginning to connect sensors and microcontrollers and start small amounts of integration, which if unsuccessful will be the thing that will jeopardize our project the most. These risks are being managed by slowly doing integration, i.e. one device at a time so if there is a problem then we can more easily determine where it is coming from. On the software side of things, the most significant risk at the moment is not being able to run the opencv library due to security issues with the browser extension (i.e. Chrome’s disabled running remote code in Manifest V3). A contingency plan in place and that Cora is currently exploring is running the blink detection code on a web app then having the web app communicate the data to the browser extension.

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?

We do not have changes on the hardware side. For the browser extension we will likely have to slightly change the flow of data: web app will run remote code (i.e. opencv.js library) -> store data in cookie -> browser extension reads cookie -> extension displays data which is different from our original plan of having the browser extension both running our blink detection script and displaying data. This change does not incur costs but may affect latency delays which is of concern to us since we do not want there to be too significant of a delay between the time when the user exhibits poor posture/eye strain to when they actually get a notification that they are exhibiting these symptoms.

Provide an updated schedule if changes have occurred.

We do not have significant design changes thus our schedule remains the same.

Lilly’s Status Report for 2/22/2025

Items completed this week:

  1. Tested the ESP32 microcontroller to make sure it worked alright (could be flashed with an example program, didn’t overheat). Researched different development environments (PlatformIO, Arduino) but ultimately decided to stick with the Arduino IDE for simplicity and ease of connecting to our specific microcontroller. I initially had concerns about the compiled code size using the Arduino IDE vs. other platforms but there should be more than enough memory on the board to handle this!
  2. Presented our design review to the class.
  3. Soldered pin headers to the ESP32 and the LSM9DS1 sensors so I can start breadboard prototyping and setting up I2C communications between them.
  4. Researched how to set up the BLE connection from the ESP32.

The I2C setup will hopefully be done tomorrow (on Sunday)! Along with connectivity checks for my soldering… Otherwise I’m pretty on-schedule, especially since I have all the necessary parts now.

 

Deliverables for next week:

  1. Finish up the design report.
  2. Test sending data over BLE between RPi and ESP32.
  3. Code up initial filtering/data processing algorithms for the gyro sensor data.
  4. Design mounting system for hat.

Kaitlyn’s Status Report for 2/22/25

This weeks deliverables: 

This week,  I worked on the Design Paper which is due this upcoming Friday. Specifically, I worked on improving my block diagrams and making a much more in-depth Gantt chart that we could add to the report.

I also worked on the RasPi and the seat pressure sensors this week. I was able to re-flash Debian onto the Pi and get it connected to the CMU Device network. After that, I installed and configured nginx so that the pi is now hosting a very basic website: 

I was also able to assign it a static IP so that it can be accessed from other networks, so we can test while not on CMU wifi.

I also focused on the sensors, which arrived on Thursday. Since they arrived later than anticipated, I was able to conduct a preliminary test, just to ensure they were working as anticipated.  This was done just using a multimeter and a basic voltage divider circuit. Now that I know that the sensors work, I can focus on wiring them up to the ADC. I was also able to find better documentation on the adafruit ADC I purchased, which help me write some preliminary code to connect the ADC to the rasPi.

 

Progress:

Due to the late arrival of the parts, I am slightly behind schedule on connecting up my sensors to the rasPi. I plan on working a bit extra on the project this week in order to catch up, and anything I am unable to do this week will also be worked on over Spring Break to ensure that I come back ahead of schedule or at least on time.

Deliverables:

This upcoming week, I am focused on connecting the ADCs, RasPi, and the sensors all together. I want to have the code written which can analyze the pressure of the person and at least return a digital value which can be used for further analysis.

Lilly’s Status Report for 2/15/2025

This week, I completed the following items:

1. Researched, finalized, and ordered materials for the neck angle-calculation module. These included the gyroscope/accelerometer module, an ESP32-C6, and a battery to power these components. I also researched the communication protocols that I will need to configure and use to send data from the sensor to the ESP32 (I2C), and from the ESP32 to the main microcontroller (BLE).

2. Researched objective measures for determining poor neck posture. I hope to implement an approximation of craniovertebral angle, which is actually used for diagnosing forward head posture, but this will require good positional calculations from the accelerometer, which may not be feasible. To achieve this, I researched methods of improving calculation accuracy for angle/position, including Kalman filtering. An alternative threshold for neck strain is simply a 15 degree downward rotation of the neck.

3. Updated the design of the neck module to use a cap/visor instead of a neckband to improve wearability, comfort, and ease of component layout.

 

4. Tested and did initial calibrations on the OpenCV Python script that we will be adopting for the blink detection part of this project. From this testing, I confirmed that rudimentary blink detection worked, and identified areas that we will need to improve upon and modify to meet our use-case requirements. These included support for single-eye blink detection, ensuring that our rate-calculations do not factor in time where neither eye is in view of the camera, improving functionality in dimmer lighting, and improving landmark detection for glasses-wearers. However, as difficulties with running a Python script from the browser extension arose, Cora will be working on converting the script to JavaScript using OpenCV.js.

5. Prepared slides and presentation for the upcoming design review. 

A couple of my deliverables from last week were not completed unfortunately (figuring out the Bluetooth implementation between ESP32/RPI, and drafting code for gyroscope calculations), as I spent much more time than expected on researching and selecting a microcontroller, and working on the design review presentation. However, these two items would be more effectively completed with the parts in hand, so this isn’t super detrimental to our schedule.

 

Deliverables for next week:

  • Present design review and write design report.
  • Set up the development environment for flashing the ESP32.
  • Research how to implement bluetooth communication between ESP32 and RPi. If ESP32 arrives on Mon/Wed, work on actually setting up this connection too.
  • If sensors arrive as well, start setting up the I2C interfaces and test sensor reliability.

Team Status Report for 2/15/2025

PART A (Cora) 

In regards to health, StrainLess has the potential to improve peoples physiological health. It is well established in the medical community that poor posture causes back pain and that staring at a screen for extended periods of time causes eye strain. With StrainLess, users receive an alert when they are exhibiting poor posture/eye strain which remind them to correct their posture and/or take a break from their screen which builds healthier habits and will therefore help them feel physically better. Psychologically, physically feeling better helps people have a better mood. Especially with things like chronic back pain and headaches associated with prolonged computer usage, which can negatively impact peoples’ emotional wellbeing. In regards to safety, StrainLess will be built with the user’s safety in mind. Specifically, we are ensuring that the electronics are safe and do not get too hot and burn the user’s skin by testing our product. We also are using bluetooth for communication between devices to prevent cords from getting caught. In regards to welfare, StrainLess helps meet the basic needs of people living in modern society because for many people working 9-5 jobs they are sitting at a desk and this is our target demographic for StrainLess. StrainLess will help these people reduce their back pain and eye strain.

PART B (Kaitlyn)

StrainLess is meant for people across different organizations. Our product is meant to help anybody who works at desks for extended periods of time, whether that be office workers, gamers, college students, or anybody else. We want our product to be available to those people who have difficulty maintaining good habits while sitting at a desk. Our solution approach also attempts to be as affordable as possible, so more people can use our product. We also did not want our solution approach to have any negative social impacts. In order to achieve this, we are ensuring that there is no personal data being stored about the user, and that every individual user gets the same experience. We increased our weight range to ensure as many people as possible could use the pressure sensors, and chose a CV model which is trained on a very socially diverse data set in order to ensure accuracy in CV across the entire range of users.

PART C (Lilly)

With respect to economic factors, StrainLess can improve office productivity – and therefore revenue, hopefully – by reducing the strain associated with working at a desk for long periods of time. While it would be ideal for people to not have to work at a computer all day, this is often unavoidable, especially with the rise of remote, work-from-home jobs. Since people can become very focused on their work sometimes, it can be easy to forget to take breaks, or remain in an ergonomic position for a long time, leading to severe pain when these habits persist for weeks or months. By providing gentle alerts that make the user aware of strain-inducing behaviors, we can help people mitigate eye and muscle strain – all while allowing them to continue being productive, as our system tray notifications do not require the user to stop what they are doing to manually shut them off. It’s often difficult to work when in pain, or suffering from “computer vision syndrome” (blurred vision, headaches, dry eye), so prevention of these issues is key to improving productivity. In the long run, users will also financially benefit from StrainLess as they can save money on doctor’s visits and medical items (e.g. braces) by building better work-health habits. 

RISKS + CONTINGENCIES

One of the most significant risks that could jeopardize the success of our project right now are delays in receiving our parts, as many of our next tasks cannot proceed without having the physical components to test. We are managing these risks by attempting to get as much done as we can with the parts that we do have so we are ready to go when the rest arrives. Specifically, we are working on setting up the local server on the Raspberry Pi that we already have so we can get to work on setting up Bluetooth and a server request system for the ESP32 and browser extension, respectively. Another risk we are facing is poor sensor reliability, specifically for the gyroscope modules, when they come in. As a contingency plan, we may have to incorporate multiple different sensor values into our calculation algorithms, as is done in Kalman filtering, for example. Our last potential risk is difficult with setting up the connections for the pressure mat, as the datasheet available online is somewhat sparse. To mitigate this risk, we have requested further documentation from the company and have been successful in receiving responses so far.

PROJECT CHANGES

Two main design changes have occurred since last week. 

  1. We have switched from buying individual pressure sensors and arranging them into an array ourselves, to buying a pre-wired pressure sensor mat, intended for feet. This change was necessary because the sensors we were initially looking at were very expensive (and had fewer sensors) and would require many more pins to connect to on the main microcontroller.
  2. Instead of a band going around the neck of the user to implement neck-angle calculations, we have decided to mount the gyroscopes, microcontroller, and battery onto a cap or visor. This was necessary so we could fit all our components onto something more wearable and comfortable. Also, since most of our components for the neck angle module operate optimally at 25 degrees Celsius, having the band so close to the wearer’s skin – on one of the warmest parts of their body, and potentially insulated by long hair – would have been problematic. This also helps with safety concerns relating to overheating components in contact with the user’s body, and allows us to slightly raise our weight requirement for this module since we can afford to put more items on a hat than a small band. This hasn’t caused us significant extra costs, as we would have had to buy a neck cuff to mount our components on anyway. A short-billed baseball cap or visor is likely to be similarly priced.

SCHEDULE

Although there were design changes, our schedule remains the same as we expect to get some of our parts this week.