Il mio drone tiene lo 0,9% di deriva attraverso una bolla di jamming GPS. Il codice di cui vado fiero è la riga che rifiuta di volare.

Non mi aspettavo che la parte più importante di questo progetto fosse quella che rinuncia.

Avevo passato gran parte di un pomeriggio a fissare il replay di un volo sintetico. Un drone attraversa una missione di 80 secondi su un percorso di 245,3 m. Il GPS tiene per i primi 18 secondi, poi muore quando l'aeromobile entra in una bolla di guerra elettronica simulata. Sullo schermo, tre tracce si aprono a ventaglio da quel momento. Una di esse, una linea rosa brillante, si stacca verso l'angolo della mappa e continua, sicura di sé e completamente sbagliata, mentre un piccolo indicatore accanto insiste che tutto va bene.

Quella linea rosa è l'odometria visuale-inerziale di stock, e guardarla mentirmi è ciò che ha cambiato l'intera forma di ciò che stavo costruendo. Avevo assunto che il problema difficile nella navigazione senza GPS fosse restare accurati. Non lo è. Il problema difficile è sapere, nell'unico momento che conta, che non lo sei.

Nello spazio aereo senza GPS, una posizione sicura-ma-sbagliata è più pericolosa di un onesto "non lo so."

Questa è la storia di come ho costruito Lodestar, il nostro motore di integrità della navigazione, e della settimana che ho passato a risolvere il problema sbagliato prima di capire quello giusto.

Ho inseguito l'accuratezza per una settimana prima di capire il vero problema

Sono partito da dove parte la maggior parte delle persone, cioè dallo stimatore. La guerra elettronica ha reso il GPS inaffidabile proprio nei luoghi in cui i droni autonomi contano ora: spazio aereo conteso, cave minerarie, tunnel, canyon urbani. Jamming e spoofing nello spazio aereo conteso sono ormai ampiamente riportati, abbastanza comuni da far sì che la navigazione senza GPS abbia smesso di essere una curiosità di ricerca e sia diventata un requisito duro. La soluzione ovvia è aggiungere l'odometria visuale-inerziale, fondere la telecamera con i sensori inerziali e sperare che la deriva resti piccola.

Così ho costruito un vero VIO EKF tightly-coupled e ho passato la prima settimana a renderlo accurato. Stesso filtro, tre configurazioni oneste: una baseline di dead-reckoning IMU senza alcuna visione, una VIO di stock che fonde ogni feature visuale che vede, e una versione integrity-aware più selettiva su quali feature crede. Le ho fatte girare tutte contro una ground truth che il simulatore genera indipendentemente da ogni stimatore, così niente poteva votarsi i propri compiti. L'intera missione è seeded, riproducibile byte per byte, cosa che all'epoca contava più di quanto realizzassi.

I numeri di accuratezza erano genuinamente buoni. Attraverso la bolla di jamming, lo stimatore integrity-aware tiene 0,92% di deriva, 2,26 m di errore finale su quel percorso di 245,3 m. Il dead-reckoning, per confronto, esplode a 30,95% di deriva e 75,92 m di errore finale, che è la differenza tra atterrare sul pad e atterrare nella contea successiva. Sono stato contento di me stesso per circa un giorno.

Poi ho fatto girare il convoglio.

Cosa fa una bolla di jamming a un drone che si fida dei propri occhi

Voglio essere onesto su quanto ordinario sembri il passaggio dal GPS, perché è la parte che funziona. Quando il GPS cade a t=18 s, il filtro ripesa sulla sorgente visuale-inerziale senza cambio di modalità, senza allarme, senza cucitura visibile all'operatore. La stima resta semplicemente continua. Se stessi volando la missione non sentiresti sparire il pavimento.

Ecco cosa ho sottovalutato. Un drone che gira sulla visione non fallisce peggiorando lentamente. Fallisce agganciandosi alla cosa sbagliata e riportando una posizione pulita e sicura di sé che è semplicemente spazzatura. Lo stimatore non sa di essere stato ingannato, perché il meccanismo che calcola la posizione è lo stesso meccanismo che dovrebbe notare che la posizione è sbagliata. Avevo costruito un sistema accurato fino al momento in cui era catastroficamente, silenziosamente in errore, e non avevo modo di distinguere i due dall'interno.

Non è un problema di tuning. Non puoi uscire a forza di tuning da un sistema che è sicuro di essere sbagliato. Mi serviva qualcosa che stesse del tutto fuori dallo stimatore.

Il convoglio che ha insegnato a un buon stimatore a mentire

Ho costruito lo scenario del convoglio apposta per rompere il mio stesso lavoro, e ci è riuscito. Tra t=30 e t=43 una colonna di veicoli attraversa una radura a bassa texture, spruzzando feature spurie che sembrano, a un front-end VIO affamato, esattamente come i landmark stabili che vuole tracciare. Questo è il fallimento documentato di ORB-SLAM3, quello in cui l'algoritmo traccia il camion e conclude che il drone è fermo.

