L’utilizzo del “Closed Loop Simulation” nello sviluppo dei sistemi a guida autonoma

I maggiori gruppi automobilistici sono già da tempo impegnati nella nuova sfida tecnologica che coinvolge l’intera filiera dell’automotive: lo sviluppo del veicolo a guida autonoma. Si tratta indubbiamente di un processo che richiede ingenti investimenti di denaro, l’adozione di nuovi strumenti di lavoro (ad esempio algoritmi di intelligenza artificiale) e l’ingresso di nuove professionalità prima sconosciute nell’ambito automobilistico (data scientist, matematici, etc.). Questo articolo presenta un Closed Loop Simulation Framework sviluppato da Accenture utilizzato per accelerare il ciclo di ottimizzazione degli algoritmi ADAS (Advanced Driving Assistance Systems). La nostra soluzione punta su alcuni elementi fondamentali, tra cui:

• Simulatore: nel nostro caso si tratta di VTD (Virtual Test Drive), fornito da VIRES Simulationstechnologie GmbH, parte di MSC [4]. Il simulatore è usato per creare scenari realistici e per generare i segnali dei sensori come, ad esempio, le videocamere, i RADAR e ogni altro sensore utilizzato nell’ambito del veicolo a guida autonoma;
• Dati dai sensori: sono generati ed esportati dall’ambiente di simulazione, e successivamente iniettati all’interno di una piattaforma basata su ROS (Robot Operating System) [3] su cui gira l’algoritmo ADAS.

Il Closed Loop Simulator permette di sviluppare un algoritmo ADAS seguendo una metodologia di continuous improvement and integration. Questo approccio permette ai costruttori di automobili, e a tutti i fornitori automotive, di avere a disposizione uno strumento per accelerare lo sviluppo degli algoritmi riducendo i costi poiché si riducono le lunghe e costose campagne di test con i veicoli di prova.
Nei paragrafi successivi, saranno introdotte e discusse le sfide del processo tradizionale di sviluppo in ambito AV, procedendo in seguito alla presentazione della soluzione sviluppata da Accenture.

Lo sviluppo dei sistemi a guida autonoma

I sistemi a guida autonoma si articolano su 5 livelli, come documentato dalla specifica SAE 3016, con un crescente livello di “autonomia” dal livello 0 al livello 5 come mostrato in Figura 1.

Un veicolo a guida autonoma include una serie di sensori, unità di elaborazione e attuatori che servono per sostituire l’essere umano. I sensori utilizzati per equipaggiare un veicolo a guida autonoma sono RADAR, SONAR (side sensors), LiDAR e telecamere ad alta definizione. Il ciclo di vita dello sviluppo di un sistema a guida autonoma, composto da diversi moduli HW/SW, si articola su una serie di processi ingegneristici che, ad alto livello, possono essere descritti come segue:
1. Data ingestion. Ogni singolo processo di sviluppo di un sistema a guida autonomo necessita di dati generati dai sensori installati a bordo e raccolti durante le campagne di test. Un’automobile di test può generare 6-8 TB di dati per ogni ora di test, che andranno successivamente riversati in opportuni database che possono essere una combinazione di soluzioni on-premise e in cloud. In alcuni casi si può pensare di fare un’elaborazione preventiva dei dati a bordo veicoli per cercare di “eliminare” i dati poco significativi e ridurre, quindi, la quantità di dati da copiare nella piattaforma di sviluppo;
2. Data tagging e annotation. I dati generati dalle telecamere devono essere analizzati fotogramma per fotogramma per annotare ogni oggetto, ad esempio automobili, pedoni, ostacoli, ciclisti, etc. Questo lavoro, fatto in larga misura utilizzando sistemi di video-analytics alimentati da algoritmi di intelligenza artificiali, è propedeutico per “addestrare” le reti neurali che costituiscono il “cervello” dei veicoli a guida autonoma;
3 . Sviluppo delle reti neurali. I dati raccolti nelle campagne di test sono usati per l’addestramento delle reti neurali che costituiscono l’intelligenza del veicolo a guida autonoma. Questi sono processi che richiedono l’uso di centinaia o migliaia di CPU e GPU e tecniche di high perfomance computing;
4 . Sensor reprocessing. I dati collezionati con i veicoli di prova sono usati per testare il software dei sensori. La verifica può avvenire utilizzando metodologie di SW in the Loop o HW in the loop; nel primo caso il SW di un determinato componente, ad esempio un attuatore, è stimolato con i dati generati dai sensori nelle campagne di test per verificare le funzionalità. Nel secondo caso un intero componente, HW e SW, è alimentato con i dati generati dai sensori per verificare le funzionalità. È evidente come in entrambi i casi descritti in questo paragrafo l’uso di un car simulator possa contribuire a testare componenti ADAS sopperendo alla mancanza di dati reali.
Nel prossimo paragrafo introdurremo le sfide del processo tradizionale di sviluppo dei sistemi a guida autonoma, per definire come le Closed Loop Simulations possano giocare un ruolo chiave.

