NanoEdge AI Studio: quanto è semplice portare davvero l'AI su un microcontrollore?

Perché dovreste provare NanoEdge AI Studio

Se lavorate con Raspberry Pi Pico per i vostri progetti o prototipi, saprete certamente che parlare di Intelligenza Artificiale su un oggetto con poche centinaia di Kbyte di RAM significa entrare in un mondo completamente diverso rispetto a quello dei grandi modelli generativi. Io sono arrivato a NanoEdge AI Studio proprio da qui, riprendendo un mio vecchio controller di temperatura ed allarme e chiedendomi se fosse possibile trasformare un sistema basato su soglie decise da me in qualche cosa capace di imparare ciò che per QUEL sistema rappresenta la normalità, e quindi accorgersi quando il comportamento comincia a diventare strano senza che io debba prevedere prima ogni singolo caso.

NanoEdge AI Studio, nella versione attuale 5.1, è un ambiente AutoML di STMicroelectronics pensato per creare modelli minuscoli destinati ai microcontrollori. Il punto importante, che secondo me va chiarito subito, è che NON SI TRATTA DI UN'AI CONVERSAZIONALE e quindi dentro NanoEdge non si scrive un prompt come si farebbe con ChatGPT, Gemini o Qwen. Il mio prompt è stato invece la consegna con cui ho impostato il problema e preparato il test, ovvero ottenere un rilevatore adattivo delle anomalie partendo dalla serie temporale di un sensore, usando esempi di funzionamento normale ed esempi nei quali il comportamento si discostava dalla normalità. Ho scelto volutamente questo tipo di prova perché non volevo sapere se NanoEdge fosse capace di riconoscere una condizione che avevo già definito io con una soglia, quello lo fa benissimo anche un semplice if, volevo capire se riusciva a trovare da solo una separazione utile fra NORMALITÀ ed ANOMALIA.

Il senso delle varianti che ho preparato

Le varianti del dataset non sono state create per complicare artificialmente la prova ma per evitare un test troppo facile. Se avessi fornito una normalità perfettamente piatta ed un'anomalia enormemente diversa avrei probabilmente ottenuto un bel numero sullo schermo senza imparare molto sul comportamento reale dello strumento. Ho quindi ragionato sulla presenza di più situazioni compatibili con il funzionamento normale e su deviazioni differenti, mantenendo l'idea di fondo che il sistema dovesse imparare una famiglia di comportamenti e non una singola temperatura. È esattamente qui che un sistema di anomaly detection diventa interessante, perché la domanda non è più soltanto "ho superato la soglia?" ma "questo andamento assomiglia ancora abbastanza a ciò che ho imparato come normale?".

NanoEdge AI Studio lavora molto sulle serie temporali ed il suo workflow è abbastanza diretto, si definiscono target, sensore, numero di assi e limiti di memoria, si importano i segnali regolari e quelli anomali, quindi parte il benchmark che prova migliaia di combinazioni di preprocessing, modelli e parametri cercando quella più adatta al problema ed al microcontrollore scelto. Per l'anomaly detection c'è poi un dettaglio che trovo particolarmente interessante, il benchmark seleziona la libreria migliore ma la libreria non viene necessariamente "addestrata una volta per tutte" sul PC, la normalità può essere appresa successivamente sul microcontrollore attraverso la funzione di learning e questo apre la strada ad un dispositivo capace di adattarsi sul campo.

Il primo ostacolo è stato banalissimo, ma molto istruttivo

Il primo test non è nemmeno arrivato al benchmark perché NanoEdge rifiutava il dataset dicendo che il numero delle colonne non corrispondeva al numero degli assi. All'inizio sembra uno di quegli errori poco parlanti che fanno perdere tempo, in realtà la regola del programma è precisa: ogni riga deve rappresentare un segnale indipendente, tutte le righe devono avere lo stesso numero di valori ed il numero di valori deve essere coerente con la struttura del sensore dichiarata nel progetto. Sistemato il dataset e resa coerente la forma dei segnali, l'importazione è andata a buon fine e finalmente il programma ha potuto visualizzare correttamente i dati.

Questa piccola disavventura mi è servita anche a capire meglio la logica del software, perché NanoEdge non vuole una tabella generica sulla quale poi prova ad indovinare cosa intendessimo fare, vuole segnali preparati con una struttura rigorosa. Il buffer deve restare costante, il campionamento deve essere coerente ed i dati devono essere separati correttamente fra esempi normali ed anomali. Non è un difetto, anzi per un'applicazione embedded trovo preferibile un programma che si fermi subito davanti ad un dataset ambiguo piuttosto che uno che lo accetti ed inizi a produrre risultati apparentemente convincenti.

Il benchmark ed i risultati del primo giro

