7.16. Samenvatting

Dit hoofdstuk doorliep de onderdelen van ml waar een OpenMV-toepassing naar grijpt wanneer een inferentiestap deel uitmaakt van de pipeline:

  • Concepten – wat een neuraal netwerk in rekenkundige termen is (een stapel trainbare operatoren die een tensor afbeeldt op een tensor), wat machine learning veranderde ten opzichte van klassieke beeldverwerking (het door mensen geschreven samenvattingsalgoritme is verdwenen, vervangen door gewichten die geleerd zijn uit gelabelde data), en de hello-demo die een gezichtsdetector uitvoerde in een handvol regels Python.

  • De ml-module – het ml.Model-object en zijn eigenschappen voor het inspecteren van invoer- en uitvoertensoren, de modelbestandspaden die het accepteert, en waar die bestanden zich bevinden: een alleen-lezen ROMFS-partitie voor uitvoering rechtstreeks vanuit het flashgeheugen, of elk ander MicroPython-bestandssysteem wanneer het model bij het laden naar RAM gekopieerd kan worden.

  • De inferentie-pipeline – de drie fasen die predict() na elkaar uitvoert (voorbewerking, engine-dispatch, nabewerking), de Normalization-handle voor fase één, de nabewerkings-handle voor fase drie, en de kwantisatierekenkunde die de integer-tensoren die de cam draait terugkoppelt aan de reële getallen waarop het netwerk getraind is.

  • Inferentie-engines – TFLM (de operator-interpreter die de meeste cams draaien), CMSIS-NN (de SIMD-kernelbibliotheek eronder op Cortex-M), en de NPU’s (Arms Ethos-U55 op de AE3 gekoppeld aan de Vela-offlinecompiler, ST’s Neural-ART op de N6 gekoppeld aan STAI en STEdgeAI). De engine ligt vast door de cam; het script kiest hem niet.

  • De uitvoer decoderen – de nabewerkers die ruwe uitvoertensoren omzetten in begrenzingsvakken, sleutelpunten of lijsten per klasse, de NMS-klasse die overlappende kandidaten samenvouwt, de YOLOv8-doorloop die laat zien hoe je het decoderen snel houdt door te drempelen vóór het dequantiseren, en het protocol voor het schrijven van een eigen decoder wanneer de catalogus een model niet dekt.

7.16.1. Wat nu binnen handbereik ligt

Drie dingen waar dit hoofdstuk op voorbereidt:

  • Een getraind model laden en uitvoeren. Alles in /rom/ werkt zonder verdere voorbereiding; alles wat extern wordt aangeleverd als een compatibel .tflite werkt nadat de offlinetool voor de doel-cam (Vela voor de AE3, STEdgeAI voor de N6) de juiste opmaak heeft geproduceerd.

  • Elke uitvoertensor decoderen. Wanneer de architectuur in de catalogus staat, is de juiste nabewerker mechanisch: YoloV8 voor een YOLOv8-model, BlazeFace voor BlazeFace, enzovoort. Wanneer dat niet zo is, behandelt het writing-your-own-protocol het contract en is de YOLOv8-doorloop de schoonste referentie om van te kopiëren.

  • Redeneren over prestaties. Een model dat met 30 FPS draait op een NPU kan met 3 FPS draaien op een Cortex-M7; de verhouding hangt af van hoeveel van het netwerk de cam van de CPU kan tillen. Kwantisatie, ROMFS-plaatsing, NPU-compilatie en de operatordekking van de doel-engine zijn de vier hefbomen, en het hoofdstuk behandelde elk daarvan.

7.16.2. ML stelt zich samen met de rest van de cam

Een inferentie draait zelden geïsoleerd. De image-module legt het frame vast en bewerkt het voor, de ml-module draait het netwerk, en ulab.numpy doet welk numeriek werk dan ook waarvoor geen van beide kanten iets ingebouwds heeft. Een typisch detectiescript combineert alle drie: vastleggen met csi, optioneel het frame aanpassen met image, predict() uitvoeren, het resultaat nabewerken met de juiste module uit ml.postprocessing, en ulab.numpy gebruiken voor elke eigen wiskunde die de toepassing bovenop de begrenzingsvakken wil die de nabewerker teruggaf. De drie modules delen hetzelfde geheugenmodel; de grenzen ertussen zijn waar mogelijk zonder kopie.