Kaitlyn’s Status Report for 2/21/2026

What did you personally accomplish this week on the project?

  • Designed UI screens for displaying current session information such as current foot progression angle (FPA), session history (long-term data visualization), as well as analytics (ie. natural language recommendations/trends)
  • Met with Iqui and Prof. Melisa Orta Martinez as a team and discussed built-in step tracking on the iPhone. Looked into how to utilize that feature for our own mobile application
  • Examined Design Report guidelines and started assigning tasks/organizing necessary information

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

My progress is slightly behind since I haven’t been able to fully build out the UI display for the foot angle measurement. To catch up, my group members and I will try to get the design report done earlier in the week, so we have more time to work together on examining and integrating the foot angle progression code with the IMU, as well as updating the UI accordingly.

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

  • Complete the Design Report
  • Integrate FPA code onto the mobile app backend
  • Add the 3 pages mentioned above (current session, session history, analytics)
    • Focus particularly on FPA UI: regardless of if FPA is properly being measured, the “visuals” should be added to the frontend
  • If time: have UI dynamically display changes to the user’s FPA as they walk

Team Status Report 2/21/2026

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

  1.  The code to process the IMU data includes a filter to smooth out noise (VQF filter). This filter was first planned to be on the smartphone as part of the rest of the pre-processing, but after discussions with Iqui and Dr. Melissa Orta-Martinez from CMU’s Haptics Lab, we realized we may need to move the filtering code onto the wearable device, to increase fidelity.
    1. The MCU onboard the device is currently single core, and from Iqui’s experience the current VQF library does not work on a single core MCU. We have a dual core one to switch in that still fits within our size constraints as backup.
    2. We can also sidestep the signal fidelity problem and keep the filter on the smartphone if we are able to send IMU data at a rate above 30 Hz. We will be testing the max rate of information sent through the Bluetooth module on our current MCU as specified in its datasheet.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

Other than moving the filtering code onto the MCU, no other changes have been made.

Provide an updated schedule if changes have occurred.

N/A

This is also the place to put some photos of your progress or to brag about a component you got working.

Commands sent to multiple LRAs via mux

Kaitlyn’s Status Report for 2/14/2026

What did you personally accomplish this week on the project?

  • Set up the mobile app (named “lkr-data”) using React Native, Expo, and XCode, then successfully deployed to my iPhone 13 device
    • Wrote up documentation found here, so my team members can set up the mobile app on their own smartphones if necessary
  • Established bluetooth connection between the mobile app and MCU, utilizing the BLE React Native library to scan for BLE devices, write signals to the LRA, and read accelerator data from the MCU (using Lakshmi’s MCU program)
  • Revised block diagram based on advisor feedback and fleshed out UI design requirements & solution approach for the Design Review Presentation
  • Note that although I intended to connect the MCU and IMU along with haptic driver and LRA, Rhea ended up focusing on those aspects since she has stronger soldering experience. Furthermore, app deployment took slightly longer than expected since it was my first time working with React Native and Expo, so majority of my time was spent research and debugging that process.

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

My progress is on schedule since based on our Gantt Chart, my main task for this week was connecting the smartphone to wearable, and I was able to accomplish that. Additionally, my team members managed to complete their week’s tasks as well, setting us up well for next week.

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

  • Make small usability tweaks to current UI (ie. correcting black text on black background)
  • Update mobile app components based on refined UI design requirements and solution approach
    • Implement foot progression angle measurement data/display

Rhea’s Status Report for 02/14/2026

What I did:

  • Soldered the MCU, haptic driver, and multiplexer. Soldered the connections between the haptic driver and the single LRA
  • Put together each individual hardware component to work together with Lakshmi’s code
    • Connected the haptic driver+LRA to one channel of the multiplexer to allow for sending commands to 2 separate haptic driver + LRA components for both sides of the leg as part of the device
  • LRA vibration testing
    • Read through the documentation for the haptic driver we are currently using (DRV2605), as it contains a library of preset vibration commands to drive the LRA that can be put into different sequences for different types of vibration feedback (sinusoidal, ramp up, constant, pulsing, etc.)
  • Tested the vibration feedback from the LRAs with Lakshmi using her code/pipeline to send vibration commands from the MCU to the haptic driver
    • The LRA feedback was too faint to detect a difference among the different vibration commands,
    • I debugged this issue by changing the pin the haptic driver was connected to (originally it was connected to the 3V pin, but I then adjusted it to V_in, which supplies 5V)
  • LRA type comparisons
    • Conducted literature review on different types of LRAs and their vibration amplitudes to see which models could provide the most detectable vibration amplitudes
  • Worked on Design Review presentation slides
    • Worked on the solution approach slides by compiling the information we have on hardware component comparisons (different LRAs, MCUs, IMUs)

On schedule?

I am on schedule based on our project timeline, as I have connected the necessary hardware for the device that will be worn on the shank and integrated it with the current code. I also worked on testing the LRA vibration commands. After discussing with the group, we agreed to shift around when I will start building the sleeve for the LRA by another week since ideally the hardware components for the device worn on the shank will be connected first. I also still need to look into tradeoffs between an adhesive attachment vs. using a strap for the attachment.

