Demystificerende machine learning aan de rand door echte use cases

rand is een term die verwijst naar een locatie, ver van de cloud of een big datacenter, waar je een computerapparaat (edge ​​device) hebt dat (edge) applicaties kan draaien. Edge computing is het uitvoeren van workloads op deze edge-apparaten. Machine learning aan de rand (ML@Edge) is een concept dat de mogelijkheid biedt om ML-modellen lokaal uit te voeren op edge-apparaten. Deze ML-modellen kunnen vervolgens worden aangeroepen door de edge-applicatie. ML@Edge is belangrijk voor veel scenario's waarin onbewerkte gegevens worden verzameld uit bronnen ver van de cloud. Deze scenario's kunnen ook specifieke vereisten of beperkingen hebben:

• Realtime voorspellingen met lage latentie
• Slechte of niet-bestaande connectiviteit met de cloud
• Wettelijke beperkingen die het verzenden van gegevens naar externe services niet toestaan
• Grote datasets die lokaal moeten worden voorverwerkt voordat reacties naar de cloud worden verzonden

Hier volgen enkele van de vele use-cases die kunnen profiteren van ML-modellen die dicht bij de apparatuur draaien die de gegevens genereert die voor de voorspellingen worden gebruikt:

• Beveiliging en veiligheid – Een beperkt gebied waar zware machines werken in een geautomatiseerde poort wordt bewaakt door een camera. Als een persoon per ongeluk dit gebied betreedt, wordt een veiligheidsmechanisme geactiveerd om de machines te stoppen en de mens te beschermen.
• Predictief onderhoud – Trillings- en audiosensoren verzamelen data van een tandwielkast van een windturbine. Een anomaliedetectiemodel verwerkt de sensorgegevens en identificeert eventuele afwijkingen met de apparatuur. Als er een afwijking wordt gedetecteerd, kan het edge-apparaat in realtime een noodmeting starten om schade aan de apparatuur te voorkomen, zoals het inschakelen van de pauzes of het loskoppelen van de generator van het net.
• Defectdetectie in productielijnen – Een camera legt beelden van producten op een lopende band vast en verwerkt de frames met een beeldclassificatiemodel. Als er een defect wordt gedetecteerd, kan het product automatisch worden weggegooid zonder handmatige tussenkomst.

Hoewel ML@Edge veel gebruiksscenario's aankan, zijn er complexe architecturale uitdagingen die moeten worden opgelost om een ​​veilig, robuust en betrouwbaar ontwerp te hebben. In dit bericht leert u enkele details over ML@Edge, gerelateerde onderwerpen en hoe u AWS-services kunt gebruiken om deze uitdagingen te overwinnen en een complete oplossing voor uw ML aan de rand te implementeren.

ML@Edge overzicht

Er is veel verwarring als het gaat om ML@Edge en Internet of Things (IoT), daarom is het belangrijk om te verduidelijken hoe ML@Edge verschilt van IoT en hoe beide samen kunnen komen om in bepaalde gevallen een krachtige oplossing te bieden.

Een edge-oplossing die ML@Edge gebruikt, heeft twee hoofdcomponenten: een edge-applicatie en een ML-model (aangeroepen door de applicatie) die op het edge-apparaat draaien. ML@Edge gaat over het beheersen van de levenscyclus van een of meer ML-modellen die zijn geïmplementeerd op een vloot van edge-apparaten. De levenscyclus van het ML-model kan beginnen aan de cloudzijde (op Amazon Sage Maker, bijvoorbeeld) maar eindigt normaal gesproken bij een zelfstandige implementatie van het model op het edge-apparaat. Elk scenario vereist verschillende levenscycli van ML-modellen die kunnen worden samengesteld uit vele fasen, zoals het verzamelen van gegevens; data voorbereiding; modelbouw, compilatie en implementatie op het edge-apparaat; model laden en draaien; en het herhalen van de levenscyclus.

Het ML@Edge-mechanisme is niet verantwoordelijk voor de levenscyclus van de applicatie. Daartoe dient een andere benadering te worden gevolgd. Door de levenscyclus van het ML-model en de levenscyclus van toepassingen te ontkoppelen, krijgt u de vrijheid en flexibiliteit om ze in verschillende snelheden te blijven ontwikkelen. Stel je een mobiele applicatie voor die een ML-model insluit als een hulpmiddel, zoals een afbeelding of XML-bestand. In dit geval moet u elke keer dat u een nieuw model traint en het wilt implementeren op de mobiele telefoons, de hele applicatie opnieuw implementeren. Dit kost tijd en geld en kan bugs in uw applicatie introduceren. Door de levenscyclus van het ML-model te ontkoppelen, publiceert u de mobiele app één keer en implementeert u zoveel versies van het ML-model als u nodig hebt.