Sfide del processo tradizionale di sviluppo

Oggi, grazie all’enorme progresso tecnologico, si può fare affidamento su strumenti avanzati oltre che evoluti sotto diversi aspetti (e.g. capacità computazionale, evoluzione nei processi produttivi di CPU/GPU e sensori, introduzione del cloud-computing etc.). Ciononostante, la strada verso la realizzazione di un veicolo completamente autonomo (livello 5) non è esente da grandi sfide, il che porta ad avere anche un panorama variegato in termini di strategie di sviluppo. Una delle sfide principali, riguarda in prima istanza i dati generati dai sensori installati a bordo auto, sotto molteplici aspetti tra cui:

• Data logging: ogni sensore genererà dati in output a un rate estremamente elevato, da memorizzare in modo veloce, continuo e affidabile;
• Data harmonization: è importante che i dati in output dai sensori, generati con data rate potenzialmente diversi tra loro, vengano armonizzati per ricostruire in ogni dato istante il contesto in cui il veicolo si trovava;
• Data ingestion: i dati collezionati durante il test on-field andranno trasferiti in piattaforma al termine di ogni test session per poter essere utilizzati per scopi diversi (tra cui sensor re-processing SIL/HIL, data annotation, AI and Neural Networks training etc.). Bisogna quindi prevedere meccanismi di ingestion veloci di questo enorme inbound di dati;
• Data fruition: i dati, una volta in piattaforma, dovranno poter essere usati dai diversi processi che ne necessitano. Alcuni di questi processi richiedono di far affidamento su data lake molto veloci (generalmente realizzati come cluster di High Performance Computers) per simulare in modo accelerato i dati di una o più test sessions.

La Figura 2 mostra lo schema ad anello chiuso del nostro framework ed in particolare la corrispondenza tra i nodi ROS sviluppati ed i sensori del simulatore VTD.

Passiamo ora in rassegna i passi principali che abbiamo affrontato per realizzare la soluzione di Closed Loop Simulations, in particolare:

• Il primo step è stato il setup del simulatore VTD, e la configurazione dei sensori a bordo dell’EGO vehicle (e.g. posizione dei RADAR, spettro di ogni RADAR etc.). Si è scelto un sistema host basato su distribuzione Ubuntu [2], e che avesse anche dei requisiti HW per far fronte al carico computazionale richiesto in generale dalle piattaforme per autonomous driving. È stata installata e configurata la piattaforma ROS scegliendo la release Kinetic Kame, scegliendo C++ come linguaggio di programmazione per sviluppare la soluzione (le librerie ROS esistono infatti anche nella derivazione Python);
• La fase di design dell’algoritmo per la realizzazione dell’Adaptive Cruise Control e dell’Emergency Brake Assistant ha visto alcuni step intermedi, ovvero:
• Definizione delle conversioni necessarie per gestire i dati generati dal simulatore, e ottenere i controlli di sterzata, acceleratore e freno come il simulatore se li aspetta;
• Armonizzazione delle funzioni di Emergency Brake Assistant e Adaptive Cruise Control: questo step è risultato fondamentale per definire le condizioni perché entrassero in azione le funzionalità fornite dall’algoritmo e garantire che non andassero mai in conflitto tra loro;
• Esportazione dei parametri di tuning degli algoritmi: son stati identificati i possibili parametri su cui agire ai fini di test e fine tuning. I parametri son stati infine esportati usando i ROS parameters, che offrono il grande vantaggio di poter essere aggiornati a runtime.

