Własny system LPR na przemysłowym SBC bez GPU: projekt

Projekt powstał z ustaleń badania lpr-cpu-sbc. Analitycy rozdziałów przeczytali w całości 10 264 ustalenia z prac naukowych, repozytoriów i dokumentacji technicznej, a w tekście cytują 553 ustalenia, z czego 479 naukowych lub technicznych. Deklaracje producentów pojawiają się tylko tam, gdzie innych danych nie ma, z dopiskiem „wg producenta”. Odnośniki [F…] prowadzą do ustaleń (treść i strona źródłowa), S oznacza założenie projektowe, a obliczenia są w decyzja/obliczenia/p0X.py.

System w jednym przejściu

1. Kamera 4 MP (H.265, 25 kl./s, stała krótka ekspozycja ustawiana przez SBC) patrzy wzdłuż najazdu na szlaban i widzi tablicę w strefie ok. 2–9 m przed sobą, zanim pojazd dojedzie do linii zatrzymania.

2. VPU dekoduje oba strumienie bez udziału CPU, RGA zmniejsza co drugą klatkę do 640×360, a pierścień trzyma 1,5 s zdekodowanych klatek.

3. Detektor pojazdów (YOLOX, Apache 2.0, INT8 na NPU) działa stale, 12,5 kl./s na kamerę; tracker IoU z filtrem Kalmana prowadzi ślad. Pętla albo radar nie otwiera zbierania, tylko przypisuje ślad do przejazdu i uruchamia decyzję, bo najlepsze klatki są sprzed tego sygnału.

4. Dla każdego śladu detektor tablicy z głowicą czterech narożników pracuje na wycinku z pełnej rozdzielczości na każdej klatce; CPU prostuje tablicę homografią do kanwy OCR.

5. Wycinek przechodzi twarde bramki jakości (wielkość znaku, ostrość, kąt), a potem dwa splotowe modele OCR na NPU zwracają rozkłady prawdopodobieństw na każdej pozycji.

6. Fuzja uśrednia rozkłady po pozycjach z wielu wycinków śladu, dekoduje wynik z ograniczeniem składni polskich tablic, a skalibrowana pewność decyduje: odczyt przyjęty, druga szansa na liście zamkniętej albo ścieżka wyjątku.

7. Każdy przejazd zostawia wycinki, odczyty i pewności; serwer z GPU robi z nich automatyczne etykiety i douczanie, a nowa wersja modelu przechodzi kwantyzację z douczaniem i próbę w cieniu, zanim trafi na SBC.

Karta projektu: decyzje i parametry wiążące

W rozdziałach część obciążeń liczono przy różnych założeniach (5, 12,5 albo 25 kl./s; osobny regresor narożników albo głowica detektora; głos całym ciągiem albo po pozycjach). Poniższa tabela ustala wartości obowiązujące; tam, gdzie rozdział liczy inaczej, rozstrzygnięcie podaje kolumna „Źródło decyzji”.

Budżety w liczbach

• Czas: od klatki do odczytu 51–75 ms; od wyzwolenia do decyzji opóźnienie kamery plus 22–102 ms, przy szlabanie podnoszonym 1,5–4 s (rozdz. 1.5).

• Błąd: 99,0% = straty wyzwolenia 0,05% + braku wycinków 0,15% + losowego OCR po fuzji 0,10% + błędów stałych pojazdu 0,40% + odrzuceń progiem 0,30%; błędne odczyty ≤ 0,1% przejazdów (rozdz. 4.1). Największą pozycją są błędy stałe (śruby, brud, czcionka), których głosowanie nie usuwa: cele trzymają się razem przy ok. 0,2% takich pojazdów (rozdz. 4.5).

• Dane: wersja 1 od ok. 5000 unikalnych polskich tablic, cel 99% przy 20 000–30 000 unikalnych tablic S (rozdz. 3.6).

Najważniejsze luki

• Brak wyniku żadnego modelu na polskich tablicach i brak niezależnego pomiaru 99% na wjeździe parkingowym; wszystkie wartości skuteczności pochodzą z tablic innych krajów i przechodzą przez budżet z rozdz. 4.

• Brak zmierzonego opóźnienia kamera → SBC (rozdz. 1 podaje protokół pomiaru) i pomiarów czasów sieci na NPU RK3588J dla dokładnie tych wejść (przeskalowano z pomiarów dla innych wejść).

• Brak danych o odblasku tablicy powyżej 45° i o skuteczności nocą przy dużych kątach; stąd ograniczenie ≤ 30° w nocy.

• Brak zmierzonego zysku z syntetyków i z poprawek operatora dla tablic polskich.

Część 1Potok przetwarzania i budżet czasu

1.1Maszyna stanów przejazdu

DecyzjaKażdy pas ma własny automat z sześcioma stanami: BEZCZYNNOŚĆ, ŚLAD, WYZWOLENIE, DECYZJA, PRZEJAZD, WYJĄTEK. Zbieranie wycinków zaczyna się w chwili potwierdzenia śladu pojazdu w strefie pasa, a nie w chwili wyzwolenia; sygnał obecności z pętli lub radaru (styk ze sterownika szlabanu na wejście cyfrowe SBC) tylko przypisuje ślad do transakcji i otwiera termin decyzji. Wyzwolenie wizyjne (ślad stoi w strefie pętli) działa jako kanał zapasowy.

Dlaczego

• Pętla reaguje tylko na metal i nie może reagować na pieszych i rowery F38316, ale pojazdy z małą powierzchnią metalu w podłodze mogą jej nie uruchomić F38317 (oba wg producenta szlabanu), a motocykle bywają pomijane F40139. Sama wizja też zawodzi: słaba detekcja w złej pogodzie i nocą destabilizuje śledzenie i zwiększa liczbę pominiętych zdarzeń F44609.
• Pętla stoi tuż przed szlabanem, więc najlepsze klatki tablicy (pojazd 3–8 m od kamery) powstają przed sygnałem. Przy 30 km/h strefa 5 m mija w 0,6 s, a trzy zgodne odczyty zbierają się średnio w 343 ms obecności śladu (obliczenia/p01.py, p. 4); decyzja jest gotowa w chwili wyzwolenia.
• Pojazd stojący generuje identyczne klatki: w Frigate po aktualizacji rozpoznawanie odpalało wiele razy na sekundę dla jednego stojącego auta F47182. Systemy parkingowe rozdzielają śledzenie IoU i klasyfikację zdarzeń progiem czasu postoju F43967.
• Model zdarzeń „nowy / aktualizacja / utracony” (wg producenta) F37936 i odrzucanie podwójnych odczytów F33168 wymagają jawnego stanu transakcji.

Parametry i wykonanie

Ryzyko i lukiBrak danych w źródłach: odsetka fałszywych i pominiętych wyzwoleń pętli, radaru i wizji przy szlabanach parkingowych; dane o fałszywych wyzwoleniach fotokomórek pochodzą z systemów kontroli wysokości (ptaki, owady, rośliny) F38633. Progi 1,0 s, 0,5 s, 5 s i 30 s są założeniami S.

1.2Dekodowanie, zmniejszanie i bufor klatek

DecyzjaStrumień główny 2688×1520 H.265 przy 25 kl./s, I-klatka co 25 klatek, dekodowany ciągle przez MPP (jądro BSP Rockchip, bez ścieżki V4L2 z jądra głównego) do liniowego NV12 w buforach dma-buf. RGA skaluje każdą drugą klatkę do 640×360 RGB i robi wycinki z pełnej rozdzielczości bez kopiowania przez CPU. Bufor pierścieniowy trzyma 1,5 s zdekodowanych klatek na kamerę.

Dlaczego

• Zmierzone dekodowanie 8K30 HEVC na RK3588 z prędkością 55,8 kl./s F50262 daje ok. 1851 Mpx/s; dwie kamery 4 MP przy 25 kl./s potrzebują 204 Mpx/s, czyli 11,0% VPU i 2,2 ms na klatkę (p. 1).
• Stos MPP był ok. 3 razy szybszy przy 4K niż sterownik V4L2 z jądra głównego (pomiar na RK3576), bo pracuje w trybie ciągłym zamiast pojedynczych zgłoszeń na klatkę F47872; w jądrze głównym dekoder RK3588 działa na jednym rdzeniu, a obsługa dwóch jest w toku F50705; RKMPP wymaga jądra BSP 5.10 lub 6.1 F47820.
• Kopia 50 MB przez CPU trwa ok. 90 ms F50263; kopiowanie każdej klatki NV12 (6,13 MB) kosztowałoby 11 ms, a przy 50 kl./s 0,55 rdzenia (p. 1). ffmpeg-rockchip przekazuje klatki między dekoderem i RGA przez DMA bez kopii F49157, a potok RK3588S z RGA i NPU zostawia CPU wolne F47117.
• Częstotliwość ustawia się w kamerze, bo obniżanie jej w programie marnuje dekodowanie odrzucanych klatek F37745; I-klatka co tyle klatek, ile wynosi kl./s, to ustawienie zalecane w dokumentacji Frigate F48645.

Parametry i wykonanie

• Rozmiar bufora wyjścia MPP: hor_stride × ver_stride × 3/2 F48978 = 6,13 MB. Tryb pamięci „pure external” F36175: aplikacja przydziela pulę 38 klatek pierścienia + 8 klatek na bufor referencyjny dekodera na kamerę S.
• Bufor 1,5 s: 38 klatek, 233 MB na kamerę, 466 MB dla dwóch (p. 1). Wystarcza na przejazd strefy 5 m przy ≥ 12 km/h; wolniejsze pojazdy mają ślad założony na żywo, więc bufor służy tylko do ponownej analizy po wyzwoleniu bez śladu i do zapisu dowodu. Frigate trzyma podobnie ok. 25 klatek na kamerę w pamięci współdzielonej F38395.
• Pamięć ciągła (CMA) nie może być wąskim gardłem: ścieżka V4L2 bez kopii wymaga puli CMA ≥ 512 MB F38764, a pod presją CMA liczba buforów spada z 24 do 8 i 4 F39942; pulę przydziela się raz przy starcie i sprawdza jej wielkość.
• Czas klatki: znacznik RTP przeliczony na czas ścienny z raportów RTCP SR, które kamery ONVIF zawsze wysyłają F33808; kamera synchronizuje zegar z SBC przez NTP. Wejście wyzwolenia ma znacznik z tego samego zegara.
• Skalowanie: 2688×1520 → 640×362 → 640×360 z dopełnieniem do 640×384 (wielokrotność 32) S.
• Awaria dekodera: reset VDPU381 resetuje też jego wbudowany IOMMU i kasuje mapowania F46881, więc po błędzie odtwarza się sesję i pulę buforów; przekroczenie czasu dekodowania kończy się zatrzymaniem strumienia i odbudową kolejek, jak w sterowniku vaapi-v4l2-bridge F43643. Programowego dekodowania 4 MP jako zapasu nie ma (Frigate też go nie ma F36667).

Ryzyko i lukiPrzewodnik GStreamer Rockchip (wg producenta) odradza RGA na RK3588 jako „nieprawidłowe” F39225, a Jellyfin i ffmpeg-rockchip używają go w potoku bez kopii F50340F49157. Dlatego przy starcie RGA przechodzi test zgodności z wynikiem CPU na klatce wzorcowej; przy niezgodności skalowanie przejmuje CPU. Brak danych w źródłach: czasu jednej operacji RGA dla 4 MP i jednoczesnego dekodowania 2×4 MP na RK3588 zmierzonego wprost.

1.3Detekcja pojazdu i śledzenie

DecyzjaDetektor pojazdów rodziny YOLOX (licencja Apache-2.0), INT8, wejście 640×384, uruchamiany co drugą klatkę (12,5 kl./s na kamerę) we wszystkich stanach. Śledzenie: własny tracker IoU z filtrem Kalmana i dwuetapowym kojarzeniem w stylu ByteTrack (najpierw ramki pewne, potem słabe), bez reidentyfikacji.

Dlaczego

• Etap pojazdu przed tablicą usuwa fałszywe trafienia i skraca czas F49108, a detektor tablic dostaje wtedy obiekty średnie i duże zamiast małych F38331. Odczyt z całego obrazu bez lokalizacji dał 15,8% dokładnych odczytów wobec 40,6% z wycinkiem F45438. Ten sam układ (detekcja na obrazie zmniejszonym o połowę, wycinek tablicy z pełnej rozdzielczości, śledzenie Kalmana na ARM) działa w kamerze FPGA F45265.
• Licencja: modele Ultralytics (YOLO11, YOLOv8) są na AGPL-3.0 (wg kart modeli) F42083F40071, co wyklucza je w zamkniętym produkcie; YOLOX jest na Apache-2.0 F46886. YOLOX-tiny INT8 na RK3588 z 3 rdzeniami NPU to 18 ms w dokumentacji Frigate F44265.
• Częstotliwość: systemy ALPR potrzebują co najmniej 10 kl./s, żeby nie gubić pojazdów między klatkami F43791. Przy 12,5 kl./s pojazd z prędkością 30 km/h przesuwa się o 0,67 m między detekcjami (p. 4), a pojazd jadący na kamerę głównie rośnie w kadrze zamiast przesuwać się w bok (wg producenta) F36628, więc ramki z kolejnych detekcji mocno się nakładają.
• Wybór trackera nie ma znaczenia statystycznego: zamiana IoU na ByteTrack przy stałej fuzji zmienia wynik o 1–2 pkt F45929. Prosty tracker IoU (ok. 100 linii) wystarcza przy typowej liczbie pojazdów, a reidentyfikacja dokłada wagi, RAM i CPU F47263; własna implementacja nie niesie obcej licencji.

Parametry i wykonanie

• Klasy: samochód, dostawczy, ciężarowy, autobus, motocykl, osoba. Próg pewności 0,5 dla kojarzenia pierwszego etapu, 0,1 dla drugiego S; IoU kojarzenia ≥ 0,3 S.
• Ślad potwierdzony po 2 kolejnych trafieniach (Frigate używa 2 klatek inicjalizacji F33882); usunięcie po 12 detekcjach bez trafienia (≈ 1 s) S; ramki węższe niż 48 px w obrazie 640×360 są pomijane S (system z Hertfordshire pomija łaty pojazdów < 40 px F47991).
• Pole pasa, strefa pętli i linia szlabanu to wielokąty na obrazie; ślad należy do pola, gdy leży w nim środek dolnej krawędzi ramki. Kierunek: znak zmiany położenia tej krawędzi w oknie 0,5 s.
• Wywołanie NPU jest blokujące, więc każdy tor ma własny wątek roboczy na własnym rdzeniu NPU F39981; więcej wątków niż optimum nasyca pamięć i grzeje SoC bez zysku F39982.

Ryzyko i lukiBrak danych w źródłach: czasu YOLOX przy wejściu 640×384 na jednym rdzeniu NPU; budżet przyjmuje ostrożny czas 15,5 ms przeskalowany liniowo z YOLOv8n INT8 (p. 2). Brak danych w źródłach: skuteczności detekcji klas „osoba” i „motocykl” przy szlabanach.

1.4Wybór wycinków do OCR i koniec zbierania

DecyzjaDetektor tablicy z czterema narożnikami pracuje na każdej klatce aktywnego śladu (25 kl./s) na wycinku z pełnej rozdzielczości. Wycinek trafia do OCR tylko po przejściu sześciu twardych bramek; z każdej pary kolejnych klatek do OCR idzie lepsza (najwyżej 12,5 odczytu/s na ślad). Bramki odrzucają, ale nie ważą głosów. Zbieranie kończy zgoda trzech odczytów, limit 20 odczytów lub wyjście tablicy z kadru.

Dlaczego

• Ważenie klatek rozdzielczością wycinka i ostrością Laplasjanu nie dało istotnej poprawy ponad samo głosowanie F44574, a wszystkie pozostałe błędy po fuzji to pozycje, w których żadna klatka nie zawierała poprawnego znaku F42543. Wartość mają więc odrzucenie klatek bezużytecznych i więcej niezależnych odczytów, nie wagi.
• Ramka tablicy musi pochodzić z detektora na każdej klatce: przenoszenie obszaru tablicy przez tracker kumuluje dryf, przy którym zawodzą zarówno dekodery LSTM, jak i Transformer F42182, a błędy strukturalne wynikają głównie z niestabilności tego obszaru, nie z wyboru dekodera F43838. Ramka prostokątna bez narożników nie pozwala wyprostować skośnej tablicy (wg autora modelu) F42927.
• Wielkość znaku: 8×16 px dało 100% odczytów, poniżej 5×10 px mniej niż 36,4% F36256; model OpenVINO dla szlabanów wymaga tablicy ≥ 96 px (wg producenta) F40518.
• Liczba odczytów: śledzenie IoU z głosowaniem ważonym pewnością, uruchamiane dopiero po trzech odczytach o pewności > 0,4 zgodnych z formatem, podniosło dokładne odczyty z 66,7% do 81,8% F44435F43308; trzy jednakowe odczyty z kolejnych klatek autorzy z Hertfordshire traktują jako pewne F49078. Głosowanie po 35 klatkach podniosło dokładność z 29% do 69% przy spadku przepustowości o 18% przy 20 klatkach F47298F42008; dla polskich tablic model CNN-RNN z głosowaniem na nagraniach parkingowych stracił tylko 1,8% względem zdjęć F38498F49142.

Parametry i wykonanie

• Wycinek pojazdu: dolne 60% ramki pojazdu przeniesionej do 4 MP, poszerzone o 10%, RGA do 512×256 S; na klatkach bez detekcji pojazdu ramkę daje predykcja trackera poszerzona o 15% S, ale ramka tablicy zawsze pochodzi z detektora. Wycinek tablicy do OCR: ramka z narożników poszerzona o 20% (jak w potoku rumuńskim F44437), prostowanie homografią do wejścia OCR.
• Bramki (wszystkie muszą przejść):
  • G1 wysokość znaku h_z = 0,73 × wysokość tablicy w px (80/110 mm F38418; wymiar 520×110 mm wg producenta F44218) ≥ 16 px; czołowo odpowiada to tablicy 104 px (p. 8);
  • G2 cztery narożniki w kadrze z marginesem ≥ 8 px;
  • G3 wariancja Laplasjanu na wycinku znormalizowanym do h_z = 32 px ≥ 0,35 × mediana śladu S;
  • G4 odchylenie z homografii |θ| ≤ 60° S (zakres, w którym Geo-CTM poprawiło wynik istotnie F45969);
  • G5 pewność detektora tablicy ≥ 0,25 S: liczy się czułość, bo fałszywy wycinek odrzucą OCR i format (wg autora modelu) F42926;
  • G6 środek tablicy przesunął się o ≥ 0,25 h_z od ostatniego odczytu albo minęła ≥ 1 s.
• Odczyt ważny: pewność OCR ≥ 0,4 i zgodność z formatem tablic F44435.
• Zgoda (koniec zbierania): ≥ 3 ważne odczyty jednego ciągu i co najmniej dwa razy więcej głosów niż drugi ciąg S. Limit K_max = 20 ważnych odczytów S; postój: ≤ 1 odczyt/s i ≤ 3 głosy z postoju.
• Przy 30 km/h strefa 5 m daje 15 klatek i ok. 5 ważnych odczytów, przy 10 km/h ok. 16 (p. 4).
• Smuga ruchu przy 30 km/h i 1/1000 s to 8,3 mm wobec kreski znaku 9 mm (p. 8); migawka ≤ 1/1000 s to wymaganie wobec kamery.

Ryzyko i lukiWyniki 66,7→81,8% dotyczą tablic rumuńskich, 29→69% saudyjskich, a granica 8×16 px tablic chińskich i włoskich. Brak danych w źródłach: zależności dokładności OCR od kąta i ostrości dla tablic polskich.

1.5Budżet czasu i opóźnienie decyzji

