Category: Kaitlyn’s Status Reports

This week, I continued to verify the seat module, as well as improve the code/design I already had. First, I created a cover and attachment for the seat module. This is a cover for the plastic sensors, which are located inside. I then tested to ensure that the cover does not change the outputs of the pressure sensor readings, which it does not. I also ensured that the straps which hold the cover in place are adjustable using velcro, meaning that the cover can be moved between chairs if need be.  I then created a casing for the RPi5 and the wiring for the seat module. This is to ensure there is a much smaller tripping hazard, as well as keep all of the wiring safe and isolated from the user as much as possible in order to prevent any potential shock.

 

 

 

 

After that was complete, I also ensured that the way we were saving baselines was modified to remain consistent with the rest of the teams – this meant ensuring that a baseline could be saved multiple times in the span of one work session without needing to completely restart the program.

I also wrote a simple bash script which will start up all of the different modules in the program (the neck sensor, lean sensor, and server) in order to ensure we make our solution as easy as possible for users.

Lastly, I began testing the seat module with different people. Right now, I was only able to get one person to test, and I saved all of the sensor data to a csv file. I will be using this data (plus that of other peoples) to continue modifying the algorithm for detecting a lean to make it more robust.

Attached is a brief video which shows how the sensors change when someone else is sitting on the chair.

I would say that I am definitely on track to meet the deadline for our project. I have finished the creation completely, as well as all integration I need between components for the module I own. All I have left to do is to continue testing and make any iterations I need based on the results. This next week, I hope to move into more testing and validation in order to show that the seat module is robust.

Now that you have some portions of your project built, and entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have run or are planning to run. In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?

I will continue to run tests on how accurate the lean data actually is. For this, I plan on going to techspark and using calibrated weights that will be placed on the sensors as a person is sitting in order to simulate a lean. I will then see how much weight needs to be shifted in order for a lean to be registered. I also will leave the weights in each position for 10 minutes – to ensure that the averaging of data will still detect a lean even after an extended period of time. This will ensure that any noise did not impact the overall performance of the module. Like previously mentioned, I do not think it will be 0.5 lbs, but I do think it will be much better than I originally thought. This is due to the averaging of all the sensors, plus a change in the actual lean detection algorithm.

I will also have a bunch of different users sit on the chair and simulate leans in different directions, to ensure that I am able to catch leans on people who are not me. Since I mainly used my data when making the algorithm, I will probably have to make some minor changes. I will also be saving the data points of each person to a csv file to analyze and use for possible changes.

I will create a google form for these users to fill out, which will just ask the user how comfortable they found the seat module, if it interfered with how they were sitting, and if they found the module accurately detected when they leaned. These will be rated on a scale of 1-5, with 5 being the most desirable outcome.

I will also myself just use the chair while working for around an hour, while saving the data. I will also video myself from the side, which should help me see when I actually lean. I will then compare the results from the saved data with the video timestamp to ensure that I accurately detect when I am leaning. This should give some extra data I can use to ensure the algorithm is correct.

 

This week, I continued work with Cora on integration of the sensors with the browser as well as creating data to help visualize and test our project in the future. I was able to hook up the seat pad to a seat and have a friend demonstrate different types of posture (baseline, front/back/side lean).

More specifically, I first worked on making a more permanent wire solution for the seat module. Since the wires from last week were all over the place,  I have broken them apart and taped them in such a way to prevent any open wire, as well as ensure that they do not fall out when the chair is in use.

After that, I calibrated the sensors themselves. I have changed the sensor positions from their first iteration to a different configuration: 

On the left is the before, and on the right is the after. This new configuration better takes into account how the shifts in weight are mainly seen in the outside of the chair, and uses that in order to make the necessary calculations.

Furthermore, I began working on a visualization tool that we will use for both the interim demo and for data collection in order to meet the testing requirements of the design. This includes plotting over the past 10 minutes the data we are getting from each of the 16 sensors coming through to the PI. This information will be used in order to demonstrate what we are doing with the data from the chair sensors.

Lastly, I ensured that the data being sent to the server was processed on the Pi, and only a size 4 1-bit array of lean data was actually sent to the extension in order to decrease the overall latency of the server.  This is instead of a size 16 integer array, which would have much higher latency both to send and to process on the front-end.

