Introductie
De SAE AutoDrive-uitdaging is een 4-jarige collegiale ontwerpwedstrijd, waaraan 8 teams uit de VS en Canada deelnemen. Het technische doel op hoog niveau voor het jaar 3 van deze wedstrijd is om te navigeren op een rijcursus in de stad in een geautomatiseerde rijmodus zoals beschreven door SAE-niveau 4.
MathWorks daagt teams uit om simulatie te gebruiken
Simulatie is een zeer nuttige tool voor de ontwikkeling van autonome voertuigen. Modelgebaseerde tests kunnen helpen bij de ontwikkeling van algoritmen, testen op unit- en systeemniveau en het testen van edge case-scenario's. Echte wereld sensor gegevens kunnen worden opgenomen en afgespeeld in het systeem om de fusie-algoritmen af te stemmen. Er kan een simulatieomgeving worden gecreëerd om real-world omgevingen te modelleren en kan worden gebruikt om verschillende algoritmen en sensorposities te testen. De beste algoritmen en sensorposities die voldoen aan de teamvereisten, kunnen worden gekozen op basis van prestatieresultaten.
Elk jaar daagt MathWorks teams uit om Simulation te gebruiken via een Simulation Challenge. Deze blog behandelt kort de winnaars van de 1e en 2e plaats van de 2020 Challenge (University of Toronto en Kettering University), hun systeemontwerp en hoe ze MathWorks-tools gebruikten om de algemene competitiedoelstellingen te helpen behalen. De teams werden beoordeeld op basis van hoe ze de tools gebruikten om te presteren:
- Open-lus perceptietesten - gegevens samenvoegen voor open-lus-testen, waarbij de juistheid van de algoritmen wordt beoordeeld
- Closed-loop controls testen - het synthetiseren van closed-loop scenario's, het beoordelen van de prestatie van besturingsalgoritmen
- Codegeneratie van besturingsalgoritmen - code voor algoritmen genereren, gegenereerde code in het voertuig integreren
- Innovatie met behulp van MathWorks-tools – een techniek/technologie duidelijk verschillend van de bovengenoemde 3 categorieën
Universiteit van Toronto
Het studententeam van de Universiteit van Toronto, aUToronto, won de eerste plaats in de challenge.
Open-loop perceptie testen
De eerste stap van dit team was het synthetiseren van gegevens voor open-lus-perceptietests. Ze kozen ervoor om hun algoritme voor sensorfusie te testen. Om synthetische gegevens te synthetiseren voor testen, gebruikten ze de (DSD). Met deze app kun je synthetische rijscenario's ontwerpen om je autonoom rijden te testen. Het team gebruikte een radar en drie camera's in de algoritmen voor sensorfusie, die zijn geconfigureerd zoals weergegeven in afbeelding 3.
Figuur 1: Locaties teamsensor (© aUToronto)
Ze hebben de camerasensoren - samen met hun posities, oriëntaties en configuraties - gemodelleerd in de DSD-app om sensorgegevens te synthetiseren die in hun sensorfusie-algoritmen kunnen worden ingevoerd. De DSD simuleert de camera-output na de algoritmen voor beeldverwerking en computervisie van het team, en voegt ruis en uitschieters toe aan de gegevens.
Het Scenario Reader-blok werd gebruikt om scenario-informatie te lezen die met DSD is gemaakt. De actor-poses werden als input naar de meervoudige detectiegeneratoren gestuurd. Detecties voor deze verschillende sensoren werden vervolgens verpakt als ROS-berichtarrays (Robot Operating System) van variabele grootte en als aangepaste ROS-berichten naar specifieke ROS-onderwerpen verzonden (Afbeelding 2).
Figuur 2: Simulink-model voor testen met open lus (© aUToronto)
Het team vergeleek de output van hun objecttracker met grondwaarheidswaarden van voertuigen. De RMSE-metriek (Root Mean Square Error) werd gebruikt voor prestatiebeoordeling.
Testen van besturingselementen met gesloten lus
De belangrijkste focus van het team was het testen van hun aangepaste planner voor nieuwe mogelijkheden, zoals herroutering voor bouwzones en rond obstakels duwen. De planner is opnieuw ontworpen om een roosterstructuur te gebruiken waarbij randen van de kaart worden gesnoeid om zo nodig paden rond objecten te vinden (Figuur 3). DSD werd opnieuw gebruikt om scenario's te creëren. Ook werden slagbomen en verkeerslichten aan de scenario's toegevoegd.
Figuur 3: Roosterstructuur voor het vinden van paden (© aUToronto)
Het team modelleerde een verkeerslichtuitgever met Stateflow (figuur 4). Wanneer het ego-voertuig buiten bereik (> 50m) van het verkeerslicht is, wordt de onbekende toestand gepubliceerd. Wanneer het ego binnen bereik komt, wordt er een roodlichtbericht gepubliceerd. Het bericht wordt groen licht nadat het ego 5 seconden is gestopt.
Figuur 4: Stateflow naar model controller (© aUToronto)
De ROS-knooppunten van de controller, planner en voertuigmodel werden gelanceerd. Als het obstakel zich binnen 50 meter van het ego-voertuig bevond, werd zijn positie als een ROS-bericht naar het Simulink-model gestuurd (Figuur 5).
Figuur 5: Logica om een positiebericht te verzenden (© aUToronto)
Codegeneratie van besturingsalgoritmen
Het team genereerde code voor het algoritme voor het verwerken van stopborden (Figuur 6). Simulink Coder werd gebruikt om de Stateflow om te zetten in C++-code. Een op zichzelf staande module is gegenereerd met behulp van de codeverpakkingsfunctie. De gegenereerde module werd vervolgens samengevoegd met de teamcodebase.
Figuur 6: Logica voor remlichtregeling Stateflow (© aUToronto)
Innovatie met behulp van MathWorks-tools - Lidar-camerakalibratie
Om de objecten in een scène met ingangen van een lidar en een camerasensor nauwkeurig te interpreteren, is het nodig om de sensoruitgangen samen te smelten. Daarom voerde het team een transformatie uit tussen Lidar en teamcamera om Lidar-punten op een afbeelding te projecteren of vice versa voor sensorfusie. In plaats van handmetingen en roterende camera's te gebruiken totdat de projecties er goed uitzagen, gebruikte het team de nieuw ontwikkelde Lidar Camera-kalibratietool uit de Lidar-verwerkingstoolbox. Deze tool schat een starre transformatiematrix die de overeenkomsten vaststelt tussen de punten in het 3D-lidarvlak en de pixels in het beeldvlak
Ze bouwden een groter kalibratiebord omdat hun huidige te klein was voor de tool. De camera-kalibratietool werd gebruikt om de intrinsieke matrix voor hun camera te krijgen. De hoeken van het dambord werden in elke afbeelding gevonden, en de Lidar-gegevens. De starre transformatiematrix tussen Lidar en camera werd gevonden. Dit proces levert een transformatie op die kan worden gebruikt om de puntenwolkgegevens op afbeeldingen te projecteren of vice versa. Deze stappen worden getoond in figuur 7.
Figuur 7: (a) Camera intrinsieke matrix (b) schaakbordhoeken (c) Lidar naar camera transformatiematrix (© aUToronto)
Kettering University
De studententeam van Kettering University, won de 2e plaats in de uitdaging.
Open-loop perceptie testen
Het team gebruikte Unreal Engine om verschillende scenario's te maken. Een camera werd toegevoegd aan het ego-voertuig in Unreal met behulp van het simulatie 3D-camerablok. Een Simulink-model werd gebruikt om rijstrookdetectie uit te voeren met behulp van de onwerkelijke beelden (Figuur 8). De blauwe vierkantjes geven de rijstrookdetectiefuncties aan en de gele vierkantjes geven de uitgangen bij elke stap aan. Deze outputcijfers worden getoond in Figuur 9.
Figuur 8: Simulink-model voor testen met open lus (© Kettering University)
Afbeelding 9: Uitgangen voor rijstrookdetectie (© Kettering University)
Testen van besturingselementen met gesloten lus
Het systeemontwerp van het team bestond uit 2 toestandsmachines - longitudinaal en lateraal. Deze toestandsmachines, getoond in figuur, werden gebruikt om de logica van de controller-selectie te modelleren op basis van sensor- en besluitvormingsgegevens. Ze waren met elkaar verbonden en werden gebruikt om de subsystemen van de controller in te schakelen en te initialiseren.
Figuur 10: Staatsmachines (© Kettering University)
Gecombineerde controller-simulaties, met het Simulink-model in Figuur 11, werden uitgevoerd om de werking van alle teamcontrollers te verifiëren. Ingangen voor deze controllers werden geleverd met behulp van schuifregelaars en meters.
Figuur 11: Simulink-model voor testen met gesloten lus (© Kettering University)
De besturingssubsystemen van de machine in de lengterichting omvatten de snelheidsregelaar in de lengterichting en de automatische noodrem (AEB). Toestanden werden bepaald door de voertuigdynamiek in de lengterichting, zoals accelereren, cruisen, vertragen, stilstaan en parkeren.
De controller-subsystemen van de laterale toestandsmachine omvatten Lane Keep Assist (LKA), Lane Change en Turn controllers. Toestanden werden bepaald op basis van laterale voertuigdynamica (Figuur 12). Langssnelheid, verandering van rijstrook en LKA-controllers worden hieronder besproken.
Afbeelding 12: Statussen van de laterale controller (© Kettering University)
Longitudinale controller
Figuur 13 toont het Simulink-model dat is gebruikt om de longitudinale controller te modelleren. Het bestond uit een PID op basis van snelheid. De referentie- en uitgaande koppelsnelheden waren beperkt om binnen de limieten van de acceleratie en schokbewegingen van de concurrentie te blijven. Systeeminvoer werd geïnitialiseerd en bewerkt met schuifregelaars en er werd een bereik gebruikt om gegevens te bekijken. Afbeelding 14 toont de output van de beoogde en werkelijke longitudinale snelheid.
Figuur 13: Simulink-model met longitudinale controller (© Kettering University)
Figuur 14: Vergelijkingen van longitudinale snelheden (© Kettering University)
Rijbaanwissel controller
De Lane Change-controller van het team gebruikte adaptieve MPC (Model Predictive Control). Er werd een referentiepad gegenereerd met behulp van parametrische functies, met invoer van rijstrookwisselingen zoals voertuigsnelheid en rijstrookbreedte. De uitgangen naar de controller waren referentie laterale positie en Yaw. Een 3DOF-model (Degree of Freedom) werd gebruikt om de carrosserie van een voertuig te simuleren. Figuur 15 toont het Simulink-model dat wordt gebruikt voor simulatie. Figuur 16 toont de output van de simulatie met referentie- en gesimuleerde rijstrookwisselpaden, samen met de paden die zijn verkregen na testen in het voertuig.
Figuur 15: Simulink-model voor rijstrookwisselregelaar (© Kettering University)
Figuur 16: Vergelijkingen van rijstrookwisselpaden (© Kettering University)
Voertuigmodel
Het team ontwikkelde en valideerde een 3DOF-model met één en twee sporen. De eerste validatie werd uitgevoerd met behulp van een lineair fietsmodel. De laatste validatie werd uitgevoerd met fysieke testgegevens. Afbeelding toont de uitvoer van de vergelijking van de laterale versnelling met initiële en laatste validaties, zonder en met testgegevens.
Afbeelding 17: (a) Vergelijkingen van laterale versnelling (b) Vergelijkingen met testgegevens (© Kettering University)
Innovatie met behulp van MathWorks-tools - Onwerkelijke stad
Het team gebruikte Unreal voor het testen van al hun controllers met een gesloten lus. Ze creëerden een onwerkelijke stad met controleerbare voetgangersbewegingen en verkeerslichten. Er werden aanpasbare acteurs gemaakt en hun informatie, zoals de naam van de acteur, het type acteur, de details van de acteur, de animatiedetails en tags, werd opgeslagen voor snelle toegang. Er is ook een verkeerslichtkaart gemaakt, samen met de locatie van de lichten met het label Afbeelding 18.
Figuur 18: Onwerkelijke verkeerslichtkaart (© Kettering University)
Afbeelding 19 toont de communicatiestructuur van het Simulink-Unreal-systeem. De besluitvorming voor de Unreal-scène, bestaande uit voertuigpositie, voetgangersbeweging, verkeerslichtstatus enz., Werd gedaan met Stateflow en als input naar de controllers gestuurd (Figuur 20).
Figuur 19: Simulink Unreal-systeemcommunicatiestructuur (© Kettering University)
Figuur 20: Stateflow voor besluitvorming over onwerkelijke scènes (© Kettering University)
Concluderend konden de studententeams van de Universiteit van Toronto en Kettering University MATLAB en Simulink gebruiken om fusie-, tracking- en navigatiealgoritmen te ontwerpen, bouwen, testen en beoordelen om een stap dichter bij het bouwen van een autonoom voertuig van SAE-niveau 4 te komen in simulatie. Ze schreven ingewikkelde scenario's met verkeerslichten en meerdere actoren in verschillende simulatieomgevingen, integreerden de omgevingen met Simulink en implementeerden en testten de door hen gekozen algoritmen op deze scenario's. Perceptiealgoritmen met open en gesloten lus werden gemodelleerd en getest met Simulink en er werd code gegenereerd voor deze systemen. Teams hebben ook verschillende controlleralgoritmen ontworpen en getest met Simulink en Stateflow. De tools van MathWorks werden innovatief en uitgebreid gebruikt door beide kampioensteams.