Maar hoe correleert IoT met ML@Edge? IoT heeft betrekking op fysieke objecten die zijn ingebed met technologieën zoals sensoren, verwerkingscapaciteit en software. Deze objecten zijn via internet of andere communicatienetwerken verbonden met andere apparaten en systemen om gegevens uit te wisselen. De volgende afbeelding illustreert deze architectuur. Het concept is oorspronkelijk ontstaan ​​toen we dachten aan eenvoudige apparaten die alleen gegevens van de edge verzamelen, eenvoudige lokale verwerking uitvoeren en het resultaat naar een krachtigere computereenheid sturen die analyseprocessen uitvoert die mensen en bedrijven helpen bij hun besluitvorming. De IoT-oplossing is verantwoordelijk voor het beheersen van de levenscyclus van de edge-applicatie. Voor meer informatie over IoT, zie: Internet of Things.

Als u al een IoT-toepassing heeft, kunt u ML@Edge-mogelijkheden toevoegen om het product efficiënter te maken, zoals weergegeven in de volgende afbeelding. Houd er rekening mee dat ML@Edge niet afhankelijk is van IoT, maar dat u ze kunt combineren om een ​​krachtigere oplossing te creëren. Wanneer u dat doet, verbetert u het potentieel van uw eenvoudige apparaat om sneller realtime inzichten voor uw bedrijf te genereren dan alleen gegevens naar de cloud te sturen voor latere verwerking.

Als u een geheel nieuwe edge-oplossing maakt met ML@Edge-mogelijkheden, is het belangrijk om een ​​flexibele architectuur te ontwerpen die zowel de applicatie- als de ML-modellevenscyclus ondersteunt. We bieden enkele referentiearchitecturen voor edge-applicaties met ML@Edge verderop in dit bericht. Maar laten we eerst dieper ingaan op edge computing en leren hoe u het juiste edge-apparaat voor uw oplossing kiest, op basis van de beperkingen van de omgeving.

Edge computing

Afhankelijk van hoe ver het apparaat zich van de cloud of een big datacenter (basis) bevindt, moet rekening worden gehouden met drie hoofdkenmerken van de edge-apparaten om de prestaties en levensduur van het systeem te maximaliseren: reken- en opslagcapaciteit, connectiviteit en stroomverbruik. Het volgende diagram toont drie groepen randapparaten die verschillende specificaties van deze kenmerken combineren, afhankelijk van hoe ver ze van de basis verwijderd zijn.

De groepen zijn als volgt:

• MEC's ​​(Multi-access Edge Computing) – MEC's ​​of kleine datacenters, gekenmerkt door lage of ultralage latentie en hoge bandbreedte, zijn veelvoorkomende omgevingen waar ML@Edge voordelen kan bieden zonder grote beperkingen in vergelijking met cloudworkloads. 5G-antennes en servers in fabrieken, magazijnen, laboratoria, enzovoort, met minimale energiebeperkingen en met een goede internetverbinding, bieden verschillende manieren om ML-modellen uit te voeren op GPU's en CPU's, virtuele machines, containers en bare-metal servers.
• Dichtbij rand - Dit is wanneer mobiliteit of gegevensaggregatie vereisten zijn en de apparaten enkele beperkingen hebben met betrekking tot stroomverbruik en verwerkingskracht, maar nog steeds een betrouwbare connectiviteit hebben, hoewel met een hogere latentie, met beperkte doorvoer en duurder dan "dicht bij de rand". Mobiele applicaties, specifieke boards om ML-modellen te versnellen, of eenvoudige apparaten met capaciteit om ML-modellen uit te voeren, gedekt door draadloze netwerken, vallen onder deze groep.
• verre rand – In dit extreme scenario hebben edge-apparaten een hoog stroomverbruik of connectiviteitsbeperkingen. Bijgevolg is de verwerkingskracht ook beperkt in veel verre scenario's. Landbouw, mijnbouw, bewaking en veiligheid, en maritiem transport zijn enkele gebieden waar verre apparaten een belangrijke rol spelen. Eenvoudige borden, normaal gesproken zonder GPU's of andere AI-versnellers, zijn gebruikelijk. Ze zijn ontworpen om eenvoudige ML-modellen te laden en uit te voeren, de voorspellingen op te slaan in een lokale database en te slapen tot de volgende voorspellingscyclus. De apparaten die realtime gegevens moeten verwerken, kunnen grote lokale opslagplaatsen hebben om gegevensverlies te voorkomen.

