• 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?
Currently, the most significant risks that could jeopardize the success of the project would be connecting everyone’s parts together and making sure the communication between the components work properly, smoothly, and on time. In order to manage these risks we have thought of alternatives to mitigate this. One of the contingency plans would be to host all the data from different parts on online and we will just be pulling from it from the iOS app. We are also working together very closely and making sure each small step, change we make towards integration does not break the other parts.
• 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?
We might be hosting our data from different parts (obstacle identification and presence and direction online instead of using bluetooth), as of right now, some funky thing happened and we are not able to connect the raspberry pi to bluetooth for some weird reason. So if we do not get that figured out we might be hosting our data online for the IOS app to pull. This is necessary in order to have the three parts communicating to each other properly and work well. In terms of costs, the user would have to have access to internet all the time, but at this day and age, everyone has access to the internet! This assumes that the user has access to the internet. In order to mitigate this cost, we will encourage users to be at wifi spots more.
• Provide an updated schedule if changes have occurred.
We have no updates for our current schedule.
EXTRA:
List all unit tests and overall system test 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.
In terms of unit tests carried out:
iOS app:
For the iOS app, we tested the app on 12 users, like mentioned by last week’s status report (from Oi’s). We blindfolded users and asked them to navigate on our app. In terms of changes made, we made messages shorter but that is because users told us that long descriptions/notifications does not give them ample time to react and move safely. So that is what we’ve changed.
I have also tested that the device can remember the latest bluetooth device it was selected to pair with, and it could remember fine.
Sensors:
we’ve done tests to make sure that our sensors can detect the presence of objects and classify each sensor’s direction properly, the objects within 1-3 meters from the users were properly detected. (distance and direction tests of objects’ presence).
Machine learning model:
The ML model was tested for accuracy and latency. The accuracy was tested by running the model on both validation and test datasets. The validation test allowed us to ensure that we weren’t overfitting the model, while the testing dataset allowed us to test the overall accuracy of the model. The latency of the model was measured by running about a 100 test images and the average latency for the model was around 400 ms.
Headset:
We had users test on our headset prototype design, and we’ve found out that users also found too many sensors annoying and agitating. So we’ve decided to change that to 5 sensors instead. We want both practicality and comfort and want to be able to balance it. That was a trade-off we were willing to make.
Overall System:
In terms of the overall system, the tests that we’ve made is that everything can stay connected together and send data and read data from another fine. We still need time to verify this before we let this go. But if not we’ve already made plans like said earlier.
We’ve also measured out the lengths of the wires to the raspberry pi (from the sensors) to make sure that the user will find it comfortable. We want wires to be long enough but not too long that they are dangling everywhere. We also had to account for the possible height differences for our users and make sure that the wires are long enough from the top of one’s head to their hip. for now, we aim for that to be around 65 inches, but will do more testing on that as well.
We’ve also conducted battery testing and found out that we are within the required battery life goal, so that is good!
We are also planning on having the same 12 blindfolded users navigate in a room of obstacles (still and moving) with our app blindfolded once integration works together and gather more feedback.