Category: Team Status Reports

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.

The most significant risks is the integration, which during our test, we found that sometimes the voice command was severely delayed due to unknown reasons, which only after several voice prompts, the corresponding output can be delivered. The current solution has been using multithreading to manage all long-delay tasks such as speaking the obstacle. The contingency plans including merge different voice prompt into one, spawn less process, and prioritize for high-important obstacles such as humans (since they are moving).

No change is made to the system design. No updates to the schedule. We are on track now for testing.

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.

The most significant risk right now is training of the collected dataset. As the collected dataset will mostly be used to facilitate the accuracy in certain locations, where the collected data will actually improve detection accuracy will be significant to the meeting of the overall requirement. We manages those risks by trying to change the existing YOLO algorithm by slimming the output layers only for a limited amount of obstacles that might appear in hallway, and then, using public dataset will have a better effect.

We have not changed the block diagram as of now. Depend on the output accuracy of the training data, we might have to lower the accuracy and detection range due to hardware/software limitations.

The schedule is unchanged. We plan to deliver the model by Monday.

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:

 

 

Team Status Report for 10/07

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?

Sensor integrity within a short amount of time had posed challenges for our implementation of the design. As we are trying the test the LIDARS and Cameras, we realize that the LIDAR’s range change is dependent on the amount of light, so we need to factor the effect of solar power into our design. As we are still in the early stages of the design cycle those problems can be easily managed by autotuning the parameters depending on the camera light input level and internal API from realSense LIDAR.
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?

There are no changes to the requirement since the design review presentation. We will continue to work to have one goal in mind.
Provide an updated schedule if changes have occurred.

N/A

Please enumerate one or more principles of engineering, science and mathematics that your team used to develop the design solution for your project.

To develop the design solution of the project, we have utilized system engineering principles of high-level designs and block diagrams to clarify the solution using high-level logic. Additionally, we utilized knowledge of software engineering to carry out the coding. We have utilized the idea of a controlled experiment to test out the behavior of the real-time LIDAR in different lighting conditions and environments. Then, we are developing a statistically based machine learning model to detect and tag the object, which is a mathematical model.