Slik kan kantklare maskinlæringsprogrammer raskt distribueres

Maskinlæring (ML) tilbyr et enormt potensial når det gjelder å utvikle smarte produkter, men kompleksiteten og utfordringene involvert i modellering for nevrale nettverk (NN – neural network) og å lage ML-programmer for kanten, har begrenset utviklernes evne til å raskt levere nyttige løsninger. Selv om lett tilgjengelige verktøy har gjort ML-modellutvikling generelt mer tilgjengelig, er ikke konvensjonell ML-utviklingspraksis utviklet for å oppfylle de unike kravene til løsninger for tingenes Internett (IoT), kjøretøy, industrielle systemer og andre innebygde konstruksjoner.

Denne artikkelen gir en kort innføring i NN-modellering. Den introduserer og beskriver deretter hvordan man bruker en omfattende ML-plattform fra NXP Semiconductors som gir utviklere muligheten til å levere kantklare ML-programmer på en mer effektiv måte.

En rask gjennomgang av NN-modellering

ML-algoritmer gir utviklere et svært annerledes alternativ for programutvikling. I stedet for å skrive programvarekode som er ment å uttrykkelig løse problemer som bildeklassifisering, trener utviklere NN-modeller ved å presentere et sett med data, for eksempel bilder som er merket med det faktiske navnet (eller klassen) til entiteten som finnes i bildet. Opplæringsprosessen bruker en rekke metoder for å beregne parametrene til en modell for vekting og systematiske avviksverdier (bias) for hvert nevron og lag, noe som gjør det mulig for modellen å gi en rimelig nøyaktig forutsigelse av den riktige klassen for et inndatabilde (figur 1).

Figur 1: NN-er, slik som dette fullt tilkoblede nettverket, klassifiserer et inndataobjekt ved å bruke vekting og systematiske avviksverdier som er angitt under opplæringen. (Bildekilde: NXP Semiconductors)

ML-forskere har utviklet et bredt spekter av NN-arkitekturer utover det universale fullt tilkoblede NN-et som er vist i figur 1. For eksempel bruker bildeklassifiseringsprogrammer vanligvis det konvolusjonelle NN-et (CNN – convolutional neural network), en spesialisert arkitektur som deler bildegjenkjenning i en innledende fase som finner hovedtrekk i et bilde, etterfulgt av en klassifiseringsfase som forutsier sannsynligheten for at det hører hjemme i én av flere klasser som er etablert under opplæringen (figur 2).

Figur 2: ML-eksperter bruker spesialiserte NN-arkitekturer, slik som dette konvolusjonelle nevrale nettverket (CNN), for spesifikke oppgaver som bildegjenkjenning. (Bildekilde: NXP Semiconductors)

Selv om valget av egnet modellarkitektur og opplæringsregime har vært begrenset til ML-eksperter, har tilgjengeligheten av flere verktøy med åpen kildekode og kommersielle verktøy forenklet modellutviklingen dramatisk for storstilt distribusjon. I dag kan utviklere definere modeller med noen få kodelinjer (liste 1) og bruke verktøy som Netron-modellviseren med åpen kildekode til å generere en grafisk representasjon av modellen (figur 3) for å sjekke hver lagdefinisjon og konnektivitet.

Kopi
def model_create(shape_in, shape_out):
    from keras.regularizers import l2
    
    tf.random.set_seed(RANDOM_SEED)
 
    model = tf.keras.Sequential()
    model.add(tf.keras.Input(shape=shape_in, name='acceleration'))
    model.add(tf.keras.layers.Conv2D(8, (4, 1), activation='relu'))
    model.add(tf.keras.layers.Conv2D(8, (4, 1), activation='relu'))
    
    model.add(tf.keras.layers.Dropout(0.5))
    
    model.add(tf.keras.layers.MaxPool2D((8, 1), padding='valid'))
    model.add(tf.keras.layers.Flatten())
    
    model.add(tf.keras.layers.Dense(64, kernel_regularizer=l2(1e-4), bias_regularizer=l2(1e-4), activation='relu'))
    model.add(tf.keras.layers.Dropout(0.5))
    model.add(tf.keras.layers.Dense(32, kernel_regularizer=l2(1e-4), bias_regularizer=l2(1e-4), activation='relu'))
    model.add(tf.keras.layers.Dropout(0.5))
    model.add(tf.keras.layers.Dense(shape_out, activation='softmax'))
    model.compile(optimizer='adam', loss='categorical_crossentropy', metrics=['acc'])
    
    return model

