Doelgroep: Dit artikel is bedoeld voor ML-engineers, firmwareleads en OEM-productmanagers die de on-device HTR-engine (handwriting recognition) evalueren die wordt geleverd met de L5, Q8 en T2 leespen. We gaan ervan uit dat je het verschil begrijpt tussen online en offline herkenning, weet wat een CTC-decoder doet, en een concrete technische referentie zoekt voor modelarchitectuur, nauwkeurigheid, latentie en geheugenvoetafdruk binnen het 11-modellen lineup.
Een leespen die gedrukte tekst herkent, maakt gebruik van OCR. Een leespen die handschrift herkent, maakt gebruik van HTR — een fundamenteel ander probleem omdat de input een sequentie is van (x, y, t) streekmonsters, geen statisch beeld. De L5, Q8 en T2 bevatten een HTR-engine als premiumfunctie, voornamelijk gebruikt voor wiskundige invoer, invuloefeningen en validatie van kort-antwoordvragen in werkboeken. Dit artikel behandelt de engine, de on-device modelarchitectuur en de cijfers die je nodig hebt om een verdedigbare OEM-specificatie te schrijven.
1. Waarom OCR en HTR verschillende problemen zijn
De OCR-engine verwerkt een statisch gebinariseerd beeld en produceert een tekenreeks. De HTR-engine verwerkt een sequentie van penpuntcoördinaten over tijd en produceert een tekenreeks. De verschillen werken door de gehele pipeline door:
- Invoermodaliteit: 2D-beeld (OCR) vs 1D-temporele stroom (HTR).
- Invoergrootte: 640 x 480 x 1 byte per regel (OCR) vs 200 tot 500 monsters per streek (HTR).
- Voorverwerking: binarisatie en verbonden-component (OCR) vs hersteekproefname en smoothing (HTR).
- Modelarchitectuur: 2D CNN + RNN + CTC (OCR) vs 1D temporele CNN + BiGRU + CTC (HTR).
- Uitvoer: volledig woordherkenning (OCR) vs incrementele teken-voor-teken (HTR).
De twee engines delen code (de CTC-decoder, de woordenboekzoekopdracht, het taalmodel), maar de front-end en tussenlagen zijn onafhankelijk. We voeren HTR niet uit op de B1, B2, F8, P2, K7, KF1, Q6 en Y6 omdat die modellen de 2D-aanraaksensor en het CPU-budget voor een temporeel model missen.
2. Hardwaregrens en welke modellen HTR uitvoeren
HTR wordt alleen uitgevoerd op de matrix-touchmodellen met voldoende rekenkracht: L5, Q8 en T2. Elk van de drie gebruikt een andere SoC, dus het HTR-model wordt per platform gecompileerd.
| Model | SoC | CPU-cores | DSP/NPU | RAM beschikbaar voor HTR | Flash voor model |
|---|---|---|---|---|---|
| L5 | Cortex-A53 x4 @ 1,2 GHz | 4 | geen (alleen CPU) | 96 MB | 8 MB |
| Q8 | Cortex-A53 x4 @ 1,4 GHz | 4 | 0,5 TOPS NPU | 192 MB | 12 MB |
| T2 | Cortex-A55 x4 @ 1,8 GHz | 4 | 1,2 TOPS NPU | 384 MB | 18 MB |
De L5 voert het HTR-model uit op de CPU-cores omdat het geen NPU heeft. De Q8 en T2 kunnen uitvoeren op de CPU of de NPU; we leveren de CPU-build standaard en de NPU-build als OEM-optie voor kopers die lagere latentie nodig hebben.
3. De streekvangst-pipeline
De HTR-engine begint met de touch-controller die (x, y, t) monsters rapporteert. De monsters zijn al voorzien van tijdstempels door de touch IC. De host-MCU routeert de monsters naar een ringbuffer van 1.024 entries, wat voldoende is voor 8 seconden continu schrijven bij 120 Hz.
Voorverwerkingsstappen worden in realtime uitgevoerd naarmate de monsters binnenkomen:
- Smoothing: een 3-taps voortschrijdend gemiddelde op x en y. Verwijdert sensorjitter.
- Dehooking: verwijdert de initiële "hook"-streek die optreedt wanneer de stylus eerst het oppervlak raakt. Een hook is een snelle boog van 30 mm tot 50 mm binnen de eerste 30 ms.
- Hersteekproefname: hersteekproefname van de streek naar een vast 80 punten ongeacht oorspronkelijke snelheid. Dit is wat het model grootte-onafhankelijk maakt van schrijfsnelheid.
- Normalisatie: verplaats centroid naar oorsprong en schaal om in een 20 mm bij 20 mm begrenzingsvak te passen.
- Feature-extractie: bereken dx, dy, dx², dy² op elk hersteekproefpunt, plus pen-up-vlag. Feature-vector is 5 waarden per punt.
De 80-punten x 5-feature-vector wordt aan het model gevoerd. Voorverwerking voegt 4 ms latentie toe op de L5.
4. De modelarchitectuur
De HTR-engine gebruikt een 1D temporele CNN gevolgd door een 2-laags bidirectionele GRU, gevolgd door een CTC-decoder. De architectuur is identiek op L5, Q8 en T2; alleen de per-platform gewichtsquantisatie verschilt.
De temporele CNN heeft 3 lagen:
- Conv1D(5 → 32, kernel 5, stride 1) + batch norm + ReLU.
- Conv1D(32 → 64, kernel 5, stride 2) + batch norm + ReLU.
- Conv1D(64 → 128, kernel 3, stride 2) + batch norm + ReLU.
Uitvoer van de CNN is een 20-stap sequentie met 128 kanalen per stap (80 invoerpunten met 4 omlaaggeschaald).
De 2-laags bidirectionele GRU heeft 128 verborgen eenheden per richting, wat 256 eenheden per stap geeft. De GRU draait in beide richtingen en de uitvoeren worden samengevoegd.
De CTC-decoder is een enkele lineaire laag van 256 → 96 eenheden (94 afdrukbare ASCII-tekens plus spatie plus opvulling). Het voert een kansverdeling uit over 96 symbolen op elk van de 20 tijdstappen. De CTC-verliesfunctie lijnt de 20-stap uitvoer uit naar de doel-tekenreeks tijdens training.
Totale parameters: 412.000 gewichten voor de CNN + 296.000 voor de GRU + 24.700 voor de CTC-head = 732.700 parameters.
Op schijf is het int8-gekwantiseerde model 1,84 MB. Op de L5 expandeert het naar 1,92 MB tijdens runtime (met batch-norm gevouwen). Op de Q8 en T2 met NPU-acceleratie draait het int8-model als één enkele blob van 1,84 MB.
5. Trainingsgegevens en nauwkeurigheid
Het model is getraind op een corpus van 2,4 miljoen handschriftmonsters verzameld van 4.800 schrijvers uit 14 landen. Schrijvers omvatten links- en rechtshandigen, leeftijden 5 tot 70. Elke schrijver produceerde 500 tot 800 monsters van enkele tekens, korte woorden en korte numerieke expressies. De dataset is gebalanceerd over Engels, Spaans, Frans, Duits, Italiaans, Portugees, Arabisch, Chinees, Japans, Koreaans, Russisch, Hindi, Thai en Vietnamees.
Teken-niveau nauwkeurigheid op een apart testsetset van 80.000 monsters (niet in de trainingsset):
| Script | L5 nauwkeurigheid | Q8 nauwkeurigheid | T2 nauwkeurigheid |
|---|---|---|---|
| Engels (Latijn) | 96.4% | 97.8% | 98.4% |
| Spaans | 96.1% | 97.6% | 98.2% |
| Frans | 95.7% | 97.3% | 98.0% |
| Duits | 95.4% | 97.0% | 97.7% |
| Arabisch | 92.1% | 94.8% | 95.9% |
| Chinees | 93.8% | 95.9% | 96.7% |
| Japans (kana) | 94.0% | 96.0% | 96.9% |
| Koreaans (Hangul) | 93.6% | 95.7% | 96.5% |
| Hindi (Devanagari) | 92.8% | 95.1% | 96.1% |
| Thai | 91.9% | 94.4% | 95.5% |
| Vietnamees | 95.2% | 97.0% | 97.8% |
Woordniveau nauwkeurigheid op een aparte testsetset van 10.000 woorden (Engels) is 92,4% op de L5, 94,8% op de Q8 en 95,7% op de T2. Woordnauwkeurigheid is altijd lager dan teken nauwkeurigheid omdat een enkele verkeerd herkend teken een woord ongeldig kan maken.
6. De CTC-decoder en taalmodel
De CTC-decoder produceert een reeks van (symbool, waarschijnlijkheid) paren. We vouwen herhalingen samen en verwijderen blanco's om een kandidaat tekensequentie te verkrijgen. Vervolgens herscoort een 4-gram taalmodel de top 5 kandidaten en kiest de hoogst scorende.
Het taalmodel is een compact KenLM-model met 32 miljoen n-grammen, met een omvang van 18 MB op schijf en 24 MB in RAM tijdens runtime. Het LM is alleen Engels op de L5; de Q8 en T2 bevatten aparte LM's voor Spaans, Frans, Duits, Italiaans, Portugees, Arabisch, Chinees, Japans, Koreaans, Russisch, Hindi, Thai en Vietnamees, met een totaal van 187 MB voor alle 13 talen.
Voor OEM-kopers die een aangepast LM willen (bijvoorbeeld een uitgever-specifieke vocabulaire), kunnen we een domein-LM trainen op basis van een door de klant aangeleverd corpus van slechts 50.000 zinnen. Het trainingsproces duurt 6 uur op een enkele A100 GPU. Het aangepaste LM vervangt het algemene LM in de firmware en voegt 4 tot 8 MB toe afhankelijk van de vocabulairegrootte.
7. Modelquantisatie en platformvarianten
We leveren drie quantisatievarianten:
- float32: 2,93 MB op schijf, 3,04 MB runtime, 32 ms CNN-latentie op L5. Wordt alleen gebruikt voor debugging.
- int8 per-kanaal: 1,84 MB op schijf, 1,92 MB runtime, 32 ms CNN-latentie op L5. Standaard voor L5 en de CPU-build voor Q8/T2.
- int8 per-tensor (NPU-vriendelijk): 1,81 MB op schijf, 1,81 MB runtime, 10 ms CNN-latentie op Q8 NPU, 6 ms op T2 NPU.
De NPU-vriendelijke variant rondt elke tensor af met één schaalfactor in plaats van per-kanaals schalen, wat 0,3 procentpunt nauwkeurigheid kost maar de 3x tot 5x snelheidsverbetering op de NPU mogelijk maakt. Het nauwkeurigheidsverlies wordt hersteld door een kleine calibratiestap waarbij we 4.000 monsters door het int8-model halen en de schalen aanpassen.
8. Geheugenvoetafdruk en stroomverbruik
Op de L5 met het int8 per-kanaalmodel verbruikt de HTR-engine:
- 1,92 MB model in flash, geladen in 1,92 MB RAM bij herkenningstijd.
- 24 MB LM in RAM (alleen Engels).
- 1,1 MB ringbuffer en voorbewerkings-scratch.
- Totale werkingsset: 27 MB RAM, met 69 MB headroom op de beschikbare 96 MB.
Gemiddeld stroomverbruik tijdens een herkenningsoperatie: 92 mW gedurende 70 ms = 6,4 mJ per woord. Bij 250 mW gemiddeld scanvermogen voegt de HTR-engine ongeveer 2,5% toe aan het totale systeem-stroombudget. Op de Q8 en T2 is de energie per herkenning respectievelijk 3,4 mJ en 2,1 mJ.
9. AQL op de HTR-kalibratielijn
Elke L5-, Q8- en T2-eenheid voert een 12 seconden durende HTR-zelftest uit tijdens de kalibratie. De test presenteert een vaste 32-karakters-tekenreeks via de touchsimulator en controleert de herkende uitvoer tegen een bekend-goede referentie. Acceptatiecriteria:
- Exacte tekenreeks overeenkomst binnen 70 ms: geslaagd.
- Exacte tekenreeks overeenkomst binnen 90 ms: geslaagd met aantekening.
- 1-karakterfout: herwerken (model opnieuw flashen, herkalibreren).
- 2+ karakterfout of geen uitvoer binnen 100 ms: afkeuren.
Over 8.000 L5-eenheden gekalibreerd in Q1 2026 was de first-pass opbrengst 95,6%, herwerkingspercentage 3,1%, scrappercentage 1,3%. De dominante afkeuringsoorzaak is een verkeerd geflasht int8-model vanwege een gecorrumpeerde OTA-transfer, wat we mitigeren door een checksum-verificatie bij elke opstart.
10. HTR specificeren in een OEM-contract
Een verdedigbare HTR-specificatie omvat:
- Modelarchitectuur en kwantisatie (we leveren standaard int8 per-kanaal).
- Per-platform teken-level nauwkeurigheid op een apart testsets (Engels ≥ 96%, Chinees ≥ 93%).
- Herkenningslatentie op het target platform (L5 ≤ 80 ms, Q8 ≤ 35 ms, T2 ≤ 25 ms).
- LM-grootte en ondersteunde talen.
- Aangepaste LM-trainings-SLA (10 werkdagen voor bestellingen boven 5.000 eenheden).
- AQL-acceptatiecriteria (exacte overeenkomst binnen 90 ms op de kalibratietekenreeks).
Voor meer informatie over hoe de HTR-engine integreert met de woordenboekopzoeking, zie Leespen woordenboekbestandsindeling en editie. Voor hoe de OCR-engine die gedrukte tekst herkent is gestructureerd, zie Leespen OCR-engine vs deep learning OCR. Voor hoe de touch-samples worden voorbewerkt, zie Leespen touch-nauwkeurigheid en jittertest. Voor de OEM-specificatietaal die we aanbevelen voor handschriftaanvaarding, zie Leespen OEM- en ODM-specificatiesjabloon. Om een 5-eenheden monster aan te vragen met een aangepaste LM getraind op uw corpus, zie /request-a-quote.
Gerelateerde lectuur
- Leespen OCR-engine vs deep learning OCR
- Leespen tekstdetectie en -segmentatie
- Leespen touch-nauwkeurigheid en jittertest
- Leespen woordenboekbestandsindeling en editie
- Leespen gebarenherkenning-algoritme
- Leespen firmware-architectuur uitgelegd
Aanvullende lectuur: HTR voor wiskunde en vergelijkingsinvoer
De HTR-engine wordt ook gebruikt in een wiskunde-invoermodus op de L5, Q8 en T2. In wiskundemodus herkent het model individuele cijfers en 18 operatorsymbolen, plus 14 Griekse letters en 9 geometrische vormen. Het wiskundemodus-woordenboek is kleiner (41 symbolen vs 96 in het standaard HTR-woordenboek) dus het taalmodel kan een eenvoudig bigram zijn in plaats van een 4-gram, en de LM-grootte daalt tot 1,4 MB.
Wiskundemodus-nauwkeurigheid op een testsets van 5.000 expressies is 98,7% symbool-level op de T2 en 96,9% op de L5. We gebruiken een grammaticabewuste decoder die de uitvoer beperkt tot geldige expressiebomen, wat fouten op ambiguë invoer vermindert zoals "x × 2" vs "x · 2" vs "x ÷ 2."
Voor schoolwiskundeprogramma's gericht op groep 1-8 is de HTR-wiskundemodus de meestgevraagde functie van de afgelopen 18 maanden geweest. We hebben HTR-wiskundemodus geleverd aan 7 OEM-klanten in 5 landen, in totaal 14.500 T2-eenheden. Het gemiddelde wiskundemodus-gebruik is 8,4 minuten per leerling per dag, wat ruim binnen de 14-uur batterijlevensduur van de T2 valt.
Wiskundemodus verbruikt ook het grootste deel van de 1,2 TOPS NPU op de T2. Aanhoudende wiskunde-invoer bij 30 expressies per minuut drijft de T2 NPU naar 78% utilized, met de SoC-packagetemperatuur die stijgt van 28 °C stationair naar 41 °C na 5 minuten aanhoudende invoer. Beide waarden liggen ruim binnen het commerciële operationele venster van 0 °C tot 70 °C.