Disponibile anche in inglese: English version.
Le buche stradali costano milioni alle amministrazioni comunali. L’asfalto si usura sotto il traffico pesante, i cicli termici e le infiltrazioni di pioggia; le micro-fessure si allargano fino a formare crateri che danneggiano le auto.
Nella maggior parte delle città, la manutenzione stradale interviene solo dopo le segnalazioni dei cittadini. Un automobilista danneggia un cerchione o subisce un incidente, inoltra un reclamo, un perito effettua un sopralluogo a distanza di giorni e infine una squadra riempie il dissesto con asfalto a freddo. A quel punto, il danno circostante si è già esteso.
Dall’8 al 10 maggio 2026, insieme ai miei compagni di squadra Mirco Bonomo e Assylbek Bugybay, ho partecipato al GDG AI HACK 2026(si apre in una nuova scheda) a Milano. L’evento è stato organizzato da GDG on Campus PoliMi e GDG Cloud Milano presso il Randstad Box. Abbiamo gareggiato nella categoria “See Beyond” sponsorizzata da Luxonis(si apre in una nuova scheda) e sviluppato Techtonics: un sistema di visione artificiale montato a bordo veicolo che individua le buche e ne misura la profondità volumetrica in tempo reale.

Perché la sola rilevazione 2D non è sufficiente
La maggior parte dei sistemi di rilevamento buche esegue un modello 2D di object detection (solitamente YOLO o SSD) sui fotogrammi RGB acquisiti da una dashcam. Un rettangolo di delimitazione (bounding box) 2D individua l’anomalia visiva, ma presenta tre limiti strutturali:
- Ombre e macchie d’asfalto. Una chiazza d’olio, una rattoppatura fresca o l’ombra proiettata dai rami possono apparire identiche a una buca su una normale fotografia. Con il cambiare dell’inclinazione del sole, una singola telecamera genera troppi falsi positivi.
- Assenza di profondità. Un riquadro 2D non distingue una scalfittura superficiale di 2 mm da un cratere profondo 12 cm capace di distruggere un ammortizzatore.
- Impossibilità di stabilire priorità di intervento. Le squadre di manutenzione possono riparare un numero limitato di dissesti al giorno. Per pianificare gli interventi servono parametri oggettivi: volume, profondità massima e superficie.
Serviva la terza dimensione. Una stereo camera consente di calcolarla: a partire dalla disparità tra due punti di vista differenti, possiamo ricostruire la superficie stradale in coordinate metriche ().
Elaborazione interamente on-device (Edge Computing)
Inviare stream video ad alta definizione da centinaia di autobus urbani verso un data center centralizzato non è sostenibile. La banda di upload su rete mobile è costosa e limitata, la latenza di rete impedirebbe qualsiasi avviso tempestivo al conducente, e i flussi video includerebbero volti di pedoni e targhe di veicoli.
Per queste ragioni la telecamera svolge l’intera elaborazione a bordo: inferenza della rete neurale, calcolo della mappa di profondità e fitting del piano stradale.

Abbiamo impiegato una Luxonis OAK-D Pro. Il dispositivo integra un sensore RGB da 12 MP, una coppia di camere monocromatiche global shutter a distanza fissa (baseline stereo) e un proiettore a punti infrarossi per superfici con texture poco contrastata. La VPU integrata esegue la rete neurale ed elabora la mappa di disparità direttamente sull’hardware edge, azzerando il carico sulla CPU del veicolo ospitante.
La pipeline operativa si articola in quattro fasi:
- Rilevamento. Una rete neurale in esecuzione sulla camera identifica le regioni di interesse (ROI) che contengono potenziali danni nei fotogrammi RGB.
- Misurazione. La pipeline campiona la profondità stereoscopica all’interno e attorno a ogni ROI per calcolare la reale depressione del manto stradale.
- Valutazione del danno. Un algoritmo combina profondità e area superficiale assegnando un indice di gravità da 1 a 10.
- Segnalazione. Il dispositivo trasmette le coordinate geografiche, la gravità del danno e la marca temporale ai server comunali per la pianificazione degli interventi.
Misurare la profondità su un veicolo in movimento
Stimare la profondità volumetrica su un veicolo in corsa è stata la sfida ingegneristica più complessa. Su un banco di prova statico è sufficiente leggere il valore di distanza all’interno del riquadro. Su strada, questo metodo fallisce.
Il veicolo oscilla, rolla e rimbalza sulle sospensioni. Le carreggiate presentano pendenze, dossi e una convessità a schiena d’asino per far defluire l’acqua piovana. Una buca a cinque metri di distanza non si trova su un piano ortogonale all’asse ottico dell’obiettivo.

