Posted on

Rohaib’s Status Report for 10/10

This week, I focused on refining the desktop app UI design and software documentation for the design report (adding control flow diagrams + high level architecture). Building on the BLE research and interface scaffold, I organized the Python/PySide6 interface around live upper and lower-back readings, baseline calibration, and adjustable angle and duration thresholds. Settings changes require an MCU acknowledgment, while feedback decisions remain on the wearable.

The app is currently being tested with simulated angle readings (randomly generated), including individual and combined regional deviations. These scenarios let me check the live displays, calibration controls, and settings acknowledgment flow before connecting to hardware. I also refined the proposed guided calibration process, which will let users trial their thresholds by turning left, turning right, and stretching backward. With the updated single-motor design, the desktop will identify which back region exceeded its threshold.

My progress is on schedule with the software design and initial prototype. The current implementation supports continued UI testing while preparing for hardware integration. Real BLE communication and E2E performance still need to be tested (but our timeline for this fits into the first week of November).

Posted on

Team Status Report for 10/10

This week, our team focused on completing the design report, refining the requirements and implementation descriptions, and generating graphs and figures to explain the architecture and prototype. This helped align our hardware, firmware, and desktop application plans.

Our main risks remain reliable posture measurements and hardware integration. Sensor placement and movement could affect accuracy, so we will evaluate mounting stability, calibration, and filtering through repeated testing. We will also test communication with the IMUs and check whether motor vibration disrupts readings. If communication becomes unreliable, we can reduce the I2C bus speed or revise the wiring. The existing breakout-board prototype will allow testing to continue if PCB fabrication or debugging causes delays.

We clarified that posture is measured as regional angular deviation from a personalized baseline. We also documented the choice of one lower-back haptic motor instead of three localized motors, reducing wiring and component complexity. Although vibration will not identify the affected region, the desktop interface can provide that information.

Our overall schedule remains unchanged.

Section A: Rohaib

PosturePal addresses the need for posture awareness during prolonged seated work, a need that extends beyond students in Pittsburgh to people working in offices, studying, or using computers at home. These users may have different body proportions, preferred sitting positions, and levels of technical experience. The adjustable vest and personalized calibration are intended to accommodate these differences rather than assume one fixed posture is suitable for everyone. Configurable thresholds also allow users to choose how much deviation should trigger a reminder. To support users who are less technologically familiar, the interface should provide straightforward calibration instructions and clearly explain what each setting controls. Haptic feedback makes reminders available without requiring users to continuously watch a screen.

Section B: Carys

Different communities and workplaces have different expectations regarding clothing, personal comfort, and the use of wearable devices. PosturePal’s vest must be something users would feel comfortable wearing in their daily environment. Adjustable straps and a as-small-as-possible electronics assembly are used to make the device easier to incorporate into everyday clothing. The haptic reminders also provide a discreet form of feedback that can be used in offices, classrooms, or libraries without creating an audible interruption; instead, it is felt through a buzz. Also, because definitions about “good posture” can vary, the system uses a user-selected reference posture and provides feedback about changes from that reference. This approach gives users control over their settings and avoids presenting one posture as a universal standard.

Section C: Allison

PosturePal’s environmental considerations include battery use, electronic waste, and the materials needed to construct the wearable. The rechargeable lithium-polymer battery supports repeated use without requiring frequent replacement of disposable batteries. However, the battery and other electronic components will eventually require appropriate disposal or recycling. Keeping the electronics removable from the vest would make it easier to repair individual components and separate the textile and electronic portions at the end of their useful lives. Our decision to use a single haptic motor and driver also reduces the number of components and associated wiring compared with a three-motor design. During PCB development, reviewing the schematic and routing before fabrication will help reduce avoidable board revisions and material waste.

Posted on

Allison’s Status Report for 10/10

This week, I primarily worked on the PosturePal design report and generated graphs and figures to support the explanations of our system. I revised the hardware architecture and implementation sections to describe how the IMUs, I2C multiplexer, microcontroller, and haptic driver connect and work together. I also helped clarify how the system measures regional posture changes relative to a calibrated baseline and how our design requirements will be evaluated during testing. A significant portion of this work involved making the report understandable to someone unfamiliar with the project, including explaining our component choices and the tradeoffs behind them. I worked on organizing the report in LaTeX, formatting equations and figures, and reviewing the text for consistency between the requirements, implementation, and validation sections. The updated design report and accompanying graphs and figures document this week’s progress.

Overall, I think our progress is on schedule. This week was focused heavily on completing the design report, so most of my work involved documenting and refining our design rather than advancing the physical hardware. Writing the report also helped identify details that need to be checked before finalizing the PCB, particularly the connections between the sensing, power, and haptic subsystems. My next priority is to translate those design decisions into the board layout and keep hardware development moving forward over break.