Next week’s deliverables:

  • Present Design Review in class
  • Solder the second LRA and haptic driver
    • Integrate the additional haptic driver to the current system
    • Test vibration intensities with the 2 LRAs
  • Solder the IMU/MCU components to be worn on the foot for the FPA estimation
    • Comparison between adhevise vs. strap to attach the device on the shank

Team Status Report for 2/14/2026

  • What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
    • Our ESP32 with embedded IMU may not have the capability to send IMU data at a high enough sampling rate. We will test our ESP32’s current capabilities early next week. We currently have another dual-core ESP32 that has arrived from ordering as backup. This will not require any change to the IMU programming code.
    • Our current template for the FPA estimation algorithm may not have enough accuracy needed for helpful gait training feedback. To remedy this, we have identified sources of error in FPA estimation through discussions with PhD students from CMU’s Biomechanics and Haptics lab (position of IMU on foot, sampling rate, speed of walking). We will integrate the following tests to ensure we get maximum accuracy and understand how to finetune parameters needed for processing the IMU data
      • IMU position on foot test (top of foot, toebox, and medial side of foot)
      • Determine max sampling rate of current ESP32 and determine gate stage accuracy (the preprocessing step before calculating FPA)
      • Change participants speed of walking (via treadmill settings) and compare calculated FPA with mocap (ground truth)
    • Our current LRA set up may not have the intensity needed for recognizable scaled feedback. We have been researching different LRAs and discovered our current LRA has the highest peak intensity, so we are now planning on integrating a separate battery into our circuit to provide more power to the LRA. If this still doesn’t provide enough intensity, we plan to integrate multiple LRAs on each side of the device. This will not require large changes to the IMU programming code.
  • Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
    • Met with Iqui and Vu (PhD students from the CMU Biomechanics Lab and Haptics Lab) with all group members to discuss FPA estimation algorithm testing and finetuning. We now:
    • Aim for at least 30 samples/second for IMU measurements to ensure accurate gait stage detection
    • Allow for +/- 5 to 10 degrees of error for FPA (2 degrees of error estimation algorithms has not been verified in the literature yet. Current reliable test results have up to 15 degrees of error.)
    • Allow < 300 ms latency for the vibration command to deploy
    • Plan to test orientation of IMU on foot’s effect on device accuracy
  • Provide an updated schedule if changes have occurred.
    • Our original plan was to start building the sleeve for the LRA+MCU system this week and next week, however, we are holding off on putting the sleeve together until we finalize how many LRAs we need on each side of the device. Furthermore, we also need to consider adhesive for the LRA components versus a sleeve for better feedback reception.

(Rhea) Part A: … with respect to considerations of public health, safety or welfare. Note: The term ‘health’ refers to a state of well-being of people in both a physiological and psychological sense. ‘Safety’ is the absence of hazards and/or physical harm to persons. The term ‘welfare’ relates to the provision of the basic needs of people. 

From a public health perspective, the wearable haptic device promotes physiological wellbeing by helping users who have knee joint pain to modify their gait pattern to reduce the strain on their knee joints, potentially reducing the risk of chronic injury and long-term mobility loss. The system’s portability, along with its capability of providing real-time, interpretable feedback can increase patient confidence and engagement in rehabilitation and allow users to feel more empowered to independently manage their health. In terms of safety, the design of our device will minimize risks by using materials that are skin-safe/minimize skin irritation and LRAs that generate vibrations at an amplitude that is comfortable for the users. The device will be designed to be lightweight and unobtrusive such that users can maintain natural movements while walking. Our device will enable safer mobility, promote independence in daily activities, and reduce reliance on clinical supervision to improve overall quality of life for individuals undergoing gait rehabilitation. 

(Lakshmi) Part B: … with consideration of social factors. Social factors relate to extended social groups having distinctive cultural, social, political, and/or economic organizations. They have importance to how people relate to each other and organize around social interests.

The design of LKR accounts for the demographic of patients using the device, which are mainly older adults who are the most vulnerable to chronic conditions that cause knee pain, such as osteoarthritis. For older adults mobility is directly tied to independence, and this demographic has an increased risk of isolation [1]. Furthermore, traveling frequently to a physical therapy clinic can be financially burdensome to older adults and their families, preventing low-income families from supporting elderly members knee health early on, leading to increased hospital costs from fall injuries [2]. This device supports aging in place and a greater degree of autonomy for elderly individuals by enabling gait retraining therapy from home, at their convenience. 

(Kaitlyn) Part C: … with consideration of economic factors. Economic factors are those relating to the system of production, distribution, and consumption of goods and services.

