[Gfoss] dati GNSS grezzi da Android per Correzzione in Post processing con RTKLIB

Roberto Marzocchi roberto.marzocchi a gter.it
Mar 2 Gen 2018 15:17:39 CET


Ciao Amedeo,

ho girato la richiesta al mio collega Tiziano che non è in mailing list 
e che lavora con RTKLIB e i ricevitori GNSS low cost e questa che 
incollo qua sotto è la sua risposta.. per qualsiasi cosa metto in copia 
anche lui così vi potete aggiornare

Buon anno!

R


I raw data provenienti dai ricevitori GNSS comprendono direttamente le 
osservabili (cioè le distanze satellite ricevitore), oltre ad una serie 
di informazioni ulteriori. Con i dati grezzi non hai informazioni sulla 
posizione che invece ti devi ricavare a valle di una elaborazione in 
post processing. Il post processing, che consente di fatto di eliminare 
o ridurre gli errori che affliggono il segnale gnss, in genere richiede 
di appoggiarsi ad una stazione base di riferimento (o più d'una), della 
quale si abbiano a disposizione i dati grezzi nello stesso intervallo di 
tempo del proprio rover e, possibilmente, con lo steso rate di 
acquisizione (1 sec, 5 sec...). E' inoltre necessario che la stazione 
base sia di coordinate note, se si vuole ottenere poi le coordinate del 
proprio rover nel medesimo SR (della base).
La post elaborazione (che non è una correzione, ma una vero e proprio 
processing) la si può fare anche con RTKLIB ed in particolare 
utilizzando il modulo RTKPOST. E' possibile elaborare rilievi statici o 
cinematici, utilizzare eventualmente effemeridi scaricate a posteriori, 
utilizzare filtri sul segnale rumore ed effettuare una serie di analisi 
più fini. Il vantaggio del post processing è proprio questo: posso a 
posteriori, in ufficio, elaborare con calma e decidere quali modelli 
usare o quali parametri usare, ripetendo l'elaborazione fino a che non 
si raggiunge un risultato che ci soddisfa in termini di deviazione standard.
Tieni conto che però, affinchè un rilievo in post processing vada a buon 
fine, è necessario progettarlo con cura e mantenere alcune attenzioni in 
fase di rilievo. La prima e più importante è la durata; per poter post 
elaborare in appoggio ad una base nelle vicinanze è opportuno che il 
rilievo duri almeno 10 minuti, tutto ciò ampiamente variabile in 
funzione di frequenza, DOP, precisioni attese.
Proprio le precisioni attese sono però a mio parere il criterio 
principale. Cioè un rilievo in post processing ha senso in tre casi, 
principalmente:
-se mi aspetto precisioni spinte (centimetriche)
-se non posso fare un rilievo RTK per cause di forza maggiore (ad 
esempio assenza di copertura di rete)
-se ho necessità di "controllare" le mie misure.

Venendo alla questione smartphone, non ho ancora provato, ma lo dovrò 
fare nei prossimi tempi, nel caso ti aggiorno. Ho invece fatto numerosi 
test con chip a basso costo e i risultati sono mediamente molto 
incoraggianti. Ma è difficile riassumere cosa si intende per 
"incoraggianti". Dipende veramente molto da ciò di cui si ha bisogno, 
dalle condizioni al contorno, dall'HW. In particolare l'ultima 
considerazione in merito ai raw data da smartphone, che faccio "a 
sensazione" non avendoli appunto ancora provati, riguarda l'antenna. I 
chip ricevitori che sono all'interno degli smartphone non paiono molto 
diversi per caratteristiche dagli altri ricevitori a basso costo sul 
mercato, mentre per l'antenna le cose un po' cambiano; e per quella che 
è la mia esperienza, quando si parla di HW a basso costo in questo 
campo, il punto debole è proprio l'antenna che se poco performante 
rischia di tirare dentro molto rumore con il risultato che i raw data 
saranno molto sporchi. E quindi, nonostante il post processing consenta 
maggior margine di manovra rispetto ad un rilievo RTK, se i dati sono 
brutti non si possono fare miracoli.


Il 02. 01. 18 09:01, Amedeo Fadini ha scritto:
> Ciao a tutti,
> mi chiedevo se utilizzando i dati grezzi che sembrerebbero disponibili in
> alcune smartphone con Android [0]  è possibile applicare una correzione in
> post-processing con RTKlib...
>
> A quel che ho capito io dovrebbe esser sufficiente avere un file in formato
> NMEA  con i dati individuali dei satelliti... qualcuno ha mai provato ad
> estrarlo da uno smartphone?
>
> non mi aspetto miracoli, anche perché gli errori più frequenti in ambito
> urbano sono dettati da poca visuale, pdop basso e multipath, ma vorrei
> elaborare una procedura per i rilevatori che escono con il tablet: in
> futuro avendo budget potrei dotarli di ricevitore bluetooth a doppia
> frequenza.
>
> amefad
>
> [0] https://developer.android.com/guide/topics/sensors/gnss.html
> _______________________________________________
> Gfoss a lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
> 796 iscritti al 28/12/2017

Eng. Roberto Marzocchi, PhD
GIS Project Coordinator
Gter srl Innovazione in Geomatica, Gnss e Gis (Unige spin-off)
Piazza De Marini 3/61 - 16123 Genova
P.IVA/CF 01998770992
ph: 010-8694830 - mob: 349-8786575
E-mail: roberto.marzocchi a gter.it
skype: roberto.marzocchi84
www.gter.it

-- 
Gter social
www.twitter.com/Gteronline - www.facebook.com/Gteronline - https://plus.google.com/+GterIt/posts
www.linkedin.com/company/gter-srl-innovazione-in-geomatica-gnss-e-gis

-----------------------------------------------------------------
Please consider the environment before printing this email!



Maggiori informazioni sulla lista Gfoss