Liste 1: Utviklere kan definere NN-modeller ved å bruke bare noen få kodelinjer. (Bildekilde: NXP Semiconductors)

Figur 3: Denne grafiske representasjonen av modellen definert i liste 1, som er generert av Netron-viseren, kan gjøre det enklere for utviklere å dokumentere funksjonen og konnektiviteten til hvert lag. (Bildekilde: Stephen Evanczuk, kjører Netron på NXP-modellens kildekode i liste 1)

For endelig distribusjon, vil andre verktøy fjerne modellstrukturer som bare kreves under opplæring og utføre andre optimaliseringer for å skape en effektiv inferensmodell.

Derfor har utviklingen av ML-baserte programmer for smarte produkter vært så vanskelig

Definering og opplæring av en modell for IoT eller andre smarte produkter følger en lignende arbeidsflyt som det å lage en modell for maskinlæringsprogrammer i bedriftsskala. Utover denne likheten, bringer imidlertid utviklingen av ML-programmer for kanten ytterligere utfordringer. I tillegg til modellutvikling, møter teknikere de vanlige utfordringene relatert til å utvikle hovedprogrammet som kreves for å kjøre det mikrokontroller (MCU)-baserte produktet. Som et resultat, vil innføringen av ML til kanten kreve håndtering av to sammenhengende arbeidsflyter (figur 4).

Figur 4: Utvikling av et ML-basert program for kanten, utvider den typiske innebygde mikrokontroller-utviklingsarbeidsflyten med en ML-arbeidsflyt som kreves for opplæring, validering og distribusjon av en ML-modell. (Bildekilde: NXP Semiconductors)

Selv om mikrokontroller-prosjektets arbeidsflyt er kjent for integrasjonsutviklere, kan ML-prosjektet stille ytterligere krav til det mikrokontrollerbaserte programmet når utviklere jobber med å skape en optimalisert ML-inferensmodell. ML-prosjektet påvirker faktisk kravene til den integrerte enheten dramatisk. Kravene til tung databehandling og minne som vanligvis er forbundet med modelleksekvering, kan overstige ressursene til mikrokontrollerne som brukes i IoT og smarte produkter. For å redusere ressurskravene, bruker ML-eksperter teknikker som opprensking av modellnettverk (model network pruning), komprimering, kvantisering for å senke presisjonen eller til og med enkeltbits-parametere og mellomliggende verdier, samt andre metoder.

Selv med disse optimaliseringsmåtene kan imidlertid utviklere fortsatt finne konvensjonelle mikrokontrollere som mangler ytelsen som trengs for å håndtere det høye antallet matematiske operasjoner forbundet med ML-algoritmer. På den annen side kan bruken av en bruksprosessor med høy ytelse håndtere ML-databehandlingslasten, men denne tilnærmingen kan føre til økt latenstid og ikke-deterministisk respons, noe som forringer sanntidsegenskapene til den integrerte konstruksjonen.

Bortsett fra utfordringene relatert til valg av maskinvare, har leveringen av optimaliserte ML-modeller til kanten ytterligere utfordringer som er unike for integrert utvikling. Det høye antallet verktøy og metoder som er utviklet for ML-programmer i bedriftsskala, vil kanskje ikke være i stand til å skalere så godt til programmet og driftsmiljøet til integrasjonsutvikleren. Selv erfarne integrasjonsutviklere som forventer å raskt distribuere ML-baserte enheter, kan oppleve at de sliter med å finne en effektiv løsning blant et vell av tilgjengelige NN-modellarkitekturer, -verktøy, -rammeverk og -arbeidsflyter.