Over break, I plan to work on routing the PCB. I will first review the schematic and component placement, then route the power and signal connections while accounting for connector access, cable organization, and how the board will fit into the wearable. I also plan to check the layout for routing errors and review the connections against our prototype before preparing it for fabrication. My goal is to have a routed PCB ready for team review so that we can address any remaining issues before ordering the board.

Posted on

Carys’s Status Report for 10/10

This week, I worked to integrate feedback from our Design Presentation and Weekly Lab Check-in, specifically regarding our calibration process. Rohaib and I iterated our calibration process so it still includes the user setting their initial baseline, both for their upper and lower back posture orientation, as well as their feedback threshold for position/angular change over a specified time, but now also includes the desktop app guiding the user through a series of movements to confirm this threshold. The idea is that having users turn left, right, and then stretch back allows them to complete “basic” or “everyday” movements and determine whether their current threshold settings will notify them of worsened posture, and whether they would like that to happen.

Additionally, as a team, we met with the CMU PhD student in HCI I contacted, who has completed research on posture modelling. He recommended having the user define their “good” vs “bad” posture, which we were already planning to do, and suggested allowing the user to adjust their feedback threshold throughout PosturePal use. We had not originally considered this idea; however, we agree that implementing it would allow users to better specify their haptic feedback throughout use, building on the desktop-app-led initial movements to trial the user’s set threshold.

I believe I am on schedule. I am hoping the vests we ordered last week will be delivered over Fall Break (as unfortunately they were not delivered this week), so I can begin editing and reassembling them once I am back. Especially since this week Allison was able to trial connecting two IMUs to the MCU and demo angle changes with cardboard, triggering haptic feedback. As a result, after Fall Break, the next step is to build the vest, trial-attach the IMUs to it, and see how PosturePal handles actual spinal changes.

Posted on

Rohaib’s Status Report for 10/3

This week, I began implementing the desktop app using Python and PySide6, focusing on the Bleak interface scaffold and UI design. I separated wearable communication from the interface so the app can run on simulated MCU readings (while we are working on our hardware development). The scaffold covers connection, notifications, settings writes, and disconnection. I also implemented simulated settings acknowledgments, ensuring changes are only marked as applied after a matching response. Feedback decisions will remain on the MCU so reminders work independently of the app.

The UI includes a mocked 3D posture visualization, separate upper/lower regional angle readings, calibration, and configurable feedback thresholds. I also added SQLite session summaries and initial tests for data validation, acknowledgment handling, and persistence. Real BLE communication has not yet been tested.

I am on schedule with the initial software prototype. Next week, I plan to finalize the MCU message format and BLE configuration, document these decisions in the design report, and prepare the app to receive hardware data.

Posted on

Team Status Report for 10/3

Once our first order of parts was delivered this week, we began soldering and testing various components. For example, Allison was able to set up one of our haptic feedback motors and test it. However, upon testing, we realized that the feedback given is quite faint and could be non-noticable to a user unless the motor is very close to their body or they are wearing a shirt with a thinner material (the person the motor was tested on was in a hoodie). This, coupled with a question we were asked in our Design Presentation about our vest design and component integration, made us question how we would make the vest adjustable so that the IMUs and motors sit as close as possible to the person and provide noticeable feedback. As a result, we spent time this week improving our vest design (and therefore this was a part of our design that was changed this week), considering how we could edit it to make our haptic feedback more easily felt. Therefore, one of our current risks is determining how to design our vest to make this haptic feedback noticeable, but feel we have mitigated it with this initial test, supported by continued testing and vest design iteration where possible. We believe this design change will add no extra costs or latency to our timeline, as we have already built in time for testing and iteration in our schedule. We have ordered two vests, which we plan to edit to construct our current vest design, and are currently waiting for them to arrive.

Next week, we plan to prototype the IMU and MCU setup to gather initial data as a proof of concept for our design. This way, we have baseline information to begin our design and specifications for our Design Report while we wait for our vests to be delivered, and we can then begin further development and integration.

Posted on

Carys’s Status Report for 10/3

After completing the design presentation this week, I worked to implement and think about the questions and feedback I had been given at the end of our presentation. Specifically, the question about our current vest design and how we will properly and securely connect all of our components to it. As a team, we were not worried about attaching all components to the vest, however, ensuring the IMUs are correctly aligned with each vertebra and adjustable for every user is. As a result, I spent a large amount of my time this week refining our vest design, specifically how we will edit the vest to be adjustable and attach relevant components to it. Our working design now includes the use and reconstruction of two vests, in which we will use their original mesh components to enclose and secure our IMUs and PCBs, as well as use the various adjustable straps of the two vests to make the location of each IMU flexible for users. I then ordered our vests, and our updated parts lists and order status of each item can be found below.

Once our first round of parts was delivered this week, Allison and I began assembling and testing the pieces we had received, for example, soldering the MCU. Once the vest has been delivered, my goal for next week is to begin editing it so that the assembled parts can be easily attached and removed for iteration. Specifically, editing the vest to allow for adjustable IMU integration and PCB placement. As of right now, I feel like my work is on schedule; however, I am worried about my progress for next week. Once everything has been delivered, I would like to make good headway on my work so I feel confident about what I have completed for the project as I come back from Fall Break. Finally, I received a response from a CMU professor I contacted about their past research in posture monitoring, and they connected me with a CMU PhD researcher on the topic, who my team and I have a meeting with next week.

