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.

Cora’s Status Report for 2/15/2025

This week I worked on making a prototype browser extension. Specifically, I made a Chrome extension which I’m running in Chrome’s developer studio (this is where I’ll be testing it until we are finished then I will upload it to the Chrome Web Store so that others can download it). Currently the extension consists simply of a button which when pressed creates an alert in the user’s system tray. In the finished extension, the alert will occur when the data from the sensors indicate poor posture, but right now I just have the user press the button to demonstrate the system tray notification functionality. In addition, I created a script which allows the user to grant camera permissions in the options menu of the extension. This is important because we need the camera for the CV eye strain algorithm. This unfortunately must occur in the options of the extension and not in the extension itself because this is not an innate function of Chrome browser extensions.

My progress is on schedule. Next week I hope to add the CV script and see if we can run it in the extension (I know that Lilly has the CV script working locally but we have not yet tested it via the extension). I also want to set up the local server on the raspberry pi since we recently got possession of the pi we will be using.

Kaitlyn’s Status Report for 2/15/2024

This week, I focused on finalizing design choices, ordering parts, and creating the presentation slides/ document.  I spent a lot of time on the force sensitive resistors, because after our meeting with Tamal on Tuesday I realized it would make more sense to go with sensor arrays than with individual resistors – as this would lead to a lot of complicated wiring. I went with the following sensor array:

It is commonly used for measuring weight distribution when standing, and by using multiple of them, I can get a lot more measurement for the same price. Specifically, 1 individual FSR is  the same price as the 8 FSRs that come on this mat. I will not use all of the sensors (because I need to mux them in order to convert them to digital values), but I can play around with the different configurations of which sensor to use. As seen in the picture I am going to use 4 sensors from each pressure mat. From first glance, I want to use the 4 sensors in boxes, but based on testing I will do once the parts arrive, different mats will use different sensors. The current plan is to hook up 4 sensors through a voltage divider circuit into the ADC, which has an op amp amplifier. It will then get sent through I2C communications to the RasPi. I also spent time making the slides for the presentation this upcoming Monday. Outside of that, since we have our RasPi, I am also working towards putting the RasPi on the CMU Device network in order to host the server – this is a more complicated process than anticipated but I am working through it.

I am not behind schedule. This week, I accomplished ordering all of the necessary parts/finalizing BOM & beginning to start hosting the local server, which was what I wanted to accomplish. This upcoming week depending on when my parts arrive I might find difficulty finishing the work I want to do (a first test of the sensors and connecting the ADC) if the parts are delayed / the RasPi does not boot. To keep myself on track, I plan on continuing testing with a RasPi Pico in order to still be able to start writing and testing code for ADC and I2C this week, as this way I can stay on top of the sensor creation. It will also help me start working on the integration earlier.

Team Status Report for 2/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 risks that currently exist are making design decisions which would lead to more costly or difficult integration later on down the line. In order to mitigate this risk, we plan on buying duplicates of sensors, as well as purchasing backup plan sensors in advance in order to prevent any delay between switching to a secondary plan if it needs to occur. We also plan on meeting with our TA and advisor in order to discuss our design choices and understand the risks and challenges associated with our current design. This will allow us to make any necessary pivot we need before beginning to create the project. 

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?

No changes were made to the existing system so far, we have not yet solidified our design plan and thus any changes being made now are just us working our way towards a viable MVP. We have better solidified which sensors we will be using — Kaitlyn found the sensors for the chair, while Lilly researched gyroscopes for the neckband — and Cora completed research on which permissions will be necessary for our design to work on the Google Chrome extension platform. 

Provide an updated schedule if changes have occurred.

No schedule changes have occurred, we plan on creating the BOM and ordering parts this Monday, so we can begin to create and test our MVP as soon as possible. While the parts come in, we will work on setting up the RasPi and coding it in order so it can host a local server. We will then ensure we can connect to this server from an external network.

Lilly’s Status Report for 2/8/2025

This week I focused on researching components for the neck angle measuring system, mainly the gyroscopes.

