Posted on

Allison’s Status Report for 9/26

This week, I focused on finalizing the hardware design for our design presentation and preparing for prototyping. After identifying the components we wanted to use last week, I researched manufacturer and distributor pages to compare availability, shipping times, and specifications. I prioritized parts that could arrive quickly so we can hopefully prototype before the design report is due. This would let us collect preliminary IMU data for our posture calculations while also testing factors such as communication latency and power consumption. I also found breakout-board versions of our components to make initial prototyping easier.

I also researched how these components would translate to our eventual custom PCB. Since we will likely use SMD versions of components such as the IMUs, I checked their availability to avoid potential lead-time issues and found PCB fabrication options as well along the way. Reading through the component documentation also helped me understand their wiring and interface requirements. For example, while considering I2C versus SPI, I realized that I can include jumper or solder pads on the PCB to keep configuration options open rather than committing to one design immediately.

I believe my progress is currently on schedule. Next week, I hope to meet with my team to verify that the complete hardware design works together and begin testing the breakout boards once our components arrive. My main goal is to use what we learn from prototyping to begin the custom PCB schematic, including component connections, power distribution, and configurable interface options, while my team can work in parallel with the breakout board components to begin firmware development.

Below is what our parts list looks like right now. I hope to keep maintaining it like this, maybe adding more columns if necessary, to keep track of our components and budget.

Parts List

Posted on

Team Status Report for 9/26

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.

Posted on

Rohaib’s Status Report for 9/19

This week, I worked on the desktop app design and how it will communicate with the wearable. I outlined the main features: live posture readings, calibration, feedback settings, and session history. The proposed stack is Python with PySide6 for the interface, Bleak for BLE, and SQLite for local storage.

I also drafted the data the MCU should send to the app, including upper/lower angles, posture states, and device status. Settings changes will require an acknowledgment from the MCU. Feedback decisions will stay on the MCU so reminders still work when the app disconnects.

I am on schedule as the initial software plan is outlined, and I can start building with simulated data while the hardware is being developed. For next week, I need to agree on the initial MCU to app data format with Carys and then finalize all related design documentation for the software components + BLE communication.

Posted on

Carys’s Status Report for 9/19

My work this week centred on further research into our IMU placement, data collection, and calculations for proper integration into PosturePal. We are considering using LSM6DSOX as our IMUs due to their six-axis capability, low power consumption (0.55 mA in their higher-performance mode), and compact size (2.5 mm x 3 mm x 0.83 mm). As Allison mentioned in her weekly report, one potential drawback of these IMUs is that they do not allow for wireless communication, and as a result will integrate either I²C or SPI into our current design. As done in a 2021 research article by Paloschi et al, we will be placing IMUs on the T3, T12, and S1 vertebrae, which in the paper were compared to and validated against a motion capture system to detect poor spinal posture. The T3 and T12 movement and difference were used to capture thoracic changes, while the T12 and S1 were used for the lumbar. However, the research of  Paloschi et al did not use a wearable vest for participants when capturing this data and instead placed the IMU’s directly on the skin. As a result, we must and are working to take into account this difference in our design, specifically, how we will test for accurate measurements and worsened posture haptic feedback. One way we are considering to combat this in our design is that instead of integrating the three-axis acceleration and angular velocity given by the LSM6DSOX to calculate the IMU position over time (comparing each sensor’s new position to the location of its old one), we will compare the relative location of each sensor to the others. This way, we can determine if the upper back has curved in comparison to the middle of the spine, and similarly for the lower back. These relative calculations will also guide our calibration phase of PosturePal to identify what the user believes is their “ideal posture”. Specifically, we believe this will help us better meet our requirement of accurately identifying 90% of actual slouches or occurrences of posture worsening over stretching or other movements. 

As a result, in our current design process, we believe we are on time and in a good position to complete our design proposal with an updated approach to sensor data calculations and approach. In the next week, my goal is to finalize the positions of these IMUs and the communication protocol they will be using with our MCU and software stack with my teammates to ensure the data we are collecting and the calculations we are performing will best allow for accurate haptic feedback.

Posted on

Team Status Report for 9/19

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.

Posted on

Allison’s Status Report for 9/19

My goal this week was to determine the hardware we need for PosturePal and develop a more concrete system architecture. Our main components consist of three IMUs placed at T3, T12, and S1 to measure spinal orientation and movement, and a central controller that will process the sensor data, determine when to trigger haptic feedback, and communicate over Bluetooth with our companion software. We are heavily leaning toward the LSM6DSOX for the IMUs, and I investigated how its support for I²C and SPI, but not wireless communication, affects the rest of our design. Rather than putting a battery and wireless controller at every sensor, we plan to connect the three IMUs by thin wiring to one central hub. I also determined that a Raspberry Pi is likely unnecessarily powerful, large, and power-hungry for our application. Instead, I investigated smaller, lower-power microcontrollers/SoCs with integrated BLE, particularly the nRF52840, while keeping wireless STM32 options under consideration. The nRF52840 appears promising because it can handle our sensor processing and Bluetooth communication on a single device.

From this research, I developed a preliminary design consisting of one custom central PCB and three much smaller, identical sensor PCBs. The central PCB would contain the MCU/SoC, battery and charging circuitry, voltage regulation, sensor interfaces, potentially an I²C multiplexer, and possibly the haptic-driving circuitry. Each sensor PCB would contain an LSM6DSOX and connectors that allow a thin cable to continue along the spine between the hub, S1, T12, and T3. I also investigated several design tradeoffs that we do not want to finalize before prototyping. I²C requires fewer wires and is attractive for a wearable, while SPI avoids some addressing issues but requires more conductors. Both also require us to consider the timing differences between measurements from the three IMUs, so our current plan is to timestamp samples. I also began investigating our haptic feedback design, particularly whether localized feedback at multiple points along the spine provides a meaningful benefit over a single haptic motor. Multiple motors could provide more intuitive feedback about where the user’s posture needs correction, but would add wiring, power consumption, and potential interference with the IMU measurements. We therefore plan to test both localized and centralized haptic feedback before finalizing the design. Overall, I believe my progress is on schedule and this week significantly narrowed our hardware architecture while identifying the remaining decisions that need experimental validation.