ANPR development: where license plate recognition breaks down
A car is stopped right at the barrier, its plate is in frame, but the system is silent — and twenty seconds later a queue forms at the entrance, stretching into the street by morning.
The driver backs up and tries again, security opens manually, and the log keeps a record with no plate attached. This is exactly what a failure at the entrance looks like when license plate recognition works “well on average” but stops working at a specific lane.
The cause is almost always geometry and light, not the neural network itself. The camera hangs at an acute angle, the plate gets compressed by perspective, low sun or oncoming headlights hit the frame, and in winter dirt and snow on the plate frame add to it.
Add trailer and temporary plates, motorcycles with square plates, LEDs in the letters — and plate reading accuracy on paper becomes far from the accuracy at this entrance.
The second layer is software. The frame for recognition is taken before the car enters the detection zone, the zone covers two lanes at once, confidence thresholds are set for a different angle.
Then even a correctly read plate does not reach the controller: the result is discarded by a filter, and vehicle access control gets emptiness instead of a decision.
We break down how this is addressed: first we capture real traffic statistics — the share of passages where the plate is read on the first attempt without human involvement — and use that to design the entrance layout, exposure, zones, and decision logic.
What accurate recognition delivers: throughput and reliability
Recognition accuracy is not an abstract percentage but the number of cars a post lets through per shift without human intervention.
Every unrecognized plate turns into a manual operation: the operator checks the frame, searches for the record in the database, and opens the barrier manually. On a flow of several hundred cars per hour, such episodes add up to a queue at the entrance.
Post throughput
The passage decision is made while the car approaches the barrier: the detector highlights the plate frame, and the model reads the characters in fractions of a second.
Passage time is reduced to 2–4 seconds; with continuous flow, the lane lets through up to a thousand cars per hour. Processing runs across all cameras in parallel, and the frame queue does not grow at peak.
If a node is unavailable, the second one picks up the stream: a brief failure does not put the post into manual mode for the whole shift.
Which class of failures goes away
Errors come not from the plate but from shooting conditions — an oblique angle, oncoming headlights, dirt, plate tilt.
The two-stage scheme (first detecting the plate frame, then character-by-character reading) is resistant to this, and the stream from Axis cameras and other manufacturers is accepted via a standard interface, without replacing the equipment fleet.
If confidence is below threshold, the frame does not block the lane: it goes into a queue for review, and the barrier triggers by rule.
The share of such episodes is fractions of a percent instead of single-digit percent, and the operator turns from a participant in the cycle into a supervisor.
Every passage is logged with plate, time, and frame, so troubleshooting a failure is viewing one image, not searching for a record.
Recognition options: stationary post, mobile, cloud
The recognition mode is chosen based on site conditions, not the “power” of the model: whether there is stable power and a communication channel, whether the shooting point changes, who makes the passage decision. Below are three schemes that are realistically chosen for facility entrances.
| Option | When it fits | Limitations |
|---|---|---|
| Stationary post | Checkpoint, parking entrance, fixed boundary with constant flow | Site-bound: installation of camera and lighting, angle selection for entrance angles |
| Mobile recognition | Patrol, temporary posts, interception, changing shooting points during a shift | Requires frame stabilization and power in the vehicle; reads plates worse at speed and when dirty |
| Cloud processing | Distributed sites where they do not want to keep a compute unit on site | Requires a stable channel; frame goes for processing with delay; video storage outside the customer’s perimeter |
What is chosen for distributed sites
For a network of sites, a hybrid is usually assembled: at the site, a local compute unit handles recognition and barrier opening, while the cloud collects events for consolidated analytics and model updates.
Passage then does not depend on the channel — if communication breaks, the post continues working from the local list, and discrepancies are synchronized later.
If there are few shooting points and they are temporary, mobile mode with frames sent to the cloud deploys faster and does not require installing a compute unit on site.
ANPR development: stages from survey to site handover
The work order is structured so that errors from early steps do not surface in operation.
First we deal with the geometry of passages and the nature of the flow, and only then select cameras and recognition modes: installation without a survey produces obstructed angles and blind zones that can no longer be fixed by configuration.
Site preparation before installation
The engineer visits the site and records what determines recognition quality: number of lanes, entrance angle, height of the plate frame, sources of glare — headlights, low sun, floodlights — and areas where the plate is blocked by a trailer or tow hitch.
From this data we prepare a placement scheme with calculated angle and distance for each post, and coordinate routes and power.
- Site survey: number of lanes, speeds, plate types, lighting mode at different times of day.
- Camera and lighting placement scheme, coordination with site operations.
- Installation and connection of posts, angle adjustment using a reference plate.
- Recognition setup: zones of interest, confidence thresholds, linkage with access lists.
- Live traffic run with event verification by video and manual labeling.
- Acceptance tests according to an agreed scenario and system handover.
- Operator training: response to false triggers, manual correction, working with the event log.
Acceptance on live traffic
We count not the average accuracy on a sample, but the share of correct triggers for each post during peak hours and in darkness — these are the modes where the system most often degrades.
Based on the results, we hand over access credentials, the placement scheme, configuration, and maintenance regulations, so the site can operate without our involvement.
What remains at the site: schemes, configurations, and regulations
The delivered system is not just a working barrier. We hand over to the site a set with which the in-house engineer can maintain recognition without us: this is an acceptance condition, not an addition to the project.
- Camera placement scheme with coverage zones, heights, and angles — it shows why a specific lane is read confidently and where false triggers come from.
- Recognition profiles for each entrance: which scenarios are enabled, which thresholds filter out glare, duplicate plates, and dirty plates.
- Vehicle access lists: permanent and temporary passes, passage rules by time of day and service categories.
- Operator action regulations for each emergency situation — from “plate not read” to manual opening and conflict investigation.
- System documentation: processing logic, failure points, recovery procedure after power outage.
- Maintenance instructions: cleaning optics, checking angles, calibration after repair or camera relocation.
Access rules and roles
We delineate who adds passes, who sees the passage log, who changes recognition thresholds. Rights are fixed in a role matrix, and settings edits remain in the log — when investigating a disputed passage, it is visible who changed what.
Maintenance regulations
Planned work is scheduled by frequency, with mandatory verification of recognition on reference passages. If accuracy drops after repair or a seasonal change, this set shows at which step to look for the cause.
Case study: recognition accuracy before and after reworking the scheme
A logistics terminal with four entrance lanes and a flow of about 900 vehicles per shift.
License plate recognition accuracy there held at an acceptable level until the first difficult conditions: oncoming headlights, angled positioning in the lane, a dirty plate — and the operator opened the barrier manually, adding data to the log.
What was there at the start
The share of correct reads remained around 87% — every eighth car required human involvement.
During peak hours this created a queue at the entrance, and manual passes did not enter accounting: the discrepancy between actual entry and weight data surfaced only during the morning reconciliation. The average passage of one car took 40-50 seconds, and for road trains it was noticeably longer.
What was changed and what resulted
The root of the problem was not the model but the shooting scheme. The cameras were repositioned at a working angle to the lane, the front and rear plate zones were separated and frames synchronized between them, and lighting was added in the visible and infrared ranges.
The detector based on YOLO was additionally trained on the terminal’s own archive, and disputed low-confidence frames go not to an operator’s eye but to a separate queue together with the already recognized fragment.
Result of implementation: the share of correct reads reached 99%, manual passes dropped to a few per shift instead of a hundred, and passage time decreased to 12-18 seconds.
The queue at the entrance stopped forming during peak hours, and the operator’s log turned into a queue of rare disputed frames.
How a ready-made platform differs from an in-house recognition model
A ready-made recognition platform is an assembled pipeline: the detector finds the plate frame, normalization straightens the perspective, and the classifier reads characters against a predefined vocabulary.
This path solves the task when plates are standard, the angle is moderate, and the flow is a parking entrance or security post.
But the confidence threshold, preprocessing, and vocabulary are set by the vendor: a crumpled or covered plate, night backlight — and accuracy drops, and this part cannot be adjusted.
An in-house model is needed where frames do not resemble the platform’s training sample.
Fine-tuning on your own fleet solves this in a targeted way: we label 2–4 thousand frames from your cameras, add rare formats and difficult conditions to the training set, and raise accuracy on the tail of the distribution that the ready-made solution loses. The cost is a retraining cycle and model version control.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made platform as an external service | standard plates, flow of several thousand frames per day | frames go to a third-party environment, weights unavailable |
| Ready-made platform in your own environment | data does not leave the perimeter, plates are standard | fine-tuning within the vendor’s architecture |
| In-house model for your own fleet | non-standard fonts, difficult lighting, need version rollback | labeled corpus, regular retraining |
We choose the approach by numbers, not by taste: we run your archive through a ready-made platform of the OpenALPR level and look at the share of plates read in full, separately from character-level accuracy.
If standard frames already show 98%, and errors are concentrated in one scenario, fine-tuning is enough. If the discrepancy is systemic, an in-house model becomes cheaper in operation.
Technical doubts: quality, integrations, limitations
Accuracy above 99% is not a property of the model, but the result of tuning for a specific entrance: camera geometry, flow speed, nature of dirt contamination, and access rules.
Therefore, before starting, we capture the site’s real traffic and calculate metrics on it, not on demonstration sets.
What to do with dirty, crumpled, and partially obscured plates?
Characters are recognized character by character, so the decision is made based on accumulated confidence: if a frame gives weak signals on one or two positions, the system collects several frames of the passage and refines the result using them.
For sites with constant contamination, the model is fine-tuned on a local sample — the share of correct triggers grows by tens of percent relative to the baseline.
How does the system work at night and in rain and snow?
In darkness, lighting and short exposure play the decisive role: without them the plate blurs with motion.
Frames are taken from the video stream in tens, not individually, and combined into one inference — glare from headlights and droplets on individual frames no longer affects the result.
In heavy snowfall or downpour, recognition does not turn off but switches to operator confirmation mode.
How does recognition interface with the barrier?
The recognition event turns into a control signal for opening, not a command from the operator interface. Trigger delay, protection against repeated opening for a single passage, and a scenario for when the plate is not on the access list are configured.
In a doubtful result, the barrier does not open automatically — the event goes to the security desk with the saved frame.
How do plates get into accounting systems?
The recognized plate is matched with an entry in the reference database and transmitted to the accounting system together with time, camera, and snapshot.
Discrepancies — a typo in the database, a temporary plate, a duplicate — are collected in a separate log so the dispatcher sees them separately from regular passages. This way the passage log remains suitable for reconciliations and investigation of disputed situations.
Which scenarios remain outside recognition?
A plate completely covered with dirt or taped over, non-standard fonts, and extreme angles are the honest limits of the method. For such cases we describe the rule in advance: manual confirmation, a separate list for service vehicles, a second passage. We record limitations before launch, so as not to promise at the site what the system will not do.
Let's discuss the task: what is needed to evaluate your site
To come back with a project estimate, we need the site’s initial data.
License plate recognition depends on passage geometry, lighting, and the quality of existing cameras: from the description “two entry points” we will estimate the effort approximately, while from a scheme with angles and distances we will provide an exact implementation plan.
Not much is needed: a site plan, photographs of the passages, and a list of installed equipment are enough. If some item is unknown, we will mark it as to be clarified and include a survey in the plan.
What helps when discussing the task:
- Number of lanes and entry/exit points, including service and reversible ones — this determines the number of cameras and the passage accounting logic.
- Site plan with entrance angles, distances to the installation location, and vehicle traffic directions.
- Existing equipment: cameras, recorders, barrier controllers, their condition, and reusability.
- Shooting conditions: daytime and nighttime lighting, illumination, installation height, interference — glare, dirt, snow.
- Requirements for passage accounting: what to record (plate, time, direction), where to transmit data, whether integration with the barrier is needed.
- Site operating mode: peak-hour flow, guest entry, freight transport and special machinery, who needs reports and exports.
Based on this data, we will come back with a project estimate: equipment composition and installation locations, storage and processing scheme, work stages, and timelines.
If some initial data is missing, we will coordinate a site visit — then the implementation plan relies on real geometry, not assumptions.
