Category: Allison’s Status Reports

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.

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!

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.

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.