DecyzjaBudżet liczony dla najgorszego przypadku: oba tory aktywne jednocześnie, czasy NPU ostrożne, CPU RK3588J w trybie normalnym 1,6 GHz (wg producenta) F39707. Każda jednostka w tym przypadku ma zajętość ≤ 60%, żeby spadek przepustowości termicznej nie zatrzymał potoku. Interfejs OCR ma twardy limit 40 ms na wycinek na jednym rdzeniu A76 przy 1,6 GHz.

Dlaczego

• Na RK3588 NPU wykonuje YOLOv8 INT8 w 17,1 ms (czas operatorów NPU, CPU 0,13 ms) F42607; w potoku 9 strumieni na trzech rdzeniach czas NPU rośnie do 25,8 ms, a przetwarzanie końcowe dokłada 15,7 ms F46904. Przetwarzanie końcowe w C++ było 7,12 razy szybsze niż w Pythonie na tym samym CPU F43657.
• Pomiary modułów nie są przepustowością całego potoku: dochodzą synchronizacja, transfery pamięci i szeregowe wykonanie F47849, a benchmarki pomijają przetwarzanie wstępne i NMS F43652.
• OCR CNN + Attention-LSTM na A76 Raspberry Pi 5 osiąga ok. 16 kl./s, czyli 62,5 ms F44173; po przeskalowaniu do 1,6 GHz to 93,8 ms i przekroczenie budżetu (117% dwóch rdzeni). Na tym samym sprzęcie testowym TRBA z atencją był 5,8 razy wolniejszy niż CRNN z CTC F49181, więc model klasy CTC mieści się w ok. 16 ms (p. 3).
• Bez chłodzenia najcięższy model zachował ok. 72% przepustowości przy 36 °C otoczenia F48695, a CPU bez chłodzenia spadło z 16 do ok. 10 kl./s po ok. 1000 s pracy F46286.

Parametry i wykonanieTabela dla dwóch kamer, stan aktywny obu torów (p. 5):

• Klatka → wycinek gotowy do OCR: 34,9 ms; klatka → odczyt: 51–75 ms (p. 7); oczekiwanie w kolejce rdzenia NPU 3,5–6,6 ms (p. 6). Potok rumuński z polityką „ostatniej dostępnej klatki” trzyma < 100 ms na klatkę F43313.
• Od wyzwolenia do decyzji, gdy zgoda zapadła wcześniej: T = L_kam + 22 ms powiązania śladu (+ do 80 ms na najbliższą klatkę z detekcją); dla L_kam = 200 ms wychodzi 222–303 ms. Gdy brakuje trzech odczytów, dochodzi do 343 ms; twardy limit 1,5 s.
• Podnoszenie ramienia trwa 1,5–4 s (wg producenta) F32827; decyzja w 0,3 s wydłuża czekanie kierowcy o 8–20% (p. 7).
• Protokół pomiaru L_kam: dioda sterowana z GPIO SBC w kadrze kamery; L_kam = czas odbioru pierwszej klatki z zapaloną diodą − czas zapalenia; 200 pomiarów na kamerę, wynik p95.

Ryzyko i lukiCzasy NPU dla wejść 640×384 i 512×256 to liniowe przeskalowanie pomiarów 640×640 S. Brak danych w źródłach: opóźnienia kamera → SBC (L_kam); relacja użytkownika mówi o ok. 30 klatkach opóźnienia 720p w łańcuchu kamera–PC F37015, więc pomiar L_kam jest warunkiem odbioru. Brak pomiaru OCR klasy CTC na A76 i na NPU RK3588.

1.6Rozdział pracy, kolejki i degradacja

DecyzjaStałe przypisanie: rdzeń NPU 0 obsługuje tor A (pojazd + tablica), rdzeń NPU 1 tor B, rdzeń NPU 2 jest wspólny dla OCR (gdy model CTC skonwertuje się bez operatorów na CPU) i ponownej analizy bufora. Potok jest napisany w C++, z synchronicznymi wywołaniami na tor i krótkimi kolejkami „ostatnia klatka wygrywa”. Przeciążenie obsługuje czterostopniowa degradacja sterowana zmierzonym czasem oczekiwania i temperaturą.

Dlaczego

• Asynchroniczne wywołania na 4 strumienie podniosły przepustowość YOLOv8n na CPU i7 z 36,6 do 40,9 kl./s, ale opóźnienie z 27,3 do 103,7 ms F43653; przy szlabanie liczy się opóźnienie, więc każdy tor ma własny, synchroniczny rdzeń zamiast wspólnej kolejki wszystkich kamer, jak we Frigate F40797.
• Rdzeń A55 daje ok. 1/3 wydajności A76 F39451; przetwarzanie należy przypiąć do rdzeni A76 (na Orange Pi 5 to CPU 4–7 F43639). GIL serializuje kod Pythona i kilka wątków przetwarzania końcowego działa wolniej niż jeden F46867.
• RKNN-Toolkit2 1.6.0 nie obsługiwał części operatorów atencji na RK3588 i wykonywał je na CPU F39503; OCR na NPU musi więc być modelem splotowym z CTC.
• Na ARM Neoverse N1 najlepsza przepustowość to 1 proces z 4 wątkami, a więcej procesów obniża ją przez nasycenie pamięci F45589; chłodzenie z histerezą usunęło dławienie we wszystkich 80 testach F39593.

Parametry i wykonanie

• CPU: A76 nr 4 – tor A (odbiór RTSP, MPP, RGA, NPU, post-proc., tracker, bramki), A76 nr 5 – tor B, A76 nr 6–7 – dwa wątki OCR; A55 nr 0–3 – automat stanów, wejścia/wyjścia sterownika, zapis dowodów, sieć, watchdog.
• Kolejki: wejście toru głębokość 2, odrzucana najstarsza klatka (klatki w pierścieniu z licznikiem odwołań, bez kopii); kolejka OCR na ślad 4 wycinki, przy pełnej kolejce wypada wycinek o najmniejszym h_z; priorytet OCR: ślad w WYZWOLENIU > ślad najbliżej szlabanu > pozostałe.
• Pomiar obciążenia: NPU z /sys/kernel/debug/rknpu/load F44270, VPU z /proc/mpp_service/load, RGA z /sys/kernel/debug/rkrga/load F50342; czas oczekiwania w kolejkach jako p95 z okna 10 s.
• Degradacja (wejście przy p95 oczekiwania na NPU > 20 ms lub temperaturze SoC > 85 °C przez 10 s; powrót przy p95 < 10 ms przez 60 s) S:
  • D1: detekcja tablicy co 2. klatkę w aktywnym torze; przy dwukrotnie dłuższych czasach NPU rdzeń toru spada z 80% do 59% (p. 5);
  • D2: tor bezczynny wykrywa pojazdy co 4. klatkę; OCR ≤ 6 odczytów/s na ślad, K_max = 10;
  • D3: tor z WYZWOLENIEM dostaje rdzeń NPU 2; drugi tor tylko śledzi pojazdy i odkłada wycinki do bufora; zapis dowodów wstrzymany;
  • awaria wideo lub dekodera: tor przechodzi w WYJĄTEK dla każdego wyzwolenia, a watchdog restartuje sesję MPP.

Ryzyko i lukiDane termiczne pochodzą z Raspberry Pi 4, nie z RK3588J w szafce. Próg 85 °C i progi kolejek są założeniami S. Brak danych w źródłach: zmierzonej przepustowości trzech rdzeni NPU RK3588 z przypisaniem stałym wobec puli wątków przy dwóch kamerach.

Założenia S i obliczenia

• Obliczenia: decyzja/obliczenia/p01.py, wynik p01.out; w tekście „p. N” wskazuje punkt wyniku.
• Geometria: strefa czytelności 5 m (od 8 do 3 m przed kamerą), pętla w odległości ok. 3 m od kamery; od tego zależą liczby klatek w p. 4.
• Kamera 25 kl./s, detekcja pojazdu co 2. klatkę, OCR ≤ 12,5 odczytu/s na ślad, 70% par klatek przechodzi bramki.
• Czasy NPU: liniowe skalowanie z liczbą pikseli od 25,77 ms F46904 i 17,12 ms F42607 przy 640×640; czasy RGA, przetwarzania końcowego, trackera i prostowania przyjęte bez pomiaru.
• OCR klasy CTC 16,1 ms = 62,5 ms F44173 × 2,4/1,6 GHz ÷ 5,8 F49181; przeniesienie stosunku ze sprzętu testowego na A76 i skalowanie taktowaniem to szacunek.
• Progi czasowe automatu, bramki G3–G6 i reguła zgody „≥ 3 odczyty i 2× drugi ciąg” to wartości startowe do kalibracji na nagraniach z własnych pasów.
• Z pliku dane/nauka/p01.jsonl przeczytałem wszystkie 1968 ustaleń (pogrupowane skryptem w osiem podtematów), a w rozdziale wykorzystałem 67 z nich (z 90 ustaleń przywołanych w rozdziale).

Część 2Modele i ich trening

2.1Detektor pojazdu

DecyzjaPojazd wykrywa YOLOX-Tiny z klasami: osobowy, dostawczy lub ciężarowy, autobus, motocykl. Model pracuje w INT8 na NPU RK3588 z wejściem 640×384 (klatka 640×360 dopełniona do wielokrotności 32) i 5 kl./s na kamerę. Wyznacza okno zdarzenia i ramkę pojazdu; tablicy nie szuka.

Dlaczego

• Etap pojazdu przed tablicą jest uzasadniony pomiarami: tablica zajmuje mały ułamek kadru, a detektory słabo wykrywają małe obiekty F38588; Fast-YOLO bez wcześniejszego wykrycia pojazdu miało niską czułość na tablicach F49495; etap pojazdu ogranicza fałszywe i pominięte detekcje F48380. Detektor tablic ze stałym wejściem 640×640 gubi małe tablice w obrazach wysokiej rozdzielczości F36712.
• Detekcja pojazdu nie ogranicza skuteczności systemu: YOLOv2 osiąga 98,37% precyzji i 99,92% czułości na ośmiu zbiorach F42270, a w innej pracy średnio 99,71% i 99,90% na pięciu F49600. Najmniejsze warianty (Fast-YOLO) gubiły jednak pojazdy częściowo zasłonięte F39253, dlatego wybieram Tiny, nie Nano.
• Licencja wyklucza rodzinę Ultralytics: YOLOv5, v8, 11 i 26, także pose, mają AGPL-3.0 dla kodu i wag F32961F42400, a YOLOv7 i YOLOv9 GPL-3.0 F32962; YOLOX ma Apache 2.0 F45088. Detektory transformerowe odpadają przez NPU: szkielet RF-DETR zajmuje na NPU Rockchip 367 ms F34023, a rknn-toolkit2 1.6.0 przenosił część atencji na CPU F39503.
• Czas zmierzony na RK3588 (3 rdzenie NPU, INT8): yolox_tiny 18 ms, yolox_nano 14 ms F44265. INT8 skraca czas YOLOv8n/s/m na RK3588 o 42–51% F34659.

Parametry i wykonanie

• Wejście niekwadratowe: Laroca i in. zmienili wejście detektora pojazdów z 416×416 na 448×288, co zmniejszyło zniekształcenie i czas F35749.
• Start z wag COCO, dostrojenie na klatkach z obu docelowych kamer (dzień, noc w IR, deszcz). Detektory parkingowe tracą dużo na nowym obiekcie: Faster R-CNN 99,01% → 78,34% mAP@0,5, YOLOv12 99,46% → 81,67% F43966F43962.
• Pojazdy węższe niż 40 px w klatce 640×384 pomijam S, jak potok z 99,92% czułości pomijał wycinki pojazdów poniżej 40 px F47991. Śledzenie IoU między klatkami; z jednego toru biorę jedną tablicę z najwyższym wynikiem F47374.
• Koszt: 26 ms na klatkę (obl. D); dwie kamery po 5 kl./s to 256 ms pracy NPU na sekundę, 9–26% pojemności (obl. E).

Ryzyko i lukiBrak danych w źródłach: rozmiaru wejścia modelu YOLOX w pomiarze 18 ms, mAP YOLOX-Tiny na COCO oraz skuteczności YOLOX na polskich wjazdach.

2.2Detektor tablicy z czterema narożnikami

DecyzjaTablicę wykrywa jednoetapowy detektor na szkielecie YOLOX-Tiny z głowicą czterech punktów kluczowych (narożniki w kolejności LG, PG, PD, LD), wynikiem tablicy i klasą układu (jednorzędowa, dwurzędowa). Wejście: ramka pojazdu z klatki 4 MP, powiększona o 10% S i przeskalowana do 384×384. Narożniki przenoszę do pełnej rozdzielczości i prostuję tablicę homografią z czterech punktów prosto do kanwy OCR. Nie używam samej ramki, ramki obróconej (OBB) ani STN.

Dlaczego

• Mocno ukośna tablica jest dowolnym czworokątem, nie równoległobokiem F34390, więc potrzebne są cztery punkty i homografia. Ramka osiowa obejmuje skośną tablicę prostokątem, którego OCR nie odprostuje F37966. W ablacji systemu OBB usunięcie regresji kąta obniża dokładność tablic z 91,5% do 82,7% F43072, a i tak ten system prostuje wycinek przed OCR F44018. WPOD-NET bez prostowania osiąga 57,69% na mocno ukośnym CD-HARD F37548; prostowanie po narożnikach „znacznie” zwiększa odporność na widok ukośny F37814.
• STN uczony stratą OCR nic nie daje: dodanie STN do CRNN ze szkieletem rezydualnym i atencją obniżyło wynik z 92,38% do 92,15%, a STN z prostym CRNN dał 59,52% F39198F39199; uczony rektyfikator szkodzi na prostym tekście F50958.
• Wzorzec jest sprawdzony: YOLOv11-pose z czterema narożnikami osiąga na CCPD mAP50-95 0,994 po 30 epokach F40679; Laroca i in. (2025) łączą detektor YOLO z regresją narożników CDCC-NET F40941. Ultralytics pose ma AGPL F42400, dlatego głowicę piszę na YOLOX. OCR po prostowaniu znosi błędy narożników: TransLPRNet zachowuje 94,57–99,92% przy zaburzeniu wierzchołków F49716.
• Klasa układu w tym samym detektorze działa u Laroki i in. F32557; układ z regułami daje +3,6% F38119, a przy pewności powyżej 0,75 (92% tablic) układ był zawsze poprawny F47316.

Parametry i wykonanie

• 384 px leży w przedziale 288–608 px, który WPOD-NET stosuje dla wycinka pojazdu F34905.
• Budżet błędu: 1 px błędu punktu na wejściu 384 daje 2,6–5,2 px w klatce 4 MP, czyli 1,3–3,3% szerokości tablicy 160–200 px (obl. C). Augmentacja OCR pokrywa ten zakres: przycięcie od −2% do +8% rozmiaru tablicy F44057 i losowy margines symulujący niedokładną detekcję F47319.
• Kanwa po homografii: tablicę jednorzędową mapuję na pełną szerokość kanwy, dwurzędową na pełną wysokość; resztę wypełnia obraz wokół tablicy (proporcja kanwy 3:1, rozdz. 2.3).
• Trening: pretrening na narożnikach CCPD (licencja MIT F33211), ale tylko jako start, bo narożniki CCPD są niedokładne F39879F37597, a obrazy silnie skompresowane F43433. Dostrojenie na własnych zdjęciach z ręcznie oznaczonymi narożnikami. WPOD-NET wytrenowano od zera na 196 zdjęciach dzięki masowemu syntetycznemu wypaczaniu F34901F37547, więc stosuję losową perspektywę i obrót. Bez odbić lustrzanych F39018; bez augmentacji koloru dla głowicy układu, bo jej wyłączenie usunęło ponad połowę błędów klasyfikacji układu F38917.
• Koszt: 15 ms na wycinek (obl. D), 9 klatek w strefie = 138 ms na przejazd (obl. E).

Ryzyko i lukiBrak danych w źródłach: błędu narożników w pikselach dla tablic polskich i liczby oznaczonych zdjęć potrzebnej do dostrojenia głowicy punktów. Tablice dwurzędowe są w otwartych zbiorach rzadkie (UC3M-LP: 31 z 2547 F32774).

2.3OCR

DecyzjaOdczyt wykonują dwa modele z różnych rodzin, oba czysto splotowe (bez LSTM i atencji), w INT8 na NPU:

• OCR-A, detektor znaków z rodziny CR-NET/Fast-OCR, zbudowany na YOLOX-Nano. Wejście 96×288 w odcieniach szarości, 36 klas (0–9, A–Z, osobno „O” i „0”). Wynik: ramki znaków z pewnością; znaki porządkuje po x, a rzędy rozdziela regułą Laroki i in.: tablica jest dwurzędowa, gdy co najmniej połowa ramek leży w całości pod innym znakiem F36799.
• OCR-B, klasyfikator pozycji z rodziny Holistic-CNN/Multi-Task (splotowy szkielet i N gałęzi, każda przewiduje znak na jednej pozycji F35953). Wejście 64×192 w odcieniach szarości, 9 pozycji × 37 klas (36 znaków + „puste”), koszt docelowy ≤0,6 GFLOP S.

Na wyjściu każdy model daje ciąg, pewność dla każdego znaku (OCR-A: wynik ramki znaku, OCR-B: maksimum softmax na pozycji) i układ z detektora tablicy.

Dlaczego

• Detekcja znaków najlepiej przenosi się na tablice europejskie i ukośne: na OpenALPR-EU, którego modele nie widziały, Fast-OCR osiąga 97,2%, CR-NET 96,3%, CRNN 93,5% F38599, a na mocno pochylonym CD-HARD 59,6% i 58,7% wobec 31,7% CRNN F38600. Dostrojony detektor znaków YOLO zamyka lukę, której nie zamykają transformerowe OCR uruchomione bez douczania F45219; układ wieloetapowy z detekcją znaków osiąga 96,1% wobec 83,9% jednoetapowego F43235.
• Tablice dwurzędowe: podejścia bez segmentacji (CTC czytające jeden wiersz) nie czytają dwóch rzędów F36798, a detektor znaków czyta je bez trudności także na tablicach europejskich F43189.
• Atencja i transformery nie opłacają się na SBC. Przy tym samym szkielecie ResNet-18 dekoder Attention-LSTM osiąga 99,12% dokładności znaków, a dekoder Transformer 98,86% F44171F44172; na Raspberry Pi 5 to 16 kl./s wobec 5 kl./s F44173F44174. NPU RK3588 słabo mnoży macierze, bo jest zbudowane pod sploty F36970. PARSeq ma 23,8 mln parametrów i 3,255 GFLOP F36841, czyli 45–56 ms na rdzeniach A76 (obl. D).
• OCR-B samodzielnie jest słabszy (Multi-Task-LR 85,9% wobec 92,4% najlepszego modelu F44538; na AOLP-B bez duplikatów 95,29% wobec 97,47% TRBA F43553F50006), ale jest najszybszą rodziną (2,3 ms wobec 3,0 ms Fast-OCR na tym samym GPU F49181), uczy się z samego tekstu tablicy bez ramek znaków F35727 i zyskuje na permutacji znaków znacznie więcej niż CR-NET F45240. Detektor znaków wymaga ramek każdego znaku F46480; z tego powodu Laroca i in. nie mogli go wytrenować na RodoSol-ALPR F48544.
• Rozmiar wejścia: CR-NET sprawdzano przy 96×256 i 128×384, a wybrano 128×352 F38022; Laroca i in. dostosowali wszystkie 12 modeli do proporcji 3:1 F38879. Odczyt jest pełny od znaku 8×16 px i spada poniżej 36,4% przy znaku mniejszym niż 5×10 px F36256. Na kanwie OCR-A znak tablicy jednorzędowej ma 44 px, dwurzędowej motocyklowej 29 px; na kanwie OCR-B 30 px i 19 px (obl. B).

Parametry i wykonanie

