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.