Uitdagingen

Het is gebruikelijk om ML@Edge-scenario's te hebben waarin u honderden of duizenden (misschien zelfs miljoenen) apparaten hebt met dezelfde modellen en edge-applicaties. Wanneer u uw systeem schaalt, is het belangrijk om een ​​robuuste oplossing te hebben die het aantal apparaten kan beheren dat u moet ondersteunen. Dit is een complexe taak en voor deze scenario's moet u veel vragen stellen:

• Hoe bedien ik ML-modellen op een vloot van apparaten aan de rand?
• Hoe bouw, optimaliseer en implementeer ik ML-modellen op meerdere edge-apparaten?
• Hoe beveilig ik mijn model terwijl ik het aan de rand implementeer en laat draaien?
• Hoe kan ik de prestaties van mijn model bewaken en zo nodig bijscholen?
• Hoe elimineer ik de noodzaak om een ​​groot framework zoals TensorFlow of PyTorch op mijn beperkte apparaat te installeren?
• Hoe kan ik een of meerdere modellen met mijn edge-applicatie als een eenvoudige API ontsluiten?
• Hoe maak ik een nieuwe dataset met de payloads en voorspellingen die zijn vastgelegd door de edge-apparaten?
• Hoe voer ik al deze taken automatisch uit (MLOps plus ML@Edge)?

In de volgende sectie geven we antwoorden op al deze vragen aan de hand van voorbeelden van use-cases en referentie-architecturen. We bespreken ook welke AWS-services u kunt combineren om complete oplossingen te bouwen voor elk van de onderzochte scenario's. Als u echter wilt beginnen met een heel eenvoudige stroom die beschrijft hoe u enkele van de services van AWS kunt gebruiken om uw ML@Edge-oplossing te maken, is dit een voorbeeld:

Met SageMaker kunt u eenvoudig een dataset voorbereiden en de ML-modellen bouwen die op de edge-apparaten worden geïmplementeerd. Met Amazon SageMaker Neo, kunt u het model dat u hebt getraind, compileren en optimaliseren voor het specifieke edge-apparaat dat u hebt gekozen. Nadat u het model hebt gecompileerd, hebt u slechts een lichte runtime nodig om het uit te voeren (geleverd door de service). Amazon SageMaker Edge Manager is verantwoordelijk voor het beheer van de levenscyclus van alle ML-modellen die zijn geïmplementeerd in uw vloot van edge-apparaten. Edge Manager kan vloten tot miljoenen apparaten beheren. Een agent, geïnstalleerd op elk van de edge-apparaten, stelt de geïmplementeerde ML-modellen als een API beschikbaar voor de toepassing. De agent is ook verantwoordelijk voor het verzamelen van metrische gegevens, payloads en voorspellingen die u kunt gebruiken voor het bewaken of bouwen van een nieuwe gegevensset om het model indien nodig opnieuw te trainen. Eindelijk, met Amazon SageMaker-pijpleidingen, kunt u een geautomatiseerde pijplijn maken met alle stappen die nodig zijn om ML-modellen te bouwen, optimaliseren en implementeren in uw vloot van apparaten. Deze geautomatiseerde pijplijn kan vervolgens worden geactiveerd door eenvoudige gebeurtenissen die u definieert, zonder menselijke tussenkomst.

Gebruik geval 1

Stel dat een vliegtuigfabrikant onderdelen en gereedschappen in de productiehangar wil detecteren en volgen. Om de productiviteit te verbeteren, moeten alle benodigde onderdelen en het juiste gereedschap in elke productiefase beschikbaar zijn voor de ingenieurs. We willen vragen kunnen beantwoorden als: Waar is deel A? of Waar is gereedschap B? We hebben al meerdere IP-camera's geïnstalleerd en aangesloten op een lokaal netwerk. De camera's bestrijken de hele hangar en kunnen realtime HD-video streamen via het netwerk.

