Vraagt ​​u zich wel eens af wat er achter de verschillende niveaus van autonomie aan voertuigen schuilgaat? Wat het voertuig ziet (perceptie) en hoe het voertuig de acties van verschillende agenten in de scène voorspelt (gedragsvoorspelling) zijn de eerste twee stappen in autonome systemen. Om deze stappen succesvol te laten zijn, zijn grootschalige rijgegevenssets essentieel. Rijgegevenssets bestaan ​​meestal uit gegevens die zijn vastgelegd met behulp van meerdere sensoren zoals camera's, LIDAR's, radars en GPS, in verschillende verkeersscenario's op verschillende tijdstippen van de dag en onder verschillende weersomstandigheden en locaties. De Amazon Machine Learning Solutions-lab werkt samen met de Laboratorium voor Intelligente en Veilige Automobielen (LISA Lab) aan de University of California, San Diego (UCSD) om een ​​grote, rijk geannoteerde, real-world rijgegevensset te bouwen met fijnkorrelige voertuig-, voetgangers- en scènekenmerken.

Dit bericht beschrijft de datasetlabeltaxonomie en labelarchitectuur voor 2D-begrenzingsvakken met behulp van: Amazon SageMaker Grondwaarheid. Ground Truth is een volledig beheerde service voor het labelen van gegevens waarmee u eenvoudig zeer nauwkeurige trainingsgegevenssets kunt bouwen voor workflows voor machine learning (ML). Deze workflows ondersteunen verschillende gebruiksscenario's, waaronder 3D-puntenwolken, video, afbeeldingen en tekst. Als onderdeel van de workflows hebben labelmakers toegang tot ondersteunende labelfuncties zoals automatisch 3D-blokklikken, het verwijderen van vervorming in 2D-afbeeldingen en automatische segmenttools om de tijd die nodig is om datasets te labelen te verminderen. Daarnaast biedt Ground Truth automatische gegevenslabeling, waarbij een ML-model wordt gebruikt om uw gegevens te labelen.

LISA Amazon-MLSL Vehicle Attributes (LAVA)-dataset

LAVA is een diverse, grootschalige dataset met een unieke labelset die we hebben gemaakt om hoogwaardige gelabelde videogegevens te leveren voor een verscheidenheid aan moderne computervisietoepassingen in de automobielsector. We hebben de gegevens vastgelegd met stevig gemonteerde camera's met een sensorgrootte van 1/2.3 inch en een diafragma van f/2.8 met een resolutie van 1920×1080. Het gekozen diafragma, de sensorgrootte en de brandpuntsafstand tussen 1 en 20 meter resulteert in een scherptediepte tot oneindig, wat betekent dat de meeste objecten op de weg scherp zijn. We hebben de gegevens aangevuld met extra navigatiesensoren die lokalisatienauwkeurigheid op centimeterniveau en informatie over traagheidsbewegingen bieden. We hebben de gegevens verzameld tijdens real-world ritten in Zuid-Californië onder verschillende verlichtings-, weers-, verkeers- en wegomstandigheden om de complexiteit en diversiteit van de real-world voertuigbediening vast te leggen. Dit, samen met onze unieke set annotaties, stelde ons in staat om betrouwbare ML-modellen te ontwikkelen voor bestaande automobieltoepassingen en nieuwe die voorheen onhaalbaar waren vanwege het ontbreken van hoogwaardige gelabelde gegevens.

Van de honderden uren aan onbewerkte gegevens die zijn vastgelegd tijdens onze vele schijven voor gegevensverzameling, hebben we eerst segmenten van 10 seconden aan videogegevens verwerkt en samengesteld voor opname in de LAVA-dataset. We hebben de videoclips van 10 seconden handmatig samengesteld om 'interessante' clips te identificeren, zoals die met veel voertuig-/voetgangersactiviteit, kruispunten en manoeuvres zoals het wisselen van rijstrook. We hebben deze clips geselecteerd op basis van hun uniciteit in vergelijking met bestaande clips in de dataset en hun algehele waarde voor de training van ML-modellen voor verschillende taken. Nadat we de clips hebben samengesteld, hebben we ze verwerkt om vervorming te verwijderen en ze gecomprimeerd om ze gemakkelijk te kunnen delen en afspelen. Deze clips hebben we vervolgens opgestuurd voor etikettering volgens de vastgestelde taxonomie.

In dit bericht beschrijven we onze taxonomie, motivatie achter het ontwerp van de taxonomie en hoe we de taxonomie in kaart brengen voor Ground Truth-labeltaken om een ​​labelpijplijn te creëren die snel hoogwaardige annotaties produceert en toch flexibel is voor wijzigingen in labelprioriteiten.

LAVA dataset taxonomie

De volgende code illustreert onze LAVA-datasettaxonomie:

DRIVE_LEVEL_ATTRIBUTES |── drive_id |── weather: clear|overcast|partly cloudy|rainy|foggy|undefined |── time_of_day: daytime|night|dawn/dusk|undefined └── route: route taken for data capture

CLIP_LEVEL_ATTRIBUTES |── DRIVE_LEVEL_ATTRIBUTES |── clip_id |── scene: highway|tunnel|residential|parking lot|city street|gas station|intersection|roundabout|school zone|contruction|entrance|exit|undefined └── traffic: free-flowing|stop-and-go|undefined └── traffic_density: high|medium|low

