Posted on

Kaitlyn’s Status Report for 2/7/2026

What did you personally accomplish this week on the project?

I assisted my group in debugging the MCU (ESP32) and laptop connection. While the program didn’t work on my own laptop, we were able to work out a couple kinks related to Mac vs Windows Arduino setups. Furthermore, in addition to researching IMUs, I conducted independent research into our solution approach (LRA, Haptic Driver, etc). Since I come from a HCI/frontend background, many of the components and their functions are unfamiliar to me. Even though my main tasks center around software/UI, to be a team contributor, it’s important I can contribute to conversations surrounding the physical device setup.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Our progress is somewhat behind, since we were only able to successfully work on the MCU-laptop connection rather than other parts of the pipeline such as haptic driver, IMU connections. Since our plan is to have these connections established by the middle of next week, our team and I will meet synchronously before then to work together to build the pipeline. Over this weekend, I plan to further familiarize with the components we’ve ordered, especially in relation to how these components should work together (and what connectors we’ll need), to prepare for our work session.

What deliverables do you hope to accomplish in the next week?

  • Connect MCU –> IMU and haptic driver –> LRA, integrate with rest of device
  • Broadly research mobile app development (SwiftUI vs React Native), try and deploy an existing simple fullstack app to prep for eventual UI/backend needs
  • If time: start conducting “competitor” research into health data viz platforms like “Apple Health”

 

Posted on

Team Status Report for 2/7/2026

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plan are ready?

  • Risk: The MCU that we are currently using is single-core + Bluetooth + 6 DOF IMU, allowing us to optimize for size. However, previous literature has done computation on dual-core MCUs with a separate IMU component. It is possible that our current approach to serially transferring FPA data and vibration commands through the MCU may not work on a single-core.
    • Resolution: We have ordered the dual-core MCU, we plan on testing the vibration command pipeline using the single core MCU so that it can transfer to the dual-core MCU when we receive it.
  • Risk: 9-DOF IMU prevents drift with the addition of the magnetometer, but because the device is low to the ground it can be easily interfered with, causing noisy data that is difficult to parse for FPA analysis. 6-DOF IMU sees consistent drift, which can also interfere with data analysis.
    • Resolution: Since walking is a cyclic task, we aim to reset the IMU’s position at the point in the gait cycle where the footstep has just occurred, hopefully mitigating drift to an extent where FPA analysis isn’t greatly impacted.

    Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)?

    • Instead of the 9-DOF IMU, we will be using the 6-DOF IMU on board the ESP32.
      • This change was necessary to condense the components of the wearable device to prioritize comfort and small size. This incurs no additional cost since the 6-DOF IMU is onboard the single-core ESP32.