NXP tar for seg både maskinvareytelse og modellimplementeringsfasetter for Ml-utvikling på kanten. På maskinvarenivå oppfyller NXP sine i.MX RT1170-crossover-mikrokontrollere med høy ytelse de brede ytelseskravene til ML for kanten (edge ML). For å dra full nytte av dette maskinvarefundamentet, tilbyr NXPs eIQ (edge intelligence) ML-programvareutviklingsmiljø og programvarepakker for både uerfarne og erfarne Ml-utviklere en effektiv løsning når det gjelder å lage kantklare ML-programmer.

En effektiv plattform for utvikling av kantklare ML-programmer

NXP i.MX RT-crossover-prosessorer kombinerer sanntidsresponsen med lav latenstid fra tradisjonelle integrerte mikrokontrollere med eksekveringsmulighetene til bruksprosessorer. NXP sin i.MX RT1170-serie med crossover-prosessorer integrerer en energieffektiv Arm® Cortex®-M4-prosessor og en kraftig Arm Cortex-M7-prosessor med et omfattende sett blokkoblinger og periferiutstyr som er nødvendig for å kjøre krevende programmer, inkludert ML-baserte løsninger i integrerte enheter (figur 5).

Figur 5: NXP sine i.MX RT1170-crossover-prosessorer kombinerer de energieffektive egenskapene til konvensjonelle mikrokontrollere med den kraftige prosesseringsevnen til bruksprosessorer. (Bildekilde: NXP Semiconductors)

NXP eIQ-miljøet er fullstendig integrert i NXP sine MCUXpresso SDK- og Yocto-utviklingsmiljøer, og det er spesialkonstruert for å legge til rette for implementeringen av inferensmodeller på integrerte systemer bygget med NXP-mikroprosessorer og -mikrokontrollere. eIQ Toolkit-verktøysettet, som er inkludert i eIQ-miljøet, støtter BYOD- og BYOM-arbeidsflyter (BYOD – bring dine egne data, BYOM – bring din egen modell) gjennom flere verktøy, inkludert eIQ Portal, eIQ Model Tool og kommandolinjeverktøy (figur 6).

Figur 6: NXP eIQ Toolkit støtter BYOD-utviklere som skal lage en modell og BYOM-utviklere som skal distribuere sin egen eksisterende modell til et målsystem. (Bildekilde: NXP Semiconductors)

eIQ Portal er utformet for å støtte BYOD-arbeidsflyter for både eksperter og utviklere som ikke har erfaring med ML-modellutvikling, og gir et grafisk brukergrensesnitt (GUI) som gjør det enklere for utviklere å fullføre hvert enkelt trinn i modellutviklingsarbeidsflyten.

I den innledende fasen av utviklingen gjør eIQ Portal sitt kuratorverktøy for datasett det enklere for utviklere å importere data, innhente data fra et tilkoblet kamera eller innhente data fra en ekstern enhet (figur 7).

Figur 7: eIQ Portal sitt kuratorverktøy for datasett legger til rette for den viktige oppgaven med å forberede opplæringsdata. (Bildekilde: NXP Semiconductors)

Ved å bruke kuratorverktøyet for datasett, kan utviklere kommentere eller merke hvert element i datasettet ved å merke hele bildet eller bare spesifikke områder innenfor en spesifisert avgrensningsboks. En utvidelsesfunksjon hjelper utviklere med å gi det nødvendige mangfoldet som datasettet trenger ved å gjøre bilder uskarpe, legge til tilfeldig støy, endre egenskaper som lysstyrke eller kontrast, samt andre måter.

I den neste fasen hjelper eIQ-portalen utviklere med å velge modelltypen som passer best for programmet. For utviklere som er usikre på modelltypen, vil en veiviser for modellvalg lede dem gjennom valgprosessen basert på programtype og maskinvarefundament. Utviklere som allerede vet hvilken modelltype de trenger, kan velge en tilpasset modell som leveres med eIQ-installasjonen eller andre tilpassede implementasjoner.

eIQ Portal tar utviklere gjennom det neste kritiske opplæringstrinnet, og tilbyr et intuitivt GUI for modifisering av opplæringsparametere og visning av endringene i modellprediksjonsnøyaktighet med hvert opplæringstrinn (figur 8).

