Het maken van een dataset kan een van de meest uitdagende aspecten zijn van het creëren van een betrouwbaar model om mee te werken. Bij Au-Zone hebben we een speelkaartdataset gemaakt om de mogelijkheden van onze interne cameramodule samen met het machine learning-modeltrainingsportaal te laten zien. De afbeeldingen voor de dataset zijn allemaal afkomstig uit de DeepView Vision Starter Kit | Micro zelf en toen het eenmaal voltooid was, hebben we het eIQ-portaal gebruikt om zowel classificatie- als detectiemodellen te trainen en te creëren in een proof-of-concept-voorbeeld.
Een bruikbaar machine learning-model vereiste een diverse en robuuste dataset. We bespreken een stapsgewijze analyse van het proces van het maken van de dataset en hoe verschillende beeldomstandigheden de nauwkeurigheid van het model kunnen vergroten.
Om te beginnen werden er ongeveer 2000 foto's gemaakt met de DeepView Vision Starter Kit | Micro gebruikt de ingebouwde functie van eIQ Portal om beelden vast te leggen met een extern apparaat via het IP-adres van het bord. Om een robuust model te krijgen zijn er foto's gemaakt met verschillende omgevingen. De afbeeldingen die voor de training werden gebruikt, waren allemaal erg divers wat betreft het aantal kaarten dat aanwezig was en er werden meerdere oriëntaties van de kaarten gebruikt. Een onbevooroordeeld kaartspel van 52 kaarten was dat verder kan worden onderverdeeld in 4 suites en elke suite bestaande uit 13 kaarten van Ace – koning. Voor dit model werden 13 klassen gemaakt, één voor elk nummer, d.w.z. één voor aas, één voor twee enzovoort.
Om het proces voor het vastleggen van afbeeldingen soepel en naadloos te laten verlopen, wordt aanbevolen om de afbeeldingen in kleine batches te verdelen waarbij elke batch verschillende scenario's had, d.w.z. een andere achtergrond, verschillende belichting en verschillende objecten in de afbeeldingen. Als je eenmaal een idee hebt van alle verschillende scenario's die je wilt aanpakken, is het aan te raden om met één kaart tegelijk te beginnen en vervolgens door te gaan naar meerdere kaarten in elk frame en door dit te doen, vergroot je de nauwkeurigheid van het model en het vermogen om meerdere te detecteren. kaarten in één frame.
Aanvankelijk werden de foto's genomen in een goed verlichte kamer met een effen isolerende achtergrond. Van daaruit werden de kaarten verplaatst naar een luidruchtigere achtergrond. Daarna herhaalden we het proces verschillende keren in verschillende lichtomstandigheden:
- Alle lichten gingen uit met gesloten jaloezieën.
- Met slechts één lamp om de kaarten te verlichten.
- Semi-verlichte kamer met verschillende objecten die de kaarten in de schaduw stellen.
Samen met alle verschillende lichtomstandigheden wordt het ook aanbevolen om foto's te maken in verschillende richtingen en met verschillende objecten die de kaarten belemmeren:
- Oplaadkabel gaat over de kaarten.
- Munten om een deel van de kaarten te bedekken.
Nadat een gewenste dataset met afbeeldingen was gemaakt, was het belangrijk om de kaarten in elke afbeelding te labelen om het model betrouwbaarder te trainen. Het DeepView-detectiemodel vereist dat er begrenzingsvakken rond de kaart worden gemaakt, zelfs voor afbeeldingen van één kaart. Wanneer u de begrenzingsvakken maakt, moet u proberen slechts één kaart binnen het kader vast te leggen en onnodige achtergrondruis te vermijden. Als een object echter door de hele kaart snijdt of als er een munt op een kaart wordt geplaatst, moet het kader eromheen worden getekend. Hierdoor kan het model worden getraind zodat de kaart kan worden gedetecteerd, zelfs als de kaart gedeeltelijk is bedekt of als de kaart alleen onder een hoek zichtbaar is.
Algemene configuraties:
De augmentatietool werd gebruikt om het aantal afbeeldingen dat voor training werd gebruikt te vergroten om een getraind model van hogere kwaliteit te genereren met een relatief klein aantal trainingsafbeeldingen. De augmentatietool kan worden gebruikt om helderheid, contractie, verzadiging, oriëntatie enz. te wijzigen.
Voor dit prestatiedetectiemodel van Cards werden de volgende instellingen gebruikt:
Parameter | Waarde |
Initialisatie van gewicht | mbv3_small_320_VOC.h5 |
Invoergrootte | 320.320.3 |
Leerpercentage | 0.000001 |
Batchgrootte | 10 |
Epochs om te trainen | Oneindig (zet de stopvoorwaarde op stop bij doel en stel doelwaarde in op 1) |
Schaal | Klein |
Activering | relu6 |
Optimizer | Adam |
Zorg ervoor dat de “Schaal” en “Gewichtsinitialisatie” beide op dezelfde grootte zijn ingesteld, d.w.z. als de ene klein is, moet de andere klein zijn.
ClassificatieModel:
Een classificatiemodel wordt typisch gebruikt voor beeldverwerking van een bekend interessegebied in een vastgelegd beeld. Classificatiemodellen hebben lagere rekenvereisten in vergelijking met detectiemodellen, dus ze zijn eenvoudiger en hebben snellere inferentietijden. Als het interessegebied vastligt voor een bepaalde usecase, dan zou een classificatiemodel doorgaans goed passen. Als de detectie van een voertuig op een specifieke parkeerplaats bijvoorbeeld een classificatiemodel zou kunnen gebruiken, terwijl de detectie van meerdere voertuigen op willekeurige locaties een detectiemodel zou vereisen.
Voor het bijgevoegde voorbeeld van een speelkaart zijn dertien verschillende klassen gedefinieerd voor Aas – Koning. Wanneer u een kaart presenteert, kan deze worden geclassificeerd op basis van de afbeeldingen die zijn gebruikt om het model te trainen. Dit model vereiste geen lange trainingstijd (ongeveer 60 minuten) en werkt goed met een kleine dataset. Verder kan in de eIQ-portal het DeepView-classificatiemodel worden onderverdeeld in 3 subcategorieën:
Alle modellen die hieronder zijn gemaakt, worden uitgevoerd op de MCU (Micro Controller Units).
Prestaties– Dit model is gericht op snelheid en haalt de laagst mogelijke looptijden.
- Ons prestatiemodel werd getraind tot 41 tijdperken met een leersnelheid van 0.00001 en batchgrootte 10. Verder was de gebruikte optimizer “Adam” en de invoerafbeeldingsgrootte was 128.128. Het resultaat dat we kregen had een nauwkeurigheid van ~92%. Dit model is in combinatie met het MCU-model het meest geschikt voor hardware waar geheugen een probleem is.
Gebalanceerd – Dit model richt zich op het vinden van de balans tussen het prestatie- en nauwkeurigheidsmodel.
- Ons balansmodel is getraind tot 43 tijdperken met een leersnelheid van 0.00001 en batchgrootte 10. Verder was de gebruikte optimizer “Adam” en de invoergrootte was 128.128. Het resultaat dat we kregen had een nauwkeurigheid van ~95%.
Nauwkeurigheid– Dit model is gericht op het verkrijgen van de meest nauwkeurige resultaten mogelijk; de afweging is echter een langere looptijd.
- Ons nauwkeurigheidsmodel is getraind tot 41 tijdperken met een leersnelheid van 0,00001 en batchgrootte 10. Verder was de gebruikte optimizer “Adam” en de invoergrootte was 128.128. Het resultaat dat we kregen had een nauwkeurigheid van ~96%.
Uit de bovenstaande afbeeldingen kunnen we zien dat de runtime drastisch toeneemt wanneer we van het prestatiemodel naar het nauwkeurigheidsmodel gaan, maar de nauwkeurigheid van dat model is veel beter. Dus bij het beslissen welk model erbij hoort, komt het erop neer wat de toepassing van het model is. Als het model gegevens sneller moet verwerken, is het misschien het beste om met prestaties te werken als het probleem een hogere nauwkeurigheid vereist, is de nauwkeurigheid logischer.
Detectie:
Het DeepView Detection-model kan worden geleerd om te rapporteren welke kaart in het beeld aanwezig is en waar deze zich bevindt. Het DeepView-detectiemodel kan meerdere kaarten in de afbeelding rapporteren en het label en het vertrouwen in de resultaten rapporteren. Om een zeer efficiënt model te krijgen is veel trainingstijd en een grote dataset nodig.
Het DeepView-detectiemodel is getraind met 13 verschillende klassen en kan elke kaart uit de 13 klassen detecteren. De trainingstijd voor dit model was extreem hoog, aangezien het bijna 24 uur duurde om een werkend model te krijgen. Verder kan het detectiemodel in de eIQ-portal worden onderverdeeld in 3 subcategorieën:
Alle modellen die hieronder zijn gemaakt, worden uitgevoerd op de MCU (Micro Controller Units).
Prestaties – Dit model richt zich op snelheid en haalt de laagst mogelijke looptijden.
- Ons prestatiemodel is getraind tot 112 tijdperken met een leersnelheid van 0,0001 en batchgrootte 10. Verder was de gebruikte optimizer “Adam” en was de invoergrootte 320.320. Het resultaat dat we kregen had een nauwkeurigheid van ~87%. Dit model is in combinatie met het MCU-model het meest geschikt voor hardware waar geheugen een probleem is. Het trainen van dit model duurde ongeveer 12 uur.
Evenwichtig– Dit model richt zich op het vinden van de balans tussen het prestatie- en nauwkeurigheidsmodel.
- Ons prestatiemodel is getraind tot 207 tijdperken met een leersnelheid van 0,0001 en batchgrootte 10. Verder was de gebruikte optimizer “Adam” en de invoergrootte was 320.320. Het resultaat dat we kregen had een nauwkeurigheid van ~90%. Dit model is in combinatie met het MCU-model het meest geschikt voor hardware waar geheugen een probleem is. Het model had 37000 stappen en duurde ongeveer 17 uur
Nauwkeurigheid – Dit model is gericht op het verkrijgen van de meest nauwkeurige resultaten; de afweging is echter om een langere looptijd te hebben.
- Ons prestatiemodel is getraind tot 311 tijdperken met een leersnelheid van 0,0001 en batchgrootte 10. Verder was de gebruikte optimizer “Adam” en was de invoergrootte 320.320. Het resultaat dat we kregen had een nauwkeurigheid van ~96%. Dit model is in combinatie met het MCU-model het meest geschikt voor hardware waar geheugen een probleem is. Het model had ongeveer 61000 stappen en duurde ongeveer 24 uur.
Uit de bovenstaande afbeeldingen kunnen we zien dat de trainingstijd verandert wanneer we van het prestatiemodel naar het nauwkeurigheidsmodel gaan, maar de nauwkeurigheid van dat model is veel beter. Dus bij het beslissen welk model erbij hoort, komt het erop neer wat de toepassing van het model is. Als het model gegevens sneller moet verwerken, is het misschien het beste om met prestaties te werken als het probleem een hogere nauwkeurigheid vereist, is de nauwkeurigheid logischer.
Zhe He
Senior Embedded System Engineer, Au-Zone Technologies
Saksham Nanda
Firmware Stagiair, Au-Zone Technologies