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.