Updated Parts List as of 10/02/2026
Posted on

Allison’s Status Report for 10/3

This week, our team finished our design presentation, and I worked on several of the slides, including hardware diagrams and component research that helped us finalize our prototype design. Our ordered parts also arrived on Wednesday, so Carys and I began physically prototyping the system. While Carys worked on the vest design and we discussed ways to securely position the IMUs, I soldered header pins onto several of our components, including the nRF52840 MCU and motor controller, and soldered leads onto the vibration motor. Soldering the MCU was a little nerve-wracking because I initially had the iron set too high and left a small scorch mark near some of the traces. Since we only have one MCU, damaging it could have significantly delayed our progress, but fortunately the board still worked properly. I then wrote a basic program in the Arduino IDE and successfully tested the nRF52840 with the motor controller, making the vibration motor buzz every two seconds. The motor was much smaller than I expected (around half the size of a penny) so I also experimented with how noticeable the vibration would be when worn. I found that applying some pressure against the motor makes the vibration easier to feel, which is something we will need to account for in the vest design. I am also considering whether using multiple motors could improve the feedback, although we would first need to check the additional power requirements and motor driver limitations.

Overall, I think our progress is on schedule. We have moved from component selection and design into physical prototyping, although we still need to verify that the complete sensor system works together as expected. Next week (Monday), our main goal is to assemble an initial E2E prototype for the design report. Once the vest arrives, we can begin testing component placement, but in the meantime we can wire the nRF52840 to the IMUs and begin collecting accelerometer and gyroscope data. We also plan to start developing the MCU firmware for sampling and processing the IMU data so that we can begin reconstructing the relative orientation of the sensors and eventually use that information to estimate posture. These initial experiments should also give us concrete data and results to incorporate into our design report. Additionally, I hope this prototyping gives me the confirmation I need to begin working on the PCB board. Hopefully if I order it by fall break, it can arrive in time.

Here is a picture of the nRF with the pins soldered on (from the back). It was fun, I hope I can do some more!

Posted on

Rohaib’s Status Report for 9/26

This week, I worked through our IMU orientation calculations and documented a simplified approach for the design presentation. I clarified how VQF’s quaternion output can be converted into a rotation matrix to calculate each sensor’s forward/backward tilt. Comparing these angles at T3, T12, and L5 gives us upper and lower regional angle differences, which we then compare against the user’s calibrated baseline. I also outlined the calibration sequence and clarified why a stationary neutral position is sufficient when the sensors have known mounting directions (accelerometers output proper acceleration, and so in this ideal case the z-component would be +g).

Also, I expanded last week’s desktop app plan into a software block diagram showing the BLE interface, live posture display, settings manager, history view, and SQLite database. I also specified the proposed message formats in both directions. The MCU sends regional deviations, timestamps, and haptic activity through posture_update messages. The app sends angle and duration thresholds through set_thresholds, and the MCU confirms changes through settings_ack. This makes the interface concrete enough to begin development with simulated messages while keeping angle calculations and haptic decisions on the MCU.

I am on schedule with the software design work. Next week, I plan to begin the desktop app prototype using simulated MCU messages, focusing on packet parsing, live regional angle displays, and SQLite logging. I will also work simultaneously on the design report sections regarding the BLE communication and IMU orientation calculations.

Posted on

Carys’s Status Report for 9/26

This week I worked with my team to finalize our designs for the proposal presentation, including where we will locate the IMUs (now on the T3, T12, and L5) as well as potentially moving our haptic motors for feedback, from their original location of next to each IMU, to now being placed along the shoulders of the vest (to prevent added noise to the data collected from these IMUs when these motors shake to get the user’s attention). Additionally, I looked into the VQF library we plan to use, including reading the associated research paper, to better understand its potential for integration into our design and the values it would require from our IMUs to be successful. As we discussed in our weekly check-in, the filtering system takes in values from both a gyroscope and an accelerometer, and works to prevent gyroscope bias by calculating a small offset from the gyroscope values and subtracting that from the readings.

Moreover, as recommended in our check-in this past week, I looked into potential experts/people with experience in the posture field to contact for advice or opinions on our current approach and user problem. After talking with my team, I contacted three researchers in the space connected to CMU who published the paper “Robust, Low-cost, Non-intrusive Sensing and Recognition of Seated Postures” and we are hoping to meet with them in the next two weeks. Right now, I feel on track with my schedule, but I am anticipating my workload to increase in the next couple of weeks once we have all of our parts in for PosturePal, and I can start attaching and testing the IMUs. In the next week, I hope to secure meeting times with each of the researchers we contacted, as well as wire the IMUs (if delivered).