Posted on

Team’s Status Report for 2/22/25

Currently the most important risks that could jeopardize the success of our project is the MVP being delayed by any reason, as getting the MVP off the ground and tested will reveal any weak points that we need to address. The MVP being delayed will likely mean we will be time crunched when trying to iterate. 

We made a modification to the timing requirements based on further research into the Amber Alert use case after receiving feedback. Initially, the system was designed with a 60-second processing requirement, which aligns with the average lane change frequency on highways (2.71 miles). However, after analyzing worst-case merging scenarios, which would require about 20 seconds, we found 40 seconds would be a more appropriate constraint for the MVP to shoot for as a middle ground between these two cases, which once achieved, we would continue to target that worst-case timing requirement. This would better ensure timely license plate detection before a vehicle potentially exits the field of view. This wouldn’t have any direct costs, but it may affect the requirements we have on the processor, depending on how long it takes to do model inferencing.

Another change we are making is moving to supabase for our backend server, as it presents a much more user-friendly interface for our use case targets (law enforcement, amber alert) and is more setup-friendly.

Our schedule has not changed.

In addition, we have worked on our camera to OCR pipeline, and have made two versions of the code we will use: version 1, version 2.

Posted on

Richard’s Status Report for 2/22/25

This week I worked on the presentation with Tzen-Chuen and Eric, especially with regard to the details of the implementation, such as using YOLOv11 and AWS Lambda in our final design. In addition, I worked with Eric on setting up the pipeline of YOLOv11 to PaddleOCR. I made two versions of the pipeline, one that first detects cars and crops those images, then into license plate detection and cropping, then finally PaddleOCR to read the license plate. The second one does not do the initial car cropping and goes straight into license plate detection. The google colabs can be found here and here. I also did some more research on how to deploy the models to the raspberry pi, and found that we should use NCNN models. For our mvp, we will use a python script that I am working on running on a headless os using the optimized models. As soon as the camera arrives, we should be able to make a basic MVP excluding the cloud server.

My progress is on schedule. By next week, we hope to have a dash cam module MVP and get metrics on the initial performance of the device.

Posted on

Tzen-Chuen’s Status Report for 2/22/25

This week had a spanner thrown into the plans. On top of a very important presentation for EPP that took more time out of my week than usual, the design presentation unveiled new considerations that need to be looked into.

The work that went into the design presentation helped the team straighten out the exact direction we want to head in, and the post-presentation feedback from professor Brumley was also extremely helpful. To incorporate that feedback into something tangible, I’ve been tinkering with Supabase and lovable.ai. Another group brought up that there may be an issue in our selected camera, and I’ve been doing some research into camera resolution, field of view, and how that relates to clarity at a distance.

What’s worrying is I haven’t received an email about our camera being delivered (suitable or not), and although the raspberry pi repository hasn’t been fully fleshed out yet I have a more complete picture of what needs to be done. Next week I should be more free to steam ahead and catch back up.

Posted on

Eric’s Status Report for 2/22/25

This week, I spent a lot of time working on the design review presentation and practicing since I presented on Wednesday. This involved doing research related to the Amber alert use case, specifically for our timing requirements, since we wanted them to be based on the expected situation. I found that the 60 second requirement was sufficient for an average lane change frequency on the highway (2.71 mi) but not enough for the worst case merging scenario (20 seconds), so I made that change to the requirements.    I worked more with the PaddleOCR testing to continue exploring how it performs under more extreme weather conditions. I also worked with Richard to set up the basic pipeline of YOLOv11 to PaddleOCR, where YOLOv11 crops the image down to the plate, and PaddleOCR uses the cropped image to do OCR.

 

My progress is on schedule. Next week, I plan to continue testing the PaddleOCR with the YOLOv11 model integration, and explore methods to increase performance. I plan to use larger datasets to see how the overall pipeline performs, as well as beginning to check the inference time.

 

Posted on

Team’s Status Report for 2/15/25

The most significant risk is that the edge compute solution may not guarantee enough performance (precision and recall) to meet our MVP. The contingency plan is having a two-phase approach where if more accuracy than the edge compute raspberry pi can give us is needed, we then send the image into the cloud, where a more sophisticated model can give us better results.

A change we made to the existing design was that we are now using a Raspberry Pi 4 rather than a 5. This change was made since all the raspberry pi 5s available in storage were claimed very quickly, and since we wanted to test our software as soon as possible on actual hardware, we took a raspberry pi 4 instead. While unfortunate that we’re unable to use the most powerful hardware available, this should not have any impact on our ability to create an MVP or final device since the process for loading the models on these devices are nearly identical. When we run our model, if the performance is in the order of magnitude fitting of a compact processor, we can spend our currently plentiful remaining budget on the more powerful raspberry pi 5.

We have trained the model we will most likely use for our MVP, a YOLOv11n model trained on an open source license plate detection dataset for 400 epochs. It can be found here. We have also looked into existing OCR methods and chosen the PaddleOCR out of them, which we’re currently experimenting with.

Aside from the model, the rpi 4 is currently being developed, with a github repo to be populated by next week. The camera module is also expected to arrive next week as well.

Part A written by Richard Sbaschnig:

A.

Our device aims to improve public safety. This is done by detecting the license plates listed in active amber alerts in a dashcam. Since these alerts are sent to identify suspected kidnappers of children, by increasing the search coverage of amber alerts with our device, law enforcement will be able to find these vehicles sooner and catch kidnappers sooner. This should also have a deterrent effect, since would-be kidnappers would be less inclined knowing that there are these devices all around that can identify their car and notify the police automatically.

Part B written by Tzen-Chuen:

Our device’s social considerations don’t quite appear as an obvious point of concern. The different groups that will be interacting through our device is the manufacturer, the consumer, and the potential child abduction victim. The main point of contention may be between the consumer/end user and the manufacturer, as the manufacturer may install our device without the end user being aware of it, but I believe that this can be mitigated through an explicit opt-in system.

 

Part C written by Eric:

Our license plate recognition system is designed with one of the focuses being affordability, utilizing low-cost Raspberry Pis and camera modules. This provides a more accessible alternative to expensive surveillance systems, ensuring that even communities with limited resources can use our system. This can be especially beneficial for those in rural areas with little existing infrastructure since our device would be mounted as a dash cam, allowing for wider reach and greater impact.

Posted on

Eric’s Status Report for 2/15/25

This week, I focused on researching and testing OCR models for license plate recognition. I experimented with PaddleOCR and EasyOCR, since I saw multiple users saying that TessaractOCR doesn’t perform well. I tested PaddleOCR’s and EasyOCR’s performance on license plates with different orientations and angles. To ensure accurate comparisons, I set up a structured testing workflow and collected sample images from various scenarios. After testing, I found that PaddleOCR consistently outperformed EasyOCR when handling rotated or slanted plates. Based on these results, I decided to move forward with PaddleOCR as the primary OCR engine for the project. I also started looking into ways to eliminate detected text that isn’t from the license plate number.

My progress is on schedule. Next week, I plan to work on integrating PaddleOCR with the YOLOv11 model, and figure out what changes are needed for it to run on the Raspberry Pi. If necessary, I will experiment with different PaddleOCR configurations to further refine accuracy and speed.

The image below shows PaddleOCR’s results on an example plate:

 

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.