• Wymóg na klatce źródłowej: znak ≥16 px wymaga tablicy szerokiej na ≥104 px, a kreska ≥2 px (wg producenta F45919) ≥116 px (obl. A). Wycinki węższe niż 116 px nie trafiają do OCR S.
• Odcienie szarości, bo IR nocą i tak daje obraz jednokanałowy; tak pracują modele DenseNet z F38008 i polski CNN-RNN F48344.
• Klasy „O” i „0” rozdzielone: wspólna klasa zawodzi na tablicach zagranicznych F49855. Reguły po odczycie: tablica europejska ma 5–8 znaków F38919; w polskim wyróżniku pojazdu nie występują B, D, I, O, Z F32516; zamiany cyfra↔litera według pozycji jak w F36800. Korekta składniowa była głównym źródłem zysku (+6,15 pp dokładnego dopasowania na CCPD) F44112F44113.
• Pewności znaku nie używam jako samodzielnego kryterium akceptacji: modele mylą się z wysoką pewnością F35087, a standardowe pewności są zawyżone F45046. Akceptację wyznacza głosowanie (rozdz. 2.6).

Ryzyko i lukiBrak danych w źródłach: wyniku detektora znaków i klasyfikatora pozycji na polskich tablicach oraz ich dokładności po INT8. Zdjęcia nocne w IR stanowiły 21,5% zbioru, a dały 39–53% błędów atrybutów pojazdu F45044 i znaczną część błędów odczytu F42707; śruby mocujące odpowiadały za 72,6% z 700 błędnych odczytów F36605. Tych błędów nie usuwa wybór architektury.

2.4Przepis treningu

DecyzjaOba modele OCR i detektor tablicy uczę w trzech etapach: (1) pretrening na syntetycznych tablicach polskich i europejskich, (2) trening na prawdziwych tablicach europejskich z wielu krajów, (3) dostrojenie na tablicach polskich, w tym z docelowych kamer. Na końcu QAT (rozdz. 2.5). Zbiory dzielę po numerze tablicy i po kamerze, nie losowo po zdjęciach.

Dlaczego

• Synteza: dodanie danych w pełni syntetycznych podniosło wynik OCR na AOLP-RP o ok. 5% F37553; masowa synteza (szablony, permutacja znaków, GAN) poprawia wyniki w obrębie zbioru i między zbiorami F45234; przy 6000 prawdziwych tablic z augmentacją 98,9%, z dodatkiem generowanych 99,0% F38003, a im mniej prawdziwych tablic, tym większy zysk z generowanych F38006. Sama synteza nie oddaje jednak rzeczywistej degradacji obrazu F50016F49792.
• Transfer z sąsiednich krajów: model czeski douczony na polskich danych osiąga 89,2% wobec 87,3% od zera F43661, a dalszy trening tylko na polskich danych dał 87,2% F37842; transfer zmniejszył błąd normED o 28–38% F46574.
• Niemal-duplikaty zawyżają wynik: w AOLP-B 67,6% zdjęć testowych ma duplikat w treningu F35048, a błędy modeli po ich usunięciu rosną ponad dwukrotnie F36638. Główną przyczyną stronniczości zbiorów są kamery F38523, dlatego test między zbiorami lepiej przewiduje działanie w terenie F35041.

Parametry i wykonanie

• Generator syntetyczny: krój z przepisów (znak 80 mm, kreska 9 mm, litera do 47 mm, cyfra do 43 mm F38418) oraz szerszy krój sprzed 30.06.2018 F38420; tablice 520×110 mm, dwurzędowe 305×214 mm i motocyklowe 190×150 mm F38417; w tablicy dwurzędowej górny rząd to wyróżnik miejsca F38422. Wielkość: 300 tys. obrazów S.
• Augmentacje: jasność [0,85; 1,15], obrót ±5°, przycięcie od −2% do +8% F44057; losowe przeskalowanie z marginesem F47319; permutacja znaków F34945; negatyw obrazu F37348; rozmycie ruchu, szum Poissona, zmniejszanie rozdzielczości F37036; kompresja JPEG, cienie, szum F38468; czarne plamy w miejscach śrub S, bo osłonki śrub w IR wyglądają jak czarne plamy F50048, a mocowania dały 72,6% błędnych odczytów F36605. Bez odbić lustrzanych F39018. Syntetycznej pogody nie traktuję jako zamiennika zdjęć: dodanie obrazów z deszczem, śniegiem i mgłą nie poprawiło detekcji w tych warunkach F35057.
• Dane prawdziwe i licencje: CCPD – MIT F33211; GLPD (ponad 5 mln zdjęć, 74 kraje) z Platesmania, kopiowanie z obowiązkowym linkiem F36066; European License Plates (1455 zdjęć) – CC BY 4.0 F42925; RodoSol-ALPR i UFPR-ALPR tylko do badań niekomercyjnych F43802F40227, więc poza treningiem produktu.
• Skala: PARSeq na GLPD douczano 33 600 iteracji przy batchu 192, czyli ok. 2,15 epoki na 3 mln zdjęć (obl. I) F39575F49351. OCR: Adam, lr 10⁻³, ReduceLROnPlateau (patience 3, współczynnik 0,1), batch 64, do 100 epok, wczesne zatrzymanie po 7 F36114. Detektory: dostrojenie 30–50 epok, jak YOLOv11-pose na CCPD F40460 i YOLOv5m na GLPD F46999; etap transferu na dane polskie 30 epok F47825.
• Cel danych polskich: co najmniej 6000 różnych numerów S, bo przy 6000 prawdziwych tablic z augmentacją uzyskano 98,9% (Chiny) F38003.
• Podział: wszystkie zdjęcia jednej tablicy i jednego pojazdu w jednym podzbiorze F35819F43271; numery o NED ≥ 0,9 w tym samym podzbiorze F39296; usuwanie duplikatów hashem percepcyjnym (w jednym zbiorze wykrył 5,8% duplikatów F37962); zbiór testowy z innego obiektu i innej kamery niż trening S.
• Douczanie w eksploatacji: poprawki operatora zbierane do 2000 przypadków, potem dotrenowanie z odtwarzaniem danych w proporcji 70:30 stare:nowe F42558F41159.

Ryzyko i lukiBrak danych w źródłach: zysku z syntezy dla tablic polskich, liczby polskich zdjęć potrzebnej do 99% oraz licencji GLPD wprost dopuszczającej trening modelu zamkniętego (źródła podają tylko warunek linku F36066).

2.5Kwantyzacja i konwersja na RKNN

DecyzjaDetektor pojazdu: PTQ INT8 z kwantyzacją wag per kanał. Detektor tablicy z narożnikami i oba modele OCR: QAT INT8, 10 epok po treningu FP32. Na NPU idą tylko sploty, BN i proste aktywacje. Na CPU, w C++, zostają: dekodowanie wyjść, sigmoid i softmax, NMS, punkty kluczowe, homografia z próbkowaniem wycinka, reguły składni i głosowanie.

Dlaczego

• Detektor tablic jest wrażliwy na INT8: PTQ obniża mAP50-95 detektora tablic z 0,549 do 0,482 (−12,2%), a QAT daje 0,560 F48719 (obl. G); INT8 wyraźnie obniża precyzję detekcji tablic w kilku konfiguracjach F44170; przy tych samych ustawieniach INT8 QAT stale wygrywa z PTQ F45802.
• PTQ wymaga starannej kalibracji: naiwna PTQ YOLOv8n traci 0,058 mAP50-95, a PTQ z kontrolą dokładności 0,0138 F43651; kwantyzacja per tensor obniża wyniki pojazdów średnio o 0,25, per kanał zostaje blisko oryginału F40516; YOLOv8s per kanał traci tylko 0,45 pp F46364.
• Małe OCR znoszą INT8 po QAT: model typu LPRNet traci 0,04–0,17 pp F36260, CRNN w INT8 mieści się w ±1 pp F46956.
• Operatory: rknn-toolkit2 1.6.0 przenosił atencję na CPU F39503; NPU Arm Ethos słabo przyspiesza softmax, sigmoid i exp z głowic detektorów, więc autorzy przenieśli głowice na CPU F47325F47326; RKNN nie obsługuje głowicy YOLO26 bez NMS F47147. Rozdzielenie wyjść i dekodowanie na CPU podniosło wykorzystanie NPU RK3588 z 60% do 90% F45885.
• INT8 na RK3588 skraca czas 1,76× przy −1,6 pp mAP@0,5 F48863, a FP16 bywa tam wolniejsze od FP32 F47436.

Parametry i wykonanie

• Kalibracja PTQ: 300–500 klatek z docelowych kamer z nocą w IR i scenami bez pojazdu S; 300 obrazów z samochodami użyto do kalibracji INT8 detektora pojazdów i tablic barrier-0123 F40519.
• W FP16 zostawiam pierwszy splot i ostatnie sploty predykcyjne głowic, jak w YOLOv8s zoptymalizowanym przez Arm F46369; w detektorze tablicy dotyczy to zwłaszcza splotu punktów kluczowych S.
• Eksport: ONNX opset 12–19 (wg producenta F46072), stałe wymiary wejść F43171, postprocessing w C++, bo GIL szeregował wątki postprocessingu w Pythonie F46867.
• Weryfikacja na płytce, bo udana konwersja nie gwarantuje zgodności wyjść F47149: ten sam zbiór testowy w FP32 i na NPU; próg przyjęcia: spadek dokładności całych numerów ≤0,3 pp, czułości tablic ≤0,2 pp S.

Ryzyko i lukiBrak danych w źródłach: pomiaru QAT dla OCR i detektora z punktami kluczowymi na RKNN oraz listy operatorów RKNN 2.x działających na NPU.

2.6Fuzja 2–3 modeli OCR

DecyzjaFuzja dwóch modeli (OCR-A i OCR-B) na 6 najlepszych wycinkach śladu daje 12 głosów. Wynik to głosowanie większościowe na poziomie całego ciągu; remis rozstrzyga OCR-A (zasada MV-BM F37278). Odczyt przyjmuję, gdy zwycięski ciąg ma co najmniej 7 z 12 głosów i co najmniej 2 głosy od każdego modelu S; w przeciwnym razie trafia do ścieżki „niepewny” (rozdz. o decyzji). Czasowo fuzja na NPU się opłaca: dwa modele to 26 ms pracy NPU na przejazd, trzeci dodałby 13 ms (obl. E). Trzeciego modelu w pierwszej wersji nie dodaję, bo zysk z trzeciego modelu jest mniejszy niż z kolejnych klatek; fuzji po najwyższej pewności nie stosuję.

Dlaczego

• Głosowanie na poziomie całego ciągu wygrywa z głosowaniem po pozycjach i z wyborem najpewniejszego odczytu F34612F37274; wybór po pewności zawodzi, bo modele mylą się z wysoką pewnością, także na danych spoza treningu F35087F38293, a normalizacja pewności nie pomogła F37678.
• Zysk z modeli zależy od ich siły i różnorodności: dwa najlepsze modele dają +1,7 pp, trzy +2,5 pp, cztery najszybsze +3,0 pp przy 1,48× czasu najlepszego modelu, a trzy najszybsze słabe −1,3 pp względem najlepszego pojedynczego (obl. F) F49690F51007F49182F35091. Między zbiorami fuzja podnosi średnią z 75,9% do 90,3% F36872.
• Głosowanie po klatkach daje więcej: +13,44 pp na UFPR-ALPR i +8,08 pp na SSIG F48844F48845, +15,1 pp w wideo F45431, +28 pp dokładności znaków przy 5 klatkach zamiast 1 F48012. Głosowanie nie naprawi znaku, którego detektor nie zaproponował w żadnej klatce F44955.
• Czas poza NPU: te same dwa modele na CPU A76 to ok. 124 ms na przejazd, a PARSeq zamiast OCR-B dodałby 269–337 ms (obl. E).

Parametry i wykonanie

• Wycinki do OCR: tablica szeroka na ≥116 px w klatce (obl. A), pewność układu ≥0,75 F47316, 6 o najwyższym wyniku tablicy S; przy 30 km/h i strefie 3 m tablica jest w kadrze 0,36 s, czyli 9 klatek przy 25 kl./s (obl. E).
• Szczyt obciążenia (dwa przejazdy jednocześnie, tło detektora pojazdu): 39% NPU, gdy trzy rdzenie liczą równolegle jak przy ok. 100 kl./s YOLOv8 na 3 wątkach F42024; w wariancie ostrożnym 117%, co daje 60 ms zaległości (obl. E).
• Kod głosowania:

def fuse(reads):                      # reads: [(model, text, char_conf)], 2 modele x K wycinków
    reads = [r for r in reads if syntax_ok(r.text)]           # reguły z rozdz. 2.3
    votes = Counter(r.text for r in reads)
    top = votes.most_common()
    if not top: return None, "niepewny"
    best_n = top[0][1]
    tied = [t for t, n in top if n == best_n]
    text = tied[0] if len(tied) == 1 else pick_from_model(reads, tied, "OCR-A")   # MV-BM
    by_model = Counter(r.model for r in reads if r.text == text)
    ok = best_n >= 7 and by_model["OCR-A"] >= 2 and by_model["OCR-B"] >= 2      # S, przy 12 głosach
    return text, "pewny" if ok else "niepewny"

Ryzyko i lukiBrak danych w źródłach: zysku z połączenia dwóch modeli i wielu klatek naraz na tablicach polskich. Przy niezależnych odczytach 12 głosów o trafności 90% dałoby 99,95% (obl. F), ale błędy klatek jednego przejazdu są skorelowane (śruby F36605, stały kąt), więc to tylko górna granica.

Założenia S i obliczenia

• Skrypt decyzja/obliczenia/p02.py, wynik p02.out; sekcje A–I.
• A, B: tablica 520×110 mm F36818, znak 80 mm, kreska 9 mm F38418; px znaku = szerokość tablicy w px × 80/520. Kanwy OCR 96×288 i 64×192 o proporcji 3:1; tablica jednorzędowa na pełną szerokość, dwurzędowa na pełną wysokość z marginesem z obrazu S.
• C: błąd punktu 1 px na wejściu 384 S; wycinek pojazdu 1000–2000 px i tablica 160–200 px w klatce 2560 px S; błąd = 1 × szer. wycinka / 384, odniesiony do szerokości tablicy.
• D: przeliczniki 17,26 ms / 8,7 GFLOP = 1,98 ms/GFLOP (YOLOv8n RKNN F42607F45868) i 6,5 / 1,8 = 3,61 ms/GFLOP (mały model F41120); CPU A76: 120–150 ms / 8,7 GFLOP F36558. GFLOP modeli liczone liniowo z liczbą pikseli wejścia od YOLOv8n 640×640 S. Pomiar YOLOX-Tiny 18 ms F44265 przeskalowany przy założeniu wejścia 416×416 S. OCR-B ≤0,6 GFLOP to cel projektowy S.
• E: 30 km/h z ram systemu, strefa czytelności 3 m S, 25 kl./s S, 6 wycinków do OCR S, detektor pojazdu 5 kl./s na kamerę S. Pojemność NPU 1000 ms/s (18 ms już z trzema rdzeniami) lub 3000 ms/s (trzy rdzenie równolegle F42024).
• F: wartości fuzji z F49690F51007F35091F49182F36872; klatki z F48844F48845F45431F48012; rozkład dwumianowy przy niezależności odczytów S.
• G, H, I: różnice dokładności po kwantyzacji, krotności błędu po usunięciu duplikatów i skala treningu z ustaleń podanych w skrypcie.
• S Progi akceptacji fuzji (≥7 z 12, ≥2 od każdego modelu), progi zgodności INT8/FP32 (0,3 pp i 0,2 pp), powiększenie ramki pojazdu o 10%, 300 tys. obrazów syntetycznych, ≥6000 polskich numerów, zbiór testowy z innego obiektu.
• Z pliku dane/nauka/p02.jsonl przeczytałem wszystkie 6163 ustalenia (pogrupowane w 4879 treści po scaleniu powtórzeń) i wykorzystałem 152 z nich (pozostałe 14 cytowanych ustaleń pochodzi z plików s0X.jsonl: przepisy i wymiary tablic, licencje zbiorów, pomiary RF-DETR, WPOD-NET i YOLOv8n na rdzeniach A76).

Część 3Dane treningowe i pętla uczenia na obiekcie

3.1Zestaw startowy danych i licencje

DecyzjaModel produktu uczy się wyłącznie na danych, do których właściciel ma prawo trenowania modelu zamkniętego: własnych syntetykach polskich tablic, zbiorze CCPD (licencja MIT) użytym tylko do pretreningu detektora tablicy i narożników, nagraniach z pierwszych obiektów właściciela opisanych ręcznie oraz, opcjonalnie, zbiorze UniData PL kupionym na umowie, która wprost dopuszcza trening modelu komercyjnego. Zbiory „tylko do badań” i zbiory bez ustalonej licencji nie wchodzą ani do treningu, ani do pretreningu, ani do oceny; ich wyniki z publikacji służą wyłącznie jako punkty odniesienia.

Dlaczego

• RodoSol-ALPR i UFPR-ALPR są udostępniane tylko do badań niekomercyjnych, a pobranie wymaga umowy wysłanej z konta uczelni F33427F33503. Licencja ELP zabrania użycia zbioru w zastosowaniach komercyjnych „w jakiejkolwiek formie”, także w postaci plików z wyekstrahowanymi cechami F42163; wagi wytrenowanego modelu są taką formą S.
• Ograniczenia licencji danych przechodzą na model: projekt akhet ma licencję niekomercyjną, bo część danych treningowych była niekomercyjna F40085. Analiza licencji ODbL opisuje „skażenie licencyjne” całego modelu, gdy do puli trafi zbiór z obowiązkami udostępniania, z wyborem między otwarciem modelu a wstrzymaniem sprzedaży F48680.
• Zdjęcie widoczne publicznie pozostaje w Europie chronioną daną osobową F41999, w UE pobieranie takich danych wymaga zgody F37450, a firma trenująca model na sprzedaż jest administratorem danych treningowych F36365. To wyklucza zbiory zbierane z serwisów społecznościowych (GLPD z Platesmanii, polski podzbiór Békésiego i Eklera).
• CCPD ma licencję MIT i 366 789 zdjęć F33211F33922; adnotacja zawiera cztery narożniki tablicy F38045, ale z dużymi błędami współrzędnych także po poprawce z 2019 r. F33924.

Parametry i wykonanie

W pretreningu detektora strata narożników CCPD ma wagę 0,3 względem straty ramki S, bo narożniki są niedokładne F33924; pełną wagę dostają narożniki opisane na nagraniach pilotażowych.

Ryzyko i lukiBrak danych w źródłach: publiczny polski zbiór z licencją dopuszczającą zamknięty produkt nie istnieje, więc cała część prawdziwa pochodzi z obiektów właściciela albo z zakupu. Cena i warunki UniData nie występują w ustaleniach; pełny zbiór jest dostępny po kontakcie z dostawcą F32448.

3.2Generator syntetycznych polskich tablic

DecyzjaGenerator jest rendererem szablonowym: własne wektorowe glify zbudowane z geometrii przepisów (wariant ostry i zaokrąglony), tła i elementy tablicy rysowane programowo, bez GAN i bez silnika 3D w pierwszej wersji. Daje 100 000 wycinków OCR, uzupełnionych permutacjami znaków na prawdziwych wycinkach, oraz wklejki tablic na prawdziwe klatki dla detektora. Proporcja w partii uczącej: 3:1 (syntetyki:prawdziwe) do 5 000 unikalnych tablic prawdziwych, 1:1 do 20 000, potem 1:3 S.

Dlaczego

