ANPR Development: Why License Plates Aren't Read in Traffic Flow
At entry control, a decision is made in seconds: a car pulls up to the barrier, the frame goes for processing, the plate is checked against the allowlist — either the gate rises, or security comes out with a tablet and manually re-enters the sign.
If license plate recognition in the application fails, the queue at the entrance grows, and the operator manually handles what the automation should have covered.
Most often the issue is not the algorithm but the input data.
At night, the headlights of an oncoming car overexpose the frame; during the day, the sun hits the lens; in winter, the plate is covered with snow or dirt; and at speed, the plate's bounding box becomes blurred and skewed.
The detector either fails to find the plate area or finds it but smears the characters — and then license plate recognition errors come in batches: zero is confused with the letter O, eight with B, five with S.
The requirements of GOST R 50577 for the font design deliberately make such pairs similar, and they must be distinguished by geometry and context, not by a single character.
A separate category of failures is connectivity. The entire frame goes to the server, the response comes back with a delay, the application repeats the request and loses exactly the single frame where the plate was clearly visible.
On a weak channel, this turns into a persistent "plate not readable," even though the camera did its job.
On a test set, the claimed recognition accuracy looks decent, but at a live entrance it is determined not by the average but by the tail: night shifts, rain, skewed geometry, rare plate formats.
We analyze how this is addressed: where to place frame quality checks, what to compute on the device, and what to send to the server.
What Built-in License Plate Recognition in the Application Provides
Built-in license plate recognition moves verification to the approach stage: the camera in the application reads the plate, checks it against the permit database, and issues a command before the car stops at the barrier.
The processing time per car drops from 30–40 seconds to 3–5, and the lane stops accumulating a queue even during morning rush hour — the operator does not participate at all in the typical scenario.
The share of manual checks drops from "every second entry" to a few percent: unreadable, heavily soiled, or non-standard plates remain.
These cases go into a separate queue with photo capture and a reason tag, and do not block passage for others — the reduction in manual operations is visible here in shift workload, not in feelings.
The passage log ceases to be a manual summary: for each event, the plate number, time, checkpoint, verification result, and a link to the camera frame are recorded.
If verification fails, the reason for rejection remains in the record — resolving disputed situations with guests and contractors takes minutes instead of exporting logs and manual matching.
A separate class of errors is eliminated for repeat entries, when the same car passes several times per shift: by subscription, by one-time pass, exiting and returning.
The built-in check matches the event with the plate's history and does not generate extra triggers, while analytics on entrance load is built on the same data, without a second system.
Entrance automation delivers exactly what is verified during acceptance: seconds per car, share of manual operations, completeness of the log.
ANPR Development: Operating Modes and Limitations
The recognition mode determines where the model lives and what happens to the frame. This affects the application's behavior in an underground parking garage without network, battery consumption on the operator's phone, and how much data goes to the server.
We implement on-device recognition, server-side recognition from the camera video stream, and a hybrid scheme — and at the evaluation stage we show which mode addresses the task and which runs into scenario limitations.
| Mode | When it fits | Limitations |
|---|---|---|
| On-device recognition | One or two plates in the frame, need on-site response and offline operation; shooting from a tripod or from inside the car | Demanding on frame quality and phone resources: on weak models, battery consumption grows, long video streams are processed with dropped frames |
| Server-side recognition | Mass flow, parking lots and entry points, need a unified database and passage log | Does not work at all without network; response depends on the communication channel, frames are lost on weak coverage |
| Hybrid scheme | Need fast on-site response and server accuracy with unstable connectivity | More expensive to maintain: two models, priority rules, synchronization, and resolution of discrepancies between results |
The main limitation surfaces at acceptance — offline operation. If recognition is server-only, the application must put frames into a local queue and upload them when connectivity appears; when the buffer overflows, some passages are lost.
Therefore, for points with poor coverage, we plan in advance for degradation to an on-device model and separately describe which data remains in the log and which does not.
We do not transmit the camera video stream in full: frame selection and duplicate filtering remain on the device, and a compressed fragment goes to the server.
This reduces the load on the channel but adds delay at the selection stage — we measure its magnitude on your hardware before fixing the mode.
The hybrid scheme is chosen deliberately: we agree on priority rules and behavior for discrepancies in results in advance, otherwise support turns into constant investigations.
How Implementation Is Structured: Stages of Engineering Work
Implementing license plate recognition almost never comes down to connecting a ready-made module: the result is determined by the site geometry, lighting, and angle, not by the chosen algorithm.
Therefore, we follow a fixed sequence where each stage ends with a verifiable artifact — a diagram, a configured test bench, or a run protocol.
- Site survey. Visit to the site: entry and exit zones, camera mounting height and angle, day and night lighting, number of lanes and traffic speed.
- Data flow diagram. Where recognition is performed — on the device or on the server, which communication channel, how the event reaches the mobile application, and what happens when communication is lost.
- Camera calibration. Trigger zones, exposure, and detector threshold for the specific angle: the plate must be readable in oncoming light, in rain, and on a dirty plate.
- Integration setup. The event is tied to a scenario: permission check, opening passage, inserting the plate number into a request. Roles are separated by site.
- Recognition testing. Runs on real cars at different times of day: different plate formats, trailers, motorcycles, frames. We calculate the share of correct triggers and analyze each miss.
- Project handover. Documentation, access, procedures for false triggers and camera replacement, training of the operations service.
Delivery Package: Modules, Diagrams, and Procedures
After commissioning, the customer retains not only a working application but also a complete delivery package.
We hand over configurations, diagrams, and procedures in a form suitable for transfer to another team: without oral agreements and hidden dependencies on our infrastructure.
- Integration diagram — call sequence between the camera, application, and recognition service, exchange formats, timeouts, and failure points at each segment.
- Module documentation — interface descriptions, error codes, behavior during channel degradation, and rules for resending a frame.
- Recognition configurations — zones of interest, confidence thresholds, license plate templates, and operating modes when there is no connection to the server.
- Access policies for passage data — roles, retention periods, masking of plate numbers in exports, and logging of every database access.
- Operations procedures — frequency of updating reference databases, monitoring the share of correct triggers, and actions for incidents and rollbacks.
- Test set — annotated frames and videos from real site conditions, used to verify quality after any update.
- Deployment instructions — environments, parameters, rollout order, and post-installation checks.
Such a package removes the main risk — dependence on a single contractor. The module's logic can be verified, and support can be transferred to your own team or another contractor without reverse engineering.
Case Study: License Plate Recognition at the Entrance to a Logistics Park
Before: Queue and Manual Checks
The logistics park's checkpoint had two posts, and during morning rush hour the queue at the entrance reached 40–60 cars. Processing took 2–3 minutes: the operator manually checked the plate against the access database and duplicated it into the log.
According to the customer's own estimate, up to a third of records were lost during peak hours, and resolving a single disputed entry took half a day.
What Was Changed
Automatic license plate recognition (ANPR) was integrated into the security mobile application and the entrance kiosk: the camera reads the plate, the application checks it against the permit, and shows the operator only those cars where confidence is below a set threshold.
Regular transport passes without stopping, disputed cases go into a separate queue for review together with the saved frame. The log is filled automatically — export by time, lane, and pass type is available immediately.
Results
The morning rush hour queue decreased to 5–8 cars, average entry time — from 2–3 minutes to 20–30 seconds, the share of manual checks dropped below 10%, and log completeness reached 99%. The operator is no longer a bottleneck: one employee now covers two posts.
According to the customer's estimate, vehicle time losses at the entrance have almost disappeared, and disputed situations are resolved from saved frames in minutes.
What to Do If Recognition Is Already Integrated by a Third-Party Module
A working third-party recognition module rarely fails entirely — more often it "drifts" on some scenarios: night frames, skewed angle, dirty or partially obscured plate.
The share of correct triggers falls, and the cause is not visible: logs come in a foreign format, the model is closed, and support responds to a quality request by asking for another frame.
Rewriting the application from scratch in this situation is almost never necessary — there are three forks.
| Option | When it fits | Limitations |
|---|---|---|
| Refine the current module | Exchange contract is satisfactory, errors are concentrated in 1–2 scenarios | Need access to settings and a clear vendor roadmap; the quality ceiling is set by their model |
| Replace the recognition layer | Errors are spread across all scenarios, vendor does not provide metrics by segments | Module compatibility: different result format, its own requirements for frames and camera hardware |
| Hybrid scheme | Need an offline minimum and high accuracy on complex frames | Dual logic for merging results, more difficult debugging and model updates |
The choice comes down to one question — does the vendor provide metrics by segments: lighting, angle, frame quality.
If yes, it is often more advantageous to refine the application around recognition: clean up frame preprocessing, add a second pass on uncertain results, and filter out garbage before sending to the module.
If there are no metrics, we plan a solution migration.
We wrap recognition in our own interface so that replacing the engine does not affect business logic, collect a test set of frames from the customer's real cameras, and compare options — including offline on-device recognition via Google ML Kit — by the share of correct triggers and response time. Acceptance is based on these numbers, not on a demonstration with one lucky frame.
Technical Doubts and Frequently Asked Questions
Engineering doubts around ANPR are almost always the same, so below are short answers to what we most often discuss with customer technical teams: required accuracy, behavior on unsuccessful reads, operation on weak connectivity, and upgrading an already released application.
What recognition accuracy is considered sufficient?
Accuracy is a property of the scenario, not a single number. The camera provides a series of frames of the same car, the algorithm merges them into one result and returns a confidence score; everything below the threshold goes to manual review. We configure the threshold for the task — it is different for parking and for access control.
What happens if the plate is not recognized or is recognized incorrectly?
The scenario is not blocked: the event is marked as uncertain, frames are saved, and the decision is made by the operator or a rule — confirm, correct the plate manually, or skip.
Without connectivity, recognition runs on the device, records wait in a queue and are synchronized by identifier and timestamp, so duplicates are filtered out.
Can recognition be added to an application that is already in operation?
The refinement goes as a separate layer with its own interface, so screens and accounting logic remain the same.
The update is delivered by the standard mechanism, and we check compatibility with older versions before publication — modernization does not turn into rewriting the product.
What cameras are needed and what about support after launch?
A regular camera will do: what matters is the angle, even lighting, and absence of glare from headlights. We choose installation points on site before integration.
After launch, we monitor the share of successful reads per camera and update reference data when plate formats change.
Let's Discuss the Task and Come Back with an Implementation Plan
To discuss the task substantively, we need to understand the shooting scenario and the place of recognition in your process.
An ANPR module behaves differently: a stationary terminal at the entrance, shooting from a moving vehicle, or manual capture by an inspector — this determines the frame capture logic, angle requirements, and exactly where recognition is integrated: on the device or on the server.
To evaluate the project, it is enough to send:
- target scenarios: entry/exit, parking, access control, patrol, reconciliation with the registry;
- how plates are currently captured and what happens with the result — log, backend, dispatch;
- application platforms to support and the cameras operating on them;
- behavior on weak connectivity: is an offline queue and later upload of recognized frames needed;
- exchange formats with your accounting system and access to the test environment;
- security constraints: where images are stored, retention period, who sees the data.
In return, we send an implementation plan broken down into stages: preparation of cameras and reference sample, recognition setup, interface integration, acceptance on real plates, and production rollout.
Attached to the plan is a scope of work with responsible parties and acceptance procedure for each stage, so that the project estimate is verifiable rather than subjective.
Describe the task in any convenient form — we will come back with an estimate and a plan.