I think I am on track, especially since I plan on doing a lot of work tomorrow (Sunday 3/30) on our project. I plan on finishing up the plot, testing with a couple of people, and ensuring that the seat module is fully ready for the interim demo. However, as previously mentioned, the data I am getting does have some variance, so I am also planning on spending this week implementing a SW filter and some averaging in order to determine whether a lean is occurring or if it is just noise.

This upcoming week, I hope to continue testing the module. Then, I will shift focus onto helping Lilly and Cora with their respective modules, as well as doing the overall integration of all of the sensors to make the module look more presentable.

Unfortunately, I did not take a video of the data being processed and sent, but when on campus tomorrow I will take a video and upload it here.

This week, I continued to integrate the sensors with the web extension. I initially ran into some issues with the voltage readings through the ADC to the RPi being inconsistent, but I was able to debug the soldering I did and modify some resistors to ensure that no voltage over the max 3.3V limit was ever being sent. I also had some problems with a faulty ground connection, which I debugged. Furthermore, I worked with Cora to begin integrating the sensor data with the extension. We currently are able to send and receive data on both ends. The next step for this is to send Cora only the calculated lean data (left/right/front/back) to ensure that the latency is minimized.

Another thing I did this week is ensure that all the data being sent was as accurate as possible. I worked with 2 mats and figured out the range of voltages that were needed in order to detect a lean. Since as my previous report mentioned, they are definitely not 0.5 pound shifts, I will work on modifying my algorithm of analyzing the data to still produce the most accurate data to send to the users.

A photo of the data I am getting when 1 sensor is pressed. Voltage from unpressed sensors is very variable (between .6 and .02 V), so a detection of 0.5 pounds is unfeasible. However, an overall lean detection is still feasible.

My progress is still on schedule, as I expect my integration with Cora to be finalized by the end of this week, which is in time for the demo day. I do not think the mat will be as presentable as it will be for the final presentation, but it will be functional enough.

This upcoming week, I hope to finalize integration of the mat with Cora, by sending finalized lean calculations instead of raw data. I also plan on integrating some pauses in my sending of data if I detect the user stands up, so they do not get any excess notifications occurring. I also plan on having a friend help test the mat with all 4 sensors, to ensure that the basic lean functionality does not present false data.

This week, I tried to finish up working on developing and testing the pressure sensor mat. The first thing I did was connect up the pressure sensors to the RPi/Mux/ADC combination, to see if the readings I was getting made any sense. Once I ensured that this was the case, I was able to focus on testing how they detected lean. Unfortunately, I ran into some issues with the gpiozero library. which took a decent amount of time to resolve. One thing that we figured out is that the bluetooth libraries and the adafruit libraries are not fully compatible, and therefore we might need to have the code for the two different components running in two different virtual environments.

In the second half of the week, I focused a bit more on testing. i changed out the resistors in the voltage dividers, testing different configurations until I was able to find a resistor which provided a low enough input current to the MUX while also simultaneously giving decent granularity in voltage values.

Another thing I realized when testing is the fact that the voltage outputs of the pressure sensor do fluctuate slightly, even under the same conditions. For this reason, we will require further testing to see if the 0.5 lb granularity can be supported by these sensors.

Once I figured out the best combination of resistors (I went with 147 kOhm), I then decided to make a protoboard to hold all of the resistors and wired connections. While the breadboards were good for initial testing, they are too bulky and prone to disconnections to be used in the long run. The main reason we decided to go with a protoboard over a PCB is the common availability of all of the parts that we needed, as well as the timing. I was able to solder the protoboard over the span of Friday/Saturday with components I had on hand, while holding a peer design review and then sending the PCB out for fabrication will take significantly longer.

Finally, this Saturday I worked with the entire team to begin integrating the design. We were able to get the sensors communication with the server, and the extension was also able to send requests to the same server. We also figured out that the latency problem we were having before was a result of a shorted wire between two of the connections, as now the time between input pressure on the sensor and the server response is below 0.5 seconds, a vast improvement to what it was.

I am on schedule. I am finishing up the pressure sensors and am in the midst of integration, with constant design edits and updates as we find improvements to the system.

Over the next week, I hope to continue integrating the sensors. I want to work with Cora to ensure the data that she is receiving is accurate, and use the data I analyzed during testing to write some algorithms in the web app to analyze the sensor input and detect lean. I also want to make a much more stable and sturdy mat for the sensors, as right now it is just a plastic bag with sensors taped on.

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.

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.

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.

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.