Il nostro obiettivo non era misurare la distanza euclidea dalla telecamera, ma la profondità del dislivello rispetto alla superficie stradale circostante. Ci siamo riusciti in tre passaggi.
Fase 1: fitting del piano stradale locale
Non assumiamo che la strada sia perfettamente orizzontale. Campioniamo i pixel di profondità nella corona adiacente al riquadro di delimitazione. Questi punti appartengono all’asfalto intatto attorno alla buca e definiscono l’orientamento effettivo della carreggiata.
Applichiamo quindi una regressione sul piano tridimensionale:
dove sono le coordinate dei pixel nel frame e è la profondità. Una stima ai minimi quadrati sui punti attorno al riquadro calcola i parametri , e . Ricalcoliamo il piano su ciascun singolo fotogramma: in questo modo il riferimento si adatta istantaneamente alle vibrazioni del veicolo, alla pendenza della strada e al beccheggio dell’inquadratura.
Fase 2: filtraggio e pulizia della mappa di profondità
I dati di profondità stereo sull’asfalto grezzo contengono rumore. Riflessi di pozzanghere e la grana uniforme del bitume possono ingannare l’algoritmo di corrispondenza stereo (block matching). All’interno del riquadro applichiamo un filtro mediano sul buffer di profondità. Questo elimina i pixel anomali isolati e preserva la nettezza dei bordi della cavità.
Fase 3: estrazione robusta della profondità (95° percentile)
All’interno della ROI filtrata, la profondità locale della buca su ciascun pixel corrisponde allo scostamento rispetto al piano stradale calcolato:
Il pixel più profondo in assoluto è quasi sempre un valore anomalo causato da rumore di misura, dal riflesso di una pozzanghera o da pietrisco smosso. Per evitare sovrastime, prendiamo il 95° percentile dei valori di all’interno della regione al posto del massimo. Questo valore si mantiene stabile ed estremamente coerente tra un fotogramma e il successivo.
La dimostrazione dal vivo
Nelle 48 ore dell’hackathon abbiamo sviluppato la pipeline computazionale, ottimizzato i calcoli matematici, condotto test nell’area circostante la sede e realizzato un’applicazione di monitoraggio e tracciamento in tempo reale.
Durante la demo dal vivo davanti alla giuria, il prototipo ha:
- rilevato una buca con una confidenza del ;
- localizzato il danno nello spazio 3D a , , ;
- calcolato una depressione di sotto il livello stradale, assegnando il relativo punteggio di gravità.
Ecco il video della dimostrazione dal vivo (disponibile anche su YouTube(si apre in una nuova scheda)):


Conclusioni e lezioni apprese
In un hackathon di 48 ore non c’è tempo per astrazioni premature o complessità inutili. Si costruisce ciò che funziona sul campo, si individuano i punti di rottura dei sensori e si correggono all’istante.
Lavorare con Mirco e Assylbek è stata un’esperienza intensa e divertente: dalla calibrazione della OAK-D Pro su un banco improvvisato fino alla verifica delle formule di fitting del piano alle quattro del mattino a suon di caffè. Techtonics ha dimostrato che una stereo camera installata sui mezzi pubblici può mappare lo stato del manto stradale durante il normale servizio di linea, senza costi aggiuntivi di personale dedicato.
Un ringraziamento sincero a GDG on Campus PoliMi, GDG Cloud Milano e Luxonis per l’organizzazione dell’evento e per averci messo a disposizione l’hardware.