FRAME_LEVEL_ATTRIBUTES |── CLIP_LEVEL_ATTRIBUTES |── frame_no |── timestamp |── ignore (x N) | |── 2d_box_coordinates (left, top, right, bottom) ├── vehicle (x N) | |── 2d_box_coordinates (left, top, right, bottom) | |── track_id | |── type: car|van|truck|bus|motorbike|bicycle|undefined | |── occlusion: not occluded|partially occluded|major occlusion | |── license plate | | └── 2d_box_coordinates ├── pedestrian (x N) | |── 2d_box_coordinates (left, top, right, bottom) | |── occlusion: not occluded|partially occluded|major occlusion | └── track_id ├── lane (x N) | |── polyline_coordinates | |── lane_style: solid|dashed | |── lane_type: crosswalk|double other|double white|double yellow|road curb|single other|single white|single yellow | └── lane_direction: horizontal|vertical ├── traffic_light (x N) | |── 2d_box_coordinates (left, top, right, bottom) | |── state: red|green|yellow|undefined | |── is_front: true|false | └── occlusion: not occluded|partially occluded|major occlusion ├── traffic_sign (x N) |── 2d_box_coordinates (left, top, right, bottom) |── type: stop|yield|do not enter|wrong way|school zone|railroad|red and white regulatory|white regulatory|highway construction and maintenance|warning |── is_front: true|false └── occlusion: not occluded|partially occluded|major occlusion

De labeling-taxonomie bestaat uit een hiërarchische structuur met attributen op drive-niveau helemaal bovenaan. Deze kenmerken omvatten eigenschappen die van toepassing zijn op een hele rit voor gegevensverzameling, zoals het weer, de route of het tijdstip van de dag.

Onder de kenmerken op schijfniveau bevinden zich kenmerken op clipniveau, die overeenkomen met de videosegmenten van 10 seconden waaruit de gegevensset bestaat. Deze kenmerken op clipniveau nemen kenmerken op stationsniveau over van de bovenliggende schijf en bevatten ook extra velden zoals scène, verkeersdichtheid en verkeersstroom. Hierdoor kunnen gebruikers fijnmazige labels toewijzen aan elke afzonderlijke clip in de dataset, en kunnen gebruikers ook experimenten uitvoeren die meten hoe modellen presteren onder zeer specifieke scène-, verkeers- of weersomstandigheden. Dit soort analyse is uiterst waardevol om de gereedheid en tekortkomingen van modellen te meten voordat ze in de praktijk worden geïmplementeerd, en is niet zo gemakkelijk haalbaar in andere populaire datasets.

Onder attributen op clipniveau staan ​​de attributen op frameniveau onderaan de labelhiërarchie, die overeenkomen met elk frame in het videosegment van 10 seconden. Zoals eerder nemen de attributen op frameniveau over van attributen op clipniveau (en indirect van attributen op driveniveau) en bevatten ze bovendien velden die overeenkomen met de locaties en eigenschappen van verschillende interessante objecten in een afbeeldingsframe. De objecten van belang kunnen grofweg worden onderverdeeld in statische en dynamische objecten.

Voor dynamische objecten zoals voertuigen en voetgangers hebben we de 2D-boxlocaties en track-ID's gelabeld. Naast deze standaardattributen die in de meeste datasets worden aangetroffen, hebben we ook fijnmazige attributen voor voertuigen gelabeld, zoals kentekenplaatlocaties en de locaties en staat van het voor- en achterlicht. Dit geeft gebruikers de mogelijkheid om modellen te trainen die verder gaan dan alleen het detecteren van voertuiglocaties.

Vervolgens hebben we ons voor statische objecten in de scène gericht op rijstroken, verkeersborden en verkeerslichten. In tegenstelling tot populaire datasets voor rijstrookdetectie die zich beperken tot maximaal vier rijstroken, hebben we elke rijstrook (met behulp van polylijnen) en het type markering in onze rijrichting gelabeld. We hebben ook stoepranden en zebrapaden gelabeld omdat het belangrijke markeringen zijn die de vrije ruimte en het rijgedrag dicteren. Voor verkeerslichten hebben we elk zichtbaar licht en de staat ervan gelabeld.

Ten slotte hebben we voor verkeersborden elk zichtbaar bord en het type ervan gelabeld (zoals stoppen, opgeven en niet binnenkomen). Omdat we elk zichtbaar stoplicht en bord hebben gelabeld, hebben we ook degenen die overeenkomen met onze rijrichting gemarkeerd met een binaire indicator: is_front uit de voorgaande taxonomie. Dit geeft ons het voordeel dat we veel gelabelde borden en lichten hebben, wat de training van modellen verbetert, terwijl we nog steeds in staat zijn om degenen te identificeren die het rijgedrag daadwerkelijk beïnvloeden. Deze labeling-taxonomie stelt gebruikers in staat om de meeste typen computervisiemodellen te trainen die van belang zijn in moderne automobieltoepassingen, terwijl een aantal van de tekortkomingen in bestaande datasets cruciaal worden aangepakt.

Een voorbeeld van rijstrooklabels wordt getoond in de volgende afbeelding. De lijn loodrecht op het voertuig is het zebrapad en het label bevat de rijstrookstijl, het type en de richting. Evenzo hebben de rijstrookverdeler aan de linkerkant en de stoeprand aan de rechterkant van het voertuig labels volgens de voorgaande taxonomie.

Een gelabeld voertuig wordt getoond in de volgende afbeelding. Het voertuiglabel bestaat uit het type en occlusieniveau, naast de interne objecten van het voertuig: achterlichten met staat en kentekenplaat.

Het volgende voorbeeld toont gelabelde verkeerslichten in verschillende toestanden, oriëntaties en occlusieniveaus, en verkeersborden met verschillende typen, oriëntaties en occlusieniveaus.

Labeling-architectuur