Figur 8: Utviklere bruker eIQ Portal sitt opplæringsverktøy til å observere forbedringer i opplæringsnøyaktighet med hvert trinn, og til å modifisere disse hvis det er nødvendig. (Bildekilde: NXP Semiconductors)

I neste trinn hjelper det grafiske grensesnittet til eIQ Portal utviklere med å validere modellen. I dette stadiet konverteres modellen slik at den kan kjøre på målarkitekturen for å fastsette dens faktiske ytelse. Når valideringen er fullført, viser valideringsskjermen forvirringsmatrisen – et grunnleggende ML-valideringsverktøy som gjør det mulig for utviklere å sammenligne inndataobjektets faktiske klasse med klassen som er forutsagt av modellen (Figur 9).

Figur 9: eIQ Portal sitt valideringsverktøy gir utviklere forvirringsmatrisen som resulterer fra å kjøre en modell på en målarkitektur. (Bildekilde: NXP Semiconductors)

For endelig distribusjon, gir miljøet utviklere et valg av målinferensmotorer avhengig av prosessoren, deriblant:

• Arm CMSIS-NN (Common Microcontroller Software Interface Standard, Neural Network) nevrale nettverkskjerner utviklet for å maksimere ytelsen og minimere minneformatet til nevrale nettverk på Arm Cortex-M-prosessorkjerner
• Arm NN SDK (NN SDK – neural network, software development kit), er et sett med verktøy og inferensmotor som blant annet er utviklet for å bygge bro mellom eksisterende nevrale nettverksrammeverk og Arm Cortex-A-prosessorer
• DeepViewRT – NXP sin proprietære inferensmotor for i.MX RT-crossover-mikrokontrollere
• Glow NN – basert på Meta sin Glow-kompilator (grafsenking) og optimalisert av NXP for Arm Cortex-M-kjerner ved å bruke funksjonskall til CMSIS-NN-kjerner eller Arm NN-biblioteket hvis tilgjengelig, alternativt ved å kompilere kode fra sitt eget opprinnelige bibliotek
• ONXX Runtime – Microsoft Research sitt verktøy er utviklet for å optimalisere ytelsen til Arm Cortex-A-prosessorer.
• TensorFlow Lite for mikrokontrollere – en mindre versjon av TensorFlow Lite som er optimalisert for å kjøre maskinlæringsmodeller på i.MX RT-crossover-mikrokontrollere
• TensorFlow Lite – en versjon av TensorFlow som leverer støtte for mindre systemer

For BYOM-arbeidsflyter kan utviklere bruke eIQ-modellverktøyet til å gå direkte til modellanalyse og tidsprofilering per lag. For både BYOD- og BYOM-arbeidsflyter kan utviklere bruke eIQ-kommandolinjeverktøy som gir tilgang til verktøyfunksjonalitet, samt eIQ-funksjoner som ikke er tilgjengelige direkte gjennom det grafiske brukergrensesnittet.

I tillegg til funksjonene som er beskrevet i denne artikkelen, støtter eIQ Toolkit et omfattende sett av funksjoner, deriblant modellkonvertering og -optimalisering, som ligger langt utenfor omfanget til denne artikkelen. For å oppå rask prototyping av kantklare ML-programmer, kan utviklere generelt sett bevege seg raskt gjennom utvikling og distribusjon, der det er lite behov for å bruke mange av de mer sofistikerte funksjonene i eIQ-miljøet. Spesialiserte programvarepakker (App SW – Application Software) fra NXP tilbyr komplette programmer som utviklere kan bruke til umiddelbar evaluering, eller som grunnlag for sine egne tilpassede programmer.

Slik kan modellutvikling rask evalueres ved å bruke en «App SW»-pakke

NXP App SW-pakker leverer et komplett ML-basert program, som kombinerer produksjonsklar kildekode, drivere, mellomvare og verktøy. For eksempel tilbyr NXP ML State Monitor App SW Pack en umiddelbar ML-basert løsning på det vanlige problemet med å fastsette tilstanden til komplekse systemer basert på sensorinnganger (figur 10).

Figur 10: Utviklere kan bruke NXP App Sw-pakker, for eksempel ML State Monitor App SW Pack, for umiddelbar evaluering, eller som grunnlag for egendefinert kodeutvikling. (Bildekilde: NXP Semiconductors)