• Porównanie 16 modeli OCR na 12 zbiorach: masowa synteza podnosi wyniki w obrębie zbioru i między zbiorami, a szablony, permutacja znaków i GAN działają synergicznie F45234; 100 000 obrazów z szablonów dało nieco lepszy wynik niż 50 000 F45239; permutacja daje dużo większy zysk modelom bez segmentacji znaków (CRNN, Multi-Task) F45240.
• Sama synteza nie wystarcza: na Dataset-1 model uczony tylko na skryptowych syntetykach osiąga 42,2%, na najlepszym GAN 64,5% F38001. Przy 6 000 prawdziwych tablic GAN zmniejsza błąd tylko z 1,1% do 1,0% (obliczenia A) F38003, a GAN-y są niestabilne i podatne na mode collapse F41530. Obrazy z szablonów mają inny rozkład niż zdjęcia F39817, a syntetyczne degradacje nie odtwarzają rzeczywistego szumu F49384.
• Dla tablic europejskich użyto 4 mln syntetyków z dokładnych opisów formatów 16 krajów obok 1,4 mln zdjęć, czyli 2,86:1 (obliczenia A), ze zniekształceniami: rozmycie ruchu, szum Poissona, zmniejszanie dwuliniowe F37038F37037F37036. Dodanie w pełni syntetycznych danych do OCR poprawiło wynik na wszystkich zbiorach testowych, na AOLP-RP o ok. 5% F37553.
• Wyłączenie augmentacji koloru usunęło ponad połowę błędów klasyfikacji układu tablicy F38028. Polskie typy różnią się kolorem tła i znaków, więc generator nie zmienia odcienia; zmienia tylko jasność i kontrast.

Parametry i wykonanieSpecyfikacja obejmuje wyłącznie cechy opisane w ustaleniach:

• Wymiary: tablica jednorzędowa 520 × 110 mm (wg producenta oprogramowania LPR) F44218; dwurzędowe 305 × 214 mm (samochody, przyczepy), 190 × 150 mm (motocykle), 140 × 114 mm (motorowery) F38417; w górnym rzędzie wyróżnik miejsca, w dolnym wyróżnik pojazdu, z wyjątkiem tablic dyplomatycznych F38422. Źródłem geometrii jest rozporządzenie z 8 listopada 2024 r. (Dz.U. 2024 poz. 1709) F42280.
• Krój obecny: na tablicach samochodowych znak 80 mm, litera do 47 mm, cyfra do 43 mm, kreska 9 mm F38418; motocyklowe 45/28/7 mm, motorowerowe 30/20/16/5 mm F38419. Krój szerszy do 30 czerwca 2018 r.: litera do 54 mm, kreska 10 mm, wydawany do wyczerpania zapasów F38420F38421. I, J, 1, L i T nie wypełniają pola znaku F38424; każdy znak ma wersję normalną i wąską, a krawędzie po wytłoczeniu są zaokrąglone (wg producenta kroju) F32822F32821.
• Typy: białe znaki na czarnym (wzór 1976–2000, nadal ważny) F38591; Euroband od 1 maja 2006 r. zamiast flagi F32518; jasnozielone tło dla pojazdów elektrycznych i wodorowych F32520; zielone znaki na białym (profesjonalne) F32519; żółte tło z symbolem pojazdu (zabytkowe) F32522; czerwone znaki na białym albo na żółtym dla aut sportowych (tymczasowe) F32523. Przydział 100 000 wycinków na typy podaje sekcja B obliczeń S.
• Ciąg znaków: wyróżnik miejsca koduje województwo i powiat F49699, w gęstych regionach ma dodatkowy znak F49700; w wyróżniku pojazdu nie ma B, D, I, O, Z, z wyjątkiem tablic indywidualnych F38590; wiodące zero zostaje F38592; długość 5–8 znaków F38919. Ustalenia nie podają pełnej listy układów, więc generator odczytuje rozkład klas pozycji (litera/cyfra) z etykiet prawdziwych i losuje znaki równomiernie w klasie, co przeciwdziała dominacji lokalnych wyróżników F39815.
• Elementy fizyczne: naklejka legalizacyjna w przerwie po wyróżniku miejsca, bo powoduje błędne czytanie litery I na trzeciej pozycji F36533; śruby i zaślepki w 50% próbek S, bo mocowania odpowiadały za 72,6% z 700 błędnych odczytów w badaniu brytyjskim F42983.

geometria: homografia, yaw ~ U(0°, 60°), pitch ~ U(0°, 45°), roll ~ U(-10°, 10°)       S
rozmycie:  jądro liniowe 0–12 px w kierunku ruchu (obl. C: 1/250 s, 200 px, 60° -> 11,1 px)
skala:     zmniejszenie dwuliniowe do 40–100% i powrót; szum Poissona; JPEG q ~ U(30, 95)
IR nocą:   30% próbek mono, jasność tablicy ±30% F50127, halo wokół znaków             S
pogoda:    mgła/deszcz/cień/śnieg/odblask (Albumentations) w 30% próbek                  S
brud:      zasłonięcia 0–20% powierzchni tablicy                                          S
kolor:     bez zmian odcienia; jasność i kontrast ±15%                                    F38028

Zakres kątów obejmuje oba osie z zapasem względem pasa: w benchmarku syntetycznym 90–92% siatki kątów [0°, 89°]² daje się odczytać po rekonstrukcji F47944. Udział IR wynika z błędów: zdjęcia nocne IR to 21,5% zbioru UFPR-VeSV, ale 53,4% błędów rozpoznania marki, czyli 4,18 razy wyższa stopa błędów (obliczenia D) F45044; wygląd tablic w IR i w świetle widzialnym się różni F50312. Te same pięć transformacji pogodowych obniżyło polski model do 73,49% w deszczu i 44,58% w śniegu F42274F48671. Detektor dostaje wklejki syntetycznych tablic, zwłaszcza dwurzędowych, na prawdziwe klatki z obiektów; tak zbudowano 50 000 tablic dwurzędowych w TransLPRNet F50751.

Ryzyko i lukiBrak danych w źródłach: zmierzony zysk z syntezy dla tablic polskich lub europejskich i z symulacji nocnego IR. Proporcje 3:1, 1:1 i 1:3 opierają się na relacji 2,86:1 z pracy europejskiej i na malejącym zysku z syntezy przy rosnącej liczbie prawdziwych tablic F38006.

3.3Podział danych bez niemal-duplikatów i ocena międzyzbiorowa

DecyzjaJednostką podziału jest grupa tablicy: wszystkie wycinki z tym samym znormalizowanym numerem trafiają do jednego zbioru, niezależnie od obiektu. Każda wersja modelu ma trzy wyniki: test czasowy (ostatnie 4 tygodnie każdego obiektu) S, test z pominiętym obiektem (leave-one-site-out) i stały zbiór referencyjny 3 000 przejazdów. Audyt hashem percepcyjnym wyłapuje niemal-duplikaty między grupami.

Dlaczego

• W AOLP-B 67,6% obrazów testowych ma duplikat w treningu, a w CCPD 19,1% F48716F34473. Po podziale uczciwym błąd rośnie ponad dwukrotnie, a model najlepszy w podziale tradycyjnym spada na trzecie miejsce F36638F35050.
• Kamery statyczne dają bardzo podobne wycinki różnych zdjęć: najbliższe pary w RodoSol-ALPR mają MSE 174 i 407, w UFPR-ALPR 1 686 i 1 700 F37594; zbiory z kamer statycznych mają najsilniejszą sygnaturę F36211, a jej przyczynami są kamera i kompresja zapisu F36461. Obiekt właściciela to jedna kamera statyczna na pas.
• Nowy obiekt obniża wynik detektora pojazdów i miejsc z 99,46% do 81,67%, czyli błąd rośnie 33,9 razy (obliczenia F) F43962; w protokole leave-one-dataset-out średnia OCR spada z 82,4% do 74,5% F44416.
• W UFPR-VeSV i w marokańskim zbiorze tablic wszystkie zdjęcia pojazdu trafiają do jednego zbioru F42332F43271; audyt hashem percepcyjnym wykrył 5,8% niemal-duplikatów w zbiorze testowym detektora tablic F37962.

Parametry i wykonaniePrzy losowym podziale zdjęć 80/20 tablica z 10 zdjęciami trafia do obu zbiorów z prawdopodobieństwem 0,893 (obliczenia E).

klucz = normalizuj(numer)                    # wielkie litery, bez spacji i myślników
grupy = union_find(klucz)                    # jedna grupa = jedna tablica na wszystkich obiektach
for para in lsh(phash(wycinek_wyprostowany), hamming <= 6):     # S
    if mse(para) < 500: połącz(grupy, para)  # błędna etykieta tej samej tablicy F39469F37594
podział: grupa -> train/val/test (70/10/20) S; obiekt pominięty: wszystkie grupy obiektu -> test

Stały zbiór referencyjny: 3 000 przejazdów z co najmniej 5 obiektów, warstwy: noc IR ≥20%, kąt powyżej 30° ≥20%, tablice dwurzędowe i typy specjalne ≥10% S. Przy 10 błędach na 3 000 dolna 95-procentowa granica skuteczności wynosi 99,44%; potwierdzenie ≥99% wymaga 299 przejazdów bez błędu albo 1 693 przy 10 błędach (obliczenia G). Zewnętrzny test detektora: CCPD-Tilt i CCPD-Rotate; zewnętrzny test OCR: UniData PL po zakupie. Zbiór referencyjny nigdy nie wchodzi do treningu ani do kalibracji kwantyzacji.

Ryzyko i lukiNa parkingu ze stałymi użytkownikami te same tablice wracają setki razy, więc liczba unikalnych grup jest wielokrotnie mniejsza od liczby przejazdów S. Brak danych w źródłach: progi hasha percepcyjnego dla wycinków tablic.

3.4Zapis na SBC i automatyczne etykiety

DecyzjaSBC zapisuje dla każdego przejazdu wszystkie wycinki tablicy ze śladu wraz z odczytami i pewnościami. Etykieta śladu powstaje automatycznie, gdy co najmniej 3 ważne odczyty dają ten sam ciąg, zwycięzca ma ≥60% głosów, a model-nauczyciel na serwerze daje ten sam ciąg. Etykieta przechodzi na wszystkie wycinki śladu, także małe i rozmyte, na których pojedynczy odczyt był błędny. Ślady bez zgody trafiają do kolejki operatora.

Dlaczego

• W zbiorze LRLPR-26 tekst tablicy opisano głosowaniem większościowym OCR na pięciu wycinkach z bliska, a wycinki z daleka dostały tę samą etykietę F43209F43206. Przy takim opisie OCR mylił się w ok. 5% ścieżek UFPR-SR-Plates F38777, więc etykiety automatyczne wymagają audytu. W europejskim zbiorze 1,4 mln zdjęć 60% etykiet powstało automatycznie F37037.
• Pewność pojedynczego modelu nie nadaje się do etykietowania: modele mylą się z wysoką pewnością także na danych spoza treningu F44537; głosowanie na poziomie całego ciągu wygrywa z głosowaniem na znak i z wyborem najpewniejszej odpowiedzi F33591; dodanie pewności do głosowania zmniejsza liczbę błędów o kolejne 5–10% F48146.
• Niezależne modele zbiegają się na poprawnej odpowiedzi i rozchodzą na błędnej F48094; fuzja 4–6 modeli daje najlepszy stosunek dokładności do czasu F32587, a na danych spoza treningu podnosi średnią z 75,9% do 90,3% F36872. Po głosowaniu w klatkach zostają tablice mylone prawie w każdej klatce F45432, dlatego potrzebny jest drugi, inny model.
• Ważenie klatek ostrością i rozdzielczością nie dało istotnej statystycznie poprawy F44574; ostrość zostaje w zapisie do selekcji przykładów, nie do wag głosu.

Parametry i wykonanieZapis na wycinek: JPEG tablicy z marginesem 20%, szerokość do 256 px, ok. 10 kB S (odniesienie: brytyjski standard wymaga wycinka 120 × 60 px do 3 kB F39426), cztery narożniki, pewność detekcji, ciąg OCR, prawdopodobieństwa dwóch najlepszych klas na znak, wariancja Laplasjanu oraz średnia i odchylenie jasności F39577, czas, kamera, identyfikator śladu, decyzja szlabanu. Przy 600 przejazdach na dobę i 15 wycinkach to 88 MB na dobę i 2,57 GB na 30 dni (obliczenia J) S. SBC nie zapisuje pełnych klatek, wysyła na serwer tylko ślady wybrane poniżej i usuwa bufor po 30 dniach S.

ważne = [r for r in ślad if regex_PL(r.tekst) and min(r.p_znaku) > 0.4]   # F44435
zwycięzca, udział = głosowanie_ciągu(ważne, waga=średnia_pewność)       # F33591F48146
if len(ważne) >= 3 and udział >= 0.6 and nauczyciel(ślad) == zwycięzca:   # F49227, S
    etykieta(ślad) = zwycięzca; wyślij(ślad, wszystkie_wycinki)           # trudne wycinki = złoto
elif operator_wpisał_numer(ślad) or len(ważne) > 0:
    kolejka_operatora(ślad)
audyt: losowe 600 śladów z etykietą automatyczną na wersję; 0 błędów => błąd etykiet <= 0,5% (obl. I)

Nauczyciel to fuzja 4–6 modeli OCR o różnych architekturach, uczona na serwerze na tych samych danych co model SBC F32587 S. Najcenniejsze są ślady, w których pojedyncze wycinki przeczą etykiecie śladu: to dokładnie te przypadki, na których model SBC się myli.

Ryzyko i lukiBrak danych w źródłach: zmierzony udział błędnych etykiet przy podwójnym warunku (głosowanie i nauczyciel) dla tablic polskich; jedyny pomiar to ok. 5% błędów przy samym głosowaniu OCR F38777. Błąd systematyczny wspólny dla modelu SBC i nauczyciela przechodzi przez filtr; wykrywa go tylko audyt.

3.5Poprawki operatora, douczanie poza SBC i wdrożenie wersji

DecyzjaTrening odbywa się na serwerze z GPU; SBC tylko wnioskuje. Detektor dostraja się przy każdej nowej kamerze po 100 zweryfikowanych klatkach. OCR douczany jest od wag produkcyjnych, gdy uzbiera się 2 000 nowych zweryfikowanych śladów, w partii 70% danych bazowych i 30% nowych. Każda wersja przechodzi kwantyzację INT8 z douczaniem (QAT), ocenę modelu już po kwantyzacji na zbiorze stałym i obiekcie pominiętym, a potem kanarka w trybie cienia na 1–2 obiektach z testem znaków na parach niezgodnych.

Dlaczego

• W systemie Neural Sentinel poprawki użytkowników trafiają do bufora; po 2 000 poprawek startuje douczanie LoRA z powtórką danych 70:30 przeciw katastrofalnemu zapominaniu, a nowy model podmienia się bez przerwy w działaniu F42558. Według dokumentacji producenta Frigate+ wymaga co najmniej 100 zweryfikowanych zdjęć na kamerę, w proporcji 80% trafnych i 20% fałszywych detekcji, z różnych pór dnia F41771.
• Start od pokrewnych wag pomaga, a dłuższy trening bez nowych danych nie: transfer z tablic czeskich podniósł polski wynik z 87,3% do 89,2% F45455, transfer zmniejszył błąd normED o 28–38% F46574, a 30 dodatkowych epok na tych samych danych dało 87,2% F37842. Adaptacja z wyborem zamrożonych etapów sieci służy sytuacji z małą liczbą etykiet F50619F50620.
• Kwantyzacja po treningu obniżyła precyzję detektora tablic z 0,941 do 0,906 F47916, a QAT z 10 epokami dostrajania odzyskała i przekroczyła wynik bazowy F47193F47917; INT8 obniża precyzję detektorów tablic na części zbiorów F44170, więc oceniany jest zawsze model po kwantyzacji. Według dokumentacji RKNN-Toolkit2 konwersja do formatu RKNN odbywa się na komputerze, nie na płytce F46073.

Parametry i wykonanie

• Cykl OCR: 2 000 nowych śladów = 30% partii, czyli 6 667 śladów w cyklu, z tego 4 667 z bazy (obliczenia K); baza zawiera syntetyki rzadkich typów z 3.2. Dostrajanie trwa 30 epok od wag produkcyjnych, jak faza retreningu u Békésiego i Eklera F49505, potem QAT 10 epok F47193.
• Czas zbierania: przy kolejce 5% przejazdów jeden obiekt z 600 przejazdami na dobę zbiera 2 000 poprawek w 66,7 dnia, 10 obiektów w 6,7 dnia (obliczenia J) S.
• Kalibracja INT8: 500 wycinków z obiektów spoza zbioru stałego S.
• Bramka: na zbiorze stałym nowa wersja nie traci więcej niż 0,3 pp w żadnej warstwie i nie traci w całości S; na obiekcie pominiętym nie traci więcej niż 0,5 pp S; w cieniu (nowa wersja liczy równolegle, decyzję podejmuje stara) zbiera ≥50 przejazdów, w których wersje się różnią i operator albo nauczyciel rozstrzyga spór, i wygrywa co najmniej 32 z 50 (obliczenia H).
• SBC przechowuje poprzednią wersję i wraca do niej jednym przełącznikiem konfiguracji.

Ryzyko i lukiBrak danych w źródłach: zmierzony zysk dokładności z pętli poprawek operatora dla tablic; Neural Sentinel opisuje mechanizm, nie podaje zysku. Próg 2 000 pochodzi z systemu VLM, nie z modelu CTC.

3.6Ile danych potrzeba do celu

DecyzjaWersja 1 startuje przy ≥5 000 unikalnych polskich tablicach zweryfikowanych z obiektów pilotażowych, 100 000 syntetyków i pretreningu detektora na CCPD. Docelowo, dla 99% całych numerów na przejazd z głosowaniem w śladzie, zbiór obejmuje 20 000–30 000 unikalnych tablic (ok. 10 wycinków na ślad). Miarą ilości danych jest liczba unikalnych tablic, nie zdjęć ani przejazdów.

Dlaczego

• Sama liczba zdjęć bez augmentacji daje płaską krzywą: 9 000 → 50 000 tablic obniża błąd z 3,9% do 3,3%, a dopasowanie potęgowe wymagałoby 1,1·10¹⁰ tablic dla 1% (obliczenia L) S; 4 750 tablic z augmentacją i syntezą ma 3,3 razy mniejszy błąd niż 50 000 bez nich (obliczenia A).
• Dane z jednego obiektu przy głosowaniu dają wg operatora 98,6% przy 18 000 etykiet F42840; ekstrapolacja potęgowa daje 1% błędu przy ok. 28 900 etykietach i 0,5% przy ok. 76 700 (obliczenia L) S.
• Głosowanie w śladzie podnosi wynik z 29% do 69% przy 35 klatkach, dalej bez zysku F47298, a na UFPR-ALPR z 64,89% do 78,33% F48844; dokładność modelu sekwencyjnego rośnie monotonicznie z liczbą klatek F37035.
• 99% na tablicę przy błędach niezależnych wymaga dokładności znaku 99,857% dla 7 znaków i 99,874% dla 8 znaków (obliczenia M) S.
• Detektor na nowym obiekcie: model dostrojony 36 opisanymi zdjęciami utrzymał 94,12% wobec 95,23% na obiektach znanych F43963, a model bez adaptacji tracił 17,79 pp F43962; stąd 100 klatek na kamerę z 3.5.

Parametry i wykonanie

Ryzyko i lukiBrak danych w źródłach: krzywa dane → dokładność dla tablic polskich. Punkty z Dataset-1 pochodzą z jednego kraju o stałym formacie, a dane WINK to deklaracja operatora z jednej kamery; liczby 5 000 i 20 000–30 000 są interpolacją tych punktów S.

Założenia S i obliczenia

Skrypt decyzja/obliczenia/p03.py, wynik p03.out (sekcje A–M).

