Gebruik de ingebouwde machine learning-kern van een intelligente sensor om "Always-On" bewegingstracering te optimaliseren

De toenemende vraag van consumenten naar "always-on" bewegingstraceringsfuncties in fitness trackers en andere persoonlijke mobiele apparaten betekende in het verleden dat ontwerpers moesten kiezen tussen die functies en de batterijduur. Pogingen om het energieverbruik te verminderen betekenden onvermijdelijk een opoffering van het traceringsvermogen of de resolutie, waardoor de gebruikerservaring minder werd.

De opkomst van low-power sensors met ingebouwde bewegingsdetectiemogelijkheden helpt ontwerpers om dit compromis uit hun ontwerpen te verwijderen.

In dit artikel wordt beschreven hoe een intelligente bewegingssensor van STMicroelectronics met geraffineerde bewegingsverwerkingsmogelijkheden kan worden gebruikt om een effectievere oplossing te bieden voor always-on bewegingstracering met een laag verbruik.

Klassiek energiebeheer

In een typisch low-power mobiel systeemontwerp vormt de energie die wordt verbruikt door de host-microcontroller tijdens de normale actieve stand het grootste gedeelte van het totale energieverbruik. Daarom zijn ontwikkelaars altijd op zoek naar mogelijkheden om de microcontroller in een slaapstand met laag verbruik te laten werken en hem alleen lang genoeg te wekken om taken uit te voeren als sensorgegevensverwerking of communicatie.

Een lange tijd konden ontwikkelaars dat doel bereiken met sensors die onafhankelijk van de hostprocessor gegevens konden verzamelen. Voor toepassingen met niet al te hoge eisen aan de sensoruitgangsdatasnelheid, kon de sensor zijn on-chip buffers vullen met een reeks metingen, of zelfs direct memory access (DMA)-transacties uitvoeren om de gegevens over te dragen naar het systeemgeheugen voordat er een interrupt werd afgegeven om de processor te wekken voor het voltooien van zijn verwerkingstaken. Omdat de geïntegreerde signaalketen van de sensor signaalconditionering, -conversie en -filtering kon uitvoeren, kon de processor onmiddellijk beginnen te werken aan voorverwerkte gegevens en uitkijken naar gebeurtenissen die van belang zijn voor de toepassing.

Met de integratie van drempel-detectiefuncties in deze sensors, konden ontwikkelaars de tijd dat de processor in de laagverbruiksstand bleef nog meer verlengen. In plaats van de processor belangrijke gebeurtenissen te laten identificeren, kon de sensor alleen een weksignaal afgeven wanneer er een gebeurtenis werd gemeten die de door de ontwikkelaar ingeprogrammeerde drempelwaarden overschreed. Een ontwerper kon bijvoorbeeld dit type geavanceerde temperatuursensor programmeren om alleen een weksignaal af te geven wanneer de gemeten temperatuur een gespecificeerde maximumdrempel overschreed of onder een gespecificeerde minimumdrempel kwam.

Hoewel het verminderen van het energieverbruik op deze manier goed werkt voor meer eenvoudige vereisten, kan het aanzienlijk minder effectief zijn voor het detecteren van complexere gebeurtenissen. In combinatie met de noodzaak van always-on detectie, betekent het detecteren van deze complexe gebeurtenissen een hogere actieve duty cycle voor de processor, waardoor de oplaadbare batterijen met een relatief laag vermogen die gewoonlijk in persoonlijke draagbare apparaten worden gebruikt, snel leeglopen. Het traditionele gebruik van de host-microcontroller voor het uitvoeren van detectie is daarom niet meer mogelijk met de stijgende vraag van de gebruikers naar zowel always-on detectie als een langere batterijduur.

Als de sensor in plaats daarvan complexere detectie-algoritmes kan uitvoeren, kunnen ontwikkelaars de bestaande werkwijzen blijven gebruiken voor het verminderen van het energieverbruik van het systeem via low-power gebruiksmodi en slaapstanden van de compressor. Tegelijkertijd moet deze intelligentere sensor ontwikkelaars een hoge mate van flexibiliteit bieden. Als er gewoon een paar specifieke algoritmes in sensors worden ingebouwd, is dat niet voldoende voor de nieuwe en betere productfuncties. De inertiesensor LSM6DSOX iNEMO (LSM6DSOXTR) van STMicroelectronics bereikt die flexibiliteit met een combinatie van signaalverwerkingsfuncties en flexibele computationele mogelijkheden die in het apparaat worden ingebouwd.