Una volta corretto il formato, NanoEdge ha accettato il dataset ed il benchmark è partito regolarmente. Ed è proprio qui che si vede cosa fa davvero il programma, perché non sceglie un singolo algoritmo deciso a priori ma avvia una ricerca automatica fra molte combinazioni, osservando accuratezza bilanciata, qualità complessiva, RAM, Flash ed altre caratteristiche della libreria. Durante il mio primo giro il processo è rimasto in elaborazione parecchio tempo, tanto da farmi inizialmente pensare che si fosse bloccato, quindi NON considero quel passaggio un benchmark conclusivo dal quale pubblicare oggi una percentuale definitiva. Il risultato concreto del test introduttivo è però già importante: il dataset corretto viene riconosciuto, le due famiglie di segnali possono essere elaborate e la ricerca della libreria parte realmente, mentre il primo errore era dovuto esclusivamente alla forma dei dati e non ad un'incompatibilità del progetto.

Non voglio quindi inventare un 99 virgola qualcosa per rendere più spettacolare questo articolo. I numeri finali di balanced accuracy, RAM, Flash e qualità hanno senso soltanto dopo aver lasciato concludere il benchmark ed aver poi validato la libreria su dati che non siano semplicemente gli stessi usati per costruire il test. Questa, per me, è anche una differenza sostanziale fra fare una dimostrazione ed iniziare a costruire un dispositivo che dovrà funzionare davvero.

Quanta RAM serve e perché qui la GPU non è il problema

Qui bisogna distinguere due cose che spesso vengono mischiate. NanoEdge AI Studio gira localmente su PC, oggi su Windows oppure Ubuntu, ed il benchmark usa la macchina locale per cercare la libreria migliore; ST non pubblica nella pagina corrente del prodotto un requisito minimo di RAM del PC né indica una GPU come requisito obbligatorio, quindi attribuirgli una necessità di 16, 32 o 64 Gbyte sarebbe semplicemente inventare un dato. In assenza di GPU il programma continua ad essere utilizzabile perché NON È un LLM locale che deve caricare decine o centinaia di miliardi di parametri in memoria, il carico principale del benchmark è CPU e la durata dipende anche dalla complessità del dataset e dallo spazio di ricerca che gli lasciamo esplorare.

Sul microcontrollore la situazione è ancora più interessante. ST indica come ordine di grandezza tipico librerie NanoEdge nell'area di circa 1-20 Kbyte di RAM e Flash, anche se il consumo reale può crescere in funzione del progetto e soprattutto del buffer, ed esistono esempi ufficiali che arrivano a diverse decine di Kbyte. Questo significa che non esiste "la RAM necessaria a NanoEdge" come numero universale, perché il limite viene imposto nel progetto e la ricerca viene fatta tenendo conto anche di quello. Su un target piccolo il gioco consiste esattamente nel trovare il miglior compromesso fra capacità di riconoscimento e memoria disponibile.

Ed è qui che l'approccio mi piace parecchio. Con una Raspberry Pi Pico basata su RP2040 non sto cercando di infilare un modello generativo dentro 264 Kbyte di SRAM, sto cercando di costruire una piccola libreria specializzata che osservi una serie temporale e sappia dire quanto essa assomiglia alla normalità che ha imparato. NanoEdge supporta target Arm Cortex-M e, per i target non ST, l'impiego è previsto a livello di sviluppo mentre per un utilizzo produttivo ST invita a contattarla, quindi anche questo è un dettaglio da non dimenticare se dal prototipo si passa ad un prodotto.

Il mio parere dopo il primo contatto

La cosa che mi ha colpito maggiormente è che NanoEdge AI Studio porta l'AI embedded molto più vicino al modo di lavorare di chi sviluppa firmware. Non devo costruire da zero una pipeline di Machine Learning, scegliere a mano un algoritmo, scrivere il preprocessing e poi scoprire alla fine che il risultato occupa troppa memoria, posso partire dai segnali reali, indicare il target e lasciare al benchmark il compito di cercare una soluzione ragionevole. Ma non è magia, perché se gli fornisco dati sbagliati, poco rappresentativi oppure strutturati male il problema rimane mio, come ho visto immediatamente con il primo dataset.

Per questo il mio giudizio, almeno in questa fase introduttiva, è positivo ma con una condizione precisa: NanoEdge AI Studio mi sembra davvero interessante quando lo si usa per quello che è, ovvero uno strumento AutoML destinato al TinyML e non una scatola nera alla quale consegnare qualsiasi CSV sperando che inventi una soluzione. Il prossimo passo sarà lasciare maturare il benchmark, confrontare le librerie candidate, validarle con dati nuovi e soprattutto portare il learning e l'inference sul microcontrollore reale, perché è lì che si capirà se questo esperimento può diventare il rilevatore adattivo che avevo in mente fin dall'inizio.