ML State Monitor App SW Pack implementerer en komplett løsning for et program som har i oppgave å detektere når en vifte opererer i én av fire tilstander:

• ON (på)
• OFF (av)
• CLOGGED (tilstoppet), når viften er på, men luftstrømmen er blokkert
• FRICTION (friksjon), når viften er på, men én eller flere vifteblader opplever overflødig friksjon under drift

Noe som er like viktig for modellutviklere, er at ML State Monitor App Sw Pack inkluderer ML-modeller og et komplett datasett som representerer akselerometeravlesninger fra en vifte som kjører i hver av disse fire tilstandene.

Utviklere kan studere kode, modeller og data gitt i ML State Monitor App SW Pack for å forstå hvordan man bruker sensordataene til å trene en modell, opprette en inferensmodell og validere inferensen mot et valideringssensordatasett. NXP sin ML_State_Monitor.ipynb Jupyter Notebook som er inkludert i App SW Pack, gir faktisk et omgående bruksklart verktøy for å studere modellutviklingsarbeidsflyten i god tid før maskinvaredistribusjon.

Jupyter Notebook er en interaktiv nettleserbasert Python-eksekveringsplattform som gjør det mulig for utviklere å umiddelbart se resultatene av Python-kodeeksekvering. Å kjøre en Jupyter Notebook genererer en blokk med Python-kode, umiddelbart etterfulgt av resultatene som følger av å kjøre denne kodeblokken. Disse resultatene er ikke bare statiske visninger, men er de faktiske resultatene som oppnås ved å kjøre koden. Når utviklere for eksempel kjører NXP sin ML_State_Monitor.ipynb Jupyter Notebook, kan de umiddelbart se et sammendrag av inndatasettet (figur 11).

Figur 11: NXP sin ML_State_Monitor.ipynb Jupyter Notebook gjør det mulig for utviklere å jobbe interaktivt gjennom utviklingsarbeidsflyten for nevrale nettverksmodeller, samt vise opplæringsdata gitt i ML State Monitor App SW Pack. [Merk: Koden er avkortet her for visningsformål.] (Bildekilde: Stephen Evanczuk, kjører NXP sin ML_State_Monitor.ipynb Jupyter Notebook)

Den neste delen av koden i Notebook gir brukeren en grafisk visning av inndataene, som presenteres som separate diagrammer for tidssekvens og frekvens (figur 12).

Figur 12: Jupyter Notebook gir utviklere tidsserier og frekvensvisninger av eksempeldatasettet for viftetilstanden (OFF (av): grønn; ON (på): rød; CLOGGED (tilstoppet): blå; FRICTION (friksjon): gul). [Merk: Koden er avkortet for presentasjonsformål.] (Bildekilde: Stephen Evanczuk, kjører NXP sin ML_State_Monitor.ipynb Jupyter Notebook)

Tilleggskodeseksjoner tilbyr ytterligere dataanalyse, normalisering, forming og annen forberedelse helt til kodeutførelsen når samme funksjonsdefinisjon for modellopprettelse, model_create(), vist tidligere i liste 1. Den neste kodedelen eksekverer denne «model_create()»-funksjonen og skriver ut et sammendrag for rask validering (figur 13).

Figur 13: NXP sin ML_State_Monitor.ipynb Jupyter Notebook oppretter modellen (vist i liste 1) og viser modellens sammendragsinformasjon. (Bildekilde: Stephen Evanczuk, kjører NXP sin ML_State_Monitor.ipynb Jupyter Notebook)

Etterfulgt av en kodeseksjon for modellopplæring og evaluering, viser ML_State_Monitor.ipynb Jupyter Notebook hver forvirringsmatrise for hele datasettet, opplæringsdatasettet og valideringsdatasettet (en delseksjon av datasettet som er ekskludert fra opplæringsdatasettet). I dette tilfellet vil forvirringsmatrisen for det komplette datasettet vise god nøyaktighet med et visst antall feil, spesielt der modellen forveksler en liten prosentandel av datasettene som å være i ON-tilstand når de faktisk er i CLOGGED-tilstand, i henhold til merknaden i det opprinnelige datasettet (figur 14).

