Rhea’s Status Report for 02/21/2026

What I accomplished this week:

I practiced my presentation and presented the Design Review slides on Wednesday.

This week I integrated the second LRA and haptic driver with the current prototype for the shank (last week’s version only had one LRA being controlled by the MCU). This allows for the MCU to send vibration commands to either the left or right LRA using a mux. We also received the parts we ordered, so I was able to connect the circuit to the battery and have it run wirelessly without needing to be plugged into the laptop for data transmission.

After discussing with Dr. Melissa Orta-Martinez as well as a PhD student in her lab, Iqui, I started doing research for how to encase the hardware components that will be the most “wearable”. I looked into different materials to make a soft case compared to a hard case that has been used in previous studies.

On schedule?

I’m on schedule in terms of the hardware for the prototype (putting together both LRAs for the shank component and the IMU for the foot). However, I am behind in terms of fabricating the sleeve/cases for the components to be worn on the user’s leg. This was something I wanted to start this week. In order to make up for this, I will be able to use the slack time we built into our schedule to first finalize the plans for the soft case and order the parts early next week to start fabrication.

Objectives for next week:

  1. Finalize the plans for fabricating the soft case after discussing with Iqui one more time
  2. Order the parts for the soft case
  3. Develop vibration command sequences for the left and right LRA and test to see which vibration pattern and waveform is the most detectable
    1. For now, I will place the entire breadboard and circuit on my leg using wig tape that we have borrowed from Iqui
  4. Complete the Design Review Report

Lakshmi’s Status Report 2/21/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).

  1. Programmed shank with vibration commands through multiple LRAs via mux
  2. Set up Bluetooth data processing code pipeline on laptop (previously, could only receive IMU data through Bluetooth on the LightBlue app, now we can do post-processing on that data.)
  3. Tested max rate of Bluetooth data transfer (200 IMU data samples/sec) More than enough needed for FPA analysis calculations!!
Bluetooth receiving code on laptop, printing rate of samples received when wearable device is sending IMU data at max rate.

4.  Added VQF filter to process IMU data (mimicking what would be on the smartphone backend, not onboard the wearable device).

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

By the end of this week it was planned that we integrate the foot progression angle code with the IMU input. Our current implementation does send IMU data to the foot progression angle code, but we do not know its accuracy. I still need to test its accuracy (whether through a rudimentary on-person wearable setup or by moving the breadboard). I am still on schedule, as we have planned for slack time for this upcoming week.

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

While the thorough FPA testing (comparing with mocap) is planned for the week of March 9, I plan to use the Slack time we scheduled for this upcoming week to integrate the filter code onto the device, and verify the accuracy of the FPA measurements and gait stage detection through simple, rudimentary tests (i.e. changing the position of the breadboard and verifying the FPA measurement aligns, taping the current hardware to leg for rudimentary gait position detection tests).

During our group meeting with Iqui and Dr. Melissa Orta-Martinez of the haptics lab, they also mentioned that we could sync/confirm our gait stage detection algorithm with Apple Health’s step counter step detection, so I will be looking at that as well.

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.