Author: qiyouc

As this the last week of the course, there is no significant risks that could jeopardize the success of the project. We have already completed the project last week (include testing). Due to this, I don’t think there is any risk needs to be managed other than taking care of the system such that it does not break in presentation. A contingency plan for this would be always hold the system in both hands.

No changes were made to the existing design of the system. All the integration and other testings have been finished last weekend.  No update in schedule is needed.

Regarding the group question, our team has done unit test for each portion of our system and done integration test in latency and accuracy. A list of tasks we have done could be found below:

1. Battery Live Unit Test
2. Object detection model unit test in accuracy and latency for all different models we have tried.
3. Distance measuring script latency and accuracy unit test.
4. Speaker latency and voice quality unit test.
5. System Weight Test
6. Integration Test for whole system in latency and accuracy

For each test mentioned above, our respective findings and changes are:

1. Found battery lasted more than 2.5 hours => No change.
2. Found pre-trained model has bad performance in chairs, tables => trained another model explicitly for chairs, tables, etc.
3. Found latency is too high => revise algorithm using Numpy and pixel selecting.
4. Found latency and voice quality is optimal => No change
5. Found weight less than 5 pound => No change
6. Found latency < 500ms in average and accuracy >= 85% for big close objects => No change

These indict that our model satisfies all the use case/design requirements we have set at the start of the semester.

This week, our team inputs significant effort in interim demo and is proud to have a working demo that demonstrates the successful integration of different parts each teammate worked on and a complete working project.

The most significant risk that could jeopardize the success of the project is how to stabilize the image captured by the camera such that the image sent to the neural network isn’t blurry which could jeopardize on the accuracy of the model. Our team recognized the issue at the design stage and has following plans to handle it: 1. Have stabilizer attached to our camera to reduce the shaking. 2. Increase number of frames taking per second to increase input data size.

No change was made to the existing design of the system. Our team (Jeffery takes a lead on this) is developing the hardware/mechanical part of the system such that the Jetson/Camera/Speaker can be carried by a blind person easily.

No change in schedule.

In this week, our team puts significant effort on consolidating our ideas into a 14-page paper,  listing everything that that we have researched on and will accomplish for our project.

The most significant risk would be if the Yolo implementation has lower accuracy than we expected such that it would not reach our design requirement. However, even if this happens, the risk can be managed by training of the network, ruling out edge cases, and tuning. At least three other contingent plans are listed in section 5 of our paper and edge detection method will be the next algorithm we will pursue if the Yolo method does not work.

Quite a few changes are made to our design in the algorithm we use for object recognition. This week, the team decided to pursue Yolo as the primary algorithm such that the SLAM ways are now ranked the third after edge detection algorithm. We believe that Yolo is simpler to implement without too much loss of accuracy and the change will have no costs going forward. By using the Yolo model, we could reduce the development time cycle and put more time into testing and tuning instead of building the model ourselves or constructing a SLAM.

There has been changes made to our schedule. The detailed schedule can be found as a part of the picture but also in the picture below: