Category: Team Status Reports

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 mobile app is working with communicating between the shank mounted LRAs and the foot mounted IMU, however it hasn’t been formally tested with the mocap system and the treadmill yet. This risk is being managed as we are going to be conducting another data collection session to test the functionality of the app during treadmill walking this upcoming week. If we run into any issues with the app during the experiment we will adjust the code as necessary. 

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?

N/A

Provide an updated schedule if changes have occurred.

N/A

List all unit tests and overall system tests carried out for experimentation of the system. List any findings and design changes made from your analysis of test results and other data obtained from the experimentation.

FPA Accuracy: 

• Compared IMU-based FPA with mocap ground truth 
• Findings
  • Normal walking speed + Treadmill: RMSE is 2.24, which is within the acceptable error boundary for accurate vibration feedback
  • Fast speed (20% faster than normal) + Treadmill: RMSE is 11.93, 5x more than acceptable error
  • The FPA algorithm relies on heading measurement from the swing phase of walking, the faster one walks, the shorter their swing phase = less accuracy.

We now know the exact limits of our device, which is that we can only hold adequate FPA accuracy at the patient’s normal walking pace or slower. When we increase beyond the patient’s normal walking speed, error dramatically increases. This is completely fine for our use case, however it is good to know concrete limits of this device from testing.

 

Intuitive feedback testing: 