Bij het in kaart brengen van zo'n complexe taxonomie aan feitelijke labeltaken in Ground Truth, zijn er vaak meerdere afwegingen te maken over welke delen van de taxonomie zijn gegroepeerd in labeltaken, welke modaliteiten en annotatietypen in Ground Truth goed aansluiten bij het probleem, en of u een batch- of streamingtaakmodel wilt volgen.

Omdat we voortdurend nieuwe videoclips naar labelers wilden sturen zodra ze verzameld en beschikbaar zijn, gebruikten we Ground Truth streaming labeltaken. Dit stelde ons ook in staat om labels te ontvangen en kwaliteitsborging en -aanpassing in realtime uit te voeren nadat elke clip is gelabeld. Het verminderde ook het totale aantal labeltaken dat we parallel moesten laten lopen, omdat we slechts één langlevende streaming labeltaak per taaktype nodig hadden in plaats van meerdere taken per taaktype, afhankelijk van de batchgrootte. Voor meer informatie over de voordelen van het streamen van labeltaken, zie Realtime datalabelpijplijn voor ML-workflows met Amazon SageMaker Ground Truth.

Naast de eis van continue aanpassing, bestaat de taxonomie uit meerdere klassen en op basis van meerdere annotatietypes. Het labelen van voertuigen vereist bijvoorbeeld het gebruik van een taak voor het volgen van video-objecten om een ​​consistente instantie-ID per object te produceren in de loop van de videoclip om beweging vast te leggen, maar het labelen van verkeersborden vereist alleen detectie van video-objecten. De taxonomie vereist ook verschillende annotatietypen binnen het taaktype labeling. Voor voertuigen en verkeersborden zijn bijvoorbeeld begrenzingsvakken nodig, maar voor rijstroken zijn lijnsegmenten nodig met behulp van een polylijntool om de curve van straatmarkeringen beter te modelleren.

Het volgende is bijvoorbeeld een frame van een video die wordt gelabeld met een video-objecttrackingtaak met behulp van begrenzingsvakannotaties.

De volgende soortgelijke clip gebruikt daarentegen polylijnen-annotatie, waarbij lijnsegmenten de rijstroken definiëren.

Voor meer informatie over de beschikbare annotatietypen die worden ondersteund voor verschillende gegevensmodaliteiten, zie Maak een labelcategorieconfiguratiebestand met labelcategorie- en frameattributen.

We hebben vier hoofdredenen gevonden om onze taxonomie op te splitsen in meerdere parallelle labeltaken in plaats van te proberen alle labels voor een clip in één enkele taak uit te voeren:

• Overlappende annotaties verminderen de doorvoer van de labeler – Als een scène rijk is aan te identificeren objecten, betekent dit dat er veel sterk overlappende annotaties in één taak zullen zijn. Dit kan de doorvoer van werknemers verminderen en het aantal fouten dat door werknemers wordt gemaakt, vergroten.
• Voor verschillende annotatietypen kunnen afzonderlijke taken nodig zijn – Tegenwoordig staat SageMaker Ground Truth slechts één AnnotationType per labeltaak toe. Dit vereist het splitsen van de taxonomie gelabeld door begrenzingsvakken van die gelabeld door polylijnen.
• Meerdere labeltaken vergroten de flexibiliteit – Met meerdere taken, aangezien de prioriteiten voor labels verschuiven afhankelijk van uw eindgebruikers, is het eenvoudiger om het aantal medewerkers en resources opnieuw toe te wijzen naarmate de prioriteiten verschuiven. Als de eindgebruiker bijvoorbeeld probeert een model te bouwen dat slechts een subset van de algemene taxonomie gebruikt, zoals een voertuigdetector, kunnen labelers alle clips labelen voor alleen voertuigen en andere taken in het werknemersportaal negeren totdat ze een hogere prioriteit krijgen .
• Meerdere banen maken specialisatie mogelijk – Naarmate de specificaties voor gegevenslabels complexer worden, zijn er vaak hoge kosten verbonden aan het omscholen van gegevenslabels in verschillende modaliteiten. Het hebben van parallelle banen betekent dat bepaalde werknemers specialisten kunnen worden in alleen het labelen van verkeersborden, terwijl anderen zich kunnen specialiseren in rijstrookannotaties, waardoor de algehele doorvoer toeneemt.

Om ervoor te zorgen dat annotaties van hoge kwaliteit worden geproduceerd, hebben we een realtime aanpassingsmogelijkheid toegevoegd door een clip naar de invoer te publiceren Amazon eenvoudige meldingsservice (Amazon SNS) onderwerp van een streamingtaak op het eerste niveau voor een taaktype, waarna na voltooiing de gelabelde clip wordt verzonden naar een streamingtaak voor aanpassing die een gespecialiseerde groep meer bekwame annotators gebruikt om de uitvoer van de eerste doorgang te beoordelen. Deze senior annotators voeren kwaliteitsborging uit en wijzigen labels waar nodig. Deze aanpassingsmogelijkheid wordt ondersteund door Ground Truth's labelaanpassing en verificatiemogelijkheden.

Een eenvoudige manier om deze labeltaken met elkaar te verbinden, is door het output SNS-onderwerp van de streamingtaak op het eerste niveau te gebruiken en dit rechtstreeks te verbinden met het invoer-SNS-onderwerp van de streamingtaak op het tweede niveau (zie voor meer informatie Realtime datalabelpijplijn voor ML-workflows met Amazon SageMaker Ground Truth). We hebben een orkestratielaag bovenop Ground Truth toegevoegd met behulp van AWS Stap Functies, Amazon DynamoDB en AWS Lambda om een ​​videoclip opnieuw in te dienen wanneer een initiële of aanpassingslabeltaak niet is voltooid binnen de time-outvensters van Ground Truth.