Figur 14: Utviklere kan se forvirringsmatriser som denne for hele datasettet. (Bildekilde: Stephen Evanczuk, kjører NXP sin ML_State_Monitor.ipynb Jupyter Notebook)

I en senere kodeseksjon eksporteres modellen til flere forskjellige modelltyper og -formater som brukes av de forskjellige inferensmotorene som støttes av eIQ-utviklingsmiljøet (figur 15).

Figur 15: NXP sin ML_State_Monitor.ipynb Jupyter Notebook demonstrerer hvordan utviklere kan lagre sin trente modell i flere forskjellige modelltyper og -formater. (Bildekilde: Stephen Evanczuk, kjører NXP sin ML_State_Monitor.ipynb Jupyter Notebook)

Valget av inferensmotor kan være svært viktig når det gjelder å oppfylle spesifikke ytelseskrav. For dette bruksområdet målte NXP modellstørrelse, kodestørrelse og inferenstid (tiden som kreves for å fullføre inferens på ett enkelt inndataobjekt) når modellens mål er flere inferensmotorer, en som kjører på 996 megahertz (MHz) og en som kjører på 156 MHz (figur 16 og 17).

Figur 16: Valg av modelltype kan ha dramatisk innvirkning på modellstørrelsen, selv om de dramatiske forskjellene som vises her ikke nødvendigvis gjelder for større modeller. (Bildekilde: NXP Semiconductors)

Figur 17: Inferenstid kan avvike betydelig for evaluering av et inndataobjekt når det lastes fra RAM-minne eller flashminne, eller når prosessoren brukes med en høyere frekvens på 996 MHz kontra 156 MHz. (Bildekilde: NXP Semiconductors)

I henhold til det NXP bemerker, bruker dette eksempelprogrammet en svært liten modell, så de ganske store forskjellene som vises i disse tallene kan være vesentlig mindre i en større modell som brukes for komplekse klassifiseringer.

Bygge en systemløsning for tilstandsovervåking

I tillegg til Jupyter Notebook for interaktiv utforskning av modellutviklingsarbeidsflyten, tilbyr NXP ML State Monitoring App SW Pack komplett kildekode for implementering av designen på NXP sitt MIMXRT1170-EVK-evalueringskort. Evalueringskortet er bygget rundt NXP MIMXRT1176DVMAA-crossover-mikrokontrolleren, og det gir en omfattende maskinvareplattform, komplett med ekstra minne og flere grensesnitt (figur 18).

Figur 18: NXP sitt MIMXRT1170-EVK-evalueringskort gir en omfattende maskinvareplattform for utvikling av programmer basert på NXP i.MX RT1170-serien med crossover-mikrokontrollere. (Bildekilde: NXP Semiconductors)

Utviklere kan bruke NXP sitt program for viftetilstand til å forutsi tilstanden til en vifte ved å kombinere MIMXRT1170-EVK-evalueringskortet med et valgfritt NXP FRDM-STBC-AGM01-sensorkort, et Arduino-skjold og en egnet børsteløs DC-vifte på 5 volt, for eksempel Adafruit sin 4468 (Figur 19).

Figur 19: Utviklere kan teste NXP-eksempelprogrammet for viftetilstand med en enkel stakk bygget på MIMXRT1170-EVK-evalueringskortet. (Bildekilde: NXP Semiconductors)

Ved å bruke MCUXpresso, et integrert utviklingsmiljø (IDE – integrated development environment), kan utviklere konfigurere programmet til å enkelt innhente og lagre viftestatusdata, eller umiddelbart kjøre inferens på de innhentede dataene ved hjelp av en TensorFlow-inferensmotor, DeepViewRT-inferensmotor eller Glow-inferensmotor (liste 2).

Kopi
/* Action to be performed */
#define SENSOR_COLLECT_LOG_EXT                  1   // Collect and log data externally
#define SENSOR_COLLECT_RUN_INFERENCE            2   // Collect data and run inference
 
