Category: Team Status Reports

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.

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.

We started this week by finalizing our current design, both in part for the upcoming design presentation and report, and so we could order parts and start iterating on PosturePal as soon as possible. In doing so, we confirmed that we will be using the LSM6DSOX as our IMUs as they provide six degrees of freedom (three acceleration and three gyroscope) and therefore collect angular velocity and acceleration data we need to monitor posture changes. Additionally, we ordered the parts we will integrate into our custom PCB, such as the nRF52840 for our MCU, haptic motors, and a PCA9548 I2C Mux for the three IMUs. Going forward, we are feeling confident about our current design but are worried about lighter parts, like the IMUs or haptic motors, breaking throughout the iteration and testing process. To combat this, we ordered an excess of these items.

Additionally, after our weekly check-in, we worked to integrate our Proposal Presentation feedback into our current thinking and project design. This included better explaining (in future presentations and reports) the VQF library we will be using and framing the problem as more of a continuous values quantity and less of a classification problem. To achieve this, we further looked into the VQF library and its implications for PosturePals design, as well as how we will articulate this in our Design Presentation. To help, we have decided to show some of the equations used and the overall approach of the filtering process in our Design Presentation and Report. Moreover, in our calibration phase, we will add a set user threshold for determining ideal vs non-ideal posture (which can ideally be completed with a medical professional) instead of PosturePal/us determining and defining what is “good” vs “bad” posture. This will not only make PosturePal’s guidance more personalized to each user, but also reduce health and safety ethical implications. This is because, as undergraduate ECE students, we are not medical professionals and therefore should not be consulting on “good” vs “bad” posture. This particular change has few costs or implications for our timeline, as it is a part of PosturePal’s software implementation, which is more flexible than its hardware. Finally, our updated project schedule is below.

Status Report 2 Additional Questions
Section A: Rohaib
One of our main considerations for PosturePal is making sure that we are helping users monitor their posture without making medical decisions for them. During calibration, the user will define what they consider their ideal posture, potentially with medical expert-based feedback, and can set a threshold for how far they are comfortable deviating from it. PosturePal will then monitor these changes and provide haptic feedback when the user exceeds their chosen threshold for an extended period of time. This allows our device to promote posture awareness while avoiding defining what is medically considered “good” or “bad” posture. We will also consider the physical safety and comfort of the wearable itself, including secure component placement and safe battery operation.

Section B: Carys
We want PosturePal to be something that can be worn throughout a user’s day, so we do not want the device to interfere with these routines. This is why we’re planning to integrate the sensors and electronics into a wearable vest and use haptic feedback instead of requiring users to constantly check the application. This feedback is also pretty discreet, so a user can receive a reminder without disrupting the people around them. In our meetings, we also discussed how difficult it was to find research defining a universal standard for good posture. It was important to both us and our instructors that PosturePal does not enforce a single standard, and lets users define what they are comfortable and not comfortable with, making PosturePal more applicable to people with different lifestyles and backgrounds.

Section C: Allison
Cost and component availability have also been important considerations in the design process. For our initial prototype, we are using breakout boards so that we can assemble and test PosturePal quickly without immediately investing in a custom PCB. At the same time, I’ve been making sure the price and availability of their SMD versions is reasonable. Not only is this important for our deadline, but in general, affordable and mass-produced components is very good for production in terms of time, cost, and ease of assembly. Furthermore, good posture should be something that is promoted to all, so we want this product to be cost-accessible as well.

As a team, our focus this week was on refining the overarching architecture for PosturePal alongside our respective individual tasks. A shift in our system strategy involved narrowing down our central control unit. While we initially weighed using a Raspberry Pi or an STM32 board, our research demonstrated that a compact, energy-efficient SoC featuring built-in BLE (like the nRF52840) is far better tailored to the wearable’s compute and wireless transmission demands. Beyond the controller, we pinpointed several core trade-offs that require physical validation prior to finalization. These include selecting between I²C and SPI protocols, establishing sensor timestamping methods, and determining if localized multi-point haptics offer sufficient utility to warrant the extra power draw, cabling complexity, and signal noise on the IMUs. Building a preliminary test bench will let us analyze these parameters in a unified setup before ordering our custom boards.

Splitting up hardware, firmware, sensing, mechanical housing, haptics, and app development lets us make concurrent progress, but it leaves our deliverables tightly coupled. Ensuring the full system functions properly means that these distinct parts must interface seamlessly. To mitigate this risk, we plan to prototype interfaces early on and integrate as early as possible. Looking ahead to next week, we plan to first finalize the design review/proposal, and if orders come in, then we would also look to wire the three IMUs onto a physical test rig, gather sample data across various user postures, assess bus communication and experiment with haptic placement to gauge its influence on sensor readings.