SageMotion, a popular commercially available haptic biofeedback system, costs around $20K. In contrast, our system is meant to be low-cost ($110 for hardware components), allowing individuals who can’t afford SageMotion to still benefit from gait retraining. Another method for improving gait is attending physical therapy sessions, but session costs can be high and for individuals who live in rural areas, transportation methods may be limited (and also costly). Our system is designed to work effectively at-home with no professional medical supervision needed, offloading these expenses. 

Lakshmi’s Status Report for 2/14/2026

What I did:

  • Programmed the MCU (code can be found here) to connect with my phone via Bluetooth through the LightBlue BLE test app.
    • The MCU now sends accelerometer data to the phone (we have tested from 0.1 times/sec to 1 time/sec), and can receive vibration commands from the phone.
  • Programmed the MCU to deploy these vibration commands to the LRA.
    • Added mux functionality to this code.
      • Createdan encoding scheme that encodes the vibration command and the LRA it should be sent to.
    •  Now we can send commands to the two LRAs in the device (necessary to provide vibration feedback to both sides of the leg). Created a suite of vibration test commands for LRA feedback testing.
  • Wrote up documentation for how to program the MCU with this functionality, so each team member can interface with the Bluetooth communication independently.
  • Tested the vibration feedback from the LRAs along with Rhea.
    • The LRA feedback was too faint to detect a difference among the different vibration commands, Rhea is focusing on getting greater power through to the LRA to increase its intensity.

On schedule?

I’m on schedule according to our Gantt chart. I have successfully programmed the IMU with bluetooth for IMU to laptop communication, and created test commands for the laptop -> LRA device pipeline.

Next week’s deliverables:

  • Integrate IMU output into FPA estimation algorithm
  • Test LRA feedback intensity
  • Set up device on participant (one of our teammates), test feedback efficacy with no FPA estimation algorithm refinement

Lakshmi’s Status Report for 2/7/2026

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

    • This week I worked on getting communication between the ESP32 and the laptop working consistently. I was able to send simple commands to the ESP32  reliably, however I discovered that the ESP32 has to be put into bootloader mode each time I compile and flash new code on it. Below is a photo of all three of the onboard LEDs that were newly programmed to ON.

      ESP32 (MCU) programmed with all LEDs to ON
    • I placed an order for the parts for the wearable device. Beyond that, I specifically looked into using the Adafruit Flex Perma-Proto board for a greater degree of flexibility in our circuitry. One of the aims we have for this product is increasing user comfort while maintaining standards of accuracy set in the previous literature, I believe this flexible proto board is a step in this direction.
    • Along with the group I met with two PhD students working in the biomechanics lab for advice on our design. I focused on understanding the interface between existing FPA code and the signals we would get from our current IMU setup. I was able to clarify that we only need a 6 DoF IMU, and we can address drift by resetting the IMU position every footstep. They also pointed us towards VQF, a library for FPA estimation that is optimized for embedded applications.

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

  • I had planned to get the full pipeline laptop -> MCU -> haptic driver -> LRA pipeline set up this week, however I was only able to get the MCU connected to my laptop. According to our Gantt chart, we are still on time for getting the full pipeline set up, since it is due ~2/11, so I will be scheduling time with Rhea and Kaitlyn to work on connecting the three devices on this upcoming Monday/Tuesday. This weekend, I plan on looking over the datasheets for the haptic driver and LRAs the PhD students loaned us to see how to set up code to send pulse commands to the vibration components before we get the pipeline ready.

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

  • Connect MCU -> haptic driver -> LRA pipeline
  • Access position data from IMU
  • Familiarize myself with the VQF library
  • Familiarize myself with the existing work on calculating FPA

Rhea’s Status Report for 2/7/2026

  • What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

I assisted with compiling the parts list to being prototyping. The current MCU chosen is a single-core MCU with an integrated 6 DoF IMU that is capable of BLE+WiFi data transmission. An alternative MCU has also been ordered that is a dual-core MCU, but it does not have a built in IMU, which means that the size of the prototype would have to increase if the MCU and IMU were separate components.

I also met with Dr. Eni Halilaj with the group to get some guidance on the project and feedback on high level goals that were listed in our Gantt Chart and proposal presentation.

I conducted literature review to learn more about foot angle progression (FPA) estimation by reading the following paper. I also start planning out the BLE data transmission pipeline from the laptop to the MCU, as well as how to set up the connection between the MCU and the haptic driver.

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

Currently, my progress is on schedule since I already had the single-core MCU to start testing and working with while waiting for the other parts we have ordered to arrive.

  • What deliverables do you hope to complete in the next week?

I hope to start working on connecting the MCU to the haptic driver with a breadboard at first as a proof of concept.

I also plan to work on developing the MCU —> laptop pipeline using the single core MCU that we have, and that code will ideally be easily translated to another MCU if we decide to go with the dual-core MCU instead. As part of this, I will work on implementing code for BLE data transmission between MCU —> laptop to plot test/sample data before transitioning to having it display the raw IMU data.

Finally, I will conduct further literature review on FPA estimation and a previous study’s algorithm for this calculation and how to integrate their approach for our device components. The code will be added and updated to the project’s GitHub repo.

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”

 

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.