Risk Mitigation
One vital part of our product solution is determining the relative fullness of a shopping cart using an edge detection algorithm. Edge detection can be potentially inaccurate, but it is the most important part of our calculation for figuring out which checkout line is the fastest, and therefore we need to minimize the amount of error in this case. Therefore, if our preliminary edge detection algorithm implementation has a larger error rate than wanted for figuring out the relative fullness of a cart, we will purchase more cameras (3 more, 1 extra camera per checkout line). We have enough budget to do this, and so it should allow us to achieve a higher accuracy rate with our edge detection algorithm given the extra camera angle to gather data.
Design Changes
We made many changes this week due to fleshing out our design. The most important change we made was eliminating the use of an FPGA in our project. We realized that speed isn’t a stringent requirement for our needs (we care about accuracy the most), and therefore we decided to just run the backend entirely on a laptop.
Furthermore, instead of detecting the number of items in a cart, which is error prone and very inaccurate, we are planning to use edge detection to instead estimate the relative fullness of a shopping cart and then use a metric of sorts to determine the approximate amount of time it would take to check out a cart that is x% full.
We are planning on changing our programming language of choice to Python from C++ because of our choice to leave out FPGAs from our design. Python will be much simpler to understand and code reviews will be more quick with this change. Looking into OpenCV, we observed that writing in Python does not generate much overhead compared to a C++ implementation of the same function, and so our change should not incur any unwanted performance issues.
Schedule
We’ve changed our schedule because of our decision to change our design to no longer incorporate an FPGA. Now Simon is working on software modules. Here is our Gantt chart:
Part A: Grocery stores are all over the world and an essential part of people’s lives. With our product solution, people will have a more streamlined and efficient shopping experience, waiting for a shorter period of time to check out of a store. Waiting much less time will help people spend less time at the grocery store and allocate more time for their other priorities.
Part B: Our product solution emphasizes the need for a timely and more efficient grocery shopping experience. Today’s society is greatly motivated by fast paced lifestyles and convenient solutions, which our system design caters to. With our system producing a timely result to users, we expedite the shopping process for customers who are on a time crunch and have other priorities that they want to spend their time on. Our system uses algorithms that analyze the queue length and cashier speed to cater to the cultural value of time optimization. We can see across many cultures that time optimization is important and multiple cultures have even put efforts towards creating tools and innovations that revolutionize the efficiency of daily operations. Additionally, our system is inclusive for different cultures where people might not necessarily understand the same language, but since we only deal with numbers, we are able to cater to multiple groups of people.
Part C: We don’t believe our product solution will have any significant impact on the environment. The only related aspect is the electricity the cameras and laptop will use, but compared to the cost of lighting and climate control for a grocery store, this will be negligible. Grocery stores use roughly 50 kWh of electricity per square foot per year and the average grocery store is 40k square feet, while a camera uses around 10 kWh per year, a standard laptop uses 450 kWh per year, and a small monitor uses around 500 kWh per year. Assuming a reasonable number of cameras (<100), the increase in electricity consumption will be less than 0.1% by my estimates.
Part A was written by Brian, Part B was written by Shubhi, Part C was written by Simon