Contents
Het bieden van een end-to-end-omgeving, die op een dag validatie kan vervangen, vereist verfijnde, high-fidelity-modellen van elk deel van de wereld. Het gebruik van aiSim's open API's en SDK zorgt ervoor dat de integratie van deze vele elementen naadloos en prestatie-efficiënt is, en ondersteunt use-cases aan beide kanten van het V-model.
Vooraf bepaalde of spontane tests
Er kunnen twee verschillende benaderingen worden gevolgd bij het testen van verschillende wegscenario's in een simulator.
In de meeste gevallen willen we onze software voor geautomatiseerd rijden (Ego-voertuig) testen in een zeer specifieke, goed gedefinieerde situatie. Voor elke deelnemer stellen we de verschillende startposities en snelheid in. Vervolgens definiëren we welke trajecten ze moeten volgen, of welke acties ze moeten uitvoeren wanneer aan een specifieke voorwaarde is voldaan of een vooraf ingestelde tijd is verstreken. Deze scenario's worden altijd op dezelfde manier uitgevoerd, zonder dat er iets niet gespecificeerd wordt, zodat we altijd precies weten wat we testen. We kunnen dan verschillende, strikte voorwaarden specificeren om de acties en reacties van het Ego-voertuig te evalueren en uiteindelijk het scenario af te sluiten met een mislukt of geslaagd resultaat.
Deze aanpak is vooral belangrijk om de naleving van verschillende normen te controleren, zoals NCAP, ISO11270, ISO15622, ISO17361, ISO17387 en de komende GSR, ALKS bijvoorbeeld. aiSim biedt een geavanceerde scenario-editor om eenvoudig scenario's voor het vermijden van ongevallen te ontwerpen en een deterministische simulatie-uitvoering om te zorgen voor correlatie met tests in de echte wereld.
Deze benadering van het testen van scenario's wordt algemeen toegepast in de wereld, en er is ook een relatief nieuwe standaard over dit onderwerp. Omdat OpenSCENARIO 1.0 nu publiekelijk beschikbaar is, kan elk bedrijf dat simulatoren ontwikkelt ervoor kiezen om het te ondersteunen, en door dit te doen, kan elk scenario dat met een toolchain is gebouwd, worden gedeeld met anderen en worden uitgevoerd in andere simulators, als ze dezelfde standaard ondersteunen.
Meestal, vooral wanneer een nieuwe functie wordt ontwikkeld in software voor automatisch rijden of rijassistentie, willen we heel specifiek zijn over wat we testen en vertrouwen we op de hierboven beschreven methode. Wanneer een functie echter al goed is getest binnen specifieke scenario's, zullen we de tests opschalen en proberen te bewijzen dat het systeem niet alleen goed werkt in beperkte omgevingen, maar ook robuust genoeg is om situaties door te laten die niet kunstmatig zijn gemaakt, maar liggen dichter bij echte gevallen. Deze aanpak kan ook worden opgesplitst in twee verschillende methoden.
Scenario's maken van opnamen uit de echte wereld
Als het doel is om scenario's te creëren die zo dicht mogelijk bij de praktijk komen, zou een manier om dit te doen zijn om de weg op te gaan met een voertuig dat is uitgerust met specifieke sensoren, dat vervolgens in staat is om de omgeving en de acties vast te leggen. van alle deelnemers continu. Wanneer zich een interessant scenario voordoet, kunnen we al deze opname- en sensorlogboeken gebruiken om exact hetzelfde scenario in een simulator te repliceren. Zodat we kunnen herscheppen wat er in de echte wereld is gebeurd. Uiteraard brengt deze methode zeer hoge kosten met zich mee, aangezien we verschillende, geavanceerde sensoren nodig hebben om de kleinste details van de weg vast te leggen. Ook onze teams zijn genoodzaakt om langere tijd rond te rijden met de mogelijkheid dat er niets nuttigs gebeurt. Zelfs als we erin slagen interessante situaties te verzamelen, moet er nog veel werk worden verzet om deze opnames om te zetten in virtuele scenario's, de locaties opnieuw te creëren zodat ze overeenkomen met hoe ze in de opnames verschenen, enz.… Dit proces is complex, dit octrooi beschrijft een voorbeeld van een dergelijk systeem in detail: US10482003 "8211; Methode en systeem voor het aanpassen van een regeleenheid van een autonome auto.
Procedurele verkeersgeneratie is ook een optie
De andere benadering is het gebruiken van bestaande locaties die al beschikbaar zijn in de simulator en het vervolgens procedureel genereren van verkeer op basis van verschillende vereisten. Het uiteindelijke doel van deze systemen is meestal om het werkelijke gedrag van bestuurders en de verkeersstroom zo goed mogelijk te modelleren, maar tot op heden heeft elk beschikbaar systeem zijn eigen beperkingen.
Toen we begonnen met het ontwikkelen van onze simulator, begonnen we natuurlijk met het met de hand maken van elk subsysteem dat nodig was, zodat we snel testfuncties konden leveren. Hoewel het voor ons erg belangrijk is om onze interfaces open te houden en onze systemen modulair te bouwen, is het bij het experimenteren met nieuwe verificatievereisten vaak veel efficiënter om eerst een werkend prototype te maken, onafhankelijk van de beoogde uiteindelijke implementatie. om te zien of de geboden oplossing inderdaad iets is dat werd gevraagd. Daarom creëerden we eerst ons eigen verkeerssysteem, dat in staat was om elk weggedeelte snel te bevolken door procedureel voertuigen rond het Ego-voertuig te genereren. Het centrum van de simulatie bleef echter altijd het Ego-voertuig, dus elke parameterset werd ontwikkeld vanuit het perspectief van het Ego. We waren in staat om te bepalen hoeveel voertuigen we wilden zien in de rijstrook, of op de linker- of rechterrijstrook van het Ego-voertuig. We waren ook in staat om specifieke manoeuvres te definiëren in een descriptor op hoog niveau en vervolgens verschillende auto's te observeren die elkaar inhalen, van rijstrook veranderen, invoegen in het verkeer of de snelwegen verlaten. Dit systeem bleek een tijdje erg waardevol te zijn, vooral omdat we voornamelijk snelwegscenario's hebben getest, waarbij slechts een zeer beperkte subset van verkeersregels wordt gebruikt.
Zolang de voertuigen elkaar op veilige afstand konden volgen en de nodige rijstrookwisselingen konden uitvoeren, konden we verschillende, zeer uiteenlopende situaties genereren.
Onlangs begonnen we onze focus te verleggen naar stedelijke scenario's en we zagen dat hoewel ons verkeersgeneratorsysteem redelijk goed werkt, er verschillende functies ontbreken om aan de behoeften van complexere verkeersscenario's te voldoen. Een voorbeeld hiervan was wanneer de voertuigen op een kruispunt zonder verkeersborden aankwamen en voor elkaar moesten wijken. De procedureel gegenereerde voertuigen konden eenvoudige verkeersregels volgen. Desalniettemin was het opzetten van dergelijke onderhandelingen een van de voorbeelden waarin we zagen dat er meer ontwikkeling nodig zou zijn als we de complexe verkeerssituaties wilden oplossen die zich in een stedelijke omgeving zouden kunnen voordoen.
SUMO in aiSim
Dit was het punt waarop we besloten om de markt rond te kijken om te zien welke oplossingen van derden beschikbaar waren. We waren op de hoogte van SUMO (Simulatie van Stedelijke Mobiliteit), maar hadden het nooit geëvalueerd voor onze interne behoeften. Als een natuurlijke volgende stap zijn we gaan onderzoeken of en hoe we het konden integreren in onze simulator, ter vervanging van onze eigen oplossing voor het genereren van verkeer. Hoewel de SUMO-bibliotheek erg complex is, is er gelukkig voldoende documentatie online beschikbaar om de eerste stappen te ondersteunen. Nadat we diep in de documentatie waren gedoken en ons vertrouwd hadden gemaakt met de structuur van de bibliotheek, konden we deze dankzij onze Traffic API gemakkelijk integreren in aiSim. Als gevolg hiervan kan SUMO nu worden gebruikt in plaats van ons voormalige procedurele systeem om verkeer op de weg te genereren. Op het huidige niveau kunnen we het gedrag van voertuigen in SUMO nauwkeurig modelleren en we werken continu aan het toevoegen van ondersteuning voor extra functies.
Met aiSim streven we ernaar om een modulair pakket aan onze partners te leveren, en daar hebben we ook rekening mee gehouden bij het integreren van SUMO in de simulator. We wilden de integratie tot een minimum beperken, maar ook volledige ondersteuning bieden voor alle functies die beschikbaar zijn in SUMO, dus hebben we uiteindelijk besloten om co-simulatie te implementeren. Wanneer een scenario in de simulator wordt geladen en er wordt verwezen naar een SUMO-configuratiebestand in het scenario, wordt ook een instantie van de SUMO-wereld gemaakt. Bij elke tijdstap synchroniseren we deze twee werelden eenvoudig met elkaar, bevragen en positioneren we de SUMO-bestuurde voertuigen in aiSim, terwijl we de positie van het Ego-voertuig terugkoppelen naar de SUMO-wereld. Hierdoor kunnen de gegenereerde voertuigen de acties van een op afstand bestuurbaar voertuig respecteren. Ook hebben we de relevante code voor de integratie geïmplementeerd in een module die open source is voor onze partners. Als de huidige implementatie niet voldoende is, of een update van de bibliotheek of een verdere wijziging nodig is, kan dit eenvoudig worden uitgevoerd zonder actieve medewerking van onze kant. Op deze manier zijn iteratietijden bij het samenwerken veel sneller, omdat wachten op AImotive om iets te doen volledig wordt geëlimineerd.
En dit brengt weer standaarden en de uitwisselbaarheid van scenario's. De grootste onzekerheid met open standaarden (zoals OpenSCENARIO) op dit moment is dat ze grotendeels afhankelijk zijn van implementatie. Als twee verschillende simulatorontwikkelaars de standaard op verschillende manieren implementeren, zullen ze verschillende resultaten krijgen en als gevolg daarvan zal het gemaakte scenario niet uitwisselbaar zijn. Omdat SUMO echter een vooraf gebouwde bibliotheek en een openbare interface biedt om mee te communiceren, betekent dit dat elk SUMO-configuratiebestand identiek zal worden uitgevoerd in elke simulator die het ondersteunt, wat echte uitwisselbaarheid biedt voor de gebruikers van deze bibliotheek.
András Bondor
Senior AI-ingenieur, AImotive
