Team Status Report for 11/22

Risks and Mitigations

Our team has fully integrated all the software side of the system. The biggest risk for now is the physical connections not having stable connections for long term use. Since we changed around our physical design pretty late and put in the orders late as well, we have to speed up the process of CADing the new design and connecting the camera, display, lights, and the SBC in a stable manner.

Another risk is to have the user sessions be intuitive  (touch screen display being comfortable to use), since we changed our design from using buttons to a touch screen.  We designed the UI to have menu items + ordered a larger display, but we plan to conduct user study pretty soon to gather more information on how comfortable it is to use our product.

Our latency risk has been mostly fixed this week by parallelizing our models with threads and shortening the preview. The blaze face also does a great job quickly capturing our face for each session. We will continue testing the latency to ensure that we consistently hit the target latency.

Design Changes

We are using a real mirror and a 7 inch display so that the user can more clearly see their face and the analysis results. These were the physical changes mentioned last week (we have decided to confirm on the changes).  Our overall system has the same functionality.

Schedule

Our team is pretty much on track! We plan to focus on testing next week.

Team Status Report for 11/15

Risks and Mitigations

This week, after the interim demo, we got some feedback on improving the physical design. It was harder to see through the mirror film for our screen display than we imagined. One suggestion made to our group was to change our design so that we have an actual mirror and the display right beneath the actual mirror instead of a see through mirror film. This would improve the quality of the reflection as well as the screen display. Although we are still contemplating on what design to go with, we have placed and received the parts to change our design as suggested.

We also got feedback on our latency for our inference models. We didn’t have the time measured for the inference models, and we got questions on whether our product will meet the timing we aimed for. After the interim demo, Isaiah measured the time for each inference models, which averaged 2.01 seconds. We are planning to figure out a way to run the models in parallel to achieve the timing for our MVP.

Besides the two concerns mentioned above, we are still working on improving the accuracy of our models. Isaiah is still working with the models to improve the accuracy, while Siena and Corin are working with the lighting that is optimal for the input image.

Design Changes

As mentioned in the first part of the section above, we are contemplating on getting rid of the mirror film and replacing it with an actual mirror. The display will be beneath the mirror instead of behind the mirror film, if the design changes. None of the software side will change, and our product will still deliver the same functionality (just a slight modification in the physical side of the product).

Schedule

We are pretty much on track!

 

Team Status Report for 11/8

Risks and Mitigations

This week, we worked on integration and put together a mock mirror for our interim demo. Through this process and by testing the integrated model, we noticed a few challenges. 

  • Reflection – The quality of our “mirror” functionality is low. We plan to address this by adding a black background directly behind the two way mirror (in areas excluding our LCD, of course).
  • Lighting – Lighting heavily impacts our analysis results. We have yet to install the LED lights discussion in our design report, so adding that will help us get more accurate results. 
  • Rounded cornet design – The plywoods we currently have don’t bend well, making it difficult for us to fill the edges of our casing. We plan to look into a different material for this. However, it would also be fine to have 90 degree corners instead of the rounded ones as it will just affect the appearance of the mirror, not the functionality.

 

Design Changes

After testing the mirror, we decided to add a preview feature before a picture is taken so the user gets more feedback from the system. It reduces confusion on the user’s end as they don’t have to guess about whether they are in frame or not. However, this won’t affect other aspects of our design. 

Schedule

No change to schedule! We are on track 🙂 

Team Status Report for 11/1

  • 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?

This week all of our parts arrived! We have progress in most of our subcomponents, but because our parts arrived on Thursday, we didn’t have too much time to integrate all of our subcomponents. As we transfer our parts one by one, we are expecting a lot of hurdles in putting everything together.  Siena was working with another camera before our actual camera arrived, and there was already a problem with the new camera that we didn’t encounter in our old camera. This is preventing us from connecting it to the rest of the hardware (buttons and the screen with the mock app).

We also need to start combining all of our mock setups with the actual data input/output from our camera and the ML model. During this process,  we will need a lot of communication/trial and error, since we expect various compatibility issues with our mock data formats and actual outputs from the camera and ML model.

Isaiah is done training the models for the majority of our classes. Since most of our subcomponents are done, we aim to mitigate the risks that comes with integration by working together next week to connect everything  – the camera inputs to the model and the model outputs to the display (app).

  • 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?

No changes were made to our existing design requirements. We just received all of our parts, and after checking them out and testing on a few components, we think it’ll be sufficient with our existing design.

  • Provide an updated schedule if changes have occurred.

The schedule didn’t change except that the hardware buildup/testing is going for a week longer (until the mid-demo) because our parts arrived later than expected. everything else will remain the same.

link to schedule: https://docs.google.com/spreadsheets/d/1g4gA2RO7tzUqziKFuRLqA6cGWfeL0QYdg5ozW9hug74/edit?usp=sharing

Team Status Report for 10/25

  • 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?

Our most significant risk for hardware persists from last week: our parts are still not here. However, through some snooping, we were able to find a few replacement parts available on campus (for example, a Camera Module 3 and a button). We have started working with them this week, but how we bring up the parts we ordered and some APIs may differ. This is now our greatest concern in terms of our hardware progress. To mitigate this challenge, we have been looking into the differences between our temporary replacement parts and our desired ones and finding their counterpart functions and more scalable interactions between the software. 

The most significant risk in software persists as well, the accuracy of the models. Similarly, the contingency plans involve gathering more data as explained in the design report/previous status reports. Additionally, if the sunburn model becomes exceedingly difficult to train effectively, this could cause the problem to get off schedule. The contingency plan mainly involves going back to gathering more data, but if that doesn’t solve the problem, then re-reviewing existing solutions and directly implementing them would follow.

  • 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?

No changes were made to our existing design in terms of hardware. 

We have been sticking to our plan this week!

  • Provide an updated schedule if changes have occurred.

No change in schedule!