Sensorarchitectuur

De LSM6DSOX iNEMO is een system-in-package (SiP) die micro-elektromechanische systeem- (MEMS) sensors, speciale signaalketens, filters en gespecialiseerde rekenmotoren combineert in een landrasterarraypakket (LGA) van slechts 2,5 x 3,0 x 0,83 millimeter (mm). Samen met de interne drieassige versnellingsmeter en drieassige digitale gyroscoop MEMS-sensors kan het apparaat worden geconfigureerd als sensorhub met de mogelijkheid om de werking van tot vier externe sensors apart te organiseren via speciale hubregisters.

De LSM6DSOX is gebaseerd op dezelfde architectuur als de eerdere LSM6DSO, van STMicroelectronics en biedt alle mogelijkheden en functies van dat eerdere apparaat (zie "IMU's: laat je host slapen met on-board machine learning"). Met de LSM6DSOX vult STMicroelectronics de eindigetoestandsautomaat (FSM, finit-state machine) die in het eerdere apparaat werd geboden echter aan met een machine learning (ML)-kern voor de classificatie van gegevenssets door middel van tot acht beslissingsbomen. Zelfs zonder de FSM- en ML-kernmogelijkheden in te schakelen, kunnen ontwikkelaars geavanceerde bewegingsdetectiemogelijkheden implementeren dankzij de geavanceerde signaalketens die worden gebruikt om gegevens van de MEMS-sensors voor te verwerken.

Zoals met veel geavanceerde sensors heeft de architectuur van de LSM6DSOX meerfasige signaalketens die een analoog-naar-digitaal converter (ADC) combineren met meerdere filteringsfasen. De gyroscoopsignaalketen vult de ADC-fase aan met een reeks selecteerbare digitale filters, waaronder een hoogdoorlaatfilter (HPF), een laagdoorlaatfilter (LPF1) en een tweede laagdoorlaatfilter (LPF2) die in de hogeprestatiemodus van het apparaat werken, maar in normale of laagverbruiksmodi worden omzeild (Afbeelding 1).

Afbeelding 1: Net als bij de eerdere LSM6DSO van STMicroelectronics, volgt de LSM6DSOX iedere sensor met een gespecialiseerde, eigen signaalketen met meerdere filterfasen, zoals hier te zien is voor de gyroscoopsensor. (Bron afbeelding: STMicroelectronics)

Omdat de versnellingsmeter nodig is voor veel van de geïntegreerde mogelijkheden, is de signaalketen van de versnellingsmeter aanzienlijk verbeterd in deze architectuur. De eerste fasen bieden de basis signaalconditionerings- en -conversiemogelijkheden die te vinden zijn in de meeste geavanceerde sensors. Een analoog antialiasing-laagdoorlaatfilter biedt bijvoorbeeld basis signaalconditionering, een 16-bits ADC digitaliseert de geconditioneerde signalen en de gedigitaliseerde resultaten worden door een digitaal laagdoorlaatfilter geleid. Het apparaat onderscheidt zich door het geraffineerde, samengestelde filterblok dat op deze eerste conversiefase volgt (Afbeelding 2)

Afbeelding 2: Zowel in de eerdere LSM6DSO- en nu in de LSM6DSOX-bewegingssensor van STMicroelectronics ondersteunt een uitgebreide versnellingsmetersignaalketen host-onafhankelijke detectie van diverse complexe bewegingen, zoals vrije val, multidimensionale oriëntatie en enkel/dubbel tikken (S/D). (Bron afbeelding: STMicroelectronics)

Met een combinatie van verwerkingsblokken en filters kan de samengestelde filtersectie van de versnellingsmeter autonoom een grote verscheidenheid aan complexe gebeurtenissen detecteren waarvoor de processor tot nu toe gewekt moest worden en gespecialiseerde gebeurtenisdetectiecode moest uitvoeren. Maar nu kunnen ontwikkelaars filterparameters programmeren om automatisch te detecteren en interrupts af te geven voor een grote hoeveelheid complexe bewegingen, zoals enkel of dubbel tikken, vrije val, activiteit/inactiviteit, oriëntatie met zes graden (6D) van vrijheid of 4D-oriëntatie, wat gewoonlijk wordt gebruikt om bewegingen van het apparaat te detecteren. Bijvoorbeeld de overgang van staande naar liggende modus.