• Wagi narożników CCPD 0,3; ślad w cieniu; retencja bufora SBC 30 dni; brak pełnych klatek na SBC.
• Proporcje syntetyki:prawdziwe 3:1 / 1:1 / 1:3 i progi 5 000 / 20 000 tablic; przydział 100 000 wycinków na typy (sekcja B).
• Zakresy generatora: yaw 0–60°, pitch 0–45°, roll ±10°, rozmycie 0–12 px (sekcja C: blur = v·t·sin θ·W/0,52 m przy v = 30 km/h), IR 30%, pogoda 30%, brud 0–20%, śruby w 50% próbek, jasność i kontrast ±15%.
• Stopa błędów IR: (0,534/0,215)/(0,466/0,785) = 4,18 (sekcja D); wyciek przy losowym podziale: 1 − 0,8ᵏ − 0,2ᵏ (sekcja E).
• Podział 70/10/20, test czasowy 4 tygodnie, próg Hamminga 6 i MSE 500, warstwy zbioru stałego; granice Cloppera–Pearsona przy niezależnych przejazdach (sekcja G).
• Progi auto-etykiet: ≥3 ważne odczyty, udział zwycięzcy ≥60%, zgodność z nauczycielem; audyt 600 śladów (n ≥ ln 0,05 / ln(1 − q), sekcja I).
• Przepływ: 300 przejazdów na kamerę na dobę, 2 kamery, 15 wycinków, 10 kB na wycinek, kolejka 3–5% (sekcja J).
• Bramka kanarka: 0,3 pp, 0,5 pp, 50 par niezgodnych, ≥32 wygrane (test znaków, sekcja H); kalibracja INT8 na 500 wycinkach; powtórka 70:30 (sekcja K).
• Krzywa potęgowa e(N) = e₀(N/N₀)^(−a) do ekstrapolacji (sekcja L); niezależność błędów znaków (sekcja M).
• Z pliku dane/nauka/p03.jsonl przeczytałem wszystkie 5 679 ustaleń (po scaleniu powtórzeń 3 659 unikalnych twierdzeń z 511 źródeł), a w rozdziale wykorzystałem 96 z nich; pozostałe cytowania pochodzą z dane/s0X.jsonl (opis polskich tablic i licencji zbiorów).

Część 4Droga do 99%: decyzja o numerze

4.1Budżet błędu na przejazd

DecyzjaCel 99,0% poprawnych całych numerów na przejazd rozpisujemy na pięć strat, z których każdą system mierzy osobno w dzienniku zdarzeń: wyzwolenie i detekcja pojazdu 0,05%, za mało użytecznych wycinków tablicy 0,15%, losowy błąd OCR, który przetrwał fuzję, 0,10%, błąd stały pojazdu (śruba, brud, czcionka, naklejka) 0,40%, poprawny odczyt odrzucony progiem pewności 0,30%. Iloczyn (1 − e) daje 99,00%. Drugi, niezależny cel: błędny odczyt (misread) ≤ 0,10% wszystkich przejazdów; brak odczytu (no-read) trafia do ścieżki wyjątku i mieści się w pozostałych stratach.

Dlaczego

• Detekcja nie jest wąskim gardłem: wykrycie pojazdu 99,92% F38914, tablicy 99,45% na całym zbiorze testowym ośmiu zbiorów F38915, a autorzy wskazują rozpoznanie znaków jako wąskie gardło F35748. Na zbiorach spoza uczenia czułość detekcji spada jednak do 97,8% F44229, więc detektor też dotrenowujemy na danych z obiektu.
• Straty etapów mnożą się: potok z 95,2% dokładności na znak daje 88,7% całych tablic F49020. Z wykryciem 99,45% OCR z jednego obrazu musiałby czytać 99,55% całych ciągów (p04 B3), a model CNN-RNN dla tablic polskich osiąga 86,4% na klatkę wideo i 89,2% na zdjęcie F42278F42783, PARSeq na 74 krajach 87,93% F49344.
• Po fuzji zostają głównie błędy skorelowane: po głosowaniu 21,7% pojazdów w UFPR-ALPR i 31,0% na wjazdach parkingowych PSU ma błąd, którego głosowanie przy niezależnych klatkach by nie zostawiło (p04 B4). Dlatego największa pozycja budżetu to E4, a jej zmniejszenie jest zadaniem danych z obiektu (4.5).

Parametry i wykonanie

Przy 30 km/h i strefie 4 m jest 4,8 klatki przy 10 kl./s, 7,2 przy 15 kl./s i 12 przy 25 kl./s (p04 A, N = L / v · fps), więc OCR w oknie zdarzenia pracuje z co najmniej 15 kl./s, aby N ≥ 7, a po bramce jakości n ≥ 5 S. Dziennik zdarzeń zapisuje dla przejazdu czas wyzwolenia, klatki, wszystkie wycinki z szerokością tablicy w pikselach, rozkłady na pozycjach, wynik fuzji, cechy pewności i decyzję; z tych pól liczymy E1–E5 bez ponownego przetwarzania wideo.

Ryzyko i lukiWymagania E2 i E3 zakładają niezależne klatki S; klatki jednego pojazdu są skorelowane, więc wartości z tabeli są dolnymi granicami. Brak danych w źródłach o udziale tablic dwurzędowych, zagranicznych i specjalnych w ruchu na polskich parkingach.

4.2Fuzja odczytów z wycinków śladu

DecyzjaStosujemy fuzję miękką po pozycjach: OCR zwraca dla każdego użytecznego wycinka rozkład prawdopodobieństw na każdej pozycji, system wybiera długość modalną, uśrednia rozkłady pozycji w obrębie tej długości i dekoduje wynik z ograniczeniem składni (4.3). Jakość wycinka działa jako bramka (szerokość tablicy, ostrość, pewność detekcji), nie jako waga. Wybór pojedynczego odczytu o najwyższej pewności jest wykluczony. Głos całym ciągiem liczymy równolegle i używamy jako cechy decyzji.

Dlaczego

• W konkursie ICPR 2026 (269 zespołów F38084) zwycięzca sumował logity pięciu klatek przed dekodowaniem F37050, drugi zespół uśredniał ważone log-prawdopodobieństwa F37051, trzeci głosował po znakach z rozstrzyganiem remisu pewnością F37047. Pięć klatek zamiast jednej dało ok. 28 pkt proc. dokładności znaku (CRNN 44,14% → 72,17%) F48012.
• Dla wielu obrazów tego samego modelu głos po pozycjach (MVCP) daje +4,5–5,0 pkt proc. wobec najwyższej pewności i głosu całym ciągiem F49385. Dla wielu różnych modeli głos całym ciągiem wygrywa nieznacznie, bo głos po pozycjach psują odczyty o znak dłuższe lub krótsze F37679, a w tablicach europejskich większość błędów to właśnie zgubiony lub dodany znak F43189. Stąd grupowanie po długości przed głosem po pozycjach.
• Najwyższa pewność przegrywa ze wszystkimi wariantami głosu, bo modele mylą się z wysoką pewnością F35087, a na danych spoza uczenia nie poprawia żadnego zbioru F38293. Dołączenie pewności do głosu zmniejsza liczbę błędów o dalsze 5–10% względem samego liczenia głosów F48146.
• Ważenie klatek rozdzielczością i ostrością Laplace'a nie dało istotnej poprawy ponad dobrą fuzję F44574, a błędne przypisanie znaków między klatkami obniża wynik poniżej pojedynczej klatki F42541. Kamera jest stała, a wycinek pochodzi z pełnej rozdzielczości, więc śledzimy tablicę jako całość i nie kojarzymy pojedynczych znaków między klatkami.

Parametry i wykonanie

def fuzja(wycinki):                       # jeden ślad = jeden przejazd
    R = [w for w in wycinki
         if w.szer_tablicy_px >= W_MIN and w.ostrosc >= S_MIN and w.det_conf >= 0.5]
    if len(R) < K_MIN:                    # K_MIN = 3
        return BRAK_ODCZYTU()                 # strata E2
    L = argmax_l(sum(w.pewnosc for w in R if len(w.tekst) == l))  # długość modalna
    G = [w for w in R if len(w.tekst) == L]
    P = [mean(w.rozklad[i] for w in G) for i in range(L)]  # średni rozkład na pozycji
    tekst, margines = dekoduj_ze_skladnia(P)                # 4.3
    zgodnosc = sum(dekoduj_ze_skladnia([w.rozklad]).tekst == tekst for w in R) / len(R)
    mv = najczestszy_ciag(R)                                # głos całym ciągiem
    return KANDYDAT(tekst, P, margines, zgodnosc, mv == tekst, len(R))

OCR musi zwracać rozkład na każdej pozycji: w modelu z głowicą na pozycję (fast-plate-ocr, wyjście max_plate_slots × słownik F36779) jest to wyjście sieci, w modelu CTC rozkład z kroków czasowych przypisanych do znaku. K_MIN = 3 odpowiada regule systemu rumuńskiego (trzy odczyty z pewnością > 0,4 zgodne ze składnią F44435); W_MIN i S_MIN ustala rozdział kamerowy. Symulacja S (p04 C) odtwarza kierunek wyników z prac: przy n = 5 najwyższa pewność daje 93,5%, głos całym ciągiem 98,95%, fuzja miękka 99,07%, z dekodowaniem składni 99,29%; przy n = 3 grupowanie długości podnosi głos po pozycjach z 98,30% do 98,58%, a fuzja miękka daje 98,75%.

Sufit przy błędach skorelowanych. Fuzja nie naprawia błędu obecnego we wszystkich wycinkach: wszystkie pozostałe błędne pozycje to przypadki, w których prawdziwy znak nie pojawił się w żadnej klatce F43867, a po głosowaniu zostają tablice mylone prawie w każdej klatce, np. 5 i S F45432. Wynik PSU przestaje rosnąć powyżej 35 klatek F47298. Model „odsetek s pojazdów błędnych w każdej klatce” daje s = 21,7% dla UFPR-ALPR i 31,0% dla PSU, a 22/22 filmów z tablicami polskimi ogranicza s tylko do ≤ 12,7% (p04 B4). Skuteczność nie przekroczy 1 − s przy dowolnej liczbie klatek, więc powyżej n = 5–7 zysk daje praca nad E4, nie nad fuzją.

Ryzyko i lukiBrak danych w źródłach o porównaniu reguł fuzji na tablicach polskich; jedyny pomiar wideo z Polski obejmuje 22 filmy.

4.3Walidator składni tablic PL/UE w dekodowaniu

DecyzjaSkładnię stosujemy wewnątrz dekodowania, nie jako filtr po fakcie: na uśrednionych rozkładach pozycji system wybiera najlepszy ciąg zgodny z szablonem (klasa znaku na każdej pozycji). Korekta wyniku jest dozwolona tylko w obrębie par mylnych; każda inna niezgodność ze składnią obniża pewność i kieruje przejazd do 4.4. Tablice niepolskie dostają tylko regułę długości 5–8 bez korekt, a tablice indywidualne osobną gałąź bez wykluczeń liter.

Dlaczego

• Na 1950 obrazach CCPD korekta ze składnią podniosła trafność całych tablic z 53,90% do 60,05% (+6,15 pkt proc., 95% CI 4,97–7,44) i była głównym składnikiem poprawy F44112F44113; składały się na nią kontrola długości, ograniczenia pozycji, mapy par mylnych i heurystyka liczby liter F44114.
• Klasyfikacja układu tablicy jest konieczna, by uniknąć błędów liczby znaków i par litera/cyfra F34730; system wieloregionowy stosuje mapy zamian 1⇒I, 2⇒Z, 5⇒S, 6⇒G, 8⇒B oraz B⇒8, D⇒0, I⇒1, S⇒5 tylko przy pewnie rozpoznanym układzie F36800F36136. W systemie dla bramek poboru opłat 38,2% wszystkich błędów to zamiany O/0, I/1, B/8 F43931.
• Po dobrej fuzji wieloklatkowej dekodowanie ze składnią nie dało istotnej poprawy F44574; w symulacji p04 C składnia daje +2,8 pkt proc. na pojedynczym wycinku (86,57% → 89,41%) i +0,2 pkt proc. po fuzji pięciu wycinków (99,07% → 99,29%). Zysk koncentruje się na błędach stałych w parach mylnych, których fuzja nie usuwa.
• Stałe reguły zawodzą dla pojazdów z innych krajów i tablic indywidualnych F47996F49855; jedyną regułą dla tablic europejskich w badaniu wieloregionowym była długość 5–8 znaków F38919.

Parametry i wykonanie

def dekoduj_ze_skladnia(P):               # P: lista rozkładów na pozycjach
    kandydaci = []
    for szablon in SZABLONY[dlugosc(P)]:  # PL, indywidualne, profesjonalne, stare, UE
        tekst = [argmax(P[i][c] for c in szablon.klasa[i]) for i in range(len(P))]
        if szablon.miejsce and tekst[:szablon.dl_miejsca] not in KODY_MIEJSCA:
            continue
        logp = sum(log(P[i][tekst[i]]) for i in range(len(P)))
        kandydaci.append((logp, tekst, szablon))
    najlepszy, drugi = dwa_najlepsze(kandydaci)
    wolny = [argmax(P[i]) for i in range(len(P))]       # dekodowanie bez składni
    korekta = [i for i in range(len(P)) if wolny[i] != najlepszy.tekst[i]]
    if any((wolny[i], najlepszy.tekst[i]) not in PARY_MYLNE for i in korekta):
        flaga("poza parami mylnymi")       # obniża pewność (4.4)
    margines = min(P[i][najlepszy.tekst[i]] - drugi_znak(P[i], najlepszy.szablon.klasa[i])
                   for i in range(len(P)))
    return najlepszy.tekst, margines, najlepszy.logp - drugi.logp

PARY_MYLNE = {O/0, D/0, B/8, I/1, Z/2, S/5, G/6} według F36800F45537. Listę wyróżników miejsca i szablonów wyróżnika pojazdu ładujemy z rozporządzenia o rejestracji i oznaczaniu pojazdów (Dz.U. 2024 poz. 1709 F42280) jako plik konfiguracyjny, aktualizowany bez zmiany modelu.

Ryzyko i lukiZmierzony zysk składni (+6,15 pkt proc.) pochodzi z tablic chińskich przy niskim punkcie wyjścia i nie przenosi się wprost na tablice polskie. Brak danych w źródłach: pełna lista szablonów wyróżnika pojazdu i udział tablic indywidualnych w ruchu.

4.4Kalibracja pewności i decyzja „nie wiem”

DecyzjaPewność odczytu to skalibrowane prawdopodobieństwo poprawności: regresja izotoniczna S na cechach przejazdu (margines na pozycji, najmniejsze średnie prawdopodobieństwo na pozycji, przewaga log-prawdopodobieństwa nad drugim ciągiem zgodnym ze składnią, zgodność wycinków i głosu całym ciągiem, liczba wycinków, flaga korekty, warstwa dzień/noc IR, PL/UE). System przyjmuje odczyt, gdy P(poprawny) ≥ t. Poniżej progu przejazd dostaje drugą szansę na liście zamkniętej (pojazdy wewnątrz przy wyjeździe, lista abonamentowa), a gdy i ona nie rozstrzyga, trafia do ścieżki wyjątku z najlepszym wycinkiem.

Dlaczego

• Surowa pewność nie odróżnia błędów: modele mylą się z wysoką pewnością F35087; normalizacja pewności różnych modeli przed fuzją nie poprawiła wyników F37678; w OpenALPR na wideo 15 kl./s ok. 25% odczytów było całkowicie błędnych przy pewności 70% i wyższej F42632.
• Separacja jest możliwa po właściwym zaprojektowaniu: MC-dropout na sieci LPR osiąga AUC 0,994 w wykrywaniu błędnych predykcji przy 99,0% trafności tablic (CCPD), podczas gdy porównywane metody nie wykrywają swoich błędów wcale F36343F36347. Predykcja selektywna wymaga kalibracji klasyfikatora, bo standardowe wyniki pewności są zawyżone F45046F42710.
• Zgodność niezależnych modeli jest dobrym sygnałem (routing po entropii konsensusu kieruje dalej 7,3% próbek i podnosi trafność o 8,2% F48095), ale zgodność klatek jednego pojazdu zawodzi przy błędach stałych: w symulacji p04 D2 prawie nie obniża ryzyka, a margines na pozycji przy pokryciu 98% zmniejsza błędne odczyty z 0,71% do 0,32% (n = 5) i z 0,69% do 0,17% (n = 7).
• Lista zamknięta działa: zapytanie do bazy możliwych tablic wraz z klasyfikacją wyglądu pojazdu dało +7,8 pkt proc. ponad samo głosowanie czasowe (89,6%) F51204.

Parametry i wykonaniePróg z kosztów: przyjmujemy, gdy P(poprawny) ≥ c_m / (c_m + c_n), gdzie c_m to koszt błędnego odczytu, a c_n koszt ścieżki wyjątku; przy c_m/c_n = 10 (punktacja +1/0/−10 F43709) próg wynosi 0,909, przy 100 wynosi 0,990 (p04 D1). Ostateczne t to największe pokrycie na lokalnym zbiorze kalibracyjnym, przy którym jednostronna górna granica 95% (Clopper-Pearson) odsetka błędnych odczytów wśród przyjętych nie przekracza celu: dla ≤ 0,1% potrzeba 2995 przyjętych przejazdów bez błędu albo 4742 przy jednym, dla ≤ 0,2% odpowiednio 1497 i 2371 (p04 D3). Kalibrację i próg liczymy osobno dla warstw dzień, noc IR i tablice niepolskie; dla tablic europejskich próg musi być wyższy, bo przy niższym detektor znaków dodawał fałszywe znaki na tablicach o mniejszej liczbie znaków F47317. Na małej próbie podniesienie progu potrafi pogorszyć obserwowany odsetek błędów F43040, więc progu nie stroimy na mniej niż ok. 1500 przejazdach. Lista zamknięta przyjmuje dopasowanie przy odległości edycyjnej 0, a przy odległości 1 tylko dla pary mylnej z 4.3, gdy żaden inny element listy nie leży w odległości ≤ 2 S.

Ryzyko i lukiBrak danych w źródłach o kalibracji pewności OCR na tablicach polskich ani o krzywej ryzyko–pokrycie zmierzonej na wjeździe parkingowym; MC-dropout wymaga wielu przebiegów modelu na wycinek, a jego koszt na NPU RK3588 nie jest zmierzony.

4.5Błędy stałe: śruby, brud, czcionka, naklejki

DecyzjaBłąd stały obsługujemy na trzech poziomach. Przejazd: zgodne wycinki z niskim marginesem na jednej pozycji albo z niezgodnością składni poza parami mylnymi nie są korygowane, tylko trafiają do ścieżki wyjątku z zaznaczoną pozycją. Obiekt: każda korekta operatora tworzy wpis (pozycja, odczyt, prawda, warstwa); macierz pomyłek per pozycja wyzwala alarm, gdy jedna para przekroczy ustalony udział korekt S. Model: korekty operatora wracają do uczenia z powtórką danych bazowych, a augmentacja dokłada zaślepki śrub i zabrudzenia na pozycjach znaków.

Dlaczego

• W 700 błędnych odczytach brytyjskich zaślepki i śruby odpowiadały za 72,6%, zabrudzenia za 23,0%, czcionka niedozwolona za 0,9% F41960; śruby w obrębie znaków ma 63% ± 4% tablic F45377. Śruba w literze U dała 28,5% błędnych odczytów w 997 rejestracjach dziesięciu pojazdów, a po wymianie na śrubę 6 mm 0,3% (358/359) F45373F45374. Pozycje 2 i 5 skupiają 50% błędów od śrub F41966. Zaślepka wygląda inaczej w podczerwieni niż w świetle widzialnym (żółta jako L, czarna jako O) F47657F46160.
• Na tablicy polskiej naklejka powodowała błędne odczytanie litery I na trzeciej pozycji; po retuszu ta sama tablica była czytana poprawnie F36533.
• Większość błędów przy testach na nowych zbiorach wynika z innej czcionki i elementów tablicy, a nie z trudnych zdjęć F47129F37333; znaki I, J, 1, a w części wzorów L i T nie wypełniają pola znaku na polskiej tablicy F38424.
• Cechy pewności OCR wykrywają błąd stały tylko wtedy, gdy prawdziwy znak ma ślad w rozkładzie (p04 D2b), więc resztę zmniejsza model, który ten znak widzi: transfer z tablic czeskich, węgierskich i słowackich zmniejszył błąd tablic polskich o 28–38% F49521, a na zbiorze chińskim 4750 prawdziwych tablic dało 99,0% F38005. Korekty operatora wracają do uczenia z powtórką 70:30 danych bazowych do nowych F44789, z dotrenowaniem co 2000 korekt F42558; augmentacja celuje w słabe znaki (G, K, M, O, Q, S z AP < 0,95) F47618F47626.

