Diferenças entre posicionamento RTK obtido no ReachView e no RTKNAVI DEMO5 B33

Olá!

Estou avaliando a capacidade de usar o receptor M2 como base e me deparei com algumas características que gostaria de compartilhar.

A metodologia foi ocupar um marco de coordenadas conhecidas e comparar os desvios RMS de posicionamentos RTK realizados com relação a três estações-base da rede RBMC-IP: (1) distante cerca de 18 km; (2) distante 200 km e (3) distante 500 km do marco.

Foram obtidos dois conjuntos de resultados:

(1) gerados diretamente do receptor pelo REACHVIEW 2.22.4 (conjunto LLH);

(2) obtidos via RTKNAVI (V. DEMO-5 B33-C) em um PC Windows 10; na mesma rede WIFI em que o receptor estava (conjunto NAVI).

Foram utilizadas duas antenas, uma helicoidal da marca Tersus modelo AX3705 AX3705 GNSS Antenna | Tersus GNSS (TERSUS) e outra da marca Navspark modelo GRADE ANTENNA - http://navspark.mybigcommerce.com/survey-grade-antenna/ (GRADE), ambas captam sinais dos sistemas GPS (G), GLONASS (R) e GALILEO (E) de dupla frequência.

Realizei 7 ocupações de cada antena em realização RTK com cada base RBMC (…) ao longo de 1 hora cada, em horários diversos com a taxa de frequência de 1hz; totalizando 42 ocupações e mais de 350.000 realizações RTK.

De cada ocupação foram obtidos os valores de dispersão RMS dos vetores E-W; N-S e U-D do posicionamento com relação às coordenadas conhecidas do marco. Tais valores foram tabulados e permitiram avaliar a dispersão das soluções obtidas em cada processamento, gerando 84 conjuntos de dados de variação de posicionamento, 42 LLH e outros 42 NAVI.

O que chama a atenção é a diferença entre a qualidade do posicionamento dos resultados LLH em comparação aos NAVI: em média, o desvio RMS obtido pelo processamento direto no receptor (LLH) é cerca de duas vezes maior do que o do conjunto NAVI, obtido no PC (…) sendo que para a distância-base mais curta (~18km), o efeito é bem mais notório!

A figura abaixo apresenta as médias tridimensionais das dispersões RMS dos vários levantamentos em relação às distâncias-base. Os diâmetros das circunferências indicam a medida do desvio-padrão das médias.

GRAFICO_RMS_M2_D_BASE

Independente da antena (TERSUS ou GRADE) os resultados LLH (em vermelho) são piores que os obtidos no processamento NAVI (em verde).

Para a distância base de 500 km a diferença é menos perceptível – pode-se obter resultados similares com o conjunto LLH ou NAVI (…) já para uma distância de 18km, caso se utilize somente os dados LLH, imputa-se o dobro de erro do que se usasse um PC com o RTKNAVI.

A mesma sistemática está sendo utilizada para avaliar os receptores M+ (MP) e o ANTIGO REACH (AR) com antenas de simples frequência.

Os dados preliminares apontam que a diferença, nos receptores de simples frequência, não passa de 10% e sem uma tendência (hora o conjunto LLH é melhor, hora o NAVI… indicando que a diferença pode ser causada por outros motivos: geometria dos satélites, qualidade das antenas, etc…)

A minha intenção seria utilizar o M2 sem a necessidade de um PC – gerando soluções RTK diretamente do Reach View (LLH)… mas diante dos resultados, parece que necessitarei de mudar minhas intenções!

Espero que as próximas versões do Reach View possam tratar melhor as soluções RTK e gerar dados mais acurados.

Qual foram as bases da RBMC-IP utilizadas? Qual sua posição? O Reach M2 possui o sinal L2C, sugiro verificar se estas bases possuem também o sinal L2C para o satélite GPS. As bases possuem GALILEO e/ou BEIDOU? Isto ajudaria significativamente caso não possuam L2C.

Vi uma imagem do seu teste no seu post na área em inglês.

Atrás da câmera (onde você está) é coberto? Você só possui metade do céu limpo?

A finalidade do teste é demonstrar que o processamento interno do M2, via ReachView está oferendo um resultado RTK com qualidade degradada em relação do RTKNAVI DEMO5.

O posicionamento do marco de teste não é o mais indicado para precisão e acurácia (no parapeito da janela aqui em casa) - suprimindo parte da visão do céu.

O fato é que a falta de qualidade no posicionamento está presente para os dois resultados (LLH e NAVI - tanto que eu não discuto a precisão e a acurácia do posicionamento)… e o resultado NAVI se apresenta com uma qualidade melhor em todas as comparações.

O melhor posicionamento RTK possível foi obtido pelo DEMO5, com uso de um PC e adquirindo os dados do receptor pela rede WIFI.

Essa solução acaba acarretando mais bagagem para campo (um PC, rede wifi…)

A minha intenção é apresentar a questão para a comunidade e esperar que o pessoal da EMLID perceba a necessidade de melhorar a implementação do REACHVIEW para posicionamento RTK,

Uma possibilidade é que esse comportamento seja exclusivo da minha unidade…
Algo que eu não tenho como testar (só tenho essa unidade)