De geavanceerde detectors van het samengestelde filter combineren de resultaten van de verwerkingsblokken en -filters om hun detectie uit te voeren. Detectie van enkel tikken gebruikt bijvoorbeeld het ingebouwde hellingsfilter, dat voortdurend de helling genereert op het huidige versnellingsmeter-sample, acc(t_n), als:

helling(t_n) = [ acc(t_n) - acc(t_n-1) ] / 2 (Vergelijking 1)

Voor een enkele-tikgebeurtenis, stijgt de helling tot boven een bepaalde drempel en daalt snel vergeleken met een bredere schokgebeurtenis (Afbeelding 3). Door het gebruik van drempel- en schok-vensterduurwaarden die door de ontwikkelaar worden ingesteld, kan het apparaat automatisch de enkele-tikgebeurtenis detecteren en een interrupt afgeven aan de host-microcontroller.

Dubbele-tikdetectie bouwt voort op deze benadering, door een extra parameter toe te voegen om de vereiste wachttijd tussen de twee enkele-tikgebeurtenissen te specificeren.

Afbeelding 3: De bewegingssensors LSM6DSO en LSM6DSOX bieden host-onafhankelijke detectie van enkele-tikgebeurtenissen met een ingebouwde hellingsfunctie die een snellere terugkeer naar basisniveaus laat zien voor een enkele tik (a) vergeleken met de kenmerken van een brede schokgebeurtenis (b). (Bron afbeelding: STMicroelectronics)

De mogelijkheid van het apparaat om afgeleide gegevens te genereren, zoals helling, speelt een centrale rol in de meer geavanceerde mogelijkheden die beschikbaar zijn met de geïntegreerde FSM en machine learning (ML)-kern. Omdat de FSM-functie is besproken in het eerder genoemde artikel, richt de rest van dit artikel zich op de ML-kern van de LSM6DSOX en het gebruik daarvan bij het detecteren van veel complexere bewegingsgebeurtenissen, zoals bewegingssequenties en zelfs complexe bewegingsactiviteiten zoals specifieke oefeningen.

Beslissingsbomen

De ML-kern van de LSM6DSOX biedt verwerking op sensorbasis op een niveau dat veel verder gaat dan de bekende geparametriseerde drempelinstellingen die in veel geavanceerde intelligente sensors worden gebruikt. Met de ML-kern kunnen ontwikkelaars complexe detectiealgoritmes in het apparaat implementeren, waardoor always-on detectie van complexe bewegingsgebeurtenissen mogelijk wordt zonder dat de microcontroller hoeft te worden gewekt. Hier gebruikt de ML-kern beslissingsbomen om een gebeurtenis te identificeren op basis van patronen van ingangsgegevens.

Beslissingsbomen worden al jaren gebruikt in beslissingsondersteunende systemen en ontleden complexe beslissingen in een reeks selecties op basis van het testen van de ingangsgegevens, of attributen, tegen voorgedefinieerde omstandigheden. Vanaf de eerste node, of root, wordt de waarde van een attribuut getest en de beslissing om door te gaan naar een bepaalde child-node wordt bepaald door de resultaten (Afbeelding 4).

Afbeelding 4: Een beslissingsboom genereert een resultaat met behulp van een sequentie van nodes die allemaal een ingangswaarde testen voor een bepaald attribuut tegen een voorwaarde, zoals een bepaald drempelniveau, om door te gaan naar verschillende child-nodes afhankelijk van de resultaten van de test. (Bron afbeelding: STMicroelectronics)

Bij iedere update-cyclus, bijvoorbeeld, wordt de beslissingsboom opgeroepen om door zijn nodes heen te werken om te bepalen of de beschikbare gegevens (bij die update) geen beweging, voorwaartse beweging of een ander soort beweging vertegenwoordigden, als volgt:

1. de omvang van de meting van een versnellingsmeter testen
   • 1.1. afsluiten als de waarde onder een vooraf bepaalde waarde is (de voorwaarde)
   • 1.2. anders aftakken naar een child node om gyroscoopmetingen te testen die in hetzelfde tijdsvenster zijn genomen
     • 1.2.1. afsluiten als gyroscoopmetingen onder een vooraf bepaalde waarden zijn of
     • 1.2.2. doorgaan naar een diepere child node om andere attributen te testen die in hetzelfde tijdsvenster zijn gemeten of hetzelfde attribuut testen tegen een andere voorwaarde.

