Introduzione
La SAE AutoDrive Challenge è una competizione di design collegiale della durata di 4 anni, a cui partecipano 8 team di Stati Uniti e Canada. L'obiettivo tecnico di alto livello per l'anno 3 di questa competizione è quello di navigare in un corso di guida urbana in una modalità di guida automatizzata come descritto dal livello 4 SAE.
MathWorks sfida i team a utilizzare la simulazione
La simulazione è uno strumento molto utile per lo sviluppo di veicoli autonomi. Il test basato su modello può aiutare nello sviluppo di algoritmi, test a livello di unità e di sistema e test di scenari edge case. Mondo reale sensore i dati possono essere registrati e riprodotti nel sistema per mettere a punto gli algoritmi di fusione. È possibile creare un ambiente di simulazione per modellare ambienti del mondo reale e utilizzarlo per testare vari algoritmi e posizioni dei sensori. I migliori algoritmi e posizioni dei sensori che soddisfano i requisiti del team possono essere scelti in base ai risultati delle prestazioni.
Ogni anno MathWorks sfida i team a utilizzare la simulazione tramite una sfida di simulazione. Questo blog tratterà brevemente i vincitori del 1 ° e 2 ° posto della Sfida 2020 (Università di Toronto e Kettering University), la loro progettazione del sistema e come hanno utilizzato gli strumenti MathWorks per aiutare a raggiungere gli obiettivi generali della competizione. I team sono stati giudicati in base a come hanno utilizzato gli strumenti per eseguire:
- Test di percezione a ciclo aperto: sintetizzazione dei dati per test a ciclo aperto, valutazione della correttezza degli algoritmi
- Test dei controlli a ciclo chiuso: sintesi di scenari a ciclo chiuso, valutazione delle prestazioni degli algoritmi di controllo
- Generazione di codice di algoritmi di controllo: generazione di codice per algoritmi, integrazione del codice generato nel veicolo
- Innovazione utilizzando gli strumenti MathWorks: una tecnica/la tecnologia nettamente diverso dalle 3 categorie precedenti
Università di Toronto
Il team studentesco dell'Università di Toronto, aUToronto, ha vinto il 1 ° posto nella sfida.
Test di percezione a ciclo aperto
Il primo passo di questo team è stato quello di sintetizzare i dati per i test di percezione a ciclo aperto. Hanno scelto di testare il loro algoritmo di fusione dei sensori. Per sintetizzare i dati sintetici per i test, hanno utilizzato il (DSD). Questa app ti consente di progettare scenari di guida sintetici per testare la tua guida autonoma. Il team ha utilizzato un radar e 3 telecamere negli algoritmi di fusione dei sensori, che sono configurati come mostrato nella Figura 1.
Figura 1: posizioni dei sensori del team (© aUToronto)
Hanno modellato i sensori della fotocamera - insieme alle loro posizioni, orientamenti e configurazioni - nell'app DSD per sintetizzare i dati dei sensori da inserire nei loro algoritmi di fusione dei sensori. Il DSD simula l'uscita della telecamera dopo l'elaborazione delle immagini e gli algoritmi di visione artificiale del team e aggiunge rumore e valori anomali ai dati.
Il blocco Scenario Reader è stato utilizzato per leggere le informazioni sullo scenario create utilizzando DSD. Le pose dell'attore sono state inviate come input ai generatori di rilevamento multiplo. I rilevamenti per questi vari sensori sono stati quindi impacchettati come array di messaggi ROS (Robot Operating System) di dimensioni variabili e inviati come messaggi ROS personalizzati a specifici argomenti ROS (Figura 2).
Figura 2: modello Simulink per test a circuito aperto (© aUToronto)
Il team ha confrontato l'output del loro localizzatore di oggetti con i valori di verità a terra dei veicoli. La metrica RMSE (Root Mean Square Error) è stata utilizzata per la valutazione delle prestazioni.
Test di controlli a ciclo chiuso
L'obiettivo principale del team era testare il pianificatore modificato per nuove funzionalità come il reindirizzamento per le zone di costruzione e la spinta intorno agli ostacoli. Il pianificatore è stato riprogettato per utilizzare una struttura reticolare in cui i bordi vengono eliminati dalla mappa per trovare percorsi attorno agli oggetti, se necessario (Figura 3). Ancora una volta DSD è stato utilizzato per creare scenari. Agli scenari sono state aggiunte anche barriere e semafori.
Figura 3: struttura reticolare per la ricerca del percorso (© aUToronto)
Il team ha modellato un publisher a semaforo utilizzando Stateflow (Figura 4). Quando il veicolo dell'ego è fuori dalla portata (> 50 m) del semaforo, viene pubblicato lo stato sconosciuto. Quando l'ego rientra nel raggio d'azione, viene pubblicato un messaggio a luci rosse. Il messaggio passa a luce verde dopo che l'ego si è fermato per 5 secondi.
Figura 4: dal flusso di stato al controller del modello (© aUToronto)
Sono stati lanciati i nodi ROS del controller, del pianificatore e del modello di veicolo. Se l'ostacolo si trovava entro 50 m dal veicolo ego, la sua posizione è stata inviata come messaggio ROS al modello Simulink (Figura 5).
Figura 5: Logica per inviare il messaggio di posizione (© aUToronto)
Generazione di codice di algoritmi di controllo
Il team ha generato il codice per l'algoritmo di gestione dei segnali di stop (Figura 6). Simulink Coder è stato utilizzato per convertire Stateflow in codice C++. Uno autonomo modulo è stato generato utilizzando la funzione di confezionamento del codice. Il modulo generato è stato quindi unito al codice base del team.
Figura 6: Logica di controllo luci stop Stateflow (© aUToronto)
Innovazione utilizzando gli strumenti MathWorks - Calibrazione della fotocamera Lidar
Per interpretare accuratamente gli oggetti in una scena con ingressi da un lidar e da un sensore della telecamera, è necessario fondere insieme le uscite del sensore. Pertanto, il team ha eseguito una trasformazione tra Lidar e la telecamera del team per proiettare i punti Lidar su un'immagine o viceversa per la fusione dei sensori. Invece di utilizzare misurazioni manuali e telecamere rotanti fino a quando le proiezioni non sembravano buone, il team ha utilizzato il nuovo strumento di calibrazione della fotocamera Lidar dalla casella degli strumenti di elaborazione Lidar. Questo strumento stima una matrice di trasformazione rigida che stabilisce le corrispondenze tra i punti nel piano lidar 3-D e i pixel nel piano dell'immagine
Hanno costruito una scheda di calibrazione più grande poiché quella attuale era troppo piccola per lo strumento. Lo strumento di calibrazione della fotocamera è stato utilizzato per ottenere la matrice intrinseca per la loro fotocamera. Gli angoli della scacchiera sono stati trovati in ogni immagine e nei dati Lidar. È stata trovata la rigida matrice di trasformazione tra Lidar e fotocamera. Questo processo produce una trasformazione che potrebbe essere utilizzata per proiettare i dati della nuvola di punti sulle immagini o viceversa. Questi passaggi sono mostrati nella Figura 7.
Figura 7: (a) Matrice intrinseca della fotocamera (b) angoli della scacchiera (c) Matrice di trasformazione da Lidar a fotocamera (© aUToronto)
Kettering University
I squadra studentesca della Kettering University, ha vinto il 2 ° posto nella sfida.
Test di percezione a ciclo aperto
Il team ha utilizzato Unreal Engine per creare vari scenari. Una telecamera è stata aggiunta al veicolo dell'ego in Unreal utilizzando il blocco telecamera 3D di simulazione. Un modello Simulink è stato utilizzato per eseguire il rilevamento della corsia utilizzando immagini irreali (Figura 8). I quadratini blu indicano le funzioni di rilevamento corsia e il giallo indicano le uscite ad ogni passaggio. Queste cifre di output sono mostrate nella Figura 9.
Figura 8: modello Simulink per test a circuito aperto (© Kettering University)
Figura 9: uscite di rilevamento corsia (© Kettering University)
Test di controlli a ciclo chiuso
Il progetto del sistema del team consisteva in 2 macchine a stati: longitudinale e laterale. Queste macchine a stati, mostrate in fig, sono state utilizzate per modellare la logica della selezione del controller in base ai dati del sensore e del processo decisionale. Erano interconnessi e utilizzati per abilitare e inizializzare i sottosistemi del controller.
Figura 10: Macchine a stati (© Kettering University)
Sono state eseguite simulazioni di controller combinate, con il modello Simulink nella Figura 11, per verificare il funzionamento di tutti i controller del team. Gli input a questi controller sono stati forniti utilizzando cursori e indicatori.
Figura 11: modello Simulink per test a circuito chiuso (© Kettering University)
I sottosistemi del controller della macchina a stati longitudinali includono il controller della velocità longitudinale e la frenata automatica di emergenza (AEB). Gli stati erano determinati dalle dinamiche longitudinali del veicolo come accelerazione, crociera, decelerazione, arresto e parcheggio.
I sottosistemi del controller della macchina a stati laterali includono Lane Keep Assist (LKA), cambio di corsia e controller di svolta. Gli stati sono stati determinati in base alla dinamica laterale del veicolo (Figura 12). Di seguito vengono discussi la velocità longitudinale, il cambio di corsia e i controller LKA.
Figura 12: stati del controller laterale (© Kettering University)
Controller longitudinale
La Figura 13 mostra il modello Simulink utilizzato per modellare il controller longitudinale. Consisteva in un PID basato sulla velocità. I valori di coppia di riferimento e di uscita erano limitati per rimanere entro i limiti di accelerazione e strappi della concorrenza. Gli input di sistema sono stati inizializzati e modificati con dispositivi di scorrimento ed è stato utilizzato un ambito per visualizzare i dati. La Figura 14 mostra le uscite di velocità longitudinale target e effettiva.
Figura 13: modello Simulink del controller longitudinale (© Kettering University)
Figura 14: Confronti di velocità longitudinali (© Kettering University)
Controller per il cambio di corsia
Il controller del cambio di corsia del team utilizzava MPC adattivo (Model Predictive Control). È stato generato un percorso di riferimento utilizzando funzioni parametriche, con input di cambio corsia come velocità del veicolo e larghezza della corsia. Le uscite al controller erano posizione laterale di riferimento e imbardata. Un modello 3DOF (Grado di libertà) è stato utilizzato per simulare la carrozzeria del veicolo. La Figura 15 mostra il modello Simulink utilizzato per la simulazione. La Figura 16 mostra gli output della simulazione con percorsi di riferimento e di cambio corsia simulati, insieme ai percorsi ottenuti dopo il test a bordo del veicolo.
Figura 15: Controller per cambio di corsia modello Simulink (© Kettering University)
Figura 16: Confronto dei percorsi di cambio corsia (© Kettering University)
Modello di veicolo
Il team ha sviluppato e convalidato un modello di veicolo 3DOF a binario singolo e doppio. La convalida iniziale è stata eseguita utilizzando un modello di bicicletta lineare. La convalida finale è stata eseguita con i dati dei test fisici. La figura mostra l'output del confronto dell'accelerazione laterale con le convalide iniziali e finali, senza e con i dati di test.
Figura 17: (a) Confronti dell'accelerazione laterale (b) Confronti con i dati dei test (© Kettering University)
Innovazione utilizzando gli strumenti MathWorks - Unreal city
Il team ha utilizzato Unreal per i test a circuito chiuso di tutti i propri controller. Hanno creato una città irreale con movimenti pedonali controllabili e semafori. Sono stati creati attori personalizzabili e le loro informazioni come nome dell'attore, tipo di attore, dettagli dell'attore, dettagli dell'animazione e tag sono state archiviate per un rapido accesso. È stata anche creata una mappa del semaforo insieme alla posizione delle luci etichettata Figura 18.
Figura 18: mappa del semaforo irreale (© Kettering University)
La Figura 19 mostra la struttura di comunicazione del sistema Simulink-Unreal. Il processo decisionale per la scena Unreal, costituito dalla posizione del veicolo, dal movimento dei pedoni, dallo stato dei semafori ecc., È stato effettuato utilizzando Stateflow e inviato come input ai controller (Figura 20).
Figura 19: struttura di comunicazione del sistema Simulink Unreal (© Kettering University)
Figura 20: Stateflow per il processo decisionale sulla scena Unreal (© Kettering University)
In conclusione, i team di studenti dell'Università di Toronto e della Kettering University sono stati in grado di sfruttare MATLAB e Simulink per progettare, costruire, testare e valutare algoritmi di fusione, tracciamento e navigazione per avvicinarsi di più alla costruzione di un veicolo autonomo SAE di livello 4 in simulazione. Hanno creato scenari complessi con semafori e più attori in diversi ambienti di simulazione, integrato gli ambienti con Simulink e implementato e testato gli algoritmi scelti su questi scenari. Gli algoritmi di percezione a ciclo aperto e chiuso sono stati modellati e testati utilizzando Simulink e per questi sistemi è stato generato il codice. I team hanno inoltre progettato e testato vari algoritmi di controller utilizzando Simulink e Stateflow. Gli strumenti MathWorks sono stati utilizzati in modo innovativo ed estensivo da entrambe queste squadre di campionato.