RTK e PPK per la fotogrammetria con drone in Italia

Un drone RTK fotografa e, nello stesso istante, registra la posizione della camera con accuratezza centimetrica invece che metrica. Per la fotogrammetria significa meno target a terra, meno tempo in campo e modelli più stabili. Non significa "zero GCP": in questa guida vedi cosa il drone RTK/PPK ti dà davvero, come passare le posizioni accurate a WebODM e perché qualche punto misurato a terra resta necessario.

1. RTK e PPK: la differenza#

Entrambe le tecniche correggono la posizione GNSS del drone con i dati di una stazione di riferimento a coordinate note. La differenza è quando avviene la correzione.

Voce	RTK (Real Time Kinematic)	PPK (Post Processed Kinematic)
Quando si corregge	In volo, in tempo reale	Dopo il volo, al computer
Cosa serve in campo	Collegamento dati continuo (rete mobile o radio) con la base o la rete GNSS	Solo che il drone registri i dati grezzi GNSS
Dove finiscono le coordinate	Direttamente nell'EXIF delle foto	In un file prodotto dal software di post-elaborazione, da passare a WebODM con `--geo`
Punto debole	Se il collegamento cade, la soluzione degrada (da "fix" a "float") senza che tu te ne accorga subito	Serve un passaggio in più e un software, spesso del produttore del drone
Punto forte	Immediato, niente post-elaborazione	Non dipende dalla copertura mobile in volo; puoi rifare il calcolo con dati di riferimento migliori

Per WebODM il risultato è lo stesso: posizioni accurate delle camere. Con RTK le trovi già nell'EXIF; con PPK le fornisci con il file geo.txt (§4).

2. Droni con modulo RTK#

Il modulo RTK è presente su molti droni delle serie enterprise e su alcune piattaforme professionali:

Quadricotteri enterprise con modulo RTK opzionale o integrato. Esempi noti: DJI Mavic 3 Enterprise con modulo RTK, DJI Phantom 4 RTK e i modelli successivi delle stesse linee. Scrivono nell'EXIF (o in un log) la posizione corretta e spesso una stima dell'accuratezza.
Droni ad ala fissa o VTOL per grandi aree, quasi sempre PPK, talvolta RTK.
Piattaforme modulari con ricevitori GNSS multibanda aggiunti dall'utente, per lo più PPK.

Non riportiamo specifiche di singoli modelli, che cambiano con il firmware: verifica sul sito del produttore cosa viene scritto nell'EXIF e in quale sistema di riferimento. Per la scelta del drone vedi Quale drone per la fotogrammetria in Italia.

Cosa conta, indipendentemente dal modello: un otturatore meccanico o globale (con posizioni centimetriche il rolling shutter diventa il primo limite; WebODM può correggerlo, vedi casi particolari); la sincronizzazione tra posizione e istante di scatto; l'offset antenna-camera, compensato dal firmware nei droni di serie e da gestire a mano nelle soluzioni artigianali.

3. Stazioni base e reti GNSS in Italia#

Il drone RTK ha bisogno di correzioni. Le fonti possibili sono tre.

3.1 Base propria#

Un ricevitore GNSS fisso sul luogo del rilievo che trasmette correzioni al drone via radio o rete. Funziona anche senza copertura mobile, ma la base conosce la propria posizione solo se la misuri (statico su un caposaldo noto o inquadramento tramite una rete). Se la avvii "dove sta" con posizione autonoma, il rilievo sarà preciso al proprio interno ma traslato di metri rispetto al sistema nazionale.

3.2 Reti regionali pubbliche di posizionamento#

Molte Regioni gestiscono reti di stazioni permanenti GNSS che erogano correzioni RTK (protocollo NTRIP) e dati per il post-processing, spesso gratuitamente o con registrazione, inquadrate nel sistema nazionale RDN2008 (ETRF2000). Copertura e condizioni d'uso variano da Regione a Regione: prima di un rilievo verifica sul portale regionale se il servizio è attivo e quali "mountpoint" sono disponibili.

3.3 Reti commerciali#