Dit proces wordt herhaald totdat de test een eindnode bereikt, die in deze context overeenkomt met een bepaalde complexe bewegingsgebeurtenis, of -klasse. In dit eenvoudige voorbeeld:

• eindnode 1.1 kan aangeven dat de gegevens, of functieset, moeten worden geclassificeerd als "geen beweging"
• eindnode 1.2.1 kan aangeven dat de functieset moet worden geclassificeerd als "voorwaartse beweging"
• eindnodes onder node 1.2.2 kunnen een bewegende draai of een meer complexe verandering in richting aangeven

Natuurlijk zijn werkelijke probleemsets waarvoor het gebruik van beslissingsbomen nodig is veel complexer, met grote functiesets die veel verschillende attributen en voorwaarden bevatten. De LSM6DSOX geeft ontwikkelaars een uitgebreide set mogelijke functies, beginnend met sensorgegevens van de versnellingsmeter, gyroscoop en eventuele externe sensors die in de sensorhubverbindingsmodus zijn aangesloten (Afbeelding 5).

Afbeelding 5: Uniek voor de LSM6DSOX van STMicroelectronics: een ingebouwde ML-kern gebruikt primaire sensorgegevens, gefilterde gegevens en afgeleide parameters, zoals gemiddelde en variantie, als ingangen voor één van de acht beslissingsbomen die door het apparaat worden ondersteund. (Bron afbeelding: STMicroelectronics)

Met deze primaire sensorgegevens genereert het apparaat een groot aantal functies die met de primaire gegevens worden berekend, binnen een schuivend tijdsvenster, zoals:

• norm V = Ö( x² + y² + z²) en V²
• gemiddelde
• variantie
• energie
• piek-tot-piek
• nuldoorgang
• positieve nuldoorgang
• negatieve nuldoorgang
• piekdetector
• positieve-piekdetector
• negatieve-piekdetector
• minimum
• maximum

Voor bepaalde functies, zoals de nuldoorgangdetectors en piekdetectors, specificeert de ontwikkelaar ook een drempelwaarde voor het verschuiven van respectievelijk de nuldoorgangsas of de piekdrempel.

Gecontroleerde leerwerkstroom

Het gebruik van deze functies om een beslissingsboom te implementeren met de ML-kern van de LSM6DSOX volgt een typische gecontroleerde leerwerkstroom die wordt gebruikt bij de meeste pogingen tot het ontwikkelen van een model voor machine learning. In het algemeen begint die werkstroom met de identificatie van de activiteiten die van belang zijn en het verzamelen van data-samples die bij die activiteiten horen.

In dit geval gebruiken ontwikkelaars gewoonweg de LSM6DSOX om gegevens te verzamelen terwijl de bepaalde set bewegingsactiviteiten wordt uitgevoerd die de uiteindelijke toepassing moet detecteren. Voor deze ontwikkelingsfase kunnen ontwikkelaars een dataverwervingsplatform aanmaken met borden en software van STMicroelectronics. Voor het hardwareplatform pluggen developers gewoon het STEVAL-MKI197V1 LSM6DSOX-adaptorbord in het STEVAL-MKI109V3-evaluatiemoederbord. Als software kunnen ontwikkelaars de gratis Unico software-tool van STMicroelectronics gebruiken, die beschikbaar is voor Windows, Mac OSX en Linux.

Unico is ontworpen om te werken met het STEVAL-MKI109V3-moederbord en biedt een eenvoudige manier om gegevens die door de LSM6DSOX zijn gegenereerd te verzamelen. Voor gegevensverzameling gebruiken ontwikkelaars het moederbord en Unico samen. Hier houdt de ontwikkelaar of een assistent het moederbord vast terwijl hij/zij herhaaldelijk één van de betreffende specifieke bewegingsactiviteiten uitvoert, waarbij Unico wordt gebruikt om de bewegingsgegevens van de LSM6DSOX te verzamelen.

De gegevens die van de LSM6DSOX worden verzameld tijdens meerdere herhalingen van één enkele activiteit vormen de trainingsset voor de bijbehorende klasse (zoals "voorwaartse beweging" in ons eerdere voorbeeld). Om dat de gegevens die tijdens die beweging worden verzameld allemaal overeenkomen met diezelfde klasse, zorgt deze actieve manier van dataverzameling ervoor dat er geen aparte gegevenslabelingsfase nodig is, die gecontroleerde leerwerkstromen soms kan vertragen.