Parametry i wykonanieSygnały błędu stałego na przejeździe: zgodność ≥ 0,8 przy marginesie < m_min na jednej pozycji S, niezgodność składni na tej samej pozycji we wszystkich wycinkach, odczyt powtarzający się dla pojazdu z listy abonamentowej, który różni się od numeru z listy o parę mylną. Dla pojazdów powracających system przechowuje zatwierdzone przez operatora aliasy (odczyt błędny → numer z listy), jak warianty znanych tablic z parami I/1 i S/5 w Frigate F35365; alias działa tylko na liście zamkniętej. Dane nocne IR zbieramy i walidujemy osobno: zdjęcia IR stanowiły 21,5% zbioru UFPR-VeSV, a dały 39,4–53,4% błędów rozpoznawania atrybutów pojazdu F45044.

Ryzyko i lukiWszystkie liczby o śrubach pochodzą z Wielkiej Brytanii. Brak danych w źródłach o udziale śrub, ramek i naklejek na tablicach polskich ani o udziale błędów stałych na polskich parkingach.

4.6Protokół pomiaru 99% na własnych przejazdach

DecyzjaOdbiór na obiekcie: 3000 kolejnych przejazdów (co najmniej 2000 różnych pojazdów), każdy oceniony przez człowieka z zapisanych wycinków i obrazu przeglądowego jako poprawny, błędny odczyt albo brak odczytu (w tym brak wyzwolenia). System spełnia cel, gdy jednostronna dolna granica 95% (Clopper-Pearson) odsetka poprawnych ≥ 99,0% i górna granica odsetka błędnych odczytów ≤ 0,1%, czyli przy 3000 przejazdach co najwyżej 20 przejazdów niepoprawnych i zero błędnych odczytów.

Dlaczego

• Błędny odczyt i brak odczytu to osobne kategorie z innymi skutkami F41959F46398. Protokół testu NCDOT obejmował ręczną weryfikację każdego odczytu z obrazem, usunięcie duplikatów, liczbę błędnych znaków na tablicę i liczenie pojazdów z niezależnej kamery F38064. Brytyjski standard pozwala wyłączyć z testu tablice, których mocowania powodują błąd F40958; my ich nie wyłączamy, bo 72,6% błędów pochodzi właśnie z mocowań F41960.
• Duplikaty zawyżają wynik: bez nich odsetek błędów jest ponad dwukrotnie wyższy F39388, a w AOLP 46,9% obrazów testowych ma duplikat w zbiorze uczącym F46421. GLPD umieszcza tablice o znormalizowanej odległości edycyjnej powyżej 0,9 w tym samym podziale F39296. Start od gotowych wycinków zamiast od całego obrazu zawyża wynik F46473.
• Małe próby niczego nie dowodzą: 22/22 filmów z tablicami polskimi potwierdza tylko ≥ 87,3%, a 358/359 odczytów z 5 pojazdów liczone po pojazdach daje górną granicę błędu 45,1% (p04 B4, E4).

Parametry i wykonanie

• Wielkość próby: dolna granica ≥ 99,0% wymaga 299 przejazdów bez błędu, 1049 przy 5 błędach, 2902 przy 20 (p04 E1). Wykazanie błędnych odczytów ≤ 0,1% wymaga 2995 przejazdów bez błędnego odczytu (D3), dlatego to cel misread wyznacza 3000. System o rzeczywistej skuteczności 99,5% zalicza próbę 3000 przejazdów z prawdopodobieństwem 91,8%, a o skuteczności 99,3% z prawdopodobieństwem 47,1% (E2).
• Pojazdy powracające: liczymy liczebność efektywną n_eff = n / (1 + (m − 1) · ICC) S; przy 4 przejazdach na pojazd i ICC = 0,2 z 3000 zostaje 1875 (E4), więc raportujemy też wynik z pierwszym przejazdem każdego pojazdu w dobie.
• Warstwy: noc IR, opady, tablice niepolskie, dwurzędowe raportujemy osobno z przedziałem; 900 przejazdów nocnych pozwala na 3 błędy przy granicy 99%, a potwierdzenie 99% w warstwie wymaga co najmniej 299 przejazdów tej warstwy, więc 90 tablic zagranicznych raportujemy tylko z przedziałem (E5, E1).
• Dane do strojenia i dane odbioru pochodzą z rozłącznych okresów i rozłącznych zbiorów numerów; numery z odległością edycyjną ≤ 1 trafiają do tego samego podziału S.
• Ławka odtwarzania: wszystkie wycinki i rozkłady OCR z odbioru zapisujemy, więc każdą zmianę fuzji, składni lub progu oceniamy na tych samych przejazdach testem McNemara.

Ryzyko i lukiBrak danych w źródłach o niezależnym teście jakiegokolwiek systemu na wjeździe parkingowym z tablicami polskimi; ICC przejazdów tego samego pojazdu nie jest zmierzony i przyjmujemy go jako S.

Założenia S i obliczenia

Skrypt data/jobs/lpr-cpu-sbc/decyzja/obliczenia/p04.py, wynik p04.out (części A–E; symulacja z ziarnem 404 i 405).

• Podział budżetu na E1–E5 i cel błędnych odczytów ≤ 0,10% są decyzją projektową S (B).
• Klatki i wycinki jednego przejazdu traktujemy w B1, B2 jako niezależne S; strefa odczytu 3–4 m i n = 5 użytecznych wycinków przy 30 km/h S (A).
• Model błędu stałego: odsetek s pojazdów błędny we wszystkich klatkach, reszta niezależna; dwa warianty głosowania (ścisła większość, błędy niepowtarzalne) S (B4).
• Symulacja C i D: tablica = wyróżnik miejsca 2–3 litery + wyróżnik pojazdu bez B, D, I, O, Z, długość 7 lub 8; podmiana znaku 1,5% (60% w parę mylną), błąd długości 3%, błąd stały w 1% pojazdów na jednej pozycji w 85% wycinków, połowa bez śladu prawdziwego znaku; rozkłady pewności losowe S. Wyniki symulacji pokazują kierunek i mechanizm, nie wartości oczekiwane dla tablic polskich.
• Regresja izotoniczna jako metoda kalibracji, reguła listy zamkniętej (odległość 1 tylko dla pary mylnej, brak sąsiada w odległości ≤ 2), progi alarmu macierzy pomyłek, zgodność ≥ 0,8 jako sygnał błędu stałego, ICC i podział danych po odległości edycyjnej ≤ 1 to założenia S.
• Wyróżnik miejsca 2–3 litery przyjęto z przykładów tablic w źródłach S.
• Plik ustaleń naukowych i technicznych dane/nauka/p04.jsonl: przeczytano wszystkie 2548 ustaleń (pogrupowane skryptem w 8 podtematów, powtórzenia zwinięte do reprezentantów z listą identyfikatorów), w rozdziale wykorzystano (zacytowano) 69 z nich; pozostałe 29 odnośników pochodzi z plików sXX (przepisy o tablicach polskich, przykłady tablic, dane uzupełniające).

Część 5Odczyt przy dużych kątach najazdu

5.1Prostowanie tablicy: cztery narożniki, homografia, wycinek o stałym rozmiarze

DecyzjaKażdą tablicę wykrytą w wycinku 4 MP prostujemy przed OCR. Własny regresor narożników (mała sieć splotowa, NPU, INT8) zwraca cztery narożniki, klasę układu (jedno- lub dwuwierszowa) i pewność. CPU wylicza z narożników homografię i jednym przekształceniem perspektywicznym z interpolacją dwuliniową przenosi tablicę do prostokąta kanonicznego 256×64 px. OCR dostaje wyłącznie ten wycinek, a sieć OCR nie ma wbudowanego modułu STN.

Dlaczego

• Bez prostowania wynik na widokach ukośnych gwałtownie spada: WPOD-NET bez prostowania osiąga 84,61% na AOLP-RP i 57,69% na CD-HARD F37548. Na CD-HARD modele OCR testowane na zbiorze spoza treningu osiągają od 31,7% (CRNN) do 59,6% (Fast-OCR) F38600, a najlepsza fuzja ośmiu modeli tylko 65,4% F37676.
• Potrzebna jest pełna perspektywa, a nie obrót: odtworzenie kąta z rzutu perspektywicznego daje 87,5% wobec 57,5% dla obrotu w płaszczyźnie w szerokim zakresie kątów F39651. Mocno ukośna tablica jest dowolnym czworokątem, a nie równoległobokiem, więc dopiero cztery narożniki opisują ją w pełni F34390.
• Prostowanie odzyskuje skrajne kąty: na CCPD i RodoSol-ALPR rekonstrukcja widoku podnosi dokładność całych numerów przy ekstremalnych kątach o 15–38 pkt F47948, zakres odczytywalnych kątów wyznacza głównie geometria obrazowania F47946, a ostry spadek zaczyna się powyżej ok. 80° F47945. Jawne narożniki z homografią w TransLPRNet podnoszą wynik na CCPD-Challenge z 93,25% do 94,54% F49715.
• Ten sam podział (detektor ramki, potem regresor narożników) stosują aktualne potoki badawcze: YOLOv11 z CDCC-NET F41574 i YOLOv8 z IWPOD-NET F38776.

Parametry i wykonanie

• Wejście regresora: ramka z detektora tablic powiększona 1,3× w poziomie i 1,6× w pionie S, wycięta z ramki 4 MP i przeskalowana do 96×288 RGB przez RGA, które obsługuje skalowanie i konwersję formatu F43618F49156.
• Sieć według schematu Yoo i Juna F37402: Conv3×3 16/32/64/128 z max-pool 2, Conv3×3 128, FC 13 824→256→11 (8 współrzędnych, 2 klasy układu, pewność). Koszt: 127 M MAC, 0,25 GFLOP, 3,8 M parametrów [obliczenia T11]. Strata: suma odległości euklidesowych narożników F34070, entropia krzyżowa układu i BCE pewności.
• Prostokąt kanoniczny: tablica 520×110 mm z marginesem 21,6 mm w poziomie i 15,4 mm w pionie, czyli 563×141 mm → 256×64 px (0,455 px/mm, znak 36×21 px, kreska 4,1 px) [obliczenia T11]. Tablice 305×214 i 190×150 mm F38417 trafiają do prostokąta 128×160 px S wybieranego klasą układu. Rozmiar wyjścia równa się wejściu OCR.
• Tolerancja narożnika to połowa marginesu: 10,8 mm w poziomie i 7,7 mm w pionie, czyli 2,8 px i 2,3 px w obrazie źródłowym przy gęstości docelowej z 5.4 [obliczenia T11]. Odbiór regresora na polskim zbiorze testowym: mediana błędu narożnika ≤ 1,0 px, 99. percentyl ≤ 2,3 px, a spadek dokładności całych numerów przy narożnikach z regresora wobec narożników ręcznych ≤ 0,3 pkt S.
• Kąt łączny θ to kąt między promieniem widzenia a normalną tablicy F45351; liczymy go z homografii i ogniskowej f_px zapisanej przy instalacji (normalna r3 = r1 × r2). Gęstości próbkowania: ρ_h = krawędzie poziome czworokąta / 520 mm, ρ_v = krawędzie pionowe / 110 mm.
• Zabezpieczenia: czworokąt niewypukły, θ > 65°, pewność < 0,5 S albo zmiana szerokości ramki przez homografię o ponad 25% (próg wzorowany na BLPR F38165) kierują klatkę na ścieżkę zapasową: OCR dostaje zwykły wycinek ramki przeskalowany do 256×64, a klatka nie przechodzi bramki w 5.6.

for plate in plate_detections(frame_4mp):                     # ramka osiowa
    roi = rga_crop_resize(frame_nv12, expand(plate.box, 1.3, 1.6), w=288, h=96)
    q, layout, conf = npu_corners(roi)                          # INT8
    quad = roi_to_frame(q, plate.box)
    if conf < 0.5 or not convex(quad) or width_change(quad, plate.box) > 0.25:
        crop, geom_ok = rga_crop_resize(frame_nv12, plate.box, 256, 64), False
    else:
        H = perspective_from_4pts(quad, CANON[layout])          # układ 8x8
        crop = warp_bilinear(roi_rgb, H, CANON_SIZE[layout])    # CPU A76
        theta, rho_h, rho_v = plate_geometry(H, f_px, quad)
        geom_ok = theta <= 65
    emit(crop, geom_ok, theta, rho_h, rho_v)

Ryzyko i lukiZyski z prostowania zmierzono na tablicach chińskich, tajwańskich i brazylijskich. Sieci prostujące potrafią zniekształcić obraz prosty F50958F50995, stąd zabezpieczenia i ścieżka zapasowa. Brak danych w źródłach: zysku z prostowania dla polskich tablic w przedziałach kąta.

5.2Odrzucone alternatywy i podział pracy między NPU a CPU

DecyzjaSTN w sieci OCR, obrócone ramki (OBB), rekonstrukcja widoku i superrozdzielczość nie wchodzą do potoku podstawowego. Na NPU RK3588 działają tylko sieci splotowe w INT8 (detektor, regresor narożników, OCR). RGA wycina i skaluje, a CPU liczy homografię, przekształcenie i kąt.

Dlaczego

• Sieć splotowa w INT8 liczy się na RK3588 prawie w całości na NPU: YOLOv8 zajmuje 17,12 ms NPU i 0,13 ms CPU z 17,26 ms F42607. NPU obsługuje obliczenia mieszane INT8/INT16/FP16 F40322, więc ostatnia warstwa regresora może zostać w FP16.

Parametry i wykonanie

• Dwie kamery po 12,5 kl./s z jedną tablicą w kadrze dają 25 wywołań na sekundę: 23–65 ms czasu NPU i ok. 11 ms CPU na sekundę.
• Kwantyzację regresora kalibrujemy na 500 wycinkach z docelowych kamer S. Jeśli INT8 zwiększa 99. percentyl błędu narożnika o ponad 0,3 px względem FP32, ostatnią warstwę FC zostawiamy w FP16 S.

Ryzyko i lukiSkalowanie po FLOP pomija stały narzut wywołania NPU. Brak danych w źródłach: opóźnienia małej sieci regresyjnej w RKNN i obsługi próbkowania siatki.

5.3Trening odporny na kąt

DecyzjaRegresor narożników i OCR uczymy na mieszance obrazów realnych z narożnikami (CCPD do pretreningu, własne polskie dane z wdrożeń do dostrojenia) i syntetycznych polskich tablic nakładanych homografiami z kątem poziomym 0–65° i pionowym 0–45°. OCR uczymy na wycinkach z tego samego potoku prostowania, z celowo zaburzonymi narożnikami, utratą rozdzielczości wzdłuż skróconej osi i rozmyciem ruchu.

Dlaczego

• Masowe syntetyczne wypaczanie pozwoliło wytrenować WPOD-NET od zera na mniej niż 200 oznaczonych obrazach F34901. Dane syntetyczne dały ok. +5% na AOLP-RP F37553 i +12,1% na tablicach malezyjskich F42572; generowanie z szablonów poprawia wyniki także między zbiorami F42716.
• Typowa augmentacja w pracach ALPR (obrót ±5° F39246) nie pokrywa geometrii przy szlabanie z 5.5.
• Same dane syntetyczne nie wystarczą: modele uczone na syntetycznych degradacjach CCPD zawodzą na degradacjach realnych F48222. BLPR uczy detektor na scenach z Blendera z ekstremalną perspektywą i dostraja go na danych ulicznych, osiągając 89,6% poprawnych znaków F35468F35467.
• OCR uczony z zaburzeniem wierzchołków utrzymuje 94,57–99,92% przy zaburzonych narożnikach F49716.
• Skos jest najczęstszą anomalią w danych ulicznych (3241 przypadków wobec 1067 rozmytych) F37073, a kąty powyżej 45° obniżają wynik o 42,8 pkt F45313.

Parametry i wykonanie

• Generator: polski krój (znak 80 mm, litera do 47 mm, cyfra do 43 mm, kreska 9 mm F38418), losowe ciągi zgodne ze składnią tablic S, szablon z losową perspektywą, szumem i cieniem jak w F36108, tło z klatek własnych kamer bez tablic.
• Homografie: kąt poziomy U(0°, 65°), pionowy U(0°, 45°), obrót w płaszczyźnie U(−10°, 10°); połowa próbek z rozkładu kątów wyliczonego dla danej instalacji (5.5) S.
• Degradacja zależna od kąta, nakładana przed prostowaniem: zmniejszenie rozdzielczości wzdłuż osi poziomej tablicy o cos θ_h i pionowej o cos θ_v, rozmycie ruchu o długości v·sin α·t, w nocy przyciemnienie proporcjonalne do współczynnika odblasku R_A(θ) z 5.4 S.
• Zaburzenie narożników w treningu OCR: N(0; 1,5 px) na narożnik w skali obrazu źródłowego, czyli połowa tolerancji z 5.1 S.
• Proporcja w każdej paczce: 50% realnych, 50% syntetycznych S. Regresor: Adam, lr 10⁻³ dzielony przez 10 co 10 epok, paczka 32, 40 epok, jak w treningu na 30 tys. obrazów CCPD F44882. OCR: według rozdziału o OCR (przykład referencyjny: Adam, lr 2·10⁻⁴, paczka 128, 200 epok F49554).

• Polski punkt odniesienia: CNN-RNN z prostowaniem TPS-STN F48344 osiąga 87,3% całych numerów na zdjęciach polskich F36615, a głosowanie po klatkach 100% na 22 nagraniach parkingowych F38502F36613; transfer z tablic czeskich, węgierskich i słowackich przyspiesza zbieżność F49697.
• Polskie narożniki pochodzą z własnych instalacji: regresor uczony na CCPD oznacza klatki, człowiek weryfikuje (tak zbudowano GLPD F39571).
• Pomiar: dokładność całych numerów w przedziałach kąta 0–15/15–30/30–45/45–60°, osobno dzień i noc, oraz na syntetycznej siatce kątów polskich tablic, jak siatka [0°, 89°]² w F47944.

Ryzyko i lukiZbiory brazylijskie z dokładnymi narożnikami nie wchodzą do produktu z powodu licencji F40915F34481. Brak danych w źródłach: publicznego polskiego zbioru z adnotacją kąta i licencją komercyjną.

5.4Ile pikseli musi mieć skrócona tablica i co z tego wynika dla 4 MP

DecyzjaWymaganie definiujemy w obrazie źródłowym wzdłuż osi tablicy, już po skróceniu: minimum to znak 8×16 px, a cel projektowy 12×24 px, czyli ρ_h ≥ 0,255 px/mm wzdłuż szerokości i ρ_v ≥ 0,30 px/mm wzdłuż wysokości (kreska 9 mm ma wtedy 2,3 px). Kamera 4 MP spełnia cel w całym zakresie 2–10 m i 0–60°, jeśli HFOV nie przekracza wartości z tabeli poniżej. Czas ekspozycji ograniczamy do t ≤ 9 mm / (v·tg θ), a w nocy czytamy tylko przy θ ≤ 30°.

Dlaczego

• Model OCR na wycinku 94×24 osiąga 100% przy znaku co najmniej 8×16 px, a poniżej 5×10 px spada poniżej 36,4% F36256. Tablice 16×48 px dają 1,7–2,2% poprawnych odczytów F45281F38774F49981.
• W zbiorze, na którym działają typowe OCR, znaki mają 11–43 px wysokości, średnio 21,19 px F44384.
• Reguły producentów (wg producenta): co najmniej 2 px na najmniejszy element, czyli kreskę F45919F33410, i co najmniej 74 px szerokości tablicy do rozróżnienia linii F33409. Cel 12×24 px oznacza 133 px szerokości tablicy na wprost, a minimum 89 px [obliczenia T1].
• Skrócenie działa na szerokość jak cos θ, więc powyżej 31,7° wiąże wymaganie poziome (0,255 / cos θ > 0,30) [obliczenia T2].
• Nocą odblask białej tablicy maleje z kątem wejścia: 60, 25 i 6 cd/lx/m² przy 5°, 30° i 45° F51173F50128. Z krótszą ekspozycją sygnał przy 30° spada do 0,23 (10 km/h) i 0,08 (30 km/h) wartości przy 5°, a przy 45° do 0,03 i 0,01 [obliczenia T6].

