Hur man snabbt kan distribuera tillämpningar med maskininlärning för molnkanten

Av Stephen Evanczuk

Bidraget med av DigiKeys nordamerikanska redaktörer

Maskininlärning (ML) har en enorm potential för att skapa smarta produkter, men komplexiteten och utmaningarna med modellering av neurala nätverk (NN) och skapandet av tillämpningar för maskininlärning för molnkanten har begränsat utvecklarnas förmåga att snabbt leverera användbara lösningar. Även om lätt tillgängliga verktyg har gjort skapandet av modeller för ML mer lättillgängliga i allmänhet, är konventionella utvecklingsmetoder för ML inte utformade för att uppfylla de unika kraven i lösningar för sakernas internet (IoT), bilar, industrisystem och andra inbyggda tillämpningar.

Artikeln ger en kort introduktion till NN-modellering. Därefter presenteras och beskrivs hur man använder en omfattande plattform för ML från NXP Semiconductors som gör det möjligt för utvecklare att på ett effektivare sätt leverera tillämpningar med ML för molnkanten.

En snabb genomgång av NN-modellering

Algoritmer för ML förser utvecklare med ett helt annat alternativ för utveckling av tillämpningar. I stället för att skriva programkod som uttryckligen ska lösa problem som t.ex. bildklassificering tränar utvecklare NN-modeller genom att presentera en uppsättning data, t.ex. bilder som är kommenterade med det faktiska namnet (eller klassen) på den företeelse som syns på bilden. I träningsprocessen används olika metoder för att beräkna modellens parametrar för viktning och bias-värden för varje neuron respektive lager, vilket gör det möjligt för modellen att ge en någorlunda exakt förutsägelse av den korrekta klassen för en inmatad bild (figur 1).

Bild på NN-modeller såsom detta helt anslutna nätverk när det klassificerar ett inmatat objekt (klicka för att förstora).Figur 1: NN-modeller såsom detta helt anslutna nätverk när det klassificerar ett inmatat objekt med hjälp av viktnings- och bias-parametrar som fastställts under inlärningen. (Bildkälla: NXP Semiconductors)

Forskare inom ML har utvecklat ett brett utbud av NN-arkitekturer utöver den generiska helt anslutna NN som visas i figur 1. Exempelvis använder tillämpningar för bildklassificering vanligtvis CNN (convolutional NNN), en specialiserad arkitektur som delar upp bildigenkänning i en inledande fas som hittar viktiga egenskaper hos en bild, följt av en klassificeringsfas som förutspår sannolikheten för att bilden tillhör en av flera klasser som fastställts under inlärningen (figur 2).

Diagram över ett CNN (Convolutional Neural Network) (klicka för att förstora)Figur 2: Experter inom ML använder specialiserade NN-arkitekturer, t.ex. detta CNN-nätverk (convolutional neural network), för specifika uppgifter som bildigenkänning. (Bildkälla: NXP Semiconductors)

Även om valet av en lämplig modellarkitektur och inlärningsprogram har varit begränsat till experter inom ML, har tillgången till flera verktyg med öppen källkod och kommersiella verktyg förenklat modellutvecklingen dramatiskt för storskalig användning. Idag kan utvecklare definiera modeller med några få rader kod (lista 1) och använda verktyg som den öppna källkodsmodellen Netron för att generera en grafisk representation av modellen (figur 3) för att kontrollera varje lagers definition och anslutningsmöjligheter.

Kopiera
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

Lista 1: Utvecklare kan definiera NN-modeller med bara några få rader kod. (Kodkälla: NXP Semiconductors)

Bild på den grafiska representationen av den modell som definieras i lista 1 (klicka för att förstora).Figur 3: Den här grafiska representationen av den modell som definieras i listag 1, som genereras av Netron-viewer, kan hjälpa utvecklaren att dokumentera varje lagers funktion och anslutningsmöjligheter. (Bildkälla: Stephen Evanczuk, kör Netron på NXP-modellen med källkod i lista 1)

För slutgiltiga leverans, tar andra verktyg bort de modellstrukturer som endast behövs under inlärningen och utför andra optimeringar för att skapa en effektiv inferensmodell.

Varför det har varit så svårt att utveckla tillämpningar baserade på ML för smarta produkter

