Autoware 2.0 integra il Diffusion Planner, ma il selettore non è attivo

La Autoware Foundation ha rilasciato Autoware 2.0, che affianca al planner tradizionale il Diffusion Planner, un generatore di traiettorie basato su apprendimento. Per chi sviluppa sistemi di guida autonoma, la novità è poter scegliere un planner appreso senza abbandonare lo stack esistente. Ma nella versione 2.0.0 non c’è ancora il confronto automatico tra più generatori: all’avvio se ne seleziona uno solo e il selettore delle traiettorie non viene lanciato. La Fondazione presenta inoltre nuovi strumenti per reperire modelli, comporre aree di lavoro e documentare configurazioni complete.

In sintesi: l’architettura descrive un futuro in cui più moduli producono traiettorie e un selettore le valuta; il rilascio attuale permette invece di scegliere tra planner a regole e Diffusion Planner. La differenza separa il progetto architetturale dalle funzioni effettivamente operative nella versione 2.0.0.

Che cosa può usare oggi chi sviluppa

La Fondazione annuncia Autoware 2.0 come un’evoluzione dello stack, non come la sua sostituzione. La documentazione tecnica precisa che, nella versione 2.0.0, il parametro di avvio planning_setting consente due scelte: rule_based, predefinita, oppure diffusion_planner. In entrambi i casi il risultato passa attraverso la validazione della pianificazione; con il Diffusion Planner, il componente di post-elaborazione passa al validatore la prima traiettoria candidata.

La documentazione dell’architettura 2.0 distingue questo funzionamento attuale dal disegno generale: più generatori possono produrre traiettorie candidate; il selettore dovrebbe verificarle, scartare quelle non sicure e classificare le restanti prima di sceglierne una. Nella 2.0.0, però, quel nodo e i relativi componenti non vengono lanciati. La presenza dei pacchetti nel software non equivale quindi alla disponibilità della selezione automatica.

Il planner appreso non coincide con una guida end-to-end completa

Il rilascio introduce metodi di pianificazione appresi, ma non sostituisce con un unico modello tutti i moduli della piattaforma. Nella configurazione documentata, il Diffusion Planner riceve informazioni quali stato del veicolo, mappa vettoriale, percorso, oggetti tracciati e stato dei semafori, e produce traiettorie candidate. La Fondazione descrive anche un’architettura che in futuro può ospitare generatori end-to-end e configurazioni ibride; non significa che la versione 2.0.0 esegua già un sistema end-to-end unico dalla lettura dei sensori al comando del veicolo.

La demo in simulatore con moduli a regole e modelli E2E è riportata nel comunicato della Fondazione. È una dimostrazione in simulazione, non una misura di prestazioni o una prova di sicurezza su strada. Anche il selettore, nel disegno architetturale, dovrebbe applicare controlli e classificare traiettorie: poiché non è attivo nella 2.0.0, non va presentato come una protezione già implementata in quel rilascio.

C’è inoltre un requisito pratico per chi vuole provare il Diffusion Planner: usa TensorRT e la procedura documentata richiede una GPU NVIDIA. La configurazione Autoware 2.0.0 indicata dalla Fondazione usa la versione v5.0 del modello. Il versionamento aiuta a identificare quale artefatto è associato alla configurazione, ma non dimostra da solo l’idoneità del modello a ogni veicolo o condizione di utilizzo.

Modelli e pacchetti: più strumenti per comporre lo stack

La gestione dei modelli passa a una logica per pacchetto: Hugging Face diventa la sede predefinita per modelli e dataset della Fondazione, con versioni identificabili. I manifesti possono comunque indicare altri server, tra cui l’infrastruttura ML della Fondazione, AWS o servizi di terze parti. Il cambiamento rende più esplicito da dove provengono gli artefatti e quale versione viene scaricata; non certifica i modelli né sostituisce i test sul sistema in cui saranno usati.

L’Autoware Index è un registro di pacchetti compatibili e configurazioni di riferimento. Attraverso il sito e l’interfaccia a riga di comando, gli sviluppatori possono selezionare componenti e dipendenze e generare un file .repos per comporre un’area di lavoro. Il registro pubblica anche risultati di compilazione e test dei pacchetti rispetto a versioni di Autoware: sono verifiche di compatibilità software circoscritte, non una valutazione di sicurezza dell’intero veicolo.

La Fondazione segnala inoltre che cinque pacchetti di Autoware Universe sono stati spostati in repository separati e registrati nell’Index. La scelta allarga la scoperta e la composizione dei componenti oltre il repository principale, lasciando ai contributori la gestione dei rispettivi pacchetti.

Il Reference Design documenta una configurazione completa

Assemblare moduli software non basta a descrivere un sistema di guida autonoma: contano anche veicolo, sensori, hardware di calcolo, condizioni operative e caso d’uso. Il framework Autoware Reference Design combina un profilo di impiego con uno stack software di riferimento, includendo moduli, versioni dei modelli e parametri. L’obiettivo dichiarato è rendere documentata e riproducibile una configurazione, così che componenti e requisiti possano essere valutati insieme.

Un progetto di riferimento è però un modello documentato e adattabile, non una garanzia che la configurazione sia pronta per la produzione o adatta a ogni contesto. Il comunicato distingue esplicitamente tra capacità previste e risultati dimostrati; per giudicare l’applicabilità restano necessari test riferiti alla piattaforma, all’ambiente operativo e ai requisiti specifici.

Che cosa resta da verificare nei prossimi passaggi

Il contributo concreto di Autoware 2.0 è l’aggiunta di un planner appreso selezionabile, insieme a strumenti più strutturati per versionare modelli, individuare pacchetti e descrivere stack completi. Il passaggio architetturale successivo è rendere operativa la selezione tra più generatori: la documentazione colloca questa evoluzione nella roadmap, non tra le funzioni già attive nella 2.0.0.

Per valutare l’impatto del rilascio occorrerà quindi distinguere tre piani: la pianificazione tradizionale già disponibile, l’opzione Diffusion Planner da provare con i requisiti hardware documentati e il sistema multi-generatore con selettore descritto come obiettivo architetturale. Le prove su veicoli e condizioni operative specifiche restano decisive per stabilire che cosa una configurazione possa fare al di fuori della simulazione.