/* Inference engine to be used */
#define SENSOR_COLLECT_INFENG_TENSORFLOW        1   // TensorFlow
#define SENSOR_COLLECT_INFENG_DEEPVIEWRT        2   // DeepViewRT
#define SENSOR_COLLECT_INFENG_GLOW              3   // Glow
 
/* Data format to be used to feed the model */
#define SENSOR_COLLECT_DATA_FORMAT_BLOCKS       1   // Blocks of samples
#define SENSOR_COLLECT_DATA_FORMAT_INTERLEAVED  2   // Interleaved samples
 
 
/* Parameters to be configured by the user: */
/* Configure the action to be performed */
#define SENSOR_COLLECT_ACTION                   SENSOR_COLLECT_RUN_INFERENCE
 
#if SENSOR_COLLECT_ACTION == SENSOR_COLLECT_LOG_EXT
/* If the SD card log is not enabled the sensor data will be streamed to the terminal */
#define SENSOR_COLLECT_LOG_EXT_SDCARD           1   // Redirect the log to SD card, otherwise print to console

Liste 2: Utviklere kan enkelt konfigurere NXP ML State Monitor-eksempelprogrammet ved å endre definisjonene som er inkludert i header-filen sensor_collect.h. (Bildekilde: NXP Semiconductors)

Programmet kjører med en ukomplisert prosessflyt. Hovedrutinen i main.c oppretter en oppgave kalt MainTask, som er en rutine som ligger i modulen sensor_collect.c.