Att definiera och träna en modell för sakernas internet eller andra smarta produkter följer ett liknande arbetsflöde som att skapa en modell för tillämpningar för maskininlärning i företagsskala. Utöver denna likhet innebär utvecklingen av tillämpningar med ML för molnkanten flera ytterligare utmaningar. Vid sidan av modellutvecklingen står konstruktörer inför de välkända utmaningarna att utveckla den huvudsakliga tillämpningen som krävs för att köra deras mikrokontrollerbaserade produkt. För att få ML till molnkanten krävs det därför att man hanterar två sammanhängande arbetsflöden (figur 4).

Figur 4: Utveckling av en tillämpning baserad på ML för molnkanten utökar det typiska arbetsflödet för utveckling av inbyggda MCU:er med ett arbetsflöde för ML som krävs för att träna, validera och distribuera en ML-modell. (Bildkälla: NXP Semiconductors)

Även om MCU-projektets arbetsflöde är bekant för utvecklare av inbyggda system kan ML-projektet ställa ytterligare krav på den MCU-baserade tillämpningen när utvecklarna arbetar för att skapa en optimerad ML-inferensmodell. Faktum är, att ML-projektet har en drastisk inverkan på kraven på den inbyggda enheten. Den tunga beräkningsbelastningen och minneskraven som vanligtvis är förknippade med modellkörning kan överskrida resurserna i de mikrokontroller som används i sakernas internet och smarta produkter. För att minska resurskraven tillämpar experter inom ML olika tekniker som modellnätverkssortering, komprimering, kvantisering till lägre precision, eller till och med parametrar och mellanvärden på en bit, och andra metoder.

Även med dessa optimeringsmetoder kan utvecklare dock konstatera att konventionella mikrokontroller inte har den prestanda som krävs för att hantera det stora antal matematiska operationer som är förknippade med ML-algoritmer. Å andra sidan skulle en högeffektiv tillämpningsprocessor kunna hantera beräkningsbelastningen för ML, men det tillvägagångssättet kan leda till ökad latens och icke-deterministiska svar, vilket försämrar realtidsegenskaperna i deras inbyggda konstruktion.

Förutom utmaningarna med hårdvaruvalet har leverans av optimerade ML-modeller för molnkanten ytterligare utmaningar som är unika för inbyggd utveckling. Det stora antalet verktyg och metoder som utvecklats för ML-tillämpningar i företagsskala kanske inte är lika skalbara för inbyggda utvecklares tillämpningar och driftsmiljöer. Även erfarna utvecklare av inbyggda system som förväntar sig att snabbt kunna använda ML-baserade enheter kan få svårt att hitta en effektiv lösning bland en mängd tillgängliga NN-modellarkitekturer, verktyg, ramverk och arbetsflöden.

NXP hanterar både hårdvaruprestanda och modellimplementering i samband med utveckling av ML i molnkanten. På hårdvarunivå uppfyller den högeffektiva Crossover-mikrokontrollern i.MX RT1170 från NXP de omfattande prestandakraven för ML i molnkanten. För att dra full nytta av denna hårdvarubas finns programvaruutvecklingsmiljön eIQ (edge intelligence) för ML från NXP och programvarupaket som ger både oerfarna och erfarna utvecklare av ML en effektiv lösning för att skapa tillämpningar med ML för molnkanten.

En effektiv plattform för utveckling av avancerade ML-tillämpningar

Crossover-processorerna NXP i.MX RT kombinerar realtidsresponsen med låg latens hos traditionella inbyggda mikrokontroller med exekveringskapaciteten hos högeffektiva tillämpningsprocessorer. Processorserien i.MX RT1170 från NXP integrerar en strömsnål Arm® Cortex®-M4-processor och en högeffektiv Arm Cortex-M7-processor med en omfattande uppsättning funktionsblock och kringutrustning som behövs för att köra krävande tillämpningar, inklusive lösningar baserade på ML i inbäddade enheter (figur 5).

Figur 5: Crossover-processorerna i.MX RT1170 från NXP kombinerar den strömsnåla kapaciteten hos konventionella mikrokontroller med den högeffektiva bearbetningskapaciteten hos tillämpningsprocessorer. (Bildkälla: NXP Semiconductors)

Miljön eIQ från NXP är helt integrerad i utvecklingsmiljöerna MCUXpresso SDK och Yocto från NXP och är särskilt utformad för att underlätta implementering av inferensmodeller i inbyggda system som byggs med mikroprocessorer och mikrokontroller från NXP. eIQ Toolkit ingår i miljön eIQ och stöder arbetsflöden för att ta med egna data (BYOD) och egna modeller (BYOM) med hjälp av flera verktyg, inklusive eIQ Portal, eIQ Model Tool och kommandoradsverktyg (figur 6).