Na het verzamelen van bewegingsgegevens voor iedere bewegingsgebeurtenisklasse die van belang is, gebruiken ontwikkelaars Unico om de gegevens en het klasselabel te herzien. Buiten het gebruik voor datareview, laat Unico ontwikkelaars ook meerdere aspecten van de gewenste beslissingsboom configureren, filters definiëren, tijdsvensters instellen en de specifieke functies selecteren die moeten worden gebruikt bij het opbouwen van de beslissingsboom.

In de praktijk beperken ontwikkelaars gewoonlijk de functies die worden gebruikt voor het detecteren van een bepaalde set activiteiten tot het kleinst mogelijke aantal, wat wordt bepaald door ervaring en experimenten. Zelfs met een minimale functieset hangt het efficiënt implementeren van een beslissingsboom sterk af van het bepalen welke van die functies, of attributen, moeten worden getest bij iedere node van de beslissingsboom. Het is belangrijk om het "beste" attribuut te kiezen om te testen bij iedere node om de grootte van de beslissingsboom te beperken, wat met name belangrijk is voor een apparaat met beperkte bronnen, zoals een sensor.

Opmerking voor de lezer: Je zult je inmiddels misschien wel afvragen hoe het zit met het gebruik van functie versus attribuut. Het probleem daarmee is dat we het hebben over "functies" voor ML-modellen, terwijl ze in beslissingsboom-jargon "attributen" worden genoemd. We hebben geprobeerd om ons aan de ene of de andere term te houden per sectie, maar hier schakelen we over van "functie" naar "attribuut" voor de volgende discussie over beslissingsbomen. Zonder twijfel vind je ander plaatsen waar de termen door elkaar worden gebruikt, maar hier en later in het "arff"-gedeelte is het "attribuut".

Hoewel het concept eenvoudig is, kan de selectie van het beste attribuut om te gebruiken bij iedere beslissingsnode weinig intuïtief zijn voor beslissingsbomen met een groot aantal attributen, die allemaal worden vertegenwoordigd met een breed bereik aan gegevenswaarden. De favoriete manier om het beste attribuut te vinden om te testen bij iedere node, is het berekenen van de Shannon-entropie van het attribuut bij die node, met Vergelijking 2:

entropie(p₁,p₂,...,p_n) = - p₁log₂(p₁) - p₂log₂(p₂)... - p_nlog₂(p_n) (Vergelijking 2)

De waarschijnlijkheid p_n vertegenwoordigt ieder van de n mogelijke klassen die bij dat attribuut horen.

Het resultaat is de informatiecontent, gepresenteerd in bits in waarden van 0 tot 1, in plaats van alleen maar 0 of 1, in de bekendere definitie van bits.

De informatie-"versterking" van ieder attribuut wordt dan het verschil tussen deze informatiewaarde en de basis-informatiewaarde die is berekend voor het attribuut op basis van een waarschijnlijkheid van een correcte beslissing die zou optreden zonder gebruik van de beslissingsnode. Hoewel een gedetailleerde kijk op deze berekening niet bij het doel van dit artikel hoort, wordt voor een intuïtieve benadering vergeleken welke benadering waarschijnlijk de gewenste uitkomst het meest efficiënt zal bieden: een resultaat op basis van met brute kracht bottom-up door de gegevensset snijden op basis van waarden van dat attribuut (de "basis"), of een resultaat op basis van een top-down selectie op basis van specifieke waardegebieden voor dat attribuut. Top-down selectie gebruikt een "verdeel en heers"-benadering die gewoonlijk het aantal mogelijke uitkomsten sneller zal verminderen dan de bottom-up benadering.

Snelle implementatie

Gelukkig hoeven ontwikkelaars zich maar zelden te bekommeren om de details van de optimalisatie van de informatieverzameling en attribuutselectie. In plaats daarvan kunnen ze gebruik maken van gratis beschikbare machine learning tools van derden, zoals Weka, die automatisch de benodigde berekeningen maken die nodig zijn voor het genereren van optimale beslissingsbomen.