Architectuur diagram

Nu we de algemene vereisten hebben behandeld die onze labelarchitectuur aandreven, laten we de functionaliteit van de stapfunctie die we hebben geïmplementeerd om het verzenden van een gegevensobject naar elke lopende streamingtaak af te handelen, op hoog niveau bekijken, terwijl randgevallen rond de vervaldatum worden afgehandeld.

Elke combinatie van videoclip en labelcategorieconfiguratie heeft een onafhankelijk lopende stapfunctieaanroep die ervoor zorgt dat de videoclip door elke gewenste labeltaak wordt geleid. Elke run beheert de status voornamelijk via DynamoDB, waarbij alleen wordt vertrouwd op de status van de statusmachine om de annotatietaak-ID's door te geven aan volgende statussen. De DynamoDB-tabel die verantwoordelijk is voor het volgen van annotatietaken houdt alle metagegevens bij, waaronder de clip-ID, invoermanifestlocatie van de clip, uitvoermanifestlocatie van labeltaakuitvoer en labelkenmerknaam, naast statusinformatie (compleet, mislukt of gestopt).

De oplossing biedt ook een API voor het starten van streaming labeltaken met verschillende labelcategorieconfiguraties. Deze streamingtaak wordt gedeeld door alle clips die worden verzonden voor labeling en die dezelfde modaliteit hebben (bijvoorbeeld begrenzingsvakken voor voertuigen). De oplossing slaat deze labeltaken ook op naam op in een aparte DynamoDB-tabel die metadata bijhoudt over de streamingtaken die via de oplossing zijn gestart, inclusief invoer- en uitvoer-SNS-onderwerpen. Met een aparte API voor het beheer van de levenscyclus van streamingtaken kunnen we geen overbodige labeltaken per clip lanceren, maar alleen taken starten voor de unieke modaliteiten die we willen labelen.

Een SageMaker-notebookinstantie start elke stapfunctie-run (ook wel een annotatietaak genoemd) en doorloopt een lijst met geüploade videoclips in Amazon eenvoudige opslagservice (Amazon S3) en roept de API voor het maken van annotaties aan voor elk clip- en modaliteitspaar. De API voor het maken van de annotatietaak slaat de gevraagde annotatietaak op in DynamoDB en start vervolgens een stapfunctie-run om de gevraagde taak uit te voeren. De notebook biedt de invoerlocatie van de clip, het aantal frames per seconde en de lijst met labeltaken die deel uitmaken van de workflow naar de API voor het maken van annotaties, die die informatie doorgeeft aan elke stapfunctie die wordt uitgevoerd. De volgende annotatietaakdefinitie definieert bijvoorbeeld dat de gegeven clip moet worden verzonden naar een streaminglabeltaak VOTVehicle, dan moet de uitvoer van deze eerste streamingtaak naar een tweede taak worden gestuurd AdjVOTVehicle voor aanpassing:

{ "labelingJobs": [ { "jobName": "VOTVehicle", "inputConfig": { "clipS3Uri": "s3://clip_bucket_fake/clip_id_1234", "fps": 1 }, "jobLevel": 1 }, { "jobName": "AdjVOTVehicle", "inputConfig": { "chainFromJobName": "VOTVehicle" }, "jobLevel": 2 } ]
}

Het volgende statusmachinediagram beschrijft de algemene logische stroom voor elke gemaakte annotatietaak, die een videoclip en een lijst met labeltaken omvat om de videoclip door te sturen. Elke videoclip doorloopt een transformatielus (Transformation, IsDoneTransforming, WaitForTransformComplete), die beeldframes extraheert met een bepaalde snelheid van frames per seconde. Na frame-extractie stuurt de statusmachine de frames naar een Ground Truth-streamingtaak voor initiële labeling (TriggerLabelingFirstLevel, CheckForFirstLevelCompletion).

Nadat het labelen is voltooid, stuurt de statusmachine de frames en labels naar de labelbeoordeling in de labeltaak op het tweede niveau (TriggerLabelingSecondLevel, CheckForSecondLevelCompletion).

Na aanpassing verwerkt de statusmachine de labels (PostProcessing) door samenvattende metadata over de clips te berekenen en opgeslagen in Amazon S3 (Complete).

De toestandsmachine bevat ook omgekeerde toestandsovergangen terug van CheckForFirstLevelCompletion naar TriggerLabelingFirstLevel en van CheckForSecondLevelCompletion naar TriggerLabelingSecondLevel. Deze statusovergangen geven de pijplijn de mogelijkheid om opnieuw te proberen een clip voor labeling te verzenden als een vervaldatum of probleem wordt gedetecteerd tijdens de eerste labelronde. We behandelen deze uitzonderingsgevallen in meer detail in de volgende sectie.

SNS-onderwerpen verbinden en de levenscyclus van de videoclip beheren

Voor het gebruik van streamingtaken voor langlopende annotatietaken is een orkestratielaag vereist, zoals eerder vermeld. Om uit te leggen waarom, doorlopen we een directe benadering voor het verbinden van streaming labeling-taken via Amazon SNS en beschrijven we de mogelijke storingsstatussen.

Het volgende diagram beschrijft een manier om verbinding te maken tussen de initiële labeltaak en de aanpassingstaak waarvoor geen tussenkomst van een orkestratiestapfunctie vereist is.

Deze aanpak werkt goed wanneer taken snel worden voltooid (vóór de TaskAvailabilityLifetimeInSeconds opgegeven tijdens het maken van een labeltaak). Wanneer clips echter in de wachtrij staan ​​voor labeling voor een langere tijd dan de taakbeschikbaarheid, kan de clip worden neergezet Amazon Simple Queue-service (Amazon SQS) of Ground Truth in de pijplijn.