Figur 6: NXP eIQ Toolkit stöder BYOD-utvecklare som behöver skapa en modell och BYOM-utvecklare som behöver distribuera sin egen befintliga modell till ett målsystem. (Bildkälla: NXP Semiconductors)

Portalen eIQ är utformad för att stödja BYOD-arbetsflöden för både experter och utvecklare som är nya inom utveckling av ML-modeller och har ett grafiskt användargränssnitt (GUI) som hjälper utvecklare att lättare slutföra varje steg i arbetsflödet för modellutvecklingen.

I det inledande utvecklingsskedet gör eIQ-portalens verktyg för hantering av datauppsättningar det lättare för utvecklare att importera data, hämta data från en ansluten kamera eller hämta data från en fjärrenhet (figur 7).

Figur 7: eIQ-portalens verktyg för att hantera datauppsättningar underlättar den kritiska uppgiften att förbereda inlärningsdata. (Bildkälla: NXP Semiconductors)

Med hjälp av hanteringsverktyget för datauppsättningar kan utvecklare kommentera eller märka varje objekt i datauppsättningen genom att märka hela bilden eller bara specifika områden som finns inom en specificerad avgränsningsruta. En förstärkningsfunktion gör det lättare för utvecklare att ge datauppsättningen den mångfald som krävs genom att göra bilder oskarpa, lägga till slumpmässiga störningar, ändra egenskaper som ljusstyrka eller kontrast och andra metoder.

I nästa fas gör eIQ-portalen det lättare för utvecklare att välja den typ av modell som är bäst lämpad för tillämpningen. För utvecklare som är osäkra på vilken typ av modell de ska välja finns en modellvalsguide som hjälper utvecklarna genom urvalsprocessen baserat på typ av applikation och hårdvarubas. Utvecklare som redan vet vilken typ av modell de behöver kan välja en anpassad modell som tillhandahålls med eIQ-installationen eller andra anpassade implementationer.

Portalen eIQ tar utvecklarna genom nästa kritiska inlärningssteg och erbjuder ett intuitivt gränssnitt för att ändra inlärningsparametrar och visa förändringarna i modellens noggrannhet vid förutsägelser för varje inlärningssteg (Figur 8).

Figur 8: Utvecklare använder eIQ-portalens inlärningsverktyg för att se hur inlärningsnoggrannheten förbättras i varje steg och för att ändra dem vid behov. (Bildkälla: NXP Semiconductors)

I nästa steg hjälper eIQ-portalens grafiska användargränssnitt utvecklare att validera modellen. I detta skede konverteras modellen för att köras på målarkitekturen för att fastställa dess faktiska prestanda. När valideringen är klar visar valideringsskärmen förvirringsmatrisen - ett grundläggande valideringsverktyg för ML som gör det möjligt för utvecklare att jämföra de inmatade objektens faktiska klass med den klass som modellen förutspår (figur 9).

Figur 9: Valideringsverktyget i eIQ-portalen förser utvecklare med den förvirringsmatris som uppstår när en modell körs på en målarkitektur. (Bildkälla: NXP Semiconductors)

För den slutliga installationen ger miljön utvecklarna möjlighet att välja mellan olika målinferensmotorer beroende på bland annat, processor:

  • Arm CMSIS-NN (Common Microcontroller Software Interface Standard, Neural Network) - kärnor för neurala nätverk som utvecklats för att maximera prestandan och minimera minnesavtrycket för neurala nätverk på Arm Cortex-M-processorkärnor.
  • Arm NN SDK (neural network, software development kit) - en uppsättning verktyg och en inferensmotor som utformats för att skapa en brygga mellan befintliga ramverk för neurala nätverk och Arm Cortex-A-processorer, bland andra.
  • DeepViewRT – NXP:s egenutvecklade inferensmotor för i.MX RT crossover MCU:er
  • Glow NN – Baserad på Metas kompilator Glow (grafsänkning) och optimerad av NXP för Arm Cortex-M-kärnor genom att använda funktionsanrop till CMSIS-NN-kärnor eller Arm NN-biblioteket om det finns tillgängligt, annars genom att kompilera kod från det egna inhemska biblioteket.
  • ONXX Runtime – Verktyg fråm Microsoft Research som är utformade för att optimera prestandan för Arm Cortex-A-processorer.
  • TensorFlow Lite for Microcontrollers – en mindre version av TensorFlow Lite, optimerad för att köra modeller för maskininlärning på i.MX RT crossover MCU:er.
  • TensorFlow Lite – en version av TensorFlow med stöd för mindre system.