AWS-panorama past mooi in dit geval. AWS Panorama biedt een ML-appliance en beheerde service waarmee u computer vision (CV) kunt toevoegen aan uw bestaande vloot van IP-camera's en kunt automatiseren. AWS Panorama geeft je de mogelijkheid om CV toe te voegen aan je bestaande IP-camera's (Internet Protocol) en taken te automatiseren die traditioneel menselijke inspectie en bewaking vereisen.

In de volgende referentiearchitectuur tonen we de belangrijkste componenten van de applicatie die draait op een AWS Panorama Appliance. De Panorama Application SDK maakt het gemakkelijk om video van camerastreams vast te leggen, gevolgtrekkingen uit te voeren met een pijplijn van meerdere ML-modellen en de resultaten te verwerken met behulp van Python-code die in een container wordt uitgevoerd. U kunt modellen uitvoeren vanuit elke populaire ML-bibliotheek, zoals TensorFlow, PyTorch of TensorRT. De resultaten van het model kunnen worden geïntegreerd met bedrijfssystemen op uw lokale netwerk, zodat u in realtime kunt reageren op gebeurtenissen.

De oplossing bestaat uit de volgende stappen:

1. Verbind en configureer een AWS Panorama-apparaat met hetzelfde lokale netwerk.
2. Train een ML-model (objectdetectie) om onderdelen en gereedschappen in elk frame te identificeren.
3. Bouw een AWS Panorama-toepassing die de voorspellingen uit het ML-model haalt, een volgmechanisme op elk object toepast en de resultaten naar een realtime database stuurt.
4. De operators kunnen query's naar de database sturen om de onderdelen en gereedschappen te lokaliseren.

Gebruik geval 2

Voor ons volgende gebruik: stel je voor dat we een dashcam maken voor voertuigen die de bestuurder in veel situaties kunnen ondersteunen, zoals het vermijden van voetgangers, op basis van een CV25 bord van Ambaralla. Het hosten van ML-modellen op een apparaat met beperkte systeembronnen kan moeilijk zijn. Laten we in dit geval aannemen dat we al een goed ontwikkeld over-the-air (OTA) leveringsmechanisme hebben om de applicatiecomponenten die nodig zijn op het edge-apparaat te implementeren. We zouden echter nog steeds profiteren van de mogelijkheid om OTA-implementatie van het model zelf uit te voeren, waardoor de levenscyclus van de toepassing en de levenscyclus van het model worden geïsoleerd.

Amazon SageMaker Edge Manager en Amazon SageMaker Neo passen goed bij deze use case.

Edge Manager maakt het voor ML edge-ontwikkelaars gemakkelijk om dezelfde vertrouwde tools in de cloud of op edge-apparaten te gebruiken. Het vermindert de tijd en moeite die nodig is om modellen in productie te krijgen, terwijl u de modelkwaliteit in uw apparaatpark continu kunt bewaken en verbeteren. SageMaker Edge bevat een OTA-implementatiemechanisme waarmee u modellen op de vloot kunt implementeren, onafhankelijk van de applicatie of apparaatfirmware. De Edge Manager-agent stelt u in staat om meerdere modellen op hetzelfde apparaat te gebruiken. De agent verzamelt voorspellingsgegevens op basis van de logica die u beheert, zoals intervallen, en uploadt deze naar de cloud, zodat u uw modellen in de loop van de tijd periodiek opnieuw kunt trainen. SageMaker Edge ondertekent uw modellen cryptografisch, zodat u kunt controleren of er niet mee is geknoeid terwijl het van de cloud naar het edge-apparaat gaat.

Neo is een compiler as a service en past bijzonder goed in deze use case. Neo optimaliseert automatisch ML-modellen voor inferentie op cloudinstanties en edge-apparaten om sneller te werken zonder verlies van nauwkeurigheid. Je begint met een ML-model gebouwd met een van ondersteunde kaders en getraind in SageMaker of ergens anders. Vervolgens kiest u uw doelhardwareplatform (raadpleeg de lijst met ondersteunde apparaten). Met een enkele klik optimaliseert Neo het getrainde model en compileert het in een pakket dat kan worden uitgevoerd met behulp van de lichtgewicht SageMaker Edge-runtime. De compiler gebruikt een ML-model om de prestatie-optimalisaties toe te passen die de best beschikbare prestaties voor uw model extraheren op de cloudinstantie of het edge-apparaat. Vervolgens implementeert u het model als een SageMaker-eindpunt of op ondersteunde edge-apparaten en begint u voorspellingen te doen.