Parametry i wykonanieMinimalna ogniskowa 4 MP (2560 px) dla celu 12×24 px: f_px / największy HFOV / ogniskowa w mm według karty kamery 4 MP 1/1,8″, w której 12 mm odpowiada HFOV 39,8° (f_px ≈ 295·f_mm, wg producenta F37639) [obliczenia T2]:

• Przy 60° i 10 m potrzeba ok. 17 mm, czyli więcej niż daje obiektyw 2,8–12 mm. Przy HFOV 45° kamera 2 MP spełnia cel do 7,7 m na wprost i 4,5 m przy 60°, a 4 MP do 10,3 m i 6,1 m [obliczenia T3].
• Ekspozycja: kreska skraca się jak cos θ, a ruch poprzeczny rośnie jak sin θ. Przy kryterium „rozmycie ≤ jedna skrócona kreska” t_max wynosi przy 30 km/h 1,87 ms (30°), 1,08 ms (45°) i 0,62 ms (60°), a przy 10 km/h 5,61, 3,24 i 1,87 ms [obliczenia T5]. Tabela Axis (wg producenta, 3,4 ms przy 30° i 30 km/h F36627) odpowiada stałemu przesunięciu ok. 14 mm, więc dopuszcza rozmycie ok. 1,8 skróconej kreski [obliczenia T5].
• Próg dla polskiego kroju mierzymy przy odbiorze OCR: znane wycinki degradujemy do wysokości znaku 6–20 px co 1 px w czterech przedziałach kąta i odczytujemy, gdzie dokładność całych numerów spada poniżej 99%.

Ryzyko i lukiPróg 8×16 px zmierzono małym LPRNet na tablicach chińskich i włoskich F36256. Przelicznik ogniskowej pochodzi z jednej karty katalogowej, a kompresja H.265 obniża efektywną rozdzielczość (silna kompresja CCPD psuje czytelność tablic F40693). Brak danych w źródłach: współczynnika odblasku powyżej 45°.

5.5Geometria montażu przy pasie ze szlabanem; kiedy druga kamera

DecyzjaKamera stoi w linii szlabanu (obudowa szlabanu, słupek na wysepce albo wysięgnik), z przesunięciem bocznym o ≤ 2,5 m i wysokością 1,3–2,5 m, i czyta tablicę w czasie najazdu, w strefie ok. 2–9 m przed kamerą, a nie na linii zatrzymania. Obiektyw dobieramy tak, by kadr obejmował całe okno odczytu (θ ≤ 45° i znak ≥ 12×24 px): HFOV 46–53°, czyli ok. 9–10 mm. Okno zdarzenia obejmuje klatki sprzed wyzwalacza: bufor wycinków śladu trzyma co najmniej 6 s. Drugą kamerę stawiamy, gdy prosty odcinek najazdu jest krótszy niż d₁ + N·v/fps.

Dlaczego

• Tablica stojąca 0,8 m przed kamerą w linii szlabanu ma kąt łączny 54–78° (o = 0,5–3,0 m) [obliczenia T4]; 45° osiąga dopiero 1–4 m przed kamerą [obliczenia T12].
• Kamera za szlabanem musi patrzeć ponad ramieniem: przy 2 m od tablicy potrzebuje co najmniej 2,9 m wysokości, przy 3 m co najmniej 4,1 m [obliczenia T4]. Kąt łączny na stopie nadal wynosi wtedy 53° [obliczenia T7].
• W czasie najazdu kąt maleje z odległością. W konfiguracji B (o = 2,0 m, h = 2,5 m) wynosi 45° przy 2,85 m, 25° przy 6,1 m i 17° przy 9,4 m, a znak maleje z 31×52 do 14×24 px [obliczenia T7]. Każda pozycja na torze daje kolejną próbę z innym kątem i oświetleniem F47783.

Parametry i wykonanieTablica na 0,5 m, rozrzut toru ±0,5 m, linia zatrzymania 0,8 m przed kamerą, 12,5 kl./s S [obliczenia T7, T7b]:

• Wybieramy A lub B. W C kadr wymiarowany kątem pionowym (HFOV 62°) skraca okno do 6 m, D wymaga wysokiego słupa, a okno nocne ma w C i D tylko 1,2–1,45 m [obliczenia T7b].
• Większe przesunięcie boczne odsuwa okno od szlabanu: przy h = 1,3 m okno zaczyna się na 0,95 m (o = 0,5 m), 2,2 m (o = 2,0 m), 3,15 m (o = 3,0 m) i 4,1 m (o = 4,0 m) [obliczenia T12].
• Pojazd wjeżdżający z łuku, skręcony o −15° względem pasa, przesuwa początek okna w B z 2,85 do 4,35 m [obliczenia T8].
• Bufor: przejazd przez okno B trwa 4,7 s przy 5 km/h, a od końca okna do stopu mija kolejne 1,5 s [obliczenia T9b]. Wyzwalacz z pętli lub radaru przy szlabanie zamyka okno zdarzenia i uruchamia decyzję, a detekcja tablic działa przez cały czas ruchu w strefie.
• Reguła drugiej kamery: L_prosty ≥ d₁ + N·v_max/fps, gdzie d₁ to początek okna, a N = 5 klatek S. Przy 30 km/h N·v/fps wynosi 3,33 m dla 12,5 kl./s i 1,67 m dla 25 kl./s [obliczenia T9], więc B potrzebuje co najmniej 6,2 m prostego najazdu. Gdy warunek nie jest spełniony (skręt tuż przed szlabanem, wyjazd z rampy, przesunięcie powyżej 2,5 m przy krótkim najeździe), druga kamera obejmuje odcinek, którego pierwsza nie widzi pod kątem ≤ 45°, a obie zasilają ten sam ślad i głosowanie z 5.6.
• Z zapisanych przy instalacji o, h, f_px i linii zatrzymania system wylicza okno, bramki i rozkład kątów do treningu (5.3).

Ryzyko i lukiLiczby pochodzą z modelu kamery otworkowej bez dystorsji. Brak danych w źródłach: zmierzonej skuteczności dla konkretnej geometrii pasa ze szlabanem i dla układu dwóch kamer na jednym pasie.

5.6Wybór klatek i głosowanie przy zmiennym kącie

DecyzjaKażda klatka śladu przechodzi bramkę geometryczną: θ ≤ 60° (nocą ≤ 30°), znak ≥ 8×16 px, rozmycie ≤ skrócona kreska. Z klatek, które przeszły, bierzemy najwyżej 5 o największym wyniku q = min(znak_w/12, znak_h/24, kreska/rozmycie, 2), z liniową karą za kąt powyżej 45° i odstępem co najmniej 0,5 m drogi między klatkami. Głosujemy po pozycjach znaków (MVCP) na wyprostowanych wycinkach, remis rozstrzyga pewność OCR, a obrazów nie uśredniamy. Decyzja zapada, gdy trzy klatki dają ten sam numer zgodny ze składnią.

Dlaczego

