Summary
We made progress over the last week on multiple fronts:
- We finished the Design Report for submission with all the necessary specifics that demanded more research, facts and figures to support our arguments regarding the technological applications and rationale behind our design choices.
- Worked on and successfully deployed the webserver that connects the Rpi to a mock database to store information and queries from it.
- Performed a substantial amount of training on the YOLOv11 model and figured out ways to improve object recognition for new items
- Created new datasets to be able to train and minimize bias in the training of the ML model
- SQLite and Amazon RDS were modularly implemented and unit-tested successfully
- CAD designs for the RPi camera have been created that will need to go into print for our setup
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?
As mentioned earlier, our most significant risk is the performance of our ML object detection model, as the quality of our product is directly tied to its performance. Integrating the querying process will help improve the object detection accuracy of our model, however, we are working on creating customized datasets for commonly misplaced items (pencils, wallets, keys) in order to improve our model’s performance and accuracy before resorting to querying.
Our second risk is the fact that we have yet to test the performance of using the cloud architecture versus doing it locally. Our efforts have been parallelized in creating both sets of infrastructure but they have yet to be integrated well enough to be able to do performance testing. We have allocated a good proportion of our time to work on integration and then test out all our metrics in order to evaluate this.
Our third risk is the fact that we have been striving toward creating a preliminary model with only 1 camera. Hence, in order to support more cameras, we may have to make a few more design changes in the infrastructure to get better images and work on the algorithm to choose the image. We have allocated a few days to work on this after the aforementioned risks are mitigated.
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 have been no further changes to the requirements, block diagram, specs etc. We have been implementing subsystems as intended and carrying out unit testing for each subsystem to make it meet our benchmarks.
We have yet to work on our text-to-speech model, but all our efforts are going into hitting mvp before we aim to include other components in our system.
How the product solution you are designing will meet a specified need
Part A was written by Giancarlo, Part b was written by Ethan, Part c was written by Swati
Part A:
Our solution will address considerations regarding global factors primarily because of how we have designed with modularity as a primary goal. For example, it would be easy for us to add functionality to our server which translates queries from one language to another. Additionally, because we already plan on using vector distance on the queries to determine which object we recognize is closest to the object the user is searching for, we should be able to account for differences in local dialects.
Additionally, if users from a specific demographic would like our model to detect a new object, our modularity allows us to easily train a new model on our own hardware, and upload it to customers in the form of a software update.
Part B:
Our solution aims to address cultural factors by ensuring the privacy is a large focus. Some cultures may be hesitant to have a camera in their home supplied by a company that they personally are not a part of and for that reason, we aim to provide the option of having all processing happen locally. In addition, we are considering creating various designs for different aesthetic standards that various cultures have. Though one cultural consideration we are not able to bypass is cultures that dislike all electronics. Given that we run a vision model we can’t accommodate said group unfortunately meaning our potential base of costumers is not 100% of the world but close to it.
It will be difficult to promise any more than this. If an individual has a religious or moral belief that they should not have pictures taken of them, or that they cannot use electronics on a certain day of the week, or they don’t have access to power or internet, there is not much we can do to in these circumstances, even if there is a need for a solution to the problem we are trying to solve for an individual in these circumstances.
Part C:
The product solution we are designing addresses the critical need for locating misplaced items in households while considering environmental factors. We aim to minimize the system power consumption, in order to make it power efficient. Additionally, using cloud services like AWS allows for optimized resource allocation, ensuring that computational demands do not require excessive hardware setups that could contribute to electronic waste.
Moreover, our product can help reduce unnecessary manufacturing and resource consumption by enabling households to reuse items they might otherwise replace after misplacing. Instead of purchasing new products to replace lost items, this system encourages responsible use and reduces waste in line with sustainable living principles.
0 Comments