Some risks we noticed were the RPis we were planning to use with our UWB node weren’t fully compatible with our design. Additionally, a risk that also came to light was the possibility that RPi 5s wouldn’t be consistent in their compatibility with other aspects of our design, such as the UWB nodes and Microphones due to port configuration. Furthermore, what we expect for our project is the fact that we have so many moving parts and modules that depend and interact with each other. If we get slightly delayed in development of one part, the delay could cascade down our schedule and cause pretty bad problems in terms of development down the line. We plan on mitigating these risks by first testing with the RPi 5 to ensure that they work with our modules, as well as including slack time in our schedule to ensure that if we are delayed, we have sufficient time to catch up and finish before any deadlines. As of right now, the only potential change to our design might be the shift from using the RPi 5s to the RPi 4s because of the powering/communication issue that could happen with the Pi 5s and the UWB tags. We do want to test both and see if there is genuinely an issue with the Pi 5. If the Pi 5 works, we’ll stick with that because we already got several from the inventory, and we wouldn’t have to use a portion of our budget on purchasing 4 different Pi 4s. Additionally, we switched to using BLDC motors instead of stepper motors, as we realized the VESC motor controller we’re borrowing from inventory doesn’t support stepper motor operation. Not many costs are incurred, as connections all stay the same.We slightly delayed our ordering schedule to wait for the design review from our TA and Professor Qing. This way we can adjust the bill of materials accordingly within specification. We are now planning to order the necessary parts before spring break starts on 02/28. Doing so will allow us to have the necessary parts and initialize our first prototype.