• Głosowanie po klatkach podnosi wynik z 85,45% do 93,53% na SSIG i z 64,89% do 78,33% na UFPR-ALPR F49532F49533. Pięć klatek zamiast jednej daje ok. +28 pkt dokładności znaków F48012, a MVCP daje największe zyski spośród strategii fuzji F49385. Głosowanie z pewnością usuwa co najmniej trzecią część pozostałych błędów nawet przy dokładności znaków powyżej 99% F48147.
• Uśrednianie obrazów z różnych kątów szkodzi: fuzja medianą dała 77,4% wobec 79,5% najlepszego pojedynczego wycinka (dane operatora) F42853. Duże, bliskie wycinki (100–200 px) czytają się poprawnie, a małe, dalekie (40–80 px) przegrywają w głosowaniu F41563.
• Wybór według samego najmniejszego kąta bierze w konfiguracji B klatki z 9–10 m ze znakiem 13–15 px. Wynik q wybiera klatki z 2,7–5,3 m, z kątem 28–47° i znakiem 22–31 px [obliczenia T10]. Kąt wchodzi do q przez skrócenie (cos θ), rozmycie (sin θ) i karę powyżej 45°.
• Ważenie głosów jakością (rozdzielczość, ostrość Laplace'a) nie dało istotnego zysku ponad dobrą asocjację F44574, więc q tylko wybiera klatki. Przy tej samej silnej deformacji we wszystkich klatkach fuzja nie odzyskuje dokładności F42838, a znaku niewidocznego w żadnej klatce głosowanie nie odtworzy F44580; odstęp 0,5 m wymusza różnorodność klatek.
• Asocjacja znaków między klatkami: transformacja podobieństwa zamiast pełnej homografii F44960; potok Geo-CTM podnosi wynik z 85,40% do ponad 91,5% F42540, także przy zmianie perspektywy 0–60° F45908. Adaptacyjne zatrzymanie zużywa o 56% mniej widoków niż stałe pięć F42826.

Parametry i wykonanie

cand = []
for f in track:                                   # wycinki z 5.1, kolejne klatki śladu
    cw, ch = 47 * f.rho_h, 80 * f.rho_v           # znak w px po skróceniu
    stroke = 9 * f.rho_h                           # kreska w px
    blur = f.track_speed_px * f.t_exp / f.frame_dt # rozmycie z prędkości na torze
    theta_max = 30 if night else 60
    if f.geom_ok and f.theta <= theta_max and cw >= 8 and ch >= 16 and blur <= stroke:
        q = min(cw / 12, ch / 24, stroke / max(blur, 1e-3), 2.0)
        if f.theta > 45: q *= (60 - f.theta) / 15
        cand.append((q, f))
sel = pick_top(cand, k=5, min_spacing_m=0.5)       # odstęp drogi z toru
reads = [ocr(f.crop) for _, f in sel]
result = mvcp_vote(reads) if same_layout(reads) else mv_hc(reads)
if count_agree(reads, result) >= 3 and syntax_ok(result): decide(result)

• Gdy po wyjściu z okna bramkę przeszły mniej niż 3 klatki, ślad dostaje status „niepewny” i trafia na ścieżkę z rozdziału o decyzji. Przy różnych długościach odczytu stosujemy głosowanie sekwencyjne MV-HC (w fuzji modeli 92,4% → 97,6% F37391).

Ryzyko i lukiWynik q i odstęp 0,5 m wynikają z modelu i symulacji, a nie z pomiaru na tablicach przy szlabanie. Dane WINK pochodzą od operatora jednej kamery. Brak danych w źródłach: porównania wyboru klatek według kąta z wyborem według pikseli dla polskich tablic.

Założenia S i obliczenia

• Skrypt data/jobs/lpr-cpu-sbc/decyzja/obliczenia/p05.py, wynik p05.out (tabele T1–T12).
• Model kamery otworkowej: kamera w (0, 0, 0), tablica w (x, −y, d); r = √(x² + y² + d²); kąt łączny θ = arccos(c·n), gdzie c to promień tablica→kamera, a n normalna tablicy F45351; gęstość próbkowania ρ_h = f_px·√(1 − (c·h)²)/r i ρ_v = f_px·√(1 − (c·v)²)/r; znak w px = 47·ρ_h × 80·ρ_v; rozmycie w px = f_px·v·t·sin α / r; t_max = 9 mm·cos θ / (v·sin θ). Dla samego kąta poziomego wymagane f_px = max(12/47 · r / cos θ, 24/80 · r).
• Przelicznik ogniskowej: f_px = 1280 / tg(39,8°/2) / 12 mm = 295 px/mm (wg karty kamery F37639); obiektyw prostoliniowy, bez dystorsji S.
• Sygnał nocny ∝ R_A(θ)·t_exp / r² (IR przy obiektywie, kąt wejścia = θ), R_A z F51173, ekspozycja ograniczona do 10 ms S.
• Koszt przekształcenia: 44 operacje na piksel wyjścia S; pomiar na hoście x86 (jeden wątek, gcc -O2, kod skalarny) wyznacza tylko rząd wielkości.
• Założenia S: tablica UE 520×110 mm F44218 na 0,5 m; rozrzut toru ±0,5 m; stop 0,8 m przed kamerą; ramię szlabanu 1,1 m, 0,5 m za tablicą; strefa do 10 m; 12,5 kl./s; N = 5; cel znaku 12×24 px = 1,5 × minimum F36256; rozmycie ≤ jedna skrócona kreska; marginesy 21,6 i 15,4 mm; progi zabezpieczeń; kryteria odbioru regresora; proporcja danych 50/50; rozkłady kątów w syntezie.
• Z pliku dane/nauka/p05.jsonl przeczytano wszystkie 2525 ustaleń (pogrupowane skryptem na 9 podtematów), a w rozdziale wykorzystano 75 z nich; pozostałe 29 cytowanych ustaleń pochodzi z plików dane/s01–s08.jsonl.

Część 6Sprzęt wynikający z potoku

6.1SoC: budżet NPU i VPU dla dwóch kamer

DecyzjaBazą jest RK3588J; potok planujemy tak, by w stanie nominalnym zajmował najwyżej ok. 55% pojemności NPU, co po dławieniu termicznym (−27,7%) daje ok. 75% i zostawia zapas. RK3576 dopuszczamy tylko przy strumieniu 12,5 kl./s i modelach nominalnych, x86 N100 nie mieści budżetu bez obniżenia liczby klatek.

Dlaczego

• Pomiar niezależny: YOLOv8 INT8 na NPU RK3588 trwa 17,26 ms, z czego CPU tylko 0,13 ms F42607. Tabela rknn_model_zoo (jeden rdzeń NPU) podaje YOLOv8n 640×640 INT8 76,3 kl./s, czyli 13,1 ms, PP-OCRv4-rec 48×320 12,7 ms i LPRNet 1,65 ms; RK3576 jest na rdzeń szybszy o 12–27% F42580F42583F42582. Pomiar niezależny jest więc o ×1,32 dłuższy od tabeli i to on wchodzi do budżetu.
• Inferencja RKNN domyślnie używa jednego rdzenia; podział wyjść na trzy rdzenie podniósł wykorzystanie NPU z 60% do 90% F41117F41118. Inferencja blokuje wątek, więc przepustowość dają równoległe procesy, a ich nadmiar nasyca pamięć i podnosi temperaturę SoC F39981F39982.
• W teście terenowym bez aktywnego chłodzenia przepustowość inferencji spadała o 19,3–27,7% przy wzroście temperatury otoczenia z 22 do 36 °C F47515; budżet dzielimy więc przez 0,72.
• VPU RK3588 zdekodował HEVC 8K30 z prędkością 55,8 kl./s, czyli 1851 Mpx/s, wobec 184 Mpx/s potrzebnych dla 2×4 MP przy 25 kl./s: zapas ×10 F50262. Dekodowanie programowe zajęłoby ok. 4,1 z 8 rdzeni (górne oszacowanie z transkodowania F39847), więc VPU jest obowiązkowe; i.MX8M Plus dekoduje sprzętowo najwyżej 1080p60, 124 Mpx/s F43050, i odpada.

Parametry i wykonanieKoszt NPU na klatkę zdarzenia jednej kamery: wariant najgorszy = detekcja pojazdu 640×640 (17,3 ms) + detekcja tablicy 640×640 (17,3 ms) + OCR klasy PP-OCRv4-rec (12,7 ms) = 47,3 ms; wariant nominalny = 640×384 (10,4 ms) + 384×384 (6,2 ms) + OCR (12,7 ms) = 29,3 ms. Pojemność RK3588 = 3 rdzenie × 0,9 = 2,7 rdzenio-s/s. Obie kamery w zdarzeniu jednocześnie:

Przydział: jeden proces inferencji na model i rdzeń NPU, wspólna kolejka wycinków obu kamer do OCR. Detekcja jałowa poza zdarzeniem (2×5 kl./s, 640×384) zajmuje 4% NPU. Porównanie x86: sama detekcja 640 na CPU N100 przy 2×12,5 kl./s wymaga 1,06 całego procesora (OpenVINO, 23,6 kl./s F36125); NPU Core Ultra 7 155H wykonuje YOLOv8n w 7,0 ms F38055, ale nie ma w danych ceny ani wersji przemysłowej.

Ryzyko i lukiYOLOv8 i YOLO11 to AGPL-3.0 dla kodu i wag F32961F40071; w budżecie służą tylko jako wzorzec kosztu modelu klasy ~8,7 GFLOPs F45868, a modele zamkniętego produktu z innych rozdziałów muszą zmieścić się w tej samej klasie. Operatory attention w RKNN-Toolkit2 1.6.0 schodziły na CPU F39503, więc OCR z attention łamie budżet. Brak danych w źródłach: liczba rdzeni NPU RK3576, takt NPU w RK3588J i pomiar NPU dla wejścia 640×384.

6.2CPU, RAM i zapis

DecyzjaCztery rdzenie A76 rezerwujemy na OCR awaryjny, śledzenie, fuzję i decyzję, rdzenie A55 na sieć, zapis i I/O. Ścieżka dekoder → NPU działa bez kopiowania pełnych klatek przez CPU (DMA-BUF), CPU dotyka tylko wycinków. RAM: 8 GB LPDDR4X z pulą CMA ≥512 MB. eMMC ≥32 GB w trybie pSLC na system tylko do odczytu, osobny przemysłowy SSD M.2 na zdarzenia.

Dlaczego

• Rdzeń A55 daje ok. 1/3 wydajności A76 F39451. OCR CNN+Attention-LSTM trwa na A76 2,4 GHz 62,5 ms na wycinek, wariant z dekoderem Transformer 200 ms F44173F42184; RK3588J w trybie normalnym taktuje A76 1,6 GHz F39707, co daje 94 i 300 ms. Dwa pojazdy po 10 wycinków na czterech A76 to 0,47 s dla CNN i 1,5 s dla Transformera, więc OCR na CPU może być tylko klasy CNN.
• Kopiowanie przez CPU kosztowało ok. 90 ms na 50 MB F50263; pełna klatka NV12 4 MP (5,53 MB) to 10 ms, a 2×25 kl./s pełnych kopii zajmuje pół rdzenia. ffmpeg-rockchip przenosi ramki przez dekoder, RGA i koder bez kopiowania (DMA) F49157; ścieżka V4L2 bez kopiowania wymaga CMA ≥512 MB, inaczej płyta się zawiesza F38764.
• Potok dwóch strumieni 1080p na RK3588S zajmuje 276–304 MB RSS F47117; po przeskalowaniu do 4 MP, z buforem 1 s i CMA suma wynosi ok. 2,3 GB, więc 4 GB daje zapas ×1,8, a 8 GB ×3,5.
• eMMC 16 GB wytrzymała 23 TiB zapisu F36726, tryb pSLC wydłuża życie ponad dwukrotnie kosztem połowy pojemności (wg producenta) F36293. Zdarzenia z dwóch pasów (2000 pojazdów na dobę na pas S, 0,7 MB na pojazd S) to 2,73 GB/dobę: trwałość nie jest ograniczeniem, ale 32 GB użytkowe mieszczą tylko 12 dób. Ciągłe nagrywanie 2×4 Mbit/s S (80,5 GiB/dobę) zużywa eMMC 64 GB w 3,2 roku.

Parametry i wykonanieNV12 4 MP = 2560×1440×3/2 B (wzór bufora MPP F48978); bufor pierścieniowy 1 s × 2 kamery: 138 MB przy 12,5 kl./s, 276 MB przy 25 kl./s. Procesy OCR i fuzji przypięte do rdzeni A76 (na Orange Pi 5 to CPU 4–7 F43639). SSD na nagrywanie ciągłe przez 5 lat: TBW ≥158 TB; na same zdarzenia wystarcza dowolny SSD przemysłowy ≥256 GB (94 doby). Fuzja głosowaniem jest pomijalna obliczeniowo: odległość edycyjna dla tekstów ~1K znaków to 0,2 ms F48931.

Ryzyko i lukiPrzewodnik Rockchip uznaje RGA na RK3588 za „nieprawidłowe” i odradza F39225, a ffmpeg-rockchip używa RGA w ścieżce bez kopiowania F49157; skalowanie do 640×384 robimy więc w preprocesingu NPU albo na CPU na wycinkach. Dane o trwałości eMMC pochodzą z jednego badania z 2019 r. na układzie 16 GB.

6.3Jądro, termika, watchdog, zasilanie i I/O

DecyzjaObraz produkcyjny działa na jądrze BSP Rockchip 6.1 LTS z rkmpp i rknpu, zamrożonym w wersji; jądro główne utrzymujemy jako sprawdzaną alternatywę. SoC musi mieć ścieżkę cieplną do metalowej obudowy o oporze ≤2,5 °C/W przy 10 W i ≤3,6 °C/W przy 7 W dla 55 °C w szafce. Watchdog działa dwupoziomowo, zasilanie 24 V DC, I/O: ≥4 wejścia izolowane, ≥2 wyjścia bezpotencjałowe, 2× RS-485, RTC z baterią.

Dlaczego

• rkmpp działa tylko na BSP 5.10 i 6.1 F39844, a sprzętowe dekodowanie i NPU w gotowych systemach wymagają rkvdec2 i rknpu z BSP F44046. W jądrze głównym jest jednordzeniowa ścieżka VDPU381, wielordzeniowa jest w pracach F50705; na dystrybucyjnym jądrze 6.12 ffmpeg nie użył VPU F39680, na jądrze 7.1.8 most VA-API→V4L2 przeszedł 32 z 32 testów, w tym 4K F39941. Na RK3576 MPP z BSP był 2,3–3× szybszy od pojedynczych zgłoszeń V4L2 F48256, a sterownik RKNPU DKMS nie kompilował się na jądrze Armbian 6.11 F36972.
• Opór złącze–otoczenie RK3588 na płytce referencyjnej wynosi 8,7 °C/W F47747, dławienie zaczyna się od ok. 80 °C (wg producenta) F36314, maks. Tj = 125 °C F43924. Moduł RK3588 pobiera 6,98 W w teście CPU F49278, a SoC 5–13 W F38811. Przy 7 W i 55 °C goła płytka dałaby Tj = 116 °C; potrzebny opór jest 2,4–3,5× mniejszy niż na płytce referencyjnej. W opisanym wdrożeniu RK3588 w szczelnej skrzynce IP65 bez wentylatora dławił się przy 42 °C po 2–3 godzinach (wg producenta) F38811.
• Przy awarii akceleracji sprzętowej Frigate nie przechodzi na CPU F36667; w jądrze głównym reset dekodera VDPU381 po błędzie zeruje także jego wewnętrzne IOMMU F46881; dojrzały sterownik obsługuje przekroczenie czasu dekodowania przez STREAMOFF i odbudowę kolejek F43643.
• Zasilanie przez USB-C PD wprowadzało Rock 5B w pętlę restartów, producent zaleca 12 V DC F40134.

Parametry i wykonanieWatchdog programowy karmi sprzętowy (SoC ma pięć watchdogów F42949):

co 1 s, dla każdej kamery:
  if klatki_zdekodowane_1s < 0.8*fps: restart_rtsp(); po 3 razach: reset_sesji_dekodera()
  if brak_wyników_NPU > 2 s: restart_procesu_inferencji()
  if temperatura_SoC > 85 °C: obniż fps do 12,5 i zapisz alarm
karm /dev/watchdog tylko, gdy wszystkie testy są zielone (timeout 30 s S)

System plików główny tylko do odczytu przez overlayfs chroni przed zanikiem zasilania (wg sprzedawcy) F33965. I/O na pas: wejście z przekaźnika detektora pętli (styk DC 24 V/3 A F39340) lub radaru, wejście stanu szlabanu S, wyjście „otwórz” do wejścia sterownika szlabanu; dla dwóch pasów 4 DI i 2 DO plus zapas.

Ryzyko i lukiDla RK3588J źródła podają −40…85 °C F39704 albo −20…70 °C przy przepływie powietrza 0,7 m/s F45245, oba wg producentów. Brak danych w źródłach o MTBF i statystykach awarii SBC w szafkach zewnętrznych.

6.4Kamera: piksele na tablicy i obiektyw

DecyzjaNa dalekim końcu strefy odczytu tablica ma mieć ≥128 px szerokości na wprost, ≥148 px przy kącie bocznym 30° i ≥181 px przy 45°. Kamera 4 MP (≥2560 px w poziomie) z obiektywem zmiennoogniskowym ustawionym na kąt widzenia ≤58° dla strefy 3–8 m (≤49° przy 45°); obiektyw stały 2,8 mm odpada.

Dlaczego

• Krój polskiej tablicy samochodowej ma znaki 80 mm i kreskę 9 mm F38418; pełny kontrast kreski wymaga dwóch pikseli na najmniejszy element (wg producenta) F34010, co daje 116 px na 520 mm.
• Modele OCR mają wejście 94 px (LPRNet 24×94 F50001) i 128 px (CRNN, PARSeq 32×128 F47015); kamera ma dostarczyć co najmniej tyle pikseli natywnie, bo SR nie pomaga poniżej 35 px długości tablicy, a pomaga dopiero w zakresie 35–50 px F37986F37987. Detektor tablic traci na małym wejściu: mAP50 0,858 przy 256 px wobec 0,958 przy 640 px F34258.
• Kąt boczny skraca rzut szerokości o cos θ S: 0,866 przy 30° i 0,707 przy 45°.
• Tablica motocyklowa ma 190 mm, znaki 45 mm i kreskę 7 mm F38417F38419: kryterium dwóch pikseli na kreskę wymaga 0,286 px/mm, czyli ×1,29 gęstości dla samochodu.

Parametry i wykonaniePoP = 2560 × 520 / (2·d·tan(HFOV/2)):

W typowej geometrii przy szlabanie (kamera 1,5 m w bok i 1,0 m nad tablicą S) kąt boczny wynosi 26,6° przy 3 m i 10,6° przy 8 m: bliski koniec strefy wyznacza kąt, daleki wyznacza piksele.

Ryzyko i lukiPróg 20–30 px na wysokość znaku (130–162 px na tablicę) to zalecenie producenta obiektywów F41013. Brak danych w źródłach: dokładność OCR w funkcji pikseli dla tablic polskich; założenie, że motocykl ma tylko tablicę tylną, jest S.

6.5Kamera: migawka z rozmycia ruchu

DecyzjaDopuszczalne rozmycie na tablicy wynosi połowę kreski, 4,5 mm. Przy 30 km/h daje to czas ekspozycji ≤1,08 ms dla kąta osi kamery z kierunkiem jazdy α ≤30° i ≤0,76 ms dla 45°. Kamera musi przyjmować zdalnie stałą ekspozycję ≤1/1000 s; migawka globalna nie jest wymagana.

Dlaczego

• Rozmycie daje tylko ruch poprzeczny: b = v·sin α·t; pojazd jadący prosto na kamerę jedynie rośnie w kadrze F36628. Wzrost skali przy 1 ms, 3 m i 30 km/h to 0,28%, czyli 0,5 px na tablicy 181 px.
• 4,5 mm to 1,1 px w wejściu OCR 128 px i 1,28 px kamery przy 148 px. Kryterium 14 mm z poradnika F37865 daje przy 30° 3,4 ms, czyli rozmycie dłuższe niż kreska; przy rozmyciu szerszym od kreski znaki się zlewają (wg producenta) F33249.
• W geometrii z 6.4 α = 31° przy 3 m, więc bliski koniec strefy wyznacza migawkę.
• Rozmycie ruchu i za mała rozdzielczość to główne czynniki degradacji w rzeczywistym LPR F38308.

Parametry i wykonaniet_max dla b = 4,5 mm:

Pochylenie od migawki szczelinowej przy czasie odczytu 20 ms S wynosi na tablicy 31–38 linii 1,8–2,2 mm, poniżej połowy kreski. Opcjonalny drugi zestaw nastaw „postój” (ślad stoi w strefie stop) pozwala wydłużyć t do 8 ms S.

Ryzyko i lukiBrak danych w źródłach: czas odczytu matryc kamer 4 MP, opóźnienie zastosowania nowej ekspozycji wysłanej przez API kamery, pomiar tolerancji OCR na rozmycie w pikselach dla tablic polskich.

6.6Kamera: ekspozycja nocna i IR

DecyzjaOświetlacz IR 850 nm wbudowany w obudowę wokół obiektywu (odsunięcie źródła ≤79 mm przy 3 m). Ekspozycję i wzmocnienie ustawia SBC w pętli zamkniętej na jasności tła tablicy w wycinku, nie automatyka kamery na całym kadrze. Nocą kamera pracuje w trybie mono z wyłączonym filtrem IR, WDR i BLC wyłączone. Katalogowy zasięg IR ≥35 m dla odczytu do 8 m przy 1 ms i kącie wejścia 30° (oszacowanie).

Dlaczego

• Minimalne współczynniki retrorefleksji białej tablicy wg normy BS, przy kącie obserwacji 0°12′: 60 / 25 / 6 cd/lx/m² dla kątów wejścia 5° / 30° / 45° F51173; tablica przy 30° oddaje 0,42, a przy 45° 0,10 światła z 5°. Norma mierzy do kąta obserwacji 1°30′, stąd odsunięcie źródła ≤ d·tan 1,5°.
• Natężenie spada z kwadratem odległości F33420: w strefie 3–8 m jasność tablicy zmienia się ×7,1, a z kątem wejścia do 30° ×17 (4,1 EV), do 45° ×71 (6,2 EV). Oświetlacz o stałym natężeniu działa tylko w pewnym zakresie odległości, dalej niedoświetla lub prześwietla F41125; kilka poziomów natężenia IR rozszerzyło zasięg detekcji F41126. Fuzja wielu ekspozycji daje duchy przy ruchu F40719, więc wybieramy najlepszą klatkę zamiast fuzji.
• Tło lambertowskie o współczynniku odbicia 0,5 S ma R' = 0,16 cd/lx/m², czyli tablica jest ×377 (8,6 EV) jaśniejsza; pomiar ekspozycji na całym kadrze robi z niej biały prostokąt F36826.
• Kontrast biała warstwa/znaki spada z 20–30:1 w paśmie widzialnym do ok. 10:1 przy 900–1000 nm F51171, a powyżej 850 nm odbicie tablic rozbiega się i obraz może być za ciemny F50123F50405; 850 nm to najczęstsze i najtańsze źródło F50095. Oświetlenie NIR przywróciło skuteczność nocną (<20 lx) prawie do poziomu dziennego F38220.

Parametry i wykonanie

dla każdej klatki z tablicą: m = percentyl 90 jasności w wycinku tablicy (8 bit)
cel: m ∈ [150, 200], piksele nasycone < 2% S
m > 200 lub nasycenie: wzmocnienie −3 dB; na minimum: moc IR −1 krok
m < 150: wzmocnienie +3 dB do limitu; na limicie: moc IR +1 krok
czas ekspozycji nigdy powyżej t_max z 6.5; nową nastawę wysyłaj co ≥3 klatki S

Łańcuch zasięgu IR: migawka 1/500 s skraca zasięg zwykłej kamery o ok. 50% (wg producenta) F33412, dalej zasięg ∝ √t i ∝ √R' S; dla 1 ms i 30° zasięg efektywny = 0,23 zasięgu katalogowego.

Ryzyko i lukiWartości retrorefleksji i widm pochodzą z badań tablic brytyjskich; brak danych w źródłach o odbiciu IR tablic polskich i o tym, czy tanie kamery przyjmują zmianę mocy IR przez API.

6.7Strumień i sterowanie kamerą

DecyzjaH.265 Main 8-bit 4:2:0 bez trybów „+”/smart codec, 12,5–15 kl./s, klatka I co 1 s, przepływność maksymalna (≥8 Mbit/s), RTSP po TCP. Kamera synchronizuje czas przez NTP i wysyła raporty RTCP SR, z których SBC mapuje czas klatki na swój zegar. Wymagane API w czasie pracy: czas ekspozycji, limit wzmocnienia, tryb i moc IR, wymuszony dzień/noc, WDR wyłączone.

Dlaczego

• Każdą klatkę dekoduje się niezależnie od żądanej liczby kl./s F33984, a klatka P wymaga poprzednich od ostatniej I F36764; przy ciągłym dekodowaniu (architektura C) GOP nie zmienia obciążenia, wyznacza za to czas do pierwszej klatki po zerwaniu połączenia i propagację błędu S.
• Po włączeniu H.265+ jakości i odstępu klatek I nie da się ustawić F44825; dokumentacja Frigate zaleca odstęp I równy liczbie kl./s F48645.
• Silna kompresja zbioru CCPD obniża czytelność tablic do tego stopnia, że autorzy wykluczyli go z eksperymentów F43433, a modele potrafią uczyć się artefaktów kompresji zamiast znaków F36214.
• Przy 8 Mbit/s klatka 4 MP dostaje 0,174 bit/px przy 12,5 kl./s i 0,087 przy 25 kl./s; strefa 5 m przy 30 km/h daje 7,5 albo 15 klatek. Głosowanie po klatkach podniosło odczyt całych tablic z 64,89% do 78,33% F49533; dostawca podaje 85,1% dla 4–7 wycinków i 92,0% dla 15–20 F48480F48479.
• Ścieżka V4L2 jądra głównego sprawdzona tylko dla HEVC Main 8-bit 4:2:0 F47794; raporty RTCP SR mapują czas zegara na czas strumienia, kamery ONVIF je wysyłają F33808.

Parametry i wykonaniefps kamery = 12,5, a 25 tylko gdy strefa jest krótsza niż 3,33 m (5 klatek przy 30 km/h); GOP = fps; tryb przepływności CBR z limitem; znacznik czasu klatki = t_RTCP(PTS) w CLOCK_REALTIME SBC zsynchronizowanym z tym samym NTP.

Ryzyko i lukiBrak danych w źródłach: zależność dokładności OCR wycinka od przepływności H.265 oraz obsługa ręcznej migawki i mocy IR przez ONVIF Imaging w konkretnych tanich kamerach; to warunek odbioru kamery w teście.

6.8Wyzwalacz

DecyzjaWyzwalaczem podstawowym jest obraz: ślad pojazdu wchodzący w ROI z detekcji 640×384 działającej stale z prędkością 5 kl./s (4% NPU). Pętla albo radar przez izolowane wejście cyfrowe są drugim, niezależnym źródłem: okno zdarzenia otwiera dowolne z nich, a polecenie „otwórz” wymaga przyjętego odczytu i potwierdzenia obecności pętlą, radarem albo stojącym śladem w strefie stop. Bufor 1 s klatek sprzed wyzwolenia czyni opóźnienie wyzwalacza nieistotnym; pętla bezpieczeństwa zostaje w sterowniku szlabanu.

Dlaczego

• Opóźnienia: detektor pętli reaguje w 20 ms (wg producenta) F39340, radar 60 GHz skanuje z częstotliwością 20 Hz, ≤50 ms (wg producenta) F44805, wyzwalacz obrazowy ≤610 ms (obliczenia K). Przy 30 km/h 1 s to 8,3 m drogi, czyli cała strefa odczytu.
• Pętla rzadko wyzwala fałszywie, bo mała masa metalu nie zadziała przekaźnika F40078, ale nie wykrywa niezawodnie rowerów i motocykli F40139F38317; woda i porzucona pętla pod nową psują detekcję (wg producenta) F37957F37958. Radar wykrywa pojazdy stojące, odróżnia pieszych i pomija ruch poprzeczny (wg producenta) F37959F39153F37955. Bariery świetlne fałszywie reagują na ptaki, śnieg i mgłę F38628F38633, a detekcja ruchu w ciemnym kadrze wyzwala LPR od drobnych zmian pikseli F35064.
• Łączenie pętli z drugim czujnikiem i wymóg kilku zdarzeń stosuje się do tłumienia fałszywych alarmów F38629; funkcje pętli wyzwalającej i pętli antyuderzeniowej należy rozdzielić (wg producenta) F39648.

Parametry i wykonanie

IDLE --(ślad w ROI ∨ DI_pętla/radar)--> OKNO (klatki od t_wyzw − 1 s)
OKNO: detekcja tablic + OCR na każdej klatce, głosowanie
OKNO --(odczyt przyjęty ∧ (DI_obecność ∨ ślad stoi w strefie stop))--> OTWÓRZ: DO impuls 500 ms S
OKNO --(ślad opuścił ROI bez obecności)--> IDLE, zdarzenie zapisane bez otwarcia
DI: transoptor 24 V, eliminacja drgań 20 ms S, znacznik CLOCK_MONOTONIC → czas klatki przez RTCP

Ryzyko i lukiBrak danych w źródłach o zmierzonym odsetku fałszywych wyzwoleń pętli, radaru i obrazu na wjazdach parkingowych.

6.9Zestaw do zakupu

Mini PC N100 (porównanie) kosztuje 130–180 USD F42348, pracuje w 0…60 °C (wg producenta) F46231 i nie mieści detekcji 2×12,5 kl./s (6.1).

Założenia S i obliczenia

• Skrypt data/jobs/lpr-cpu-sbc/decyzja/obliczenia/p06.py, wynik p06.out (sekcje A–L).
• S Tabela rknn_model_zoo podaje kl./s, a nie ms: kolumna 3 = RK3588 @single_core, kolumna 4 = RK3576 @single_core (nagłówek tabeli w źródle F42580 sprawdzony 16.10.2026); ustalenia F42580–F42584 opisują te wartości błędnie jako ms.
• S Czas detekcji skalowany liniowo liczbą pikseli wejścia od pomiaru 17,26 ms F42607: 640×384 → 10,4 ms, 384×384 → 6,2 ms; RK3576 = RK3588 × 0,78 (stosunek dla YOLOv8n w tabeli zoo); NPU RK3576 liczone jako jeden rdzeń.
• S Pojemność NPU RK3588 = 3 rdzenie × 0,9 F49930; rezerwa na dławienie 27,7% F47515.
• S OCR na CPU skalowany liniowo z taktem A76 (2,4 → 2,0 → 1,6 GHz); 10 wycinków na pojazd.
• S 4 MP = 2560×1440; strefa odczytu 3–8 m; kamera 1,5 m w bok i 1,0 m nad tablicą; bufor przed wyzwoleniem 1 s.
• S Dopuszczalne rozmycie = połowa kreski 9 mm (rdzeń kreski zachowuje pełny kontrast przy rozmyciu prostokątnym krótszym od kreski); czas odczytu matrycy 20 ms.
• S Tło lambertowskie ρ = 0,5; zasięg IR ∝ √t i ∝ √R'; nastawy pętli ekspozycji; RAM: RSS 2×1080p × 1,78 dla 4 MP plus 1 GB na system i bazę.
• S Zapis: 2000 pojazdów/dobę/pas, 0,5 MB zdjęcia przeglądowego + 10 wycinków po 20 kB; trwałość eMMC liniowa z pojemnością; nagrywanie ciągłe 2×4 Mbit/s.
• S Termika: P = 7 / 10 / 13 W, temperatura w szafce 25 / 42 / 55 °C, próg dławienia 80 °C.
• S Motocykl ma tylko tablicę tylną; impuls DO 500 ms; eliminacja drgań DI 20 ms; detekcja jałowa 5 kl./s. Ceny w walutach źródeł, cenę Dahua odczytano jak w części s04 (T14793).
• Z pliku dane/nauka/p06.jsonl przeczytałem wszystkie 2830 ustaleń (w siedmiu grupach tematycznych), a w rozdziale wykorzystałem 69 z nich (pozostałe odnośniki pochodzą z plików sekcji).