Posted on

Brian’s Status Report for 4/27

Accomplishments 

This week, I went to Salem’s with Simon and Shubhi early on in order to get approval to test our full system, but we weren’t able to do so then because of availability issues with the IT lead. Simon and I then went later on in the week, and we were able to get approval to test, and we got some data to use for testing our fullness calculating module and line counting module. I also went to Giant Eagle this week and took pictures of a few different cart configurations (mostly very full carts), like so:

Because there is noise (in the surroundings), I cropped out the images according to the bounding boxes displayed when running the shopping cart model alone and tested relative fullness on them, but found that extremely full carts are for some reason hard to detect with the current implementation. I will need to refine the implementation in the next few days in order to hopefully improve accuracy, but the module seems to work fine with carts that aren’t as full. Testing the relative fullness module on the test footage we got from Salem’s, results are very similar. The carts with much less seem to be much more accurately counted for by the relative fullness module than the carts that are nearly full. I have tried decreasing the amount of Gaussian blur in order to increase accuracy, and while the returned fullness values are somewhat more corrected, they are still quite inaccurate (returning 65% fullness for the above picture on the left), which is concerning. I have also worked on testing the upload and download speed of different length videos, and I’ve created graphs of the relationship between video length and upload/download time. My internet is a bit spotty, so I am not sure if this graph is a completely accurate depiction of the relationship between the video time and the upload/download times. Here is my code and the resulting graphs: 

Duration Upload Time (Averaged over 10 trials)  Download Time (Averaged over 10 trials)
1 second 0.61s 0.32 s
2 seconds 0.92 s 0.47 s
3 seconds 1.35 s 0.53 s 
4 seconds 1.52 s 0.55 s 
5 seconds 1.61 s  0.57 s
6 seconds 1.65 s 0.59 s
7 seconds 1.80 s 0.68 s 
8 seconds 1.92 s 0.72 s
9 seconds 2.21 s 0.76 s
10 seconds 2.3 s 0.88 s 

Progress 

In terms of progress, we are still behind schedule by quite a bit. We should be testing the fully integrated system by now, but we have run into a few roadblocks with testing at Salem’s due to discomfort from the cameras by the employees. However, since we figured out workarounds to these issues, we should hopefully be able to get testing done by tomorrow or Monday in the worst case. I will work on trying to increase fullness calculation accuracy for the next day or two while we continue to gather testing data. 



Posted on

Shubhi’s Status Report for 2/10

This week, I was able to spend some time researching computer vision algorithms to figure out what options we had for programming the part of the system that detects the number of objects in a cart. From my research, I found that OpenCV has multiple builtin algorithms for object tracking which seem promising for our use case, and also given the ease of usability and integration with the rest of the system. We also presented our proposal presentation this week, which I spent some time working on as well. Given the feedback we received from our presentation, I am considering other options other than a CV algorithm to analyze the carts, but that is something I plan on discussing with my team early next week so we can switch gears if we decide to.



Posted on

Team Status Report for 2/10

Risk Identification and Mitigation Strategies

Primary Risk Concern: A major risk for this project is choosing an acceptable FPGA to support our hardware acceleration constraints. Which FPGA we choose is important, we want one that has enough logic elements to support our RTL implementation. 

 

Mitigation Strategies: 

To address this risk before any potential issues, we are planning on using an FPGA in the project inventory (we are planning on using the DE10-Standard at the moment since Cyclone V has much more support than Cyclone IV boards). Since there is only one of these boards in the project inventory at the moment, we can pivot to ordering another Cyclone V board online if the DE10-Standard is claimed by another team (we are considering this less costly FPGA: https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=218&No=1021&PartNo=2#contents). This will be a significant portion of our budget but our required items for purchase are not as expensive as this FPGA, so we will still be well within budget even if we need to purchase another FPGA. 

 

Design Changes: 

Although we have not made changes to our design yet and will continue to discuss this on Monday, we are working to incorporate feedback from our proposal. We are considering changing our design to from being entirely wired to including wireless communication where necessary to improve our scalability. We are currently exploring our options still, but we are primarily looking at bluetooth. 

 

Schedule Change: 

After the proposal presentations, we realized that our Gantt chart wasn’t accounting for spring break, so we decided to change that and include a time for break. Note that the RTL implementation task likely will not be worked on during spring break, but we thought that it wouldn’t be as clear if we separated the same task into two different tasks.