Unico en Weka werken dan ook nauw samen om een werkstroom te leveren voor een snelle implementatie van beslissingsbomen. Gewoonlijk liggen de kritieke stappen in een specifieke ontwikkelingswerkstroom van een beslissingsboom in de eerder genoemde gegevensverzamelingsstappen, specifiek het gebruik van de LSM6DSOX voor het verzamelen van representatieve gegevenssets voor iedere activiteitenklasse die van belang is; en het gebruik van Unico voor het verfijnen van die gegevenssets en het definiëren van de beslissingsboomconfiguratie. Na voltooiing werken deze twee tools samen om de laatste fasen van het proces te versnellen.

Na het verfijnen van de gegevens en de beslissingsboomconfiguratie in Unico, gebruiken ontwikkelaars de tool om de geselecteerde functieset te converteren in een standaardformaat dat het attribuut-relatie bestandsformaat (arff, attribute-relation file format) wordt genoemd. Een arff-bestand heeft een header-gedeelte waarin de geselecteerde attributen (functies) en mogelijke klassen staan, en een gegevensgedeelte waarin de sets met verzamelde gegevens staan met de bijbehorende klasse (Lijst 1). In dit voorbeeld worden slechts enkele functies gebruikt en slechts een kleine set gegevensinstanties wordt gebruikt om een beperkte set klassen te identificeren, zoals bicep curls, lateral raises en squats.

Lijst 1: Het standaard attribute-relation file format (arff)-bestand bevat een header-gedeelte waarin attributen en klassen worden gedefinieerd, en een datagedeelte dat gegevensinstanties bevat voor ieder attribuut en bijbehorende klasse. (Bron gegevens: STMicroelectronics)

Met Weka laden ontwikkelaars het arff-bestand in het "voorverwerkings"-venster en bekijken ze een grafisch overzicht van de volledige functieset (Afbeelding 6).

Afbeelding 6: Nadat ze de Unico-tool van STMicroelectronics hebben gebruikt om een arff-bestand te genereren voor hun gegevensset, kunnen ontwikkelaars Weka, een machine learning tool van derden, gebruiken om de volledige gegevensset te bekijken, die hier wordt getoond voor de arff-gegevens in Lijst 1. (Bron afbeelding: DigiKey)

Om de beslissingsboom te bouwen, schakelen ontwikkelaars over naar het Weka-venster "classificeren", kiezen ze de Weka J48-classifier (de beslissingsboom-classifier van Weka) en klikken ze op start. In het uitgangsvenster geeft de classifier een lijst van de ingangsgegevens en wordt de beslissingsboom zowel in grafisch (Afbeelding 7) als tekstformaat weergegeven (Afbeelding 8).

Afbeelding 7: Om een beslissingsboom te maken, laden ontwikkelaars gewoonweg een arff-bestand, selecteren ze de Weka J48-beslissingsboomclassifier en genereren ze de uiteindelijke boom. De ingebouwde Weka-weergavetool wordt gebruikt om het resultaat te bekijken met een lijst van attributen en voorwaarden voor iedere node. In dit geval worden de arff-gegevens gebruikt in Lijst 1. (Bron afbeelding: DigiKey)

Afbeelding 8: Samen met een visuele weergave van de beslissingsboom genereert Weka de werkelijke J48-beslissingsboomspecificatie, in dit geval met gebruik van de arff-gegevens in Lijst 1 om de J48-specificatie te genereren in Lijst 2. (Bron afbeelding: DigiKey)

In dit voorbeeld zijn er slechts enkele regels nodig voor de gegenereerde J48-beslissingsboomspecificatie (Lijst 2).

Lijst 2: Weka genereert een J48-beslissingsboomspecificatie, zoals deze voor de arff-gegevens in Lijst 1. Ontwikkelaars laden deze specificatie in de Unico-tool van STMicroelectronics om een configuratiebestand te genereren en dit in de LSM6DSOX-sensor van STMicroelectronics te laden. (Bron gegevens: STMicroelectronics)

Nadat de J48-boomtekst in een bestand is gekopieerd en opgeslagen, laden ontwikkelaars dat tekstbestand in Unico om een registerconfiguratiebestand te genereren. Tenslotte voltooien ontwikkelaars de werkstroom door de tab laden/opslaan van Unico te gebruiken om dat configuratiebestand in de LSM6DSOX te laden. Op dit punt kan de ontwikkelaar de ondersteuningsbewegingen uitvoeren terwijl het STEVAL-MKI109V3-moederbord wordt vastgehouden zoals eerder beschreven, en Unico gebruiken om het beslissingsboom-classificatieresultaat van het LSM6DSOX-uitgangsregister te lezen voor de geconfigureerde beslissingsboom.