För arbetsflöden med BYOM kan utvecklare använda eIQ Model Tool för att gå direkt till modellanalys och tidsprofilering per lager. För arbetsflöden med både BYOD och BYOM kan utvecklare använda eIQ:s kommandoradsverktyg som ger tillgång till verktygens funktionalitet och eIQ-funktioner som inte är tillgängliga direkt via det grafiska användargränssnittet.

Förutom de funktioner som beskrivs i artikeln har eIQ Toolkit stöd för en omfattande uppsättning funktioner, inklusive modellkonvertering och optimering som ligger långt utanför den här artikelns omfång. För snabb prototypframställning av avancerade tillämpningar med ML kan utvecklare dock i allmänhet snabbt gå igenom utveckling och driftsättning utan att behöva använda många av de mer sofistikerade funktionerna i eIQ-miljön. Specialiserade programvarupaket (App SW) från NXP erbjuder kompletta program som utvecklare kan använda för omedelbar utvärdering eller som grund för sina egna anpassade program.

Hur man snabbt utvärderar modellutvecklingen med hjälp av ett App SW Pack

App SW Packs från NXP tillhandahåller en komplett tillämpning baserad på ML som kombinerar produktionsklar källkod, drivrutiner, middleware och verktyg. Som exempel finns ML State Monitor App SW Pack från NXP, en omedelbar lösning baserad på ML för det ofta förekommande problemet med att bestämma tillståndet i komplicerade system baserat på indata från givare (figur 10).

Figur 10: Utvecklare kan använda NXP App SW Packs som ML State Monitor App SW Pack för omedelbar utvärdering eller som grund för utveckling av egen kod. (Bildkälla: NXP Semiconductors)

ML State Monitor App SW Pack är en komplett lösning för en tillämpning som är avsedd att upptäcka när en fläkt arbetar i något av fyra lägen:

  • AV
  • IGENSATT, när fläkten är på men luftflödet är hindrat.
  • FRIKTION, när fläkten är på men ett eller flera fläktblad utsätts för överdriven friktion under drift.

Lika viktigt för modellutvecklare är att ML State Monitor App SW Pack innehåller ML-modeller samt en komplett datauppsättning som representerar accelerometeravläsningar från en fläkt som arbetar i vart och ett av de fyra lägena.

Utvecklare kan studera kod, modeller och data som tillhandahålls i ML State Monitor App SW Pack för att förstå hur man använder data från givare för att träna en modell, skapa en inferensmodell och validera inferensen mot en validerad uppsättning givardata. Faktum är att NXP:s Jupyter Notebook ML_State_Monitor.ipynb, som ingår i App SW Pack, är ett omedelbart verktyg för att studera arbetsflödet för modellutveckling långt före någon hårdvaruinstallation.

Jupyter Notebook är en interaktiv webbläsarbaserad plattform för körning av Python som gör det möjligt för utvecklare att omedelbart se resultaten av utförandet av Python-kod. När du kör en Jupyter Notebook genereras ett block av Python-kod, dirket följt av resultaten av körningen av detta kodblock. Resultatet är inte bara statiska visningar utan de faktiska resultat som erhålls genom att köra koden. När utvecklare exempelvis kör Jupyter Notebook ML_State_Monitor.ipynb från NXP kan de omedelbart se en sammanfattning av den inmatade datauppsättningen (figur 11).

Figur 11: ML_State_Monitor.ipynb Jupyter Notebook från NXP låter utvecklare arbeta interaktivt genom arbetsflödet för utveckling av neurala nätverksmodeller och visa inlärningdata som tillhandahålls i ML State Monitor App SW Pack. [Observera: Koden är förkortad här för visningsändamål.] (Bildkälla: Stephen Evanczuk, som kör ML_State_Monitor.ipynb Jupyter Notebook från NXP)

Nästa avsnitt av koden i Notebook ger användaren en grafisk visning av indata, presenterad som separata diagram för tidssekvens och frekvens (figur 12).

