7.16. Recapitulare

Acest capitol a parcurs componentele modulului ml la care recurge o aplicație OpenMV atunci când un pas de inferență face parte din fluxul de procesare:

  • Concepte – ce este o rețea neuronală în termeni aritmetici (un set de operatori antrenabili care transformă un tensor într-un tensor), ce a schimbat învățarea automată comparativ cu procesarea clasică a imaginilor (algoritmul de sintetizare scris de om dispare, fiind înlocuit de ponderi învățate din date etichetate) și demonstrația hello, care a rulat un detector de fețe în câteva linii de Python.

  • Modulul ml – obiectul ml.Model și proprietățile sale pentru inspectarea tensorilor de intrare și ieșire, căile de fișier ale modelului pe care le acceptă și locul unde se află aceste fișiere: o partiție ROMFS doar pentru citire, pentru execuție direct din memoria flash, sau orice alt sistem de fișiere MicroPython atunci când modelul poate fi copiat în RAM la momentul încărcării.

  • Fluxul de inferență – cele trei etape pe care predict() le rulează succesiv (pre-procesare, dispecerizare către motor, post-procesare), referința Normalization pentru prima etapă, referința post-procesorului pentru a treia etapă și aritmetica de cuantizare care leagă tensorii întregi pe care îi rulează camera de numerele cu valori reale față de care a fost antrenată rețeaua.

  • Motoare de inferență – TFLM (interpretorul de operatori pe care îl rulează majoritatea camerelor), CMSIS-NN (biblioteca de nuclee SIMD aflată sub el pe Cortex-M) și NPU-urile (Ethos-U55 de la Arm pe AE3, asociat cu compilatorul offline Vela, și Neural-ART de la ST pe N6, asociat cu STAI și STEdgeAI). Motorul este fixat de cameră; scriptul nu îl alege.

  • Decodarea ieșirii – post-procesoarele care transformă tensorii de ieșire bruți în casete, puncte-cheie sau liste pe clase, clasa NMS care comasează candidații suprapuși, parcurgerea exemplului YOLOv8 care arată cum se menține decodarea rapidă prin aplicarea pragului înainte de decuantizare și protocolul pentru scrierea unui decodor personalizat atunci când catalogul nu acoperă un model.

7.16.1. Ce devine acum accesibil

Trei lucruri pentru care capitolul pregătește terenul:

  • Încărcarea unui model antrenat și rularea lui. Orice se află în /rom/ funcționează fără pregătiri suplimentare; orice este furnizat extern sub forma unui fișier .tflite compatibil funcționează după ce instrumentul offline pentru camera țintă (Vela pentru AE3, STEdgeAI pentru N6) a produs aspectul corect.

  • Decodarea oricărui tensor de ieșire. Când arhitectura se află în catalog, alegerea post-procesorului corect este mecanică: YoloV8 pentru un model YOLOv8, BlazeFace pentru BlazeFace și așa mai departe. Când nu este, protocolul writing-your-own acoperă contractul, iar parcurgerea YOLOv8 este cea mai clară referință de la care se poate copia.

  • Raționarea asupra performanței. Un model care rulează la 30 FPS pe un NPU poate rula la 3 FPS pe un Cortex-M7; raportul depinde de cât din rețea poate prelua camera de pe CPU. Cuantizarea, plasarea în ROMFS, compilarea pentru NPU și acoperirea de operatori a motorului țintă sunt cele patru pârghii, iar capitolul le-a tratat pe fiecare.

7.16.2. ML se combină cu restul camerei

O inferență rulează rareori izolat. Modulul image captează și pre-procesează cadrul, modulul ml rulează rețeaua, iar ulab.numpy se ocupă de orice lucrare numerică pentru care niciuna dintre părți nu are o funcție integrată. Un script tipic de detectare le combină pe toate trei: captură cu csi, ajustarea opțională a cadrului cu image, rularea predict(), post-procesarea rezultatului cu modulul potrivit din ml.postprocessing și recurgerea la ulab.numpy pentru orice calcul personalizat pe care aplicația îl dorește în plus față de casetele returnate de post-procesor. Cele trei module împart același model de memorie; granițele dintre ele sunt fără copiere (zero-copy) oriunde este posibil.