While we were initially talking about using a gyroscope for tracking neck angle, I also researched inclinometers as another option since they can be used for angle measurement too, especially in steadier conditions. It seems that inclinometers on the market are mainly intended for industrial applications and are too clunky (I’m looking for something relatively flat to avoid disturbing the user) and expensive relative to our budget. So, for something wearable I continued to focus on gyroscope sensors.

As I researched, I looked into the potential of biaxial angle tracking, as forward neck posture is not the only way a user can experience neck strain after extended work periods. Most gyros have this capability anyway. I focused on options that allowed for angle tracking along at least 2 axes (sagittal and coronal) and researched the circuitry each sensor would need to work, with the aim of selecting a sensor with minimal circuitry and accuracy within our requirements, ideally much tighter as our initial goal of +/- 5 degree measurement accuracy is quite wide. Drift in the gyros also came up as a problem, which could be mitigated by doubling up the sensors – and would allow the band to be more symmetric in terms of weight on the user. I also researched/tested the range of angular velocities that our sensor would need to handle – a maximum speed of 200 deg/sec is what I looked for. Further, while an analog gyroscope would be nice so we can control the sampling rate/resolution better, I found that digital gyroscopes will be easier to find and use. A potential option is the L3GD20 gyro, which is small, has low input voltage requirements and a good-enough range.

I am on schedule for now. Further research on wearable batteries and gyroscope part selections will be completed tomorrow before our team meeting on Monday.

Deliverables for the next week:

  • Make purchases for neckband components after cross-checking with the team (Monday).
  • Research wireless connection between ESP32 + RPI.
  • Finalize design for how the neckband will be worn by the user.
  • Start drafting code for angle calculation with gyroscope data for the ESP32.

Cora’s Status Report for 2/8/2025

This week I focused on researching the browser extension. The browser extension is going to be used in order to allow the user to easily interact with our project and give them an intuitive UI to view their data and make changes such as toggle options for their camera being on/off and whether sound notifications are on/off.

I researched which browser would be best to make our extension for. I came to the conclusion that Google Chrome would be the best because of the thorough documentation that’s available, the APIs that Google provides, and its straight-forward development process. I researched what type of permissions we will need to ask the user for since the user being aware of what they’re installing is important to us. I wanted to establish the most minimally invasive permissions necessary so we’re not asking for more than what we need and compromise the user’s security. I established we will need at least the following Chrome permissions: audio (for audio notifications), notifications (for on-screen alerts), activeTab, and scripting (in order to adjust brightness of screen). These permissions will be listed in the manifest.json file which is part of the family of files that make up the extension. Note that the user must accept to all these permissions at installation time even if they later choose to disable related features. Otherwise, some permissions can be declared “optional” which is something I would like to discuss with my team to see if this makes more sense for our project.

My progress is on schedule for this week. Next week I hope to have a prototype extension ready in order to test out the basic infrastructure of our extension. I also want to begin with setting up the RasPi hosted server.

Kaitlyn’s Status Report for 2/8/2025

This week, I presented our Project Proposal to the other capstone teams and faculty. I spent ~2 hours preparing for the presentation to ensure we met all the needed requirements in the slide show, and to ensure that I could spend my time interacting with the audience instead of reading just off the slides. After presenting the proposal, I spent the rest of the week doing research into different sensors we could use in the chair. I was able to narrow it down to two types of sensors: Load Cells and Flexible Force Sensors. After putting some more thought into the overall integration, I think that using flexible force sensors (image of circuit I would need below) might be better in the long run to meet the user requirements of not impeding the user during their work, as they will not be as obtrusive on the chair. While I would need an opamp and capacitors for this circuit, I think the wiring could be done under the chair to be unobtrusive. As well, those parts are very cheap and easy to replace. Since we are using the RasPi, I also researched possible ADC converter modules for the RasPi in order to digitize the voltage inputs into the Pi. I hope this upcoming Monday to finish talking through this design choice with the team and order the parts necessary to begin creating a barebones pressure mat and testing it.

 

My progress is on schedule. This week, I wanted to complete research into parts for the pressure sensors so they could be ordered on Monday when our team next meets.

In the next week, I hope to create a much more in depth design of the chairs sensors. I hope to create a document that details exactly how the pressure sensors will be connected to the raspberry pi, and begin working on the code in order to create the averages for weight distribution on the chair.