Kopi
void MainTask(void *pvParameters)
{
    status_t status = kStatus_Success;
 
    printf("MainTask started\r\n");
 
#if !SENSOR_FEED_VALIDATION_DATA
    status = SENSOR_Init();
    if (status != kStatus_Success)
    {
        goto main_task_exit;
    }
#endif
 
    g_sensorCollectQueue = xQueueCreate(SENSOR_COLLECT_QUEUE_ITEMS, sizeof(sensor_data_t));
    if (NULL == g_sensorCollectQueue)
    {
        printf("collect queue create failed!\r\n");
        status = kStatus_Fail;
        goto main_task_exit;
    }
 
#if SENSOR_COLLECT_ACTION == SENSOR_COLLECT_LOG_EXT
    uint8_t captClassLabelIdx;
    CAPT_Init(&captClassLabelIdx, &g_SensorCollectDuration_us, &g_SensorCollectDuration_samples);
    g_SensorCollectLabel = labels[captClassLabelIdx];
 
    if (xTaskCreate(SENSOR_Collect_LogExt_Task, "SENSOR_Collect_LogExt_Task", 4096, NULL, configMAX_PRIORITIES - 1, NULL) != pdPASS)
    {
        printf("SENSOR_Collect_LogExt_Task creation failed!\r\n");
        status = kStatus_Fail;
        goto main_task_exit;
    }
#elif SENSOR_COLLECT_ACTION == SENSOR_COLLECT_RUN_INFERENCE
    if (xTaskCreate(SENSOR_Collect_RunInf_Task, "SENSOR_Collect_RunInf_Task", 4096, NULL, configMAX_PRIORITIES - 1, NULL) != pdPASS)
    {
        printf("SENSOR_Collect_RunInf_Task creation failed!\r\n");
        status = kStatus_Fail;
        goto main_task_exit;
    }
#endif

Liste 3: I NXP ML State Monitor-eksempelprogrammet, vekker MainTask en underoppgave for å innhente data eller kjøre inferens. (Bildekilde: NXP Semiconductors)

MainTask utfører forskjellige initialiseringsoppgaver før en av to underoppgaver kjører, avhengig av definisjonene som er angitt av brukeren i sensor_collect.h:

• Hvis SENSOR_COLLECT_ACTION er satt til SENSOR_COLLECT_LOG_EXT, starter MainTask underoppgaven SENSOR_Collect_LogExt_Task(), som samler inn data og lagrer det på SD-kortet, hvis konfigurert
• Hvis SENSOR_COLLECT_ACTION er satt til SENSOR_COLLECT_RUN_INFERENCE, starter MainTask underoppgaven SENSOR_Collect_RunInf_Task(), som kjører inferensmotoren (Glow, DeepViewRT eller TensorFlow) definert i sensor_collect.h mot de innsamlede dataene, og hvis SENSOR_EVALUATE_MODEL er definert, vil den resulterende ytelses- og klassifiseringsforutsigelsen vises

Kopi
if SENSOR_COLLECT_ACTION == SENSOR_COLLECT_LOG_EXT
void SENSOR_Collect_LogExt_Task(void *pvParameters)
{
[code deleted for simplicity]
    while (1)
    {
[code deleted for simplicity]
            bufSizeLog = snprintf(buf, bufSize, "%s,%ld,%d,%d,%d,%d,%d,%d,%d\r\n", g_SensorCollectLabel, (uint32_t)(sensorData.ts_us/1000),
                    sensorData.rawDataSensor.accel[0], sensorData.rawDataSensor.accel[1], sensorData.rawDataSensor.accel[2],
                    sensorData.rawDataSensor.mag[0], sensorData.rawDataSensor.mag[1], sensorData.rawDataSensor.mag[2],
                    sensorData.temperature);
 
#if SENSOR_COLLECT_LOG_EXT_SDCARD
                SDCARD_CaptureData(sensorData.ts_us, sensorData.sampleNum, g_SensorCollectDuration_samples, buf, bufSizeLog);
#else
                printf("%.*s", bufSizeLog, buf);
[code deleted for simplicity]
    }
 
    vTaskDelete(NULL);
}
#elif SENSOR_COLLECT_ACTION == SENSOR_COLLECT_RUN_INFERENCE
[code deleted for simplicity]
 
void SENSOR_Collect_RunInf_Task(void *pvParameters)
{
[code deleted for simplicity]
    while (1)
    {
[code deleted for simplicity]
                /* Run Inference */
                tinf_us = 0;
                SNS_MODEL_RunInference((void*)g_clsfInputData, sizeof(g_clsfInputData), (int8_t*)&predClass, &tinf_us, SENSOR_COLLECT_INFENG_VERBOSE_EN);
 
[code deleted for simplicity]
#if SENSOR_EVALUATE_MODEL
                /* Evaluate performance */
                validation.predCount++;
                if (validation.classTarget == predClass)
                {
                    validation.predCountOk++;
                }
                PRINTF("\rInference %d?%d | t %ld us | count: %d/%d/%d | %s      ",
                       validation.classTarget, predClass, tinf_us, validation.predCountOk,
                       validation.predCount, validation.predSize, labels[predClass]);
 
                tinfTotal_us += tinf_us;
                if (validation.predCount >= validation.predSize)
                {
                    printf("\r\nPrediction Accuracy for class %s %.2f%%\r\n", labels[validation.classTarget],
                            (float)(validation.predCountOk * 100)/validation.predCount);
                    printf("Average Inference Time %.1f (us)\r\n", (float)tinfTotal_us/validation.predCount);
                    tinfTotal_us = 0;
                }
#endif
 
    }
 
exit_task:
    vTaskDelete(NULL);
}
#endif  /* SENSOR_COLLECT_ACTION */

Liste 4: NXP-eksempelprogrammet ML State Monitor demonstrerer det grunnleggende designmønsteret for å innhente sensordata og kjøre den valgte inferensmotoren på de innhentede dataene. (Bildekilde: NXP Semiconductors)

Fordi NXP ML State Monitor App SW Pack leverer full kildekode samt et komplett sett av nødvendige drivere og mellomvare, kan utviklere enkelt utvide programmet ved å legge til funksjoner eller bruke det som utgangspunkt for sin egen tilpassede utvikling.

Konklusjon

Implementering av ML på kanten i smarte produkter i tingenes Internett (IoT) og andre bruksområder kan gi et kraftig sett med funksjoner, men har ofte resultert i utviklere som sliter med å bruke ML-verktøy og -metoder som er utviklet for programmer i bedriftsskala. Både ML-eksperter og -utviklere med liten eller ingen Ml-erfaring kan, takket være tilgjengeligheten av en NXP-utviklingsplattform som omfatter crossover-prosessorer og spesialisert modellutviklingsprogramvare, mer effektivt lage ML-programmer som er utviklet spesielt for å oppfylle kravene til effektiv kantytelse.