Tag: status report

Risk Mitigation

Now that we are training several models to go through with our CV algorithms, we realized that due to time constraints, it is imperative that we get this done as soon as possible. To do this, we are using YOLOv8, which is very user friendly, and we are training models from datasets that are publicly available whenever possible. For example, we are training models from datasets of shopping carts that are publicly available and of datasets of grocery store items that are publicly available in order to save time. 

 

Design Changes

Nothing has changed about our design. We are still implementing throughput calculations for cashiers, relative fullness calculations for carts, and detecting how many people are lined up in the same manner as was determined before spring break in our design report. 

 

Schedule Changes

Our Gantt chart remains unchanged from before. 

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 

Risk Mitigation

While we don’t have too much currently planned for our budget, it is imperative that we use it wisely when ordering cameras because of our design. Our design uses two cameras per checkout line, which gets very costly as we order more cameras to complete our system integration later in the semester. Therefore, we are currently just ordering one camera for testing and then we can change our camera if hardware requirements aren’t met, and not spend too much budget on this.

 

Design 

There were no design changes made to our system as of now. However, we are discussing what we need to do to handle choosing the correct frames in the real-time video footage we are receiving in order to not process redundant data, and how to handle the line decreasing in size.

 

Schedule

Our Gantt chart has not changed overall as of this week.

We spent part of this week talking about potentially changing the system to include a different type of sensor to observe the number of items in every cart. After discussing with our faculty advisor and talking between each other, we decided against it since it would have been an additional effort to integrate it into our system, something we didn’t think was worth it. As a team, we spent the rest of the week fleshing out and implementing the architecture of our system while also working on the design review slides. 

 

After doing some more research into how OpenCL works, we realized that OpenCL converts kernel code (C/C++) into RTL and synthesizes it, in which case our Gantt chart needs to be modified. Now, our schedule has a dependency where we need to have an algorithm in OpenCV, then find the portion of the code that needs to be sped-up, and make a C/C++ implementation from Python so that we can accelerate it using OpenCL. Therefore, the allocation of tasks has changed and a few tasks have been shuffled/removed. Below is our revised Gantt chart:

A was written by Simon, B was written by Shubhi, C was written by Brian

Part A: Our system expedites the grocery shopping process, which hopefully alleviates some of the frustrations that might arise from having to wait in lines. With regard to public health, a more pleasant shopping experience could encourage people to shop for their own groceries more frequently, which tends to be healthier than eating at restaurants. This also benefits public welfare, since our system aims to make the basic need of buying groceries more convenient. Where safety is concerned, the use of cameras in our system could be concerning for the customers. However, the only data we aim to collect about people is the number of them (and not who is) in a line at a given time, and we will not be storing any significant amount of camera footage. Furthermore, people are already monitored in grocery stores through security cameras, so our additional cameras will not be capturing any information that wouldn’t already be known for security purposes.

 

Part B: Individuals are bound to have a better shopping experience where they are able to save time at the grocery store. People are more likely to return back to the grocery store and make more visits if they have a positive shopping experience, almost fostering a sense of community at the grocery store. Many demographics of people don’t get a lot of social interaction, such as the elderly, and a positive grocery store experience provides an opportunity to foster that sense of community and increase social interaction between such groups. Integrating a system that decreases the time it takes to get to the checkout counter also decreases the overall time a customer spends at the store, which is more time to spend elsewhere that can be directed to bettering society. 

 

Part C: Our system increases the speed at which customers are able to check out of the store, and this could allow for stores to become more popular due to customer satisfaction with checkout times. With increased popularity, a given store using our system could increase revenue and by extension profit. Also, with faster checkout times, a store might not need as many cashiers to man the counters, which would also increase store profits due to cost cutting.