Completata la fase di design dell’algoritmo, ci si è concentrati sulla definizione dell’architettura SW per integrare le componenti tra loro e dar vita alla soluzione finale. Partendo dalle componenti in gioco (simulatore e algoritmo), e dalle interfacce richieste perché queste componenti potessero comunicare in modo corretto nella piattaforma ROS, son stati identificati i ROS nodes da sviluppare e i ROS topics che ognuno dei ROS nodes avrebbe “pubblicato” o a cui si sarebbe “registrato”;
Come ultimo step, si è passati alla creazione del progetto per la soluzione SW (come richiesto da ROS, usando catkin come build system) e allo sviluppo vero e proprio del codice sorgente, interamente in C++ come anticipavamo. Si è prestata particolare attenzione al ruolo dei nodi ROS per gestire l’I/O con VTD: questi due nodi ROS costituiscono i punti di contatto del simulatore con la piattaforma ROS, e in quanto tale hanno un impatto enorme sull’intera catena, sia in termini prestazionali che di correttezza delle informazioni scambiate.
Completata la fase di sviluppo, l’intera infrastruttura per le Closed Loop Simulations poteva dirsi completa, e si è potuto dar vita quindi alla fase di test dell’algoritmo sviluppato. Protagonisti di questa fase son stati due SW fondamentali della toolchain di VTD, ovvero il ROD Editor e lo Scenario Editor. Una parte importante del test è stata infatti dedicata alla creazione degli scenari ad hoc per verificare che l’algoritmo di Emergency Brake Assistant e Adaptive Cruise Control funzionasse in modo corretto, e che potesse gestire alcuni corner case. Al fine di garantire che gli use case di test fossero quanto più “agnostici” da qualsiasi conoscenza dei dettagli implementativi dell’algoritmo, le figure che si son occupate di creare le mappe e gli scenari di test son state distinte dal team di sviluppo. Le figure con expertise sul simulatore VTD e relativa toolchain hanno quindi dato vita a una serie di HD map, con relativi scenari, di complessità graduale per verificare sia in modo isolato che congiunto le due funzionalità offerte. Qui di seguito riportiamo i più significativi:
1. Straight line: il primo scenario punta alla verifica del caso base, avendo fin da subito entrambe le funzionalità di Emergency Brake Assistant e Adaptive Cruise Control attive. La mappa su cui è stato validato lo scenario è un rettilineo di circa 10 km, dove son presenti due soli veicoli, ovvero l’EGO vehicle (controllato dal nostro algoritmo) e un altro veicolo che sarà di fronte. Sarà quest’ultimo che varierà la sua velocità fino a un massimo di 130 km/h, alternando fasi in cui rallenterà a fasi in cui accelererà. In taluni casi, il veicolo effettuerà un arresto completo. Lo scopo di questo scenario è verificare che l’EGO vehicle mantenga sempre la distanza di sicurezza in relazione alla velocità del veicolo che ci precede, oltre che rallentare (fino ad arrestarsi in modo completo) per evitare la collisione.

Per validare lo scenario si è partiti con la configurazione A di sensori mostrata in Figura 3, con un solo RADAR ad ampio raggio posto sul paraurti frontale dell’auto. I test svolti su questo primo scenario hanno permesso di identificare e risolvere alcuni problemi relativi al controllo sul pedale del freno, sia in termini di reattività che di percentuale di applicazione, che determinavano una collisione quando il veicolo che ci precede effettuava un arresto completo. Un altro comportamento rilevato in fase di test, e identificato come punto da migliorare, riguardava la gestione del pedale dell’acceleratore nelle fasi “di ripartenza”, ovvero in tutti quei casi in cui il veicolo di fronte dopo aver rallentato accelerava bruscamente.
2. Cross-walk: per questo scenario si è reso necessario rivedere la configurazione a bordo aggiungendo anche un secondo RADAR frontale ma a più ampio spettro per dotare il nostro EGO vehicle di una “vista sui lati” (configurazione B in Figura 3). L’algoritmo è stato aggiornato di conseguenza per combinare le letture dei due RADAR, e è stato introdotto anche il calcolo della traiettoria per identificare una possibile collisione con gli oggetti circostanti.