Operatori privati offrono reti nazionali di stazioni permanenti con correzioni RTK in abbonamento, con copertura su tutto il territorio e assistenza. Sono la scelta comune tra chi lavora in più regioni. Verifica la copertura effettiva nella zona del rilievo e il sistema di riferimento delle coordinate (di solito ETRF2000 o WGS84 di realizzazione recente: la differenza è di decimetri e conta se lavori al centimetro).

3.4 Cosa controllare prima del volo#

Copertura dati mobile nell'area, se il drone o il telecomando ricevono le correzioni via internet.
Sistema di riferimento della rete e sua coerenza con quello dei tuoi GCP e della consegna.
Stato della soluzione in volo: fix (accurata), float (decimetrica, non affidabile), singola (nessuna correzione). Le foto scattate in float o singola vanno trattate come foto di un drone normale.
Log della sessione, da conservare per la relazione tecnica.

4. Passare le posizioni a WebODM#

4.1 Con RTK: l'EXIF basta#

Se il drone scrive nell'EXIF le coordinate corrette, WebODM le legge come quelle di qualsiasi altra foto. Devi solo dire al motore che sono accurate, con --gps-accuracy (§5). Alcuni droni scrivono anche un tag con l'accuratezza stimata: verifica nella documentazione ufficiale come la versione in uso lo tratta.

4.2 Con PPK: il file geo.txt#

Dopo il post-processing hai un file con le posizioni corrette di ogni scatto. Va convertito nel formato geo.txt che il motore legge con l'opzione --geo.

Prima riga: il sistema di riferimento, come per i GCP (EPSG:xxxx o stringa PROJ).

Righe successive: una per immagine:

testo

nome_immagine x y z [omega phi kappa] [horz_acc vert_acc]

nome_immagine: nome esatto del file.
x y z: coordinate della camera (Est, Nord, quota) nel sistema della prima riga.
omega phi kappa: angoli di assetto in gradi, facoltativi.
horz_acc vert_acc: accuratezza orizzontale e verticale in metri, facoltative.

Esempio in ETRS89 / UTM 32N con accuratezze:

testo

EPSG:25832
DJI_0412.JPG 605410.221 4991240.887 298.412 0.02 0.03
DJI_0413.JPG 605418.905 4991240.712 298.398 0.02 0.03
DJI_0414.JPG 605427.613 4991240.560 298.421 0.02 0.03

Se ometti gli angoli e indichi le accuratezze, lascia i campi degli angoli vuoti seguendo la sintassi documentata su docs.opendronemap.org: verifica la versione, perché il formato ha avuto piccole variazioni tra le release.

In WebODM il file si carica insieme alle immagini con il nome geo.txt; il motore lo usa al posto dell'EXIF. Se il software PPK produce anche un file EXIF aggiornato, puoi in alternativa riscrivere l'EXIF delle foto e procedere come con l'RTK.

5. --gps-accuracy e --force-gps#

Il motore usa le posizioni delle camere come osservazioni pesate nella compensazione. Il peso dipende da --gps-accuracy, che ha default 3 m: un valore adatto a un drone consumer.

