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.