Author: ldas

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.