Het volgende diagram illustreert deze architectuur.

De workflow van de oplossing bestaat uit de volgende stappen:

1. De ontwikkelaar bouwt, traint, valideert en maakt het uiteindelijke modelartefact dat op de dashcam moet worden ingezet.
2. Roep Neo aan om het getrainde model te compileren.
3. De SageMaker Edge-agent is geïnstalleerd en geconfigureerd op het Edge-apparaat, in dit geval de dashcam.
4. Maak een implementatiepakket met een ondertekend model en de runtime die door de SageMaker Edge-agent wordt gebruikt om het geoptimaliseerde model te laden en aan te roepen.
5. Implementeer het pakket met behulp van het bestaande OTA-implementatiemechanisme.
6. De edge-applicatie werkt samen met de SageMaker Edge-agent om gevolgtrekkingen uit te voeren.
7. De agent kan (indien nodig) worden geconfigureerd om realtime voorbeeldinvoergegevens vanuit de applicatie te verzenden voor modelbewaking en verfijning.

Gebruik geval 3

Stel dat uw klant een toepassing ontwikkelt die afwijkingen in de mechanismen van een windturbine (zoals de versnellingsbak, generator of rotor) detecteert. Het doel is om de schade aan de apparatuur tot een minimum te beperken door ter plekke lokale beschermingsprocedures uit te voeren. Deze turbines zijn erg duur en staan ​​op moeilijk bereikbare plaatsen. Elke turbine kan worden uitgerust met een NVIDIA Jetson-apparaat om sensorgegevens van de turbine te bewaken. We hebben dan een oplossing nodig om de gegevens vast te leggen en een ML-algoritme te gebruiken om afwijkingen te detecteren. We hebben ook een OTA-mechanisme nodig om de software en ML-modellen op het apparaat up-to-date te houden.

AWS IoT Greengrass V2 samen met Edge Manager passen goed in deze use-case. AWS IoT Greengrass is een open-source IoT edge runtime- en cloudservice waarmee u IoT-toepassingen op uw apparaten kunt bouwen, implementeren en beheren. U kunt AWS IoT Greengrass gebruiken om edge-applicaties te bouwen met behulp van vooraf gebouwde softwaremodules, genaamd componenten, waarmee u uw edge-apparaten kunt verbinden met AWS-services of services van derden. Deze mogelijkheid van AWS IoT Greengrass maakt het gemakkelijk om activa te implementeren op apparaten, waaronder een SageMaker Edge-agent. AWS IoT Greengrass is verantwoordelijk voor het beheer van de levenscyclus van applicaties, terwijl Edge Manager de levenscyclus van het ML-model ontkoppelt. Dit geeft u de flexibiliteit om de hele oplossing te blijven ontwikkelen door onafhankelijk nieuwe versies van de edge-applicatie en ML-modellen te implementeren. Het volgende diagram illustreert deze architectuur.

De oplossing bestaat uit de volgende stappen:

1. De ontwikkelaar bouwt, traint, valideert en maakt het uiteindelijke modelartefact dat in de windturbine moet worden ingezet.
2. Roep Neo aan om het getrainde model te compileren.
3. Maak een modelcomponent met behulp van Edge Manager met AWS IoT Greengrass V2-integratie.
4. Stel AWS IoT Greengrass V2 in.
5. Maak een inferentiecomponent met behulp van AWS IoT Greengrass V2.
6. De edge-applicatie werkt samen met de SageMaker Edge-agent om gevolgtrekkingen uit te voeren.
7. De agent kan (indien nodig) worden geconfigureerd om realtime voorbeeldinvoergegevens vanuit de applicatie te verzenden voor modelbewaking en verfijning.

Gebruik geval 4

Laten we voor ons laatste gebruik eens kijken naar een schip dat containers vervoert, waarbij elke container een aantal sensoren heeft en een signaal naar de computer- en opslaginfrastructuur stuurt die lokaal wordt ingezet. De uitdaging is dat we de inhoud van elke container en de toestand van de goederen willen weten op basis van temperatuur, vochtigheid en gassen in elke container. We willen ook alle goederen in elk van de containers volgen. Er is tijdens de hele reis geen internetverbinding en de reis kan maanden duren. De ML-modellen die op deze infrastructuur draaien, moeten de gegevens voorbewerken en informatie genereren om al onze vragen te beantwoorden. De gegenereerde gegevens moeten maandenlang lokaal worden opgeslagen. De edge-applicatie slaat alle gevolgtrekkingen op in een lokale database en synchroniseert de resultaten met de cloud wanneer het schip de haven nadert.

