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.