In een aangepast ontwerp kunnen ontwikkelaars een verandering in een beslissingsboomuitgang gebruiken om de microcontroller een weksignaal te geven en code uit te laten voeren om de gebruiker te waarschuwen, een oefeningteller te verhogen of andere bewerkingen van hogere niveaus uit te laten voeren die nodig zijn voor een toepassing.

Hoewel dit voorbeeld extreem eenvoudig is, kan de ML-kern van de LSM6DSOX classificatie van aanzienlijk complexere bewegingsgebeurtenissen ondersteunen, door meer van de eerder genoemde verschillende functies te gebruiken. STMicroelectronics beschrijft bijvoorbeeld een meer geavanceerde versie van deze eenvoudige toepassing, die veel meer functies gebruikt om workout-activiteiten te classificeren in een breder bereik aan oefeningen, zoals bicep curls, jumping jacks, lateral raises, push-ups en squats.

Samen met de gemiddelde en piek-tot-piek functies die in het eenvoudige voorbeeld worden gebruikt, voegt het complexe voorbeeld variantie, min, max en nuldoorgangsfuncties toe, die worden berekend voor een tijdsvenster van twee seconden. Deze meer geraffineerde toepassing, die in de ML-kern van de LSM6DSOX wordt uitgevoerd, leidt tot een stroomverbruik van ongeveer 569 μA (@ 1,8 V), waarvan maar ongeveer 13 μA wordt veroorzaakt door stroomverbruik van de ML-kern zelf. Op dit niveau van energieverbruik zouden ontwikkelaars zonder twijfel always-on bewegingsdetectie kunnen implementeren met maar een kleine invloed op de laadstatus van de batterij.

Kanttekening bij machine learning

In de praktijk hangen toepassingen van machine learning af van gecontroleerde leer-werkstromen, die onvermijdelijk een bepaalde afwijking doorlaten in het uiteindelijke machinelearning-model, of dat model nu een zeer complex convolutioneel neuraal netwerk is of een relatief eenvoudige beslissingsboom. Met name op beweging gebaseerde gegevens zijn zo sterk afhankelijk van fysieke morfologie en kinesiologie dat de gegevens die worden verzameld bij één persoon die een activiteit uitvoert, sterk kunnen verschillen van die van een andere persoon.

Daarom hebben ontwikkelaars die activiteitendetectie op basis van ML gebruiken te maken met de voortdurende uitdaging van het vinden van een balans tussen gegevensspecificiteit en -algemeenheid. Teveel specificiteit beperkt gewoonlijk de algemeenheid, terwijl teveel algemeenheid gewoonlijk de nauwkeurige detectie van de unieke variaties van dezelfde beweging bij verschillende personen vermindert. Hoewel die problemen niet uniek zijn voor dit specifieke gebruik, kunnen de uitdagingen bij het vinden van deze balans in gepersonaliseerde bewegingsdetectieapparaten aangeven dat er beslissingsbomen nodig zijn die kunnen worden bijgewerkt met gebruikersspecifieke gegevens. Met zorgvuldige aandacht voor deze brede gegevenswetenschapsvereisten voor machine learning, kunnen ontwikkelaars echter de LSM6DSOX en bestaande werkstroom al gebruiken om geraffineerde, always-on bewegingsdetectie toe te passen in ontwerpen met een beperkt vermogen.

Conclusie

De vraag naar zowel always-on bewegingstracering als een lange batterijduur bleek een schijnbaar onoverwinnelijke conflict te zijn voor ontwikkelaars van fitnessapparaten en andere kleine draagbare apparaten. Hoewel veel geavanceerde sensors een bepaalde graad van bewegingsdetectie kunnen leveren, los van de processor, sluit de wens om always-on detectie van complexere bewegingen die benadering uit in opkomende toepassingen.

Door de machine learning-mogelijkheden in de LSM6DSOX-bewegingssensor van STMicroelectronics te gebruiken, kunnen ontwikkelaars echter het conflict tussen always-on tracering en een lange batterijduur oplossen om meer geavanceerde, activiteitbewuste fitnessarmbanden en andere draagbare apparaten te creëren.