Team Status Report for 3/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?

  • The soft case may not cure well, we have not worked with this material before (same as last week, as we are still in the process of developing the case). 
  • The soft case may cause irritation or absorb vibrations from the LRAs, negating vibration feedback (same as last week, as we are still in the process of developing the case)
    • Contingency plan: We will be experimenting with the different materials and case shapes/dimensions to find the best one in terms of user comfort and minimizing vibration absorption 
  • We plan to have an AWS backend that triggers a mobile app notification when the user’s FPA changes (which will be determined by our FPA algorithm). However, we will most likely encounter many bugs with setting up and initializing the AWS connection with our current app (i.e. setting correct permissions, ensuring proper libraries are added, etc.)
    • Contingency plan: We will reach out to TAs during mandatory lab time with strong experience in AWS if we encounter any significant blockers.

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?

No change was made to the existing design of the project.

Provide an updated schedule if changes have occurred.

  • Soft case fabrication is taking longer than expected due to the learning curve of using CAD software and 3D printing since none of the group members have had any previous experience
    • We originally planned to finish case fabrication by the end of this week, however, we now aim to finish fabrication for the soft case by the end of next week (by 3/20th). 
  • Due to delays in case fabrication this will push back our timeline for starting to conduct testing. We originally planned to start doing motion capture in lab testing/data collection starting this upcoming week, however that will have to be pushed back to the week of the 23rd. 

Team Status Report 03/07/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?

  • The soft case may not cure well, we have not worked with this material before. 
  • The soft ase may cause irritation, or absorb vibrations from the LRAs, negating vibration feedback
    • Contingency plan: We will be experimenting with the different materials and case shapes/dimensions to find the best one in terms of user comfort and minimizing vibration absorption 
  • The FPA analysis may be deeply inaccurate, more time may be needed to tune parameters to adjust for each walking pace pushing back test time
    • Will be consulting our two PhD students for what work they’ve already seen in the space of FPA analysis, what research papers have documented precise error ranges so that I can go into finetuning and developing the FPA analysis algorithms with a base line knowledge of error rate

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?

No change was made to the existing design of the project.

Provide an updated schedule if changes have occurred.

N/A

Part A (Rhea): … with consideration of global factors. Global factors are world-wide contexts and factors, rather than only local ones. They do not necessarily represent geographic concerns. Global factors do not need to concern every single person in the entire world. Rather, these factors affect people outside of Pittsburgh, or those who are not in an academic environment, or those who are not technologically savvy, etc.

The LKR system addresses the global need for accessible and personalized rehabilitation technologies, in particular for individuals with chronic knee pain. Knee osteoarthritis affects millions of individuals worldwide. In 2050, there will be an estimated 642 million individuals with knee osteoarthritis [1]. Traditional gait retraining often requires repeated visits to specialized rehabilitation clinics with motion capture systems and trained therapists, creating barriers for individuals who live far away from medical centers, have limited financial resources, or cannot easily access consistent care. By providing real time vibrotactile feedback through a portable device, LKR allows users to retrain their gait during everyday walking activities without the need for expensive laboratory equipment. This system supports broader access to rehabilitation tools outside specialized clinical environments. The feedback provided by the device uses simple directional cues rather than complex visual or language-based cues, allowing individuals with varying levels of technological literacy or language backgrounds to interpret the feedback. 

Part B (Kaitlyn): … with consideration of cultural factors. Cultural factors encompass the set of beliefs, moral values, traditions, language, and laws (or rules of behavior) held in common by a nation, a community, or other defined group of people. 

The attitude towards aging in the United States is severely negative, and how we treat our elders reflects that. There is a strong divide between the old and young, and one cause of this is how inaccessible daily life is for non able-bodied individuals. Specifically, knee joint pain can make both daily necessities (ie. transport) and recreational activities (ie. concerts) challenging to engage in. The LKR system broadly addresses this by providing older individuals with the chance to improve their joint health and feel more comfortable and present in their everyday lives.

Additionally, due to our choice of physical components and removing the need for external human assistance, our system is designed to be lightweight and independent. This reduces the cultural stigma of being perceived as reliant or susceptible – empowering older individuals to improve their health on their own terms. 

Part C (Lakshmi): … with consideration of environmental factors. Environmental factors are concerned with the environment as it relates to living organisms and natural resources.

Traditional knee rehab requires patients to make repeated trips to a physical therapist’s office, each visit contributing to transportation emissions and the energy demands of running a large medical facility. LKR shifts knee rehabilitation to the user’s home, avoiding the environmental costs associated with transportation. The small size and low power consumption we have been designing towards to ensure longer battery life also have the added effect of being far less energy-intensive than the large electronic walking harnesses found in medical centers.

Furthermore, we have chosen to build upon an existing piece of technology that almost all patients will own: their smartphone. Rather than creating another, more specialized piece of technology beyond the wearables to process data, by using an existing technology that most patients have access to can reduce e-waste. When a patient has confirmed that the course of their gait retraining has been completed, they can simply uninstall the app, rather than having to throw out another specialized electronic device.

Rhea’s Status Report for 03/07/2026

What I accomplished this week:

This week majority of my time was spent working on the design review report. Specifically, I worked on the following sections: Abstract, Related Works, as well as all the sections related to the shank-mounted wearable and the vibrotactile feedback throughout the report.

I met with Vu and Iqui this week with Kailtlyn to discuss 3 different methods for creating the soft case for the hardware components (outlined here). After this discussion, I decided that the best method for making the case is to 3D print a mold for the case (given the dimensions of the actuator system and the central component) and create the case using the mold and liquid silicone.

On schedule? 

Yes, I am on schedule for prototype fabrication. We recently ordered a second round of parts specifically for the foot-mounted device as well as the soft case, and will begin prototyping different versions of the case after the team is back from spring break.

Objectives for next week:

  1. Fabrication of different models for the case mold. I aim to make 3 versions of the soft case
  2. Solder the new hardware components
    1. 2nd Seeed Studio MCU/IMU
    2. Integrate the on/off switch into the shank-mounted wearable
  3.  Develop vibration command sequences for the left and right LRA and test to see which vibration pattern and waveform is the most detectable

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

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. 

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.

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.