Con posizioni RTK/PPK affidabili, abbassa il valore, per esempio a 0,1 m (o al valore realistico della tua soluzione, comprensivo dell'incertezza di sincronizzazione e di offset). Così il motore "crede" alle posizioni e riduce le deformazioni.

Non esagerare verso il basso: un valore di 0,01 m su dati che in realtà hanno 5 cm di errore costringe il modello a inseguire il rumore.

Se hai anche GCP, per impostazione predefinita le posizioni GPS delle camere contano poco quando è presente un file GCP. Con --force-gps chiedi al motore di usare entrambi. È la combinazione consigliata con un drone RTK e alcuni GCP: le posizioni centimetriche stabilizzano la geometria, i GCP ancorano il sistema di riferimento e le quote.

Riepilogo:

Scenario	`--gps-accuracy`	`--force-gps`	GCP
Drone consumer, nessun GCP	3 (default) o più alto	no	—
Drone consumer con GCP	3 (default)	no	5–10
Drone RTK/PPK senza GCP	0,1 circa	no (nessun GCP presente: l'opzione non ha effetto)	solo check point
Drone RTK/PPK con GCP	0,1 circa	sì	3–5 + check point

6. Quote ellissoidiche e ortometriche#

Il GNSS, del drone o della stazione, misura altezze rispetto all'ellissoide. Le quote della cartografia e dei capitolati sono quasi sempre ortometriche, riferite al livello medio del mare tramite il modello di geoide. In Italia la differenza è di circa 37–50 m secondo la zona.

Con un drone RTK le quote dell'EXIF sono ellissoidiche (salvo droni configurati per applicare un geoide). Se non fai nulla, il DSM/DTM prodotto da WebODM avrà quote ellissoidiche: internamente coerenti ma "sbagliate" di decine di metri rispetto alla cartografia.

Hai tre strade:

GCP con quote ortometriche. Se i punti a terra sono misurati in quota ortometrica e li usi nel calcolo, il modello si adatta a quel riferimento. È la via più semplice e più difendibile.
Convertire le quote nel file geo.txt con il modello di geoide prima di darlo a WebODM.
--gps-z-offset: aggiunge un offset costante alle quote GPS. La separazione ellissoide-geoide varia sul territorio, quindi è accettabile solo su aree piccole, e va documentata.

In ogni caso scrivi nella relazione quale convenzione hai usato. Dettagli e riferimenti nella guida ai sistemi di riferimento italiani.

7. Perché anche con RTK conviene qualche check point#

Un drone RTK dà posizioni accurate delle camere. L'accuratezza del modello dipende anche da calibrazione, sincronizzazione, otturatore, geometria del volo e qualità delle immagini: un errore sistematico di scala o di quota passa inosservato se non lo verifichi con punti indipendenti a terra.

Per questo, anche con RTK: misura almeno 3–5 check point a terra e confrontali con il modello; se il committente chiede quote ortometriche o un sistema specifico, aggiungi qualche GCP e usa --force-gps; conserva i log della soluzione RTK per dimostrare che il volo era in fix. Il tempo in campo resta molto inferiore a quello di un rilievo con 8–10 GCP, e il modello è più stabile su aree grandi e superfici con poca texture.

Come verificare

Apri il report di qualità del task e controlla la sezione sugli errori GPS delle camere: con RTK e --gps-accuracy corretto, gli scarti tra posizioni misurate e ricostruite dovrebbero essere di pochi centimetri, senza deriva sistematica in una direzione. Confronta poi i check point misurati a terra con l'ortofoto e il DSM: se le differenze in quota sono tutte di decine di metri, hai un problema di ellissoide/geoide; se sono di decimetri e uniformi, verifica offset antenna e sincronizzazione; se sono sparse e di pochi centimetri, il rilievo è coerente. Il metodo di calcolo è nella guida ad accuratezza e validazione.

Problemi frequenti#

Il modello con RTK è peggiore di quello senza. Quasi sempre --gps-accuracy è stato lasciato a 3 m (le posizioni accurate non vengono sfruttate) oppure parte del volo era in float e le foto hanno posizioni miste. Controlla i log e, se necessario, escludi le foto non in fix o alza l'accuratezza a un valore realistico.

Quote sbagliate di circa 40–50 m. Ellissoide contro geoide. Vedi §6.

Il file geo.txt viene ignorato. Nome diverso da geo.txt, nomi immagine non corrispondenti, separatore decimale con la virgola o prima riga mancante.

Con GCP e RTK i residui dei GCP sono alti. Le due fonti sono in conflitto: il sistema di riferimento della rete RTK e quello dei GCP non coincidono (per esempio ETRF2000 contro WGS84 di realizzazione diversa, o quote ellissoidiche contro ortometriche). Allinea i sistemi prima di elaborare.

Prossimi passi#

Punti di controllo a terra (GCP): come misurare e caricare i GCP che affiancano il volo RTK.
Accuratezza e validazione del rilievo: calcolare l'RMSE dai check point e scrivere la relazione.
Sistemi di riferimento italiani: RDN2008, ETRS89, UTM e quote.

Fonti

Riferimento delle opzioni ODM (--geo, --gps-accuracy, --force-gps, --gps-z-offset): https://docs.opendronemap.org/arguments/(link esterno)
Documentazione ODM su GCP e file di georeferenziazione: https://docs.opendronemap.org/gcp/(link esterno)
Documentazione WebODM: https://docs.webodm.org/(link esterno)
Opzioni e flag di ODX: https://docs.webodm.org/options-flags(link esterno)