AWS Sneeuwkegel en AWS Sneeuwbal van het AWS Sneeuw Familie zou heel goed kunnen passen in deze use case.

AWS Snowcone is een klein, robuust en veilig apparaat voor edge computing en gegevensmigratie. Snowcone is ontworpen volgens de OSHA-standaard voor een optilbaar apparaat voor één persoon. Met Snowcone kunt u edge-workloads uitvoeren met behulp van Amazon Elastic Compute-cloud (Amazon EC2) computing en lokale opslag in ruwe, niet-verbonden veldomgevingen zoals booreilanden, zoek- en reddingsvoertuigen, militaire locaties of fabrieksvloeren, evenals afgelegen kantoren, ziekenhuizen en bioscopen.

Snowball voegt meer rekenkracht toe in vergelijking met Snowcone en kan daarom zeer geschikt zijn voor meer veeleisende toepassingen. De Compute Optimized-functie biedt een optionele NVIDIA Tesla V100 GPU samen met EC2-instanties om de prestaties van een applicatie in niet-verbonden omgevingen te versnellen. Met de GPU-optie kunt u toepassingen zoals geavanceerde ML en full motion video-analyse uitvoeren in omgevingen met weinig of geen connectiviteit.

Bovenop de EC2-instantie hebt u de vrijheid om elk type edge-oplossing te bouwen en te implementeren. Bijvoorbeeld: u kunt Amazon ECS of een andere containermanager om de edge-applicatie, Edge Manager Agent en het ML-model als individuele containers te implementeren. Deze architectuur zou vergelijkbaar zijn met Use Case 2 (behalve dat deze meestal offline zal werken), met de toevoeging van een tool voor containerbeheer.

Het volgende diagram illustreert deze oplossingsarchitectuur.

Om deze oplossing te implementeren, bestelt u eenvoudig uw Snow-apparaat bij de AWS-beheerconsole en start uw bronnen.

Conclusie

In dit bericht hebben we de verschillende aspecten van edge besproken waarmee u kunt werken op basis van uw gebruiksscenario. We hebben ook enkele van de belangrijkste concepten rond ML@Edge besproken en hoe het ontkoppelen van de levenscyclus van de applicatie en de levenscyclus van het ML-model u de vrijheid geeft om ze te ontwikkelen zonder enige afhankelijkheid van elkaar. We hebben benadrukt hoe het kiezen van het juiste edge-apparaat voor uw werklast en het stellen van de juiste vragen tijdens het oplossingsproces u kan helpen achteruit te werken en de juiste AWS-services te verfijnen. We hebben ook verschillende use-cases gepresenteerd, samen met referentie-architecturen om u te inspireren om uw eigen oplossingen te creëren die geschikt zijn voor uw werklast.

---

Over de auteurs

Dinesh Kumar Subramani is Senior Solutions Architect bij het UKIR SMB-team, gevestigd in Edinburgh, Schotland. Hij is gespecialiseerd in kunstmatige intelligentie en machine learning. Dinesh werkt graag samen met klanten in verschillende sectoren om hen te helpen hun problemen met AWS-services op te lossen. Naast zijn werk brengt hij graag tijd door met zijn gezin, schaakt hij en geniet hij van muziek in verschillende genres.

Samir Araújo is een AI / ML Solutions Architect bij AWS. Hij helpt klanten bij het creëren van AI / ML-oplossingen die hun zakelijke uitdagingen oplossen met behulp van AWS. Hij heeft gewerkt aan verschillende AI / ML-projecten met betrekking tot computervisie, natuurlijke taalverwerking, prognoses, ML aan de rand en meer. Hij speelt graag met hardware- en automatiseringsprojecten in zijn vrije tijd, en hij heeft een bijzondere interesse voor robotica.

• Coinsmart. Europa's beste Bitcoin- en crypto-uitwisseling.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. GRATIS TOEGANG.
• CryptoHawk. Altcoin-radar. Gratis proefversie.
• Bron: https://aws.amazon.com/blogs/machine-learning/demystifying-machine-learning-at-the-edge-through-real-use-cases/