Figur 12: Jupyter Notebook ger utvecklare tidsserier och frekvensvisningar av provdatauppsättningen för fläktlägen (AV: grönt; PÅ: rött; IGENSATT: blått; FRIKTION: gult). [Observera: Koden är förkortad för visningsändamål.] (Bildkälla: Stephen Evanczuk, som kör ML_State_Monitor.ipynb Jupyter Notebook från NXP)

Övriga kodavsnitt tillhandahåller ytterligare dataanalys, normalisering, formning och andra förberedelser tills koden når samma definition av funktionen för skapande av modellen, model_create(), som visats tidigare i lista 1. I nästa kodavsnitt utförs funktionen model_create() och en sammanfattning skrivs ut för snabb validering (figur 13).

Figur 13: NXP:s ML_State_Monitor.ipynb Jupyter Notebook skapar modellen (som visas i lista 1) och visar sammanfattad information om modellen. (Bildkälla: Stephen Evanczuk, som kör ML_State_Monitor.ipynb Jupyter Notebook från NXP)

Efter ett avsnitt med kod för modellinlärning och utvärdering visar Jupyter Notebook ML_State_Monitor.ipynb Jupyter Notebook varje förvirringsmatris för hela datauppsättningen, träningsdatauppsättningen och valideringsdatauppsättningen (en delmängd av datauppsättningen som uteslutits från träningsdatauppsättningen). I det här fallet visar förväxlingsmatrisen för hela datauppsättningen en god noggrannhet med vissa fel, framför allt när modellen förväxlar en liten procentandel av datauppsättningen med att de är påslagna när de egentligen är i läget IGENSATT, som noterats i den ursprungliga datauppsättningen (figur 14).

Figur 14: Utvecklare kan visa förvirringsmatriser som denna för hela datauppsättningen. (Bildkälla: Stephen Evanczuk, som kör ML_State_Monitor.ipynb Jupyter Notebook från NXP)

I ett senare kodavsnitt exporteras modellen till flera olika modelltyper och format som används av de olika inferensmotorer som stöds av utvecklingsmiljön eIQ (figur 15).

Figur 15: NXP:s ML_State_Monitor.ipynb Jupyter Notebook visar hur utvecklare kan spara sin tränade modell i flera olika modelltyper och format. (Bildkälla: Stephen Evanczuk, som kör ML_State_Monitor.ipynb Jupyter Notebook från NXP)

Valet av inferensmotor kan vara av avgörande betydelse för att uppfylla specifika prestandakrav. I den här tillämpningen mätte NXP modellstorlek, kodstorlek och inferenstid (tid som krävs för att slutföra inferensen för ett enda inmatat objekt) när modellen är riktad till flera inferensmotorer, en som körs på 996 MHz och en som körs på 156 MHz (figurerna 16 och 17).

Figur 16: Valet av modelltyp kan ha en drastisk inverkan på modellens storlek, även om de drastiska skillnaderna som visas här kanske inte gäller för större modeller. (Bildkälla: NXP Semiconductors)

Figur 17: Inferenstiden kan skilja sig avsevärt vid utvärdering av ett inmatat objekt när det läses in från RAM eller flash-minne, eller när processorn drivs med en högre frekvens på 996 MHz jämfört med 156 MHz. (Bildkälla: NXP Semiconductors)

Som NXP påpekar används en mycket liten modell i denna exempeltillämpning, så de ganska starka skillnaderna som visas i dessa figurer kan vara betydligt mindre uttalade i en större modell som används för komplicerade klassificeringar.

Uppbyggnad av en systemlösning för övervakning av tillstånd

Förutom Jupyter Notebook för interaktiv utforskning av arbetsflödet för modellutveckling innehåller NXP ML State Monitoring App SW Pack fullständig källkod för att implementera konstruktionen på utvärderingskortet MIMXRT1170-EVK från NXP. Utvärderingskortet bygger på crossover-MCU:n MIMXRT1176DVMAA från NXP och tillhandahåller en omfattande hårdvaruplattform, komplett med extra minne och flera gränssnitt (figur 18).

Figur 18: Utvärderingskortet MIMXRT1170-EVK från NXP är en omfattande hårdvaruplattform för utveckling av tillämpningar baserade på Crossover-MCU i serien i.MX RT1170 från NXP. (Bildkälla: NXP Semiconductors)