La VIO di stock ci è cascata del tutto. Nella stessa run seeded, si aggancia ai veicoli in movimento e vola via, finendo a 28,79% di deriva e 70,61 m di errore finale, con un ATE di 32,95 m che è in realtà peggiore di non usare alcuna visione. Quella era la linea rosa che stavo guardando. Il dettaglio brutto è che mentre falliva, la sua confidenza interna sembrava sana. Lo stimatore era sicuro di sé. Era sicuro di una posizione che andava alla deriva verso il bordo della mappa.

Lo stimatore integrity-aware sopravvive al convoglio per una ragione semplice: rifiuta di credere alle feature che appartengono a oggetti in movimento. Nel fotogramma sopra, il mascheramento semantico ha rifiutato le 10 feature del convoglio e ha tenuto solo le 2 statiche, così lo stimatore non si aggancia mai alla colonna. La traiettoria tiene. Ma la parte che non avevo previsto è ciò che ha fatto il mio monitor di integrità nello stesso momento. Non ha dipinto lo schermo di verde né ha finto che il mondo andasse bene. È passato a AMBER, perché con le feature del convoglio mascherate c'erano davvero solo una manciata di landmark statici di cui fidarsi. Era accurato ed era nervoso, allo stesso tempo, e lo ha detto.

Quella è stata la prima volta che il monitor mi ha detto qualcosa che lo stimatore non poteva, e vale più dell'accuratezza da sola. Ha anche forzato la domanda che stavo evitando.

Perché lo stimatore non può semplicemente certificare se stesso?

Ho passato un numero imbarazzante di ore a cercare di rispondere con i numeri dello stimatore stesso. Il mio primo check di integrità leggeva semplicemente l'incertezza riportata dal filtro, il suo sigma di posizione, e applicava un gate su quello. Se la covarianza sembrava stretta, vola. Sembrava ragionevole.

Il convoglio l'ha demolito. Quando la VIO di stock si è agganciata al camion, il suo sigma riportato è rimasto piccolo. Il filtro era sicuro di sé proprio perché aveva trovato qualcosa di consistente da tracciare. La consistenza era una menzogna, ma la covarianza non poteva saperlo, perché la covarianza è una dichiarazione che lo stimatore fa su se stesso. Stavo chiedendo al testimone di certificare la propria testimonianza.

La fiducia non deve dipendere dalla cosa di cui ci si fida.

Quella frase è diventata il design. Il Monitor di Integrità della Navigazione vive fuori dallo stimatore di proposito, come codice separato che risponde a una domanda diversa. Non "qual è la mia posizione," a cui risponde l'EKF, ma "questa posizione è affidabile in questo momento," a cui l'EKF è strutturalmente incapace di rispondere su se stesso. Il monitor fonde tre segnali in uno stato GREEN, AMBER o RED con soglie dure: conteggio feature utilizzabili (GREEN a 8 o più, RED sotto 1), sigma di posizione (GREEN sotto 0,6 m, RED oltre 1,5 m), e vision NIS, la consistenza delle innovazioni chi-quadro che cattura esattamente il caso in cui lo stimatore è sicuro di sé e sbagliato (GREEN sotto 7,0, RED oltre 30,0). Nessun singolo numero può essere manipolato dallo stimatore, perché due dei tre non vengono affatto dall'auto-valutazione dello stimatore.

Questa è la cosa in cui ora credo più fortemente riguardo all'autonomia safety-critical. Una VIO migliore non risolve il fallimento sicuro-ma-sbagliato, perché "è affidabile" è una domanda diversa da "cos'è questo," e non puoi rispondere alla prima con il meccanismo che ha prodotto la seconda. L'industria continua a correre per rendere lo stimatore più intelligente. L'architettura duratura non è uno stimatore più intelligente. È un monitor disposto a sovrastarlo.

La riga di codice che rifiuta di volare

Il momento in cui ho davvero capito il mio prodotto è stato il tunnel, e lo ricordo perché è il momento in cui il sistema fa di meno.

Tra t=52 e t=66 la missione entra in un tunnel buio e le feature visuali utilizzabili collassano essenzialmente a zero. Non c'è nulla da vedere. Nessuno stimatore, per quanto ben messo a punto, può fabbricare una posizione affidabile da una scena che non può osservare. Non è un fallimento da correggere. È un fatto da rispettare. La VIO di stock, ancora a tentare, scivola via in una posizione che non ha diritto di rivendicare.

Lodestar fa qualcos'altro. Le feature muoiono, l'incertezza di posizione supera la soglia, e dopo 0,5 secondi di RED sostenuto il monitor aggancia il failsafe e comanda return-to-home a t=52,5 s. Non bluffa una posizione. Dichiara la stima non affidabile e riconsegna il controllo a un comportamento sicuro, e lo fa in modo deterministico, senza alcun modello nel loop che decida qualcosa.