In plaats van deze aanpak hebben we de directe Amazon SNS-verbinding tussen de labeltaken verbroken en hebben we in plaats daarvan de CheckForFirstLevelCompletion state wacht op het SNS-onderwerp van de initiële labeltaak en behandel optioneel nieuwe pogingen voordat u verder gaat naar TriggerLabelingSecondLevel. Een DynamoDB-tabel houdt de SNS-onderwerpnamen bij voor elke labeltaak wanneer er een nieuwe streamingtaak wordt gemaakt.

We beschrijven elk geval van verval en een beperking in de volgende secties.

Omgaan met tijdslimieten van Amazon SQS

Elke streaming-labeltaak verbindt het opgegeven invoer-SNS-onderwerp met een SQS-wachtrij. Als taken binnen de labeltaak zijn voltooid, haalt Ground Truth items uit de wachtrij en maakt ze beschikbaar voor labeling. Amazon SQS heeft een limiet van 14 dagen voordat items van de invoerwachtrij verlopen, wat betekent dat als werknemers niet genoeg taken voltooien zodat de wachtrij niet de limiet van 14 dagen voor een bepaald item bereikt, dat item wordt verwijderd.

Een manier om dit aan te pakken is om clips periodiek opnieuw te verzenden met behulp van een unieke deduplicatie-ID per clip. Deze deduplicatie-ID kan samen met een clip worden gespecificeerd op het Amazon SNS-bericht. Voor meer informatie over deduplicatie-ID's en sleutels, zie Afhandeling van dubbele berichten. Zolang we de clip vóór de limiet van 14 dagen opnieuw verzenden, hebben we altijd een niet-verlopen versie in de wachtrij. Als Ground Truth twee clips ontvangt met dezelfde deduplicatie-ID, negeert het het duplicaat, waardoor deze bewerking idempotent is, ongeacht hoeveel dubbele gegevensobjecten we naar de taak sturen. We hebben een vrij korte hernieuwde pogingsperiode van 5 dagen ingesteld om ervoor te zorgen dat we herhaaldelijk de leeftijd van het gegevensitem in Amazon SQS vernieuwen voor het geval we ooit de 14-daagse periode bereiken.

Tijdslimieten voor werknemersdashboards hanteren

Een ander verloopgeval dat moet worden afgehandeld, is wanneer een object is opgenomen door de streaming-labelingtaak en beschikbaar is in de werknemersportal, maar niet kan worden gelabeld binnen de TaskAvailabilityLifetimeInSeconds. Deze time-out wordt gespecificeerd in de HumanTaskConfig van het labelen van banen. Een manier om dit probleem te verminderen, is door de MaxConcurrentTaskCount van de labeltaak. Dit vermindert het aantal taken dat Ground Truth uit zijn invoerwachtrij neemt, wat betekent dat de taaktime-out alleen actief is voor een kleiner aantal taken tegelijk. Dit is echter niet altijd een oplossing, want als het aantal gelijktijdige taken te laag wordt afgestemd, kunnen werknemers zonder taken komen te zitten terwijl extra taken uit de invoerwachtrij worden verplaatst en voorverwerkt voor labeling.

We hebben dit afgehandeld door een grote a MaxConcurrentTaskCount en het detecteren van het verlopen van de Ground Truth-taak op het output-SNS-onderwerp van de labeltaak. Wanneer de statusmachine een taakverval van Ground Truth detecteert, wordt het data-object opnieuw verzonden om de expiratietimer terug te zetten naar 0. Een waarschuwing is dat, omdat Ground Truth de deduplicatie-ID van het verlopen data-item al heeft gezien, we de clip opnieuw moeten verzenden met een gewijzigde deduplicatie-ID, zodat Ground Truth de taak als nieuw ziet en deze in het werknemersportaal toont.

Voor het uitvoeren van deze nieuwe pogingen en het bewaken van clips terwijl ze het labelingsproces doorlopen, is de externe orkestratie vereist die is beschreven in het voorgaande stapfunctiestatusdiagram. De step-functie handelt beide eerder genoemde gevallen af ​​door ofwel de vorige deduplicatie-ID opnieuw te gebruiken als we een nieuwe poging doen om Amazon SQS-time-outs af te handelen, of door een nieuwe deduplicatie-ID te genereren als we weten dat het data-object een vervaldatum heeft gehad in Ground Truth.

Stappen voor architectuurdiagram

Nu we faalgevallen en oplossingen voor langlopende streamingtaken hebben gezien, kunnen we zien hoe deze worden gemodelleerd in de stapfunctie en kunnen we nader bekijken hoe toestandsovergangen plaatsvinden.

De Trigger* statussen van de algemene stapfunctie sturen clips naar de labeltaken. Deze activeringsstatus gaat naar een controle op voltooiingsstatus die wacht tot de clip wordt gelabeld. Er is een toestandsovergang terug van CheckForFirstLevelCompletion naar TriggerLabelingFirstLevel. Hierdoor kan de controle op voltooiingsstatus teruggaan wanneer een clip niet kon worden gelabeld vanwege een van de voorgaande foutgevallen.