• Compared FPA after receiving verbal instructions vs. FPA after receiving vibrotactile feedback 
• Findings:
  • Without device: With only verbal instruction to point toes inward, patient was avg. 4.4° away from target FPA (-10 degrees from their baseline FPA
  • With device: With haptic feedback, patient was 0.1° away from target FPA

We saw that haptic feedback greatly improved patient ability to meet their target FPA goals during gait retraining, showing that the feedback was intuitive enough that the patient was able to make considerable progress towards getting their FPA to align with the recommended angle. With this in mind, we are able to confidently say that our device would greatly help patients train by themselves at home, since our data shows a marked improvement in using the device versus the alternative, which would be a reminder from a physician to a patient to point their toes more inward. 

Perceived Feedback Testing

To test if different levels of intensity of the vibrations were distinguishable while walking, we tested 3 different levels of vibrations: 100% intensity, 50% intensity, 20% intensity of pulsed vibrations. After asking the participant which level of intensity they were feeling on their shank, the participants were not able to determine any differences between the 3 intensity levels. Instead, they were only able to distinguish if the vibration was present or not. This could be due to the MCU only being able to drive 3.3V, so that the LRAs are not able to produce a strong enough vibration. This changed our device design such that we are no longer planning on implementing the scaled feedback based on the degree of error. If another MCU that could drive a higher voltage, then this could result in more distinguishable differences in the intensity levels to allow for scaled feedback. 

Intuitive UI Testing: 

To test our app’s UI, we asked participants to fill out a short survey (google form link: https://forms.gle/dZCPrsvuKGisoiJm7) locating and explaining information present on the interface. We’ve so far tested with one participant, and one change we made is ‘hiding’ the bluetooth connection pipeline from the user, and having it automatically start when the user presses ‘start’ and disconnect when the user presses ‘stop’. Furthermore, we separated the ‘calibrate’ and ‘export csv’ buttons to an admin section of the tab since they are not directly user-facing. Besides the active session workflow improvements, the participant accurately identified other elements of our UI such as data visualizations and recommendations. 

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 App can currently receive FPA measurements as well as send vibration commands, however we are still currently working on having those vibration commands automatically send based on the FPA. We will need to convert the Python script to TypeScript (like previous iterations), but we’ll need to debug and ensure the pipeline is functioning properly. Additionally, we still need to test that the calibration and data logging functions work (and debug if necessary). 
• The FPA accuracy dependent components of the device, such as vibration feedback error range, need to be finalized while still staying in line with previous research error ranges (i.e. no vibration for correct FPA +/- 2 degrees). Currently, our error range is +/- 4 degrees to prevent “noisy” feedback for toe-out training, and +/- 2 degrees for toe-in training. We need to be more certain about this fluctuation in error range between toe-in and toe-out training through further testing.
  • The goal of our device is toe-in gait retraining, so we do have a good error range for this. 

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?

N/A

Provide an updated schedule if changes have occurred.

 N/A

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?

• AWS lambda functions carry a lot of latency, so even though we are able to send IMU data through bluetooth at a rate of > 180 Hz, the actual processed FPA may be calculated at a much lower rate, causing issues with getting timely vibrotactile feedback. 
  • Mitigation: Instead of using AWS for processing, we isolate the AWS component to just data storage and have a secondary module for the app’s backend that processes the FPA. The FPA processing backend would be composed of the current python scripts we use for calculations that are currently on the laptop. 
• There could be latency with communicating between two BLE devices (foot mounted wearable + vibrotactile device on the shank), such that the vibration feedback is not able to be sent within our range outlined in our design requirement for intuitive feedback
  • Mitigation: if there is issues with latency, we will just have one MCU on the foot mounted wearable and long cables connecting this MCU to the component worn on the shank so that there is only one BLE device communicating with the laptop and driving the LRAs 

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?

Since the FPA processing for an active session will be done on the smartphone, we are now implementing a backend for the mobile app as well rather than just having all the FPA processing be done using AWS. 

Provide an updated schedule if changes have occurred.

• No changes to the schedule since the updated Gantt chart we made for the demo. We are going to start testing with the mocap system next week.

How will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?

FPA algorithm (Lakshmi):

One of the engineering design requirements was to keep the calculated FPA under a certain degree of error compared to ground truth. To measure ground truth FPA we used mocap markers on the right foot along with our foot based wearable. We then processed the mocap data after collection to determine ground truth FPA, and compared that with the online calculation of FPA from our foot based wearable. I will be running RMSE calculations on the FPA angles, and transforming them to normalize them to the baseline mocap FPA to determine the average degree of error and error per footstep between the ground truth mocap measurement and our foot mounted wearable.

User Comfort (Rhea):

One use case requirement for the device was user comfort, such that the device is unobtrusive and able to be worn while walking for prolonged periods of time. After each experimental session I will provide a user survey where the participant can rank how they felt while walking with the device on. The average score for each users response to the questions will determine whether the device and the soft case I fabricated is comfortable to wear or not. Another use case was to ensure the vibration is interpretable, as we intend to incorporate scaled feedback based on the degree of error. To test this, I will have the participants wear the device and send randomized vibration patterns and intensities and ask whether they can distinguish between the varying intensities. Based on their response to the survey, I will determine whether the percentage of intensity needs to be adjusted or not.

Mobile App (Kaitlyn):

The main use case requirement for the mobile app is that our UI is easily interpretable. In order to ensure the app is an effective and intuitive supplement for patients, we will ask individuals to participate in a short usability survey featuring questions that focuses on identifying certain info in the interface, identifying data points, and correlating recommendations and FPA data. This survey can happen after an experimental session with the physical device, but if necessary can be standalone assuming we give participants the context of our gait retraining device. Based on the survey results, we will adjust the app’s UI/UX accordingly. Particularly, our metric of success is if 92% of survey answers (across 6 trials) are accurate, then we will consider our UI intuitive and user-friendly.

Full Device Testing:

The vibrotactile feedback should be intuitive such that the user can adjust their gait based on the vibrations they feel. After each active session, we will compute the number of steps the user was able to correct after receiving the feedback as a quantifiable metric for the interpretability of the feedback. By taking the percentage of steps that were either accurate or appropriately corrected after feedback out of all steps taken, we can see how well users responded to the feedback.

Our final test for testing the entire device is gait retention, where we will have the user (outfitted with mocap beads) walk on a treadmill with the intent to follow the corrected gait, without the device. By taking the percentage of steps with the correct FPA, we can see how useful this device is for long term rehabilitation.

 

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?

• Not able to demo the FPA angle live next week, we can only demo the vibration being wirelessly sent to the LRA/HD 
  • Updating the gantt chart accordingly 
  • Cutting down on the amount of tests we are going to conduct with the device due to time constraints
• Risks with the soft case not curing well in the mold / lots of air bubbles 
  • Making more iterations of the mold until there is one that provides the best results consistently 
• The parts we ordered were missing for most of this week (we have since found the parts) 
  • Put us behind track on taking the MCU/mux off the breadboard to start user testing
  • We ordered a third round of parts that should be coming early next week so we can finish that in the first half of the week 

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 changes were made to the system design. 

Provide an updated schedule if changes have occurred.

• We are still behind on integrating the FPA code onto our mobile app. We plan on finishing this up this weekend and early next week. 
• Still behind on testing the device with the mocap system, we plan to start that in the second half of next week 
  • We are also cutting down on the amount of tests we’re going to conduct. We are aiming to only complete the FPA estimation vs. mocap ground truth as well as the gait retention tests (we are getting rid of the tests involving participants outside the 3 of us as well as the marked treadmill test) 
• We have also decided that for our 3 page UI we want to focus on getting the FPA integration down first (the real-time session page) and then getting to the other two pages (long-term data, recommendations). If we don’t have time to implement them fully, we plan on building UI with no backend integration to show what our planned interfaces would look like.

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?

• We have addressed the previous significant risks with the case, as we now have a hard case, hard flex case, and soft flex resin cases. We are now informed of the different vibration effects through these cases and are moving forward with creating soft flex resin cases.
• The risks with the FPA processing accuracy are still existing, however we will be addressing these risks during the first two weeks of April as we will move forward with testing then
• (This is from last week, but we still need to work on FPA integration) 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 changes were made to the system design. 

Provide an updated schedule if changes have occurred.

• Since we were focused on fabricating the physical cases, we are still behind on integrating the FPA code onto our mobile app. We plan on finishing this up this weekend and early next week. 

Here’s a link to a folder containing all the photos for the case development.

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. 

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.

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

• 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.

• This is also the place to put some photos of your progress or to brag about a component you got working. 
  • Video demo link: https://youtube.com/shorts/WqcRfQyk5Io?feature=share 

(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.