Utvecklare kan använda programmet för fläkttillstånd från NXP för att förutsäga läget hos en fläkt genom att stapla utvärderingskortet MIMXRT1170-EVK med ett valfritt FRDM-STBC-AGM01-givarkort från NXP, ett tilläggskort för Arduino och en lämplig borstlös likspänningsfläkt för 5 V, t.ex. 4468 från Adafruit (figur 19).

Figur 19: Utvecklare kan testa exempelprogrammet för fläkttillstånd från NXP med en enkel stack som byggs på utvärderingskortet MIMXRT1170-EVK. (Bildkälla: NXP Semiconductors)

Med hjälp av den integrerade utvecklingsmiljön (IDE) i MCUXpresso kan utvecklare konfigurera programmet för att helt enkelt samla in och lagra data om fläkttillstånd eller omedelbart köra inferens på de insamlade uppgifterna med hjälp av en TensorFlow-inferensmotor, DeepViewRT-inferensmotor eller Glow-inferensmotor (lista 2).

Kopiera
/* 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

Lista 2: Utvecklare kan enkelt konfigurera exempelprogrammet NXP ML State Monitor genom att ändra de definitioner som ingår i header-filensensor_collect.h. (Kodkälla: NXP Semiconductors)

Programmet arbetar med ett enkelt processflöde. Huvudrutinen i main.c skapar en uppgift som heter MainTask, som är en rutin som finns i modulen sensor_collect.c.

Kopiera
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

Lista 3: I exempelprogrammet NXP ML State Monitor anropar MainTask en underordnad uppgift för att samla in data eller köra inferenser. (Kodkälla: NXP Semiconductors)

MainTask utför olika initialiseringsuppgifter innan den startar en av två underordnade uppgifter, beroende på de definitioner som användaren har angett i sensor_collect.h:

  • Om SENSOR_COLLECT_ACTION är inställd på SENSOR_COLLECT_LOG_EXT startar MainTask den underordnade uppgiften SENSOR_Collect_LogExt_Task(), som samlar in data och lagrar dessa på SD-kortet om det är konfigurerat.
  • Om SENSOR_COLLECT_ACTION är inställd på SENSOR_COLLECT_RUN_INFERENCE startar MainTask den underordnade uppgiften SENSOR_Collect_RunInf_Task(), som kör den inferensmotor (Glow, DeepViewRT eller TensorFlow) som definierats i sensor_collect.h mot de insamlade uppgifterna, och om SENSOR_EVALUATE_MODEL är definierad, visas den resulterande prestandan och klassificeringsprognosen.
Kopiera
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 */

Lista 4: Exempelprogrammet NXP ML State Monitor visar det grundläggande designmönstret för att samla in givardata och köra den valda inferensmotorn på insamlad data. (Kodkälla: NXP Semiconductors)

Eftersom NXP ML State Monitor App SW Pack tillhandahåller fullständig källkod tillsammans med en komplett uppsättning nödvändiga drivrutiner och middleware kan utvecklare enkelt utöka tillämpningen för att lägga till funktioner eller använda dessa som utgångspunkt för egen utveckling.

Sammanfatttning

Att implementera ML i molnkanten i smarta produkter för IoT och andra tillämpningar kan ge kraftfulla funktioner, men ofta har utvecklare haft svårt att tillämpa verktyg och metoder för ML som utvecklats för tillämpningar i företagsskala. Med tillgång till en utvecklingsplattform från NXP med crossover-processorer och specialiserad programvara för modellutveckling kan både experter inom ML och utvecklare med liten eller ingen erfarenhet av ML, på ett effektivare sätt skapa ML-tillämpningar som är utformade specifikt för att uppfylla kraven på effektiv prestanda i molnkanten.

DigiKey logo

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of DigiKey or official policies of DigiKey.

Om skribenten

Image of Stephen Evanczuk

Stephen Evanczuk

Stephen Evanczuk har arbetat i mer än 20 år med att skriva för och om elektronikbranschen inom många olika områden som maskinvara, programvara, system och applikationer – inklusive sakernas internet. Han har en kandidatexameni neurovetenskap om artificiella neuronnät och har arbetat inom rymdfartsindustrin med mycket distribuerade säkra system och metoder för acceleration av algoritmer. När han inte skriver artiklar om teknik och konstruktion arbetar han med applikationer för djupinlärning för igenkänningssystem och rekommendationssystem.

Om utgivaren

DigiKeys nordamerikanska redaktörer