CheckForFirstLevelCompletion voert een gebeurtenisgestuurde wachttijd uit door gebruik te maken van stapfuncties taak tokens. De statusmachine slaat het taaktoken van de huidige statusmachine op in DynamoDB bij het bereiken van CheckForFirstLevelCompletion, dan laat het een Lambda-functie die luistert naar elke streaming-taakuitvoer SNS-onderwerp het aanroepen afhandelen SendTaskSuccess or SendTaskFailure naar de staatsmachine lopen. Dit betekent dat onmiddellijk nadat de labeltaak op een bepaalde clip is voltooid, de statusmachine-run van de clip gedeblokkeerd wordt en naar de volgende niveaus stroomt. Het volgende diagram illustreert deze workflow.

AWS Step Functions codevoorbeelden

De volgende Stap Functies codeblokken beschrijven de: TriggerFirstLabelingLevel en CheckForFirstLevelCompletion toestandslus in het voorgaande toestandsdiagram.

De TriggerFirstLabelingLevel state voert de Lambda-functie uit die labeltaken start. Bij een succesvolle uitvoering van de functie gaat de toestandsmachine over naar de CheckForFirstLevelCompletion staat. Bij een fout probeert de statusmachine de functie opnieuw uit te voeren als het een bekende tijdelijke fout is, of gaat over naar de BatchError staat.

"TriggerLabelingFirstLevel": { "Type": "Task", "Resource": "arn:aws:lambda:<ACCOUNT>:function:smgt-workflow-sf-trigger-labeling-job", "Parameters": { "parent_batch_id.$": "$.transformation_step_output.batch_id", "job_level": 1 }, "ResultPath": "$.first_level_step_output", "Next": "CheckForFirstLevelCompletion", "Retry": [{ "ErrorEquals": [ "Lambda.TooManyRequestsException" ], "IntervalSeconds": 5, "MaxAttempts": 8, "BackoffRate": 2 }], "Catch": [{ "ErrorEquals": [ "States.ALL" ], "Next": "BatchError", "ResultPath": "$.error-info" }]
}

Het volgende Stap Functies codeblok beschrijft de: CheckForFirstLevelCompletion toestand in het voorgaande toestandsdiagram. Deze status voert een Lambda-functie uit die wacht op de voltooiing van de labeltaak. De status wacht 432,000 seconden (5 dagen) op voltooiing van het labelen, waarna de statusmachine teruggaat naar TriggerLabelingFirstLevel en stuurt de video terug naar de Ground Truth SQS-wachtrij. Bij een fout probeert de statusmachine de Lambda-functie opnieuw uit te voeren als de fout van voorbijgaande aard is, en gaat over naar de BatchError staat als de fout niet opnieuw kan worden geprobeerd, of teruggaat naar TriggerLabelingFirstLevel als de foutstatus is verlopen, wat aangeeft dat het gegevensitem van de streamingtaak is verlopen. Deze laatste foutstatus maakt het mogelijk om items onmiddellijk na de vervaldatum opnieuw te verzenden wanneer de vervaldatum plaatsvindt binnen Ground Truth.

"CheckForFirstLevelCompletion": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken", "Parameters": { "FunctionName": "smgt-workflow-sf-wait-batch-completion", "Payload": { "token.$": "$$.Task.Token", "execution_id.$": "$$.Execution.Id", "batch_id.$": "$.first_level_step_output.batch_id" } }, "ResultPath": "$.first_level_completion_step_output", "TimeoutSeconds": 432000, "Next": "TriggerLabelingSecondLevel", "Retry": [{ "ErrorEquals": [ "Lambda.TooManyRequestsException" ], "IntervalSeconds": 5, "MaxAttempts": 8, "BackoffRate": 2 }], "Catch": [ { "ErrorEquals": [ "States.Timeout", "expired" ], "Next": "TriggerLabelingFirstLevel", "ResultPath": "$.error-info" }, { "ErrorEquals": [ "States.ALL" ], "Next": "BatchError", "ResultPath": "$.error-info" } ]
},

Voorbeelden van AWS Lambda-labels op het eerste niveau

De TriggerFirstLabelingLevel staat genoemd in de vorige sectie roept de smgt-workflow-sf-trigger-labeling-job Lambda-functie om dataset-objecten (zoals videoclips) naar een lopende streaming-labelingtaak te sturen.

Het volgende codeblok van de Lambda-functie beschrijft hoe u een taak start vanuit een set frames. De lambda_handler functie ontvangt het etiketteringsniveau (etikettering op het eerste niveau of toewijzing op het tweede niveau) en de ID van de bovenliggende partij. Het filtert de banen die moeten worden gestart op functieniveau en roept de trigger_labeling_job functie. Ten slotte slaat het de metagegevens van de labeltaak op in de DynamoDB-database als de taak geen nieuwe poging is.

def lambda_handler(event, context): """Figures out which job level tasks need to be created in a level of the step function execution.""" parent_task_id = event["parent_task_id"] job_level = event["job_level"] parent_task = db.get_task_metadata(parent_task_id) # Use a unique ID per step function execution so we can trace # which step function execution sent the data_object. execution_arn = parent_task[Attributes.STEP_FUNCTION_EXECUTION_ID] execution_id = execution_arn.rsplit("-", 1)[1] metadata_type = MetaDataTypeByJobLevel[job_level] # Filter jobs by job level to figure out which jobs should be running. labeling_jobs = parent_task[Attributes.LABELING_JOBS] current_jobs = [job for job in labeling_jobs if job["jobLevel"] == job_level] log.logging.info("Kicking off %d jobs for level %d", len(current_jobs), job_level) task_id = f"{parent_task_id}-{metadata_type.lower()}" prev_task_data = db.get_task_metadata(task_id) # If the task was already sent to the labeling job and hasn't been marked expired. is_retry = prev_task_data is not None and ( prev_task_data[Attributes.TASK_STATUS] == TaskStatus.IN_PROGRESS ) for job in current_jobs: trigger_labeling_job(parent_task_id, task_id, execution_id, job, is_retry) # Only generate the labeling job meta task in the DB if we're not retrying. if not is_retry: try: db.insert_perform_labeling_job_metadata( parent_task_id=parent_task_id, task_id=task_id, task_status=TaskStatus.IN_PROGRESS, task_metadata_type=metadata_type, num_children_taskes=len(current_jobs), ) except botocore.exceptions.ClientError as err: raise Exception(f"failed to put task id {task_id}") from err return { "task_id": task_id, }