Voglio stare attento sui numeri qui, perché l'onestà è l'intera proposta. Su questa unica missione seeded, il monitor segnala il tunnel genuinamente inosservabile il 100% delle volte e fa falsi allarmi sulla tratta senza GPS in condizioni sane circa lo 0,1% delle volte, tenendo GREEN su il 56,3% del volo senza GPS. Questi sono i risultati di questa missione, una prova fedele alla fisica del meccanismo, non una garanzia di flight-test open-world. L'affermazione duratura è la struttura: fiducia calcolata fuori dallo stimatore, RED sostenuto fino a un return-to-home agganciato, astensione onesta su una scena che nessuno potrebbe navigare. I metri esatti appartengono a questa run. L'architettura appartiene a ogni run.

La riga di codice più preziosa in uno stack di autonomia è quella che rifiuta di volare.

Cosa ho messo nel report perché nessuno debba fidarsi solo della mia parola

Non volevo che nessuno dovesse fidarsi dei miei screenshot, così l'ultima cosa che ho costruito è la ricevuta. Un click esporta un Flight Integrity Report, JSON più HTML stampabile, con il tabellone, le metriche in evidenza, la correttezza dell'astensione, il tempo del failsafe, la timeline degli eventi e, la parte che mi interessa di più, una disclosure esplicita di scope su cosa è stubbato rispetto a ciò che è differito.

Quella disclosure non è un disclaimer che seppellisco. È una feature. Il report dichiara chiaramente che il front-end visuale è un sostituto, che la fusione LiDAR è un vincolo di range simulato piuttosto che un vero fattore LiDAR, che l'interfaccia MAVLink e il throughput Jetson non sono esercitati qui, e che i 30-45 FPS su un Jetson Orin NX 16 GB sono una specifica di target-hardware, non un risultato misurato. I 16.000 aggiornamenti di propagazione EKF nel report sono stati misurati sulla macchina demo. Gli FPS no, e il report lo dice con quelle parole.

Quella run LiDAR merita di soffermarcisi perché è dove molte demo imbroglierrebbero. Attivi il LiDAR simulato e il tunnel recupera: il vincolo di range ancora la soluzione, l'integrità tiene, e nessun failsafe scatta, perché la scena non è più inosservabile. Sarebbe facile mostrare solo quella run e dichiarare il problema risolto. Ma il report porta anche il costo di cui la pagina della soluzione si fa carico, circa 250-400 g di payload e 8-12 W di potenza. Il LiDAR è un vero trade-off ingegneristico con un vero conto SWaP-C, non una vittoria gratuita, e un acquirente merita di vedere il conto accanto al beneficio.

C'è esattamente un solo modello in prossimità di questo sistema, un pulsante opzionale che redige la narrativa della technical-review dal report strutturato. Gira interamente fuori dal loop di volo. Scrive prosa. Non tocca mai una decisione di controllo. Il gate che decide se volare è deterministico, seeded e offline, e farebbe la chiamata identica con il pulsante narrativo strappato. Sono stato fermo su quel confine, perché il giorno in cui un language model ottiene un voto su se un drone si fida della propria posizione è un giorno di cui non voglio essere responsabile.

A cosa continuo a tornare

Mi sono proposto di costruire un drone che resti accurato quando il GPS muore, e l'ho fatto, su questa missione, sotto l'uno percento di deriva. Ciò che non mi aspettavo era di uscire convinto che l'accuratezza fosse la metà facile.

L'accuratezza è una gara a cui chiunque può iscriversi. Tutti in questo campo stanno rendendo il loro stimatore un po' più stretto, le loro feature un po' più dense, il loro backend un po' più intelligente, e tutto ciò è buon lavoro. Ma niente di ciò risponde alla domanda che davvero uccide un drone in una bolla di jamming, che non è "quanto sbaglio" ma "sono in una situazione in cui non posso sapere quanto sbaglio." Quella domanda deve essere posta dall'esterno dello stimatore, da qualcosa disposto a dire la cosa poco scintillante e rinunciare ai controlli.

L'accuratezza è una gara a cui chiunque può iscriversi. Un sistema che sa quando è cieco è il prodotto.

Puoi far girare l'intero sistema tu stesso e guardare la linea rosa volare via, poi guardare lo stato RED scattare, a veriprajna.com/it/demos/lodestar-autonomia-dei-droni-gps-denied-che-sa-quando-non-puo. È seeded, quindi vedrai esattamente ciò che ho visto io.

E se preferisci vederlo piuttosto che leggermi descriverlo, ecco l'intero sistema che gira da capo a coda.

La domanda che non ho smesso di rimuginare è questa. Se il comportamento più prezioso nel tuo stack di autonomia è il rifiuto di agire, quanto del tuo budget di engineering va nella parte che rinuncia, e quanto nella parte che non ha mai imparato quando farlo?