Category: Team Status Reports

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?

1. For the seat module, one risk is the results of our current lean-detection algorithm being overly variable from person to person, due to different weights or ways of sitting on the seat. This risk is being managed by testing with many different people to see what the variability looks like and refine our algorithms accordingly.
2. In the neck module, one risk is the accumulation of errors over a longer work period. So far, the angle calculation has been tested by moving the sensor around over a short period of time, and keeping the sensor stationary (on a breadboard) over a long period of time to see if the angle drifts up or down. These tests have yielded positive results, but the system has not yet been tested on a moving user over a long period, which is what we will do this week. While the sensors have been calibrated for drift on a breadboard, this error is correlated with temperature so it may change as a user wears it for a long time. This risk is just being managed by testing. If we find that the angle calculations are indeed getting worse, we can implement a more complicated recalibration procedure (where the sensor offsets are actually recalculated). However, I doubt that temperature changes will be that problematic since we’ve worked hard to give the sensors good airflow and distance from the user’s skin.
3. Within the browser extension, one risk is the security concerns associated with running third-party code to display the graphs. This risk is being mitigated by sandboxing the code that uses this third-party code!

 

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?

1. Decided to handle all of the user<->neck system interaction on the Pi instead of offloading that computation to the ESP32 as originally planned. This was mostly a result of wanting to speed up debugging/testing time, as compiling python scripts on the Pi is much faster than compiling using the Arduino IDE, and this allows us to test the neck system in a wireless mode. The original plan to do more on the ESP32 was in place because I thought I would have to completely redo the sensor offsets each time the user wanted to recalibrate, but this turned out to be unnecessary. This change also reduces the amount of power consumption on the ESP32’s end and reduces the latency between user calibration command -> change in reported angles, so it’s overall a win. No extra costs incurred.
2. Changed the plan for laying out all the components on the hat. Originally the goal was to minimize the wiring between components, but this meant the hat’s weight distribution was awfully lopsided so I just worked on making the wiring neater. I also switched to using velcro to attach the pockets holding the parts instead of a more permanent attachment (sewing or superglue) to allow for some flexibility if I need to move something. No additional costs since I already had velcro.
3. Using a battery instead of a wall plug to power the circuitry for the sensor mat (not including the Pi). No additional costs as we also had batteries lying around. 

 

Provide an updated schedule if changes have occurred.

It seems we have arrived at the “slack time” of our original schedule, but we are in fact still in testing mode.

 

System Validation:

The individual component tests (mostly) concerning accuracy (reported value vs. ground truth value) of each of our systems have been discussed in our own status reports, but for the overall project the main thing we’d want to see is all of our alerts working in tandem and being filtered/combined appropriately to avoid spamming the user. For example, we’d want to make sure that if we have multiple system alerts (say, a low blink rate + an unwanted lean + a large neck angle) triggered around the same time, we don’t miss one of them or send a bunch at once that cannot be read properly. We also need to test the latency of these alerts when everything is running together, which we can do by triggering each of the alert conditions and recording how long it takes for the extension to provide an alert about it.

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?

1. Getting the different systems using the Pi to run at the same time and still meet our latency requirements. We are still working on unit testing each part but we will be putting the code together (hopefully) ~next week. If the system becomes really slow with the RPi bluetooth sender/receiver running, we’ll have to find places to simplify our code and the data being sent to the server at a time. Currently the latencies for sending just the foot sensor readings to the server and the extension reading data from the server are pretty small, so we are not too worried. Power draw may also be a concern when we have more computation being done,  since our Pi already gets wickedly hot before we even run anything. In terms of safety we can manage this risk by keeping the Pi very far from the user when we put the mat together. We thought about having some sort of casing to protect the user, but realize this would also worsen the heating problem.
2. Managing the bluetooth connection between ESP32 and RPi. Setting this up is taking a little longer than expected (at least as of the time of writing this team report – the work continues today…) due to some unexpected incompatibilities with some of the packages we tried to use. However, we’ve already successfully tested two-way communication from the ESP32 and the nRF connect app (just downloaded on a phone), and we’ve set up a BLE scanner on the RPi with compatible libraries to test today. If we completely fail at setting this up, we could try connecting to the server via Wifi directly to send/receive data. However, this is probably way more work than using bluetooth (and would likely destroy our power requirements) so this is more of an absolute-worst case plan. We also expect the BT to be figured out soon, as there is a decent amount of documentation on this.

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?

Instead of using a breadboard to do the wiring of the foot sensor mat, we’re using a protoboard with a 3/5V regulator + voltage divider circuits + pin headers soldered on. This was needed to make connections easier to reconfigure and keep our wiring more organized/scalable (even just connecting 2 foot pads using the breadboard was already pretty burdensome). No costs were incurred since we already had the protoboards from a previous project.

Provide an updated schedule if changes have occurred.

As of right now, no schedule changes are needed. Integration is underway to set up communication between all our components, though we are still also working on getting the data sent from each part to be what we want.

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. 

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.