De volgende code toont de functie die de labeltaken start: trigger_labeling_job, trigger_streaming_job en send_frames_to_streaming_job.

De trigger_labeling_job functie roept de trigger_streaming_job functie met parameters die nodig zijn voor het verzenden van een annotatietaak naar een bepaalde labeltaak. De trigger_streaming_job functie haalt het invoer-SNS-onderwerp en invoermanifest op en maakt een bestand voor uitvoerlabels. Het roept dan de send_frames_to_streaming_job met het invoer-SNS-onderwerp, manifest en verschillende ID's.

De send_frames_to_streaming_job loopt door elk frame, maakt een deduplicatiesleutel, slaat het frame op DynamoDB op en publiceert het frame naar het output-SNS-onderwerp. De logica voor het afhandelen van zowel Amazon SQS als Ground Truth expiraties is gecodeerd in deze functie. Het kan een nieuwe deduplicatie-ID regenereren in het geval van een vervaldatum van Ground Truth, of gewoon de bestaande deduplicatie-ID hergebruiken als de nieuwe poging is om te voorkomen dat het item verloopt in Amazon SQS.

def trigger_labeling_job(input_task_id, task_id, execution_id, job_params, is_retry): """Start a labeling job and store metadata in JOB_LEVEL DB entry""" job_input = input_config_to_job_input( input_task_id, job_params["jobName"], job_params["jobLevel"], job_params["inputConfig"], ) trigger_streaming_job(task_id, execution_id, job_input, job_params, is_retry)
def trigger_streaming_job( parent_task_id, execution_id, job_input, job_params, is_retry
): """Start a streaming job""" job_name = job_params["jobName"] streaming_job_details = db.get_job_by_name(job_name) sns_arn = streaming_job_details["InputSnsArn"] task_id = f"{parent_task_id}-{job_name}" input_manifest_lines = fetch_s3(job_input.input_manifest_s3_uri).splitlines() data_object_count = len(input_manifest_lines) if not is_retry: # Create an empty file at this path to indicate this is # where the listener should write output annotations. s3_output_path = ( f"s3://{task_processing_bucket_name}/task_manifests/{task_id}/data.manifest" ) put_s3(s3_output_path, "") db.insert_job_level_metadata( parent_task_id=parent_task_id, task_id=task_id, task_status=TaskStatus.WAIT_FOR_SMGT_RESPONSE, labeling_job_name=job_name, label_attribute_name=streaming_job_details["LabelAttributeName"], label_category_s3_uri=streaming_job_details["LabelCategoryConfigS3Uri"], job_input_s3_uri=job_input.input_manifest_s3_uri, job_output_s3_uri=s3_output_path, num_data_objects=data_object_count, ) send_data_objects_to_streaming_job( task_id, execution_id, input_manifest_lines, sns_arn, is_retry )
def send_data_objects_to_streaming_job( task_id, execution_id, input_manifest_lines, sns_arn, is_retry,
): """Processes a given manifest by creating data_objects in db and sending to SNS""" log.logging.info( f"Sending {len(input_manifest_lines)} data_objects to {sns_arn} for task {task_id}" ) published_messages = [] # Content should be in ground truth manifest format, one json string per line. for data_object_index, label_object in enumerate(input_manifest_lines): log.logging.info(f"Parsing and sending data_object {data_object_index}") label_object = json.loads(label_object) data_object_id = f"{task_id}/{data_object_index}" # Fresh deduplication id to use. try_hash = str(uuid.uuid4())[:4] new_dedup_key = f"{execution_id}/{try_hash}/{data_object_id}" # Deduplication key used in output message. act_dedup_key = None if not is_retry: # This is the first time we've ever generated tasks, so write them to database # and use the brand new deduplication id. response = db.insert_data_object_task_metadata( # Tasks are hierarchical, the current task id becomes the parent task of the data object # level tasks. task_id, # The data object id becomes the new "task_id". data_object_id, TaskStatus.IN_PROGRESS, data_object_index, new_dedup_key, ) log.logging.info( f"data_object task metadata db insert response: {response}" ) act_dedup_key = new_dedup_key else: # We've already sent data objects to labeling jobs, so we are performing # a re-send here. Get the previous task's metadata to figure out what # the data object's state is. prev_data_object_data = db.get_task_metadata(data_object_id) if ( prev_data_object_data[Attributes.TASK_STATUS] == TaskStatus.FRAME_SMGT_EXPIRATION ): # The data object was explicitly marked as expired by the listener lambda. If we # tried to resend with the same deduplication id, the data object wouldn't # show back up in the worker portal because SageMaker Ground Truth will filter it. db.update_task_status(data_object_id, TaskStatus.IN_PROGRESS) act_dedup_key = new_dedup_key else: # Otherwise we are just doing a retry to keep the data objects in the input SQS queue # from getting dropped due to the 2 week limit. Here we reuse the same deduplication # id as before since SageMaker Ground Truth hasn't actually processed this data object # and seen the deduplication id yet. If we used a unique data object, we would end up # with duplicate data objects in the worker portal. act_dedup_key = prev_data_object_data[Attributes.FRAME_DEDUP_ID] log.logger.info("Using deduplication key: %s", act_dedup_key) label_object["dataset-objectid-attribute-name"] = SNS_DEDUPLICATION_KEY_NAME # Use data_object index into manifest as key. # This will allow the listener lambda to find the metadata record associated with # this data_object. label_object[SNS_DEDUPLICATION_KEY_NAME] = act_dedup_key published_messages.append(label_object) topic = sns.Topic(sns_arn) response = topic.publish(Message=json.dumps(label_object)) log.logging.info(f"sns topic publish response: {response}") return published_messages