Lo scenario, mostrato in Figura 4, si svolge su una strada a tre corsie, dove è presente un passaggio pedonale senza semaforo. L’EGO vehicle partirà sulla corsia centrale procedendo verso l’attraversamento pedonale, mentre un pedone inizierà ad attraversare le strisce: il pedone sarà completamente nascosto da un furgone parcheggiato sulla corsia di destra in prossimità delle strisce pedonali. Quando il pedone sarà visibile sulle strisce pedonali l’EGO vehicle sarà già in prossimità di esse, e ci si aspetta che l’EGO vehicle attivi la frenata di emergenza per evitare la collisione. Una volta completato l’attraversamento, l’EGO vehicle ripartirà e poco dopo si verificherà un evento di cut-in da parte di un altro veicolo che sopraggiunge sulla corsia di sinistra: anche in questo caso, grazie principalmente al secondo RADAR aggiunto, l’EGO vehicle dovrà reagire all’evento di cut-in attivando la frenata di emergenza. La fase di test di questo scenario è risultata più lunga, soprattutto alla luce delle novità introdotte sia al livello algoritmico che di configurazione dei sensori a bordo. Inutile dire che i principali problemi son emersi sulla parte di calcolo della traiettoria e relativo controllo sul pedale del freno. Anche in questo caso, successive fasi di fine tuning e bug-fix hanno permesso di gestire lo scenario nella sua interezza.
3. Overtake: in questo scenario abbiamo voluto dare la possibilità al nostro EGO vehicle di decidere quando è possibile effettuare in modo sicuro un sorpasso. La configurazione dei RADAR è stata aggiornata (configurazione C in Figura 3), e in relazione ad essa anche l’algoritmo per gestire le letture dei nuovi sensori in modo omogeneo e armonizzato con quelli già presenti. Sempre al livello algoritmico son state introdotte due nuove funzionalità, ovvero il rilevatore di stato della corsia e il decisore per il sorpasso: queste funzioni sono risultate necessarie per valutare non solo quando la corsia di sinistra è libera per effettuare il sorpasso, ma anche per valutare le condizioni di rientro sulla corsia di destra. La mappa di questo scenario è simile a quella dello scenario descritto al punto 1, ma questa volta saranno presenti molti più veicoli davanti l’EGO vehicle. In aggiunta a questi, ci sarà un veicolo che partirà accanto all’EGO vehicle sulla corsia di sinistra, bloccando temporaneamente questa e impedendoci di sorpassare il veicolo di fronte (che inizierà a rallentare gradualmente). Il resto dello scenario è volto a forzare diverse condizioni di sorpasso e rientro sulla corsia di destra per validare questa nuova versione dell’algoritmo. Anche in questo caso i primi risultati ottenuti hanno evidenziato alcuni problemi, principalmente dovuti a come le varie funzionalità introdotte interagissero tra loro in relazione alle letture ricevute dai sensori. Sempre in questa fase, è stato possibile analizzare anche la gestione del pedale dell’acceleratore al fine di risolvere il problema che era stato evidenziato con il primo degli scenari discussi.
Il set di scenari riportati sopra ha costituito un vero e proprio “virtual proving ground” per la soluzione di Closed Loop Simulation che Accenture ha sviluppato. Ognuno degli scenari ha permesso non solo di identificare e risolvere bug nell’algoritmo, ma di evidenziarne anche potenziali punti di miglioramento che son stati recepiti in successive revisioni dell’algoritmo. Ogni scenario aggiunto è infine entrato a far parte della suite di test perché fosse possibile eseguire il non-regression per ogni cambiamento apportato all’algoritmo.

Sfide del processo alternativo proposto

La fase di test e validazione descritta nelle sezioni precedenti ha permesso di evidenziare alcuni dei vantaggi della soluzione proposta, tra cui:

• Abbattimento dei costi: il bug-fix e test sul framework per ognuno dei bug emersi non ha reso necessario un solo litro di carburante;
• Complementarietà delle virtual miles: effettuare i test con il framework di Closed Loop Simulation ha permesso di anticipare molti bug che diversamente sarebbero stati riscontrati dai test on-field, con conseguenti ritardi dovuti alla fase di analisi, bug-fix e non-regression;
• Ripetibilità dei test case: l’esecuzione della suite di scenari di test ha evidenziato come in fase di bug-fix sia stato fondamentale poter riprodurre le esatte condizioni che avevano prodotto una risposta errata da parte dell’algoritmo;
• Scalabilità: una volta definita la suite di scenari di test, e messa in piedi l’infrastruttura per l’esecuzione automatica dei test case, si può far leva sul Cloud in termini computazionali per parallelizzare le test session e accelerare l’ottenimento dei relativi risultati.

L’approccio proposto porta al profilarsi di nuove figure da coinvolgere nel processo di sviluppo e test degli algoritmi AV, tra cui ad esempio il designer per gli scenari di test e il designer per le ambientazioni 3D. Sulla base di quanto precedentemente detto, queste due figure lavoreranno a stretto contatto. Infine, non si può dire che l’approccio descritto sia esente da sfide perché possa essere usato in modo intensivo e estensivo per gli scopi proposti. Uno dei punti più spinosi riguarda le HD map, alla luce del fatto che l’HD map usata per il test in Closed Loop Simulation e per il test on-field deve poter essere la stessa. In questo caso le sfide sono su molteplici aspetti, quali ad esempio la modalità di generazione delle HD Map, i processi di aggiornamento e l’inter-operabilità dei formati esistenti.

Conclusioni e sviluppi futuri

In questo articolo è stata presentata una soluzione alternativa al processo canonico di sviluppo di algoritmi ADAS, introducendo i relativi punti di forza e le potenziali sfide all’orizzonte. Osservando il contesto dei players che hanno deciso di investire in tecnologie di sviluppo per la realizzazione di veicoli autonomi si potrà capire da subito come questo sia in fermento e continua evoluzione. Non esiste in sostanza un approccio unico al problema, sebbene emergano dei macro-trend su come lo si possa affrontare. Provando a delineare un percorso verso la realizzazione di un, riteniamo che alcuni aspetti e tecnologie potranno agire da acceleratori, tra cui:
Introduzione del 5G: rivoluzionerà il modo che abbiamo di concepire a oggi la mobilità connessa, grazie all’enorme banda a disposizione. Tra i possibili use case in cui il 5G può portare enormi benefici, possiamo citare il download (e update) delle HD map, risaputamene onerose in termini di dati, come anche l’upload dei dati verso il cloud (siano essi dati per fare il training delle reti neurali, piuttosto che dati di diagnostica del veicolo);
Evoluzione dei sensori: il set “ideale” di sensori che oggi viene installato sui veicoli di test ha una BOM (Bill Of Material) considerevole. Quando si parla di evoluzione dei sensori si intende quindi un miglioramento non solo nel processo produttivo e nelle tecnologie in uso per abbattere i costi, ma soprattutto sensori più affidabili;
Smart Cities: un veicolo autonomo, seppur “connesso”, dovrà poter contare su un’infrastruttura per ottenere feedback in tempo reale su cosa accade;
AI transparency: permettere in ogni dato istante di conoscere i razionali alla base delle scelte attuate dal processo di decision making è importante per tutte le figure coinvolte nel processo di sviluppo di un veicolo autonomo.
Concludendo, risulta difficile pensare all’introduzione dei veicoli autonomi in modalità OFF/ON. Acquista invece sempre più valore l’introduzione graduale di sistemi a supporto del guidatore, che possano via via educarlo a demandare il controllo del veicolo agli algoritmi fino a che questo non risulti totale.

Riferimenti esterni

[1]    TC Sessions: Mobility 2019 [Online] https://techcrunch.com/2019/07/10/waymo-has-now-driven-10-billion-autonomous-miles-in-simulation/
[2]    Ubuntu. The leading operating system for PCs, IOT devices, servers and the cloud. [Online] https://ubuntu.com/
[3]    ROS Powering the world’s robots. [Online] https://www.ros.org/
[4]    Dupuis, Marius. VIRES Simulationtecnologie GmbH. Vires. [Online] Vires. https://vires.com/
[5]    Automated Vehicles for safety. [Online] https://www.nhtsa.gov/technology-innovation/automated-vehicles-safety.
 

« Indice del n. 96