Posted on

Tzen-Chuen’s Status Report for 2/15

This week I was working on setting up the raspberry pi for more streamlined work. This mainly consisted of determining the OS, headless or GUI, and general design goals. I also put in the order for the raspberry pi from ECE inventory and the camera module from adafruit, specifying that it should be the 75 degree No IR filter variant. While not ordered yet, research went into ways that a raspberry pi can acquire GPS data. After ordering there was pickup, and sourcing an HDMI to mini HDMI cable.

Next week will be actually hacking the code together, and while I don’t think the raspberry pi portion of the code will reach MVP, there should be significant progress in data input, and transmission. The data server still hasn’t been designed as of yet, it is scheduled for tomorrow’s group meeting where we work on finishing the design presentation slides.

I am progressing on schedule, and my deliverable for next week is a github repo with a partially coded raspberry pi. The camera should arrive next week as well.

Posted on

Richard’s Status Report for 2/15/25

This week I worked more on the YOLOv11 model as a possible model for license plate detection. I set up a workflow to make training these models very easy on the ECE machines so that we do not waste our budget. After doing this, I trained the YOLOv11n model for both 100 and 400 epochs to get a good baseline model for testing on our raspberry pi and getting to MVP as quickly as possible. The models can be found here. The precision of the 400 epoch model is 0.984 and the recall is 0.964 on the validation dataset. After training, I researched the best model file types to which I should export my trained model, and I discovered that TensorFlow Lite is a good option, especially for edge devices. After some technical problems, I was able to export the Pytorch-trained model to ONNX and then to TFLite. I tried to export with INT8 quantization to further improve performance on an edge device, however, I faced many difficulties and was not able to do it.

My progress is on schedule. Next week I hope to load the model onto the Raspberry Pi and test its performance metrics on the device, specifically on how long inference takes, so that I can figure out if I want to use a different size model or if I need to get quantization working.

Posted on

Eric’s Status Report for 2/8/25

This week, I worked on the proposal presentation slides, conducted background research on license plate recognition methods, and explored available recognition models like OpenALPR, EasyOCR, and YOLO. I also examined competitors, including Genetec, PLATESMART MOBILE DEFENDER, and Nvidia Metropolis. I experimented with online available solutions and found that current methods usually involve several steps of narrowing down the image to the license plate before running OCR. For example, they would locate the car in the image, then the license plate, and then run the character recognition. In my research, I also discovered that OpenALPR, although free, has not been updated in 5-7 years and seems to have relatively poor performance compared to more modern alternatives.

My progress is on schedule, and next week I plan to work on the design proposal, research available and relevant datasets, and try the baseline yolov11 without fine tuning to see if license plates were already one of the classes in the training set and how it performs. I will also research different preprocessing techniques to improve recognition accuracy under varying conditions such as lighting and motion blur.

Posted on

Team’s Status Report for 2/8/25

The most significant risk is likely not being able to get the edge-compute model working well enough in time, and not having enough time to switch our integration strategy to have the license plate recognition happen on the cloud. As such, we are looking into both edge-compute models as well as models that we could use to run on the cloud, and are considering how we would integrate them in each scenario so that any necessary transitions can be made without too much trouble.

The design was not solidified before this week, but the fundamental requirements have been selected, namely image recognition latency and plate detection range. These “changes” are necessary as we need concrete and realistic goals to work towards while building our design. The costs that this change incurs are minimal, as the design was not formalized previously. 

Since nothing has changed from our plans, only that our design approach is solidifying, we have not made any changes to the schedule. However, we are looking into how we can make an MVP as early as possible to begin testing early so any major changes that need to be made will happen earlier in the process.

In investigating models for license plate detection we have made a jupyter notebook for training YOLOv11 for license plate detection, linked here.

Posted on

Richard’s Status Report for 2/8/25

This week I worked on the presentation slides, researching amber alert data/statistics, competitors such as Plate Recognizer, and the requirements for our project, as well as adding detail and polish throughout the presentation. After some research into how others have implemented license plate detection, I worked on investigating the feasibility of using YOLOv11 as a base model for license plate detection, since it is popular in the space, and have looked into ways to fine-tune the model for this use case. I have made a Jupyter Notebook file that will tune the model for license plate detection using an open-source dataset I found online, and I have explored ways to have this training run on sites like Google Colab and Kaggle, as well as on the CMU ece machines. Right now I am learning toward using the ece machines due to the strict GPU restrictions with using google colab and kaggle for free. The link to the jupyter notebook is here.

My progress is on schedule. Next week I hope to have completed training on the YOLOv11 nano model on the dataset for around 100 epochs and get some preliminary data on its performance. I would also like to find out how to load the model on a Raspberry Pi and get some metrics on how fast this trained model will run on the device.

Posted on

Tzen-Chuen’s Status Report 2/8/25

This week I worked on things related to project management and direction mostly. A large portion of this was working together with Richard and Eric on the design proposal slides. While we all contributed to the overall design through discussion and research, I was the one who put together the Gantt chart. Additionally, the task of presenting the design was me, so I also practiced myself before the presentation, running through possible questions and developing fluency.

Outside of the presentation, I’ve been working on ironing out the raspberry pi and camera module details, by pouring over the documentation on the site. I’ve also been researching the best possible solution for our small-scale data storage needs when the raspberry pi uploads data to the server.

My progress is ahead of schedule, and next week I plan to have the overall design of the system and how each portion connects to each other sorted out and ready to start building towards an MVP.