Conclusie

In dit bericht hebben we de LAVA-dataset, een dataverzamelingsstrategie, labeltaxonomie en labelarchitectuur voor 2D-begrenzingsvakken beschreven met behulp van Ground Truth. De dataset was het resultaat van een samenwerking tussen de Amazon Machine Learning Solutions-lab en Laboratorium voor Intelligente en Veilige Automobielen (LISA Lab) aan de Universiteit van Californië, San Diego (UCSD)

De labeling-architectuuroplossing die is ontwikkeld voor de LAVA-dataset maakt voortdurende grootschalige videoverzameling en labelinginspanningen mogelijk. De labelarchitectuur bestaat uit een pijplijn die de labellevenscyclus van een videoclip beheert vanaf frame-extractie, labeling op het eerste en tweede niveau en time-outs. Deze pijplijn produceert annotaties van hoge kwaliteit en is flexibel voor wijzigingen in labelprioriteiten.

 De Amazon ML Solutions-lab koppelt uw team aan ML-experts om u te helpen bij het identificeren en implementeren van de meest waardevolle ML-kansen van uw organisatie. Als u hulp nodig heeft om uw gebruik van ML in uw producten en processen te versnellen, neem dan contact op met de Amazon ML Solutions-lab.

Dankwoord

De auteurs willen LISA's datasetverzameling en annotatieteam bedanken, waaronder Larry Ly, David Lu, Sean Liu, Jason Isa, Maitrayee Keskar, Anish Gopalan, Ethan Lee en Tristan Philip.

Over de auteurs

Ninad Kulkarni is een datawetenschapper in het Amazon Machine Learning Solutions Lab. Hij helpt klanten ML en AI over te nemen door oplossingen te bedenken om hun zakelijke problemen aan te pakken. Recentelijk heeft hij voorspellende modellen gebouwd voor sport- en automobielklanten.

Jeremy Feltracco is Software Development Engineer bij het Amazon ML Solutions Lab bij Amazon Web Services. Hij gebruikt zijn achtergrond in computervisie, robotica en machine learning om AWS-klanten te helpen hun AI-acceptatie te versnellen.

Saman Sarraf is Data Scientist bij de Amazon ML Solutions-lab​ Zijn achtergrond ligt in toegepaste machine learning, waaronder deep learning, computervisie en voorspelling van tijdreeksgegevens.

Akshay Rangesh is een PhD-kandidaat in Electrical & Computer Engineering aan UCSD. Zijn onderzoeksinteresses omvatten computervisie en machine learning, met een focus op objectdetectie en -tracking, herkenning van menselijke activiteit en veiligheidssystemen voor bestuurders in het algemeen. Hij is ook bijzonder geïnteresseerd in sensorfusie en multimodale benaderingen voor realtime-algoritmen.

Ross Greer is een PhD-student in Electrical & Computer Engineering aan UCSD, geadviseerd door Dr. Mohan Trivedi. Zijn onderzoek bij LISA richt zich op het schatten en voorspellen van rijgedrag met behulp van machine learning.

Nachiket Deo is een PhD-kandidaat in Electrical & Computer Engineering aan UCSD. Zijn onderzoeksinteresses omvatten computervisie en machine learning voor autonoom rijden, met een focus op intentie en bewegingsvoorspelling van omringende agenten, en analyse van bestuurdersactiviteit voor veilige controleovergangen.

Jonathan Bok is een software-engineer bij Amazon. Zijn focus ligt op het bouwen van impactvolle softwarediensten en producten om machine learning te democratiseren.

Suchitra Sathyanarayana is manager bij de Amazon ML Solutions-lab, waar ze AWS-klanten in verschillende brancheverticalen helpt hun AI en cloud-acceptatie te versnellen. Ze heeft een PhD in Computer Vision van de Nanyang Technological University, Singapore.

Mohan M. Trivedic (Life Fellow IEEE, SPIE en IAPR) is een Distinguished Professor of Electrical and Computer Engineering aan de University of California, San Diego en de oprichter van het Computer Vision and Robotics Research (CVRR, est. 1986) en het Laboratory for Intelligent en veilige auto's (LISA, est. 2001). Zijn onderzoek richt zich op intelligente voertuigen, intelligente transportsystemen (ITS), autonoom rijden, rijhulpsystemen, actieve veiligheid, mens-robot-interactiviteit, machinevisiegebieden. UCSD LISA werd bekroond met de IEEE ITSS Lead Institution Award. Trivedi was hoofdredacteur van de Machine Vision and Applications, Senior Editor van de IEEE Trans on IV en ITSC, evenals voorzitter van de Robotics Technical Committee van IEEE Computer Society en Board of
Bestuurders van de IEEE ITSS- en IEEE SMC-verenigingen.

PlatoAi. Web3 opnieuw uitgevonden. Gegevensintelligentie versterkt.

Klik hier om toegang te krijgen.

Bron: https://aws.amazon.com/blogs/machine-learning/creating-a-large-scale-video-driving-dataset-with-detailed-attributes-using-amazon-sagemaker-ground-truth/