Deixo aqui a sugestão para a comunidade que tenham um M2: coletem o posicionamento RTK do receptor em solução estática com relação a uma base RBMC próxima , simultaneamente, a solução por meio do RTKNAVI da implementação DEMO 5 (http://rtkexplorer.com/downloads/rtklib-code/) de um ponto que se saiba as coordenadas.

A solução direta do receptor terá a extensão LLH, e a saída do processamento RTKNAVI pode ser salva com a extensão .pos

Se puderem compartilhar aqui, poderei entender se esse comportamento é exclusivo da minha unidade ou se é uma característica do reachview/m2 que poderia ser melhorada…

Seguem dois exemplos de arquivos. As coordenadas do ponto de ocupação são: -3.74612765584222 -38.5305347634482 52.285 . Podem avaliar os erros pelo RTKPLOT

00_EXEMPLO_POSICINAMENTO_M2.zip (96.2 KB)

Quem puder ajudar, agradeço!

Olá a todos.

Dando continuidade com os testes, fiz 16 ocupações em um marco que instalei no telhado do prédio - 100% de céu aberto.

Avaliei duas antenas no teste - a já citada GRADE (Navspark model GRADE ANTENNA - Survey Grade Antenna - NavSpark Store) e a recém adquirida BT170 (Beitian GPS Module Receiver Antenna, Rtk Gnss Antenna, GPS Glonass Bds Galileo High-Precision Survey Antenna, Bt-170-D-SMA - China Gnss Antenna and Rtk Gnss Antenna) - 8 ocupações com cada antena, cada ocupação com cerca de 1 hora de duração com uma linha base de 18km.

O receptor usado foi o M2 com a versão 2.22.5 do reachview, tabulado como “M2_5” para não ser confundido com as medições que eu havia feito com o reachview anterior - tabulado como M2.

Para a eliminação de outliers da análise, segui providências: (1) eliminei os primeiros 5 minutos de rastreio; caso o dado ainda não estivesse dentro de uma faixa aceitável; (2) eliminei os 10 minutos iniciais - se o dado ainda apresentasse valores anomalos, considerei apenas os dados com Q1. Se nenhuma dessas ações corrigiu o dado, ele foi retirado da análise por completo.

A figura abaixo mostra todas as ocupações do M2_5 na JANELA (recepção ruim dos sinais) e TELHADO (céu aberto), comparando as acurácias dos resultados LLH (obtidos pelo REACHVIEW) e NAVI (obtidos pelo DEMO5).
A parte em vermelho apresenta as filtragens que foram feitas para eliminar os outliers.

Da figura é possivel perceber que a solução LLH tem a tendência de ser menos acurada que a NAVI, uma vez que as barras em AZUL são maiores que as ALARANJADAS - se fossem do mesmo tamanho, as duas soluções seriam iguais. Percebe-se, também, que esse comportamento é válido tanto para os dados da JANELA quanto do TELHADO.

Na figura abaixo eu apresento as médias das soluções das ocupações com o M+, tabulado como “MP”; do M2 e do M2_5 (as soluções MP estão salientdas em verde).

As barras apresentam os resultados para os diferentes modelos de antena que foram usados.
Para o M2, as já citadas GRADE, TERSUS e BT170 ganham a companhia da antena Tallysman TW3865 (https://www.tallysman.com/app/uploads/2018/09/TW3865_TW3867_Datasheet_rev3_7.pdf), tabulada como “TAL”.

Para o MP, foram usadas duas implementações da TW2406 (TW2406 Embedded Single Band GNSS Antenna | Tallysman) - uma diy com plano de solo de 10 cm (tabulada como “FCL”) e uma aproveitada de um receptor EMLID REACH RS que não funciona mais (tabulada como “RS”). Além dessas duas versões da TW2406, foi testada uma antena helicoidal que não sei a marca e/ou modelo - tabulada como “HELIX_TR”.

Da figura dá para perceber que os resultados LLH e NAVI do receptor MP são muito similares entre si (as barras AZUIS e ALARANJADAS têm tamanhos iguais)… já para os resultados do M2 e do M2_5, a tendencia é de que as barras LARANJADAS sejam menores - independentemente da qualidade de recepção de satélites (JANELA ou TELHADO) e indempendente do tipo de antena.

Ao que, concluo: para comparar a capacidade de processamento RTK entre o reachview e o rtknavi, tanto faz se a qualidade de sinal é a melhor possível (TELHADO com céu limpo) ou com uma qualidade de recepção ruim (JANELA com céu parciamente encoberto).
Concluo, ainda, que há uma boa margem para melhoria na solução LLH, pois em todos os cenários, a tendencia é que o resultado LLH seja pior que o NAVI !

Espero que o meu esforço de avaliação sirva de inspiração para que outros colegas da comunidade façam testes com os equipamentos e, assim, possamos avaliar se estamos obtendo o melhor resultado RTK que o produto pode gerar… e se não estivermos, que a equipe EMLID possa implementar as devidas adequações no reachview (seja por RTKLIB ou outra solução que esteja sendo utilizada).

1 Like

This topic was automatically closed after 100 days. New replies are no longer allowed.