Сервис на основе инверсного режима RTK

Хотелось бы обсудить вот что:
Всем известен т.н. обратный (инверсный) режим относительных спутниковых определений в реальном времени - Inverse RTK. Это когда ГНСС-приемник, установленный на определяемой точке, пересылает по какому-либо каналу связи "сырые" спутниковые данные на удаленный сервер, где соответствующий алгоритм решает навигационную задачу, т.е. вычисляет местоположение определяемой точки и передает результат на ровер.
Кто-то из лидеров рынка ГНСС-технологий уже реализовал это в конкретном решении и это применяется в съемке?
Идея не нова, но в основном вся ГНСС-аппаратура потребителя решает навигационную задачу самостоятельно (с приемом корректирующей информации естественно). А ведь обратное решение имеет свои преимущества, например:

1. Нет необходимости иметь в ГНСС-приемнике алгоритма (программного обеспечения) для RTK-решения (с разрешенеим неоднозначности фаз и т.п.), т.е. ГНСС-приемник м.б. дешевле;
2. Удаленный сервер может не только вычислять местоположение ровера в пространственной системе координат ГНСС (WGS-84, ПЗ-90.хх), но и преобразовывать их в плоские координаты, например в МСК (если заранее заданы параметры преобразования). Это позволит решить проблему секретности, когда параметры нельзя открыто использовать к контроллере RTK приемника.

Данный режим уже используется в системах мониторинга конструкций и сооружений, где координаты и смещения контролируемых точек вычисляются в центре обработки. Но там ГНСС-приемники закреплены на контролируемых точках. Я же фантазирую об мобильных роверах- переносной полевой спутниковой аппаратуре.
В настоящее время идея глобальных сервисов охватила множество сфер деятельности, например обработку пространственных данных (ДЗЗ, космоснимки...), когда результат можно получить не у себя с помощью дорогих и сложных программ и без закупки первичных данных ДЗЗ или снимков, а заказав нужные тебе данные в готовом виде на порталах услуг по обработке пространственной информации. На основе инверсного режима RTK также можно было бы организовать сервис высокоточного позиционирования для пользователей недорогих приемников (см.п.1), но что то пока никто подобного не создал. Все сервисы, предназначенные для определения местоположения в режиме реального времени, основанные на сетях дифференциальных станций, передающих RTK и DGNSS поправки, глобальные сервисы GBAS, PPP ... формируют и передают корректирующую информацию потребителю, которому необходимо иметь аппаратуру для спутниковых определений с функционалом прямого режима.
Интересно, почему?

 

Потому, что так надежнее и проще.Данные передаются от базы к роверу напрямую или через сервер, а в вашем случае добавляется лишнее звено это передача от ровера к серверу.По поводу секретности решение сомнительное.Не могу сказать на сколько дешевле будет программа для контроллера без модуля вычисления координат, скорее всего не на много.

 

Иначе "реальное время" не получится. Любые задержки критичны.

 

у Джавад в ПО Justin есть такой режим c 2012 года, называется обратный RTK.
Статья во вложении.
применимо в мониторинге (есть пара реальзованных проектов), с натягом можно попробовать снимать без контроллера (приемник индикаторами мигает когда решение получено), вынести можно только обработка на ноуте и по рации или телефону командовать правее-левее.
Если что тестирование и другие мысли по применению будут - я готов помочь. обращайтесь

 

Да, в инверсном RTK режиме данные передаются от ровера к базе или серверу и обратно. Не будем рассматривать вариант работы полевой базовой станции с одним ровером. Если база стоит в поле, то действительно будет проще использовать стандартный "прямой" режим и я не вижу смысла использовать инверсный. Рассмотрим вариант сети постоянно-действующих станций с сервером и ПО для предоставления т.н. сетевых поправок или поправки от ближайшей к роверу станции. В большинстве подобных систем при NTRIP подключении ровера к серверу ровер передает на сервер свои пространственные координаты (в системе WGS-84), а сервер,, в том числе используя информацию о местоположении ровера, посылает ему поправки. Я сейчас упускаю много деталей, но суть в том, что при "прямом" режиме RTK уже используется связь в двух направлениях. Инверсный режим подразумевает тоже передачу данных в обоих направления, только в одном направлении идут "сырые" данные от ровера на сервер, а в другом простые сообщения небольшого объема с координатами ровера.
По поводу секретности в чем сомневаетесь?
По оценкам представителей одной из компаний-производителя ГНСС-железа и софта стоимость оборудования ровера без ПО для решения навигационной задачи будет ниже на 30%. Много это или мало - вопрос, ответ на который м.б. разный в зависимости от того кому его задать, производителями или потребителям.

--- Сообщения объединены, 11 окт 2017, Оригинальное время сообщения: 11 окт 2017 ---

Думаю, что в разных сферах приложения задержки могут быть критичными или не нет. Для непрерывно движущихся объектов это действительно м.б. кричным. А если кадастровый инженер снимает координаты границ объекта недвижимости (который кстати никуда не бежит:), то он может и постоять минутку, дожидаясь решения. Это как при съемке с тахеометром, исполнитель ждет перехода помощника с вехой от точки к точке, т.е. работает у прибора периодически смотря в окуляр и отрываясь от окуляра. Так же со спутниковой аппаратурой: сделал замер, дождался решения от сервера, получил, сохранил в контроллере и пошел на следующую точку. Поспешает неторопясь" :). Оно конечно не совсем "реальное время" (и не Real Time Kinematic), но всевдо-реальное время все таки тож неплохо, и лучше чем постобработка.

 

Тема интересная, если еще учесть, что последних версиях Android можно получить доступ к сырым GNSS данным. Которые в свою очередь можно передавать для дальнейшей обработки в какой то единый центр.

Но блин денег на разработку этой темы нужен вагон, а то что они вернуться совсем не очевидно.

 

Смущает то, что Вы, по сути, будете раздавать секретные данные, кому попало и не факт, что лавочку не прикроют.Совсем без ПО не получится, так как вся соль RTK, заключается в графическом отображении данных, при выносе или съемки, на контроллере ровера, в противном случае весь смысл теряется.Хотя данный метод интересен тем, что для написания клиентского ПО не нужно будет обладать знаниями по спутниковой геодезии и интерфейсам приемника, но тут возникает другая проблема, это однобокость решения и зависимость от ПО сервера, вероятнее всего необходимо, что бы сервер поддерживал твою модель приемника, что в случае прямого типа RTK решается ПО родного контроллера, кроме того все равно нужно покупать либо ПО сервера, либо опять зависеть от сервера.Кроме того, вероятно будут проблемы с калибровкой кастомной сети и ввода и хранения ее параметров.

 

В данной модели подразумевается что преобразование координат ровера осуществляется сразу после решения навигационной задачи на сервере. При этом параметры преобразования находятся в ПО сервера, т.е. не раздаются пользователям роверов ("кому попало".).

--- Сообщения объединены, 11 окт 2017, Оригинальное время сообщения: 11 окт 2017 ---

Отображение текущих координат (для выноса или съемке) осуществляется на контроллере, т.к. в идее заложена передача координат решения с сервера на ровер (простые и легкие в смысле в объема информации в байтах сообщения).

--- Сообщения объединены, 11 окт 2017 ---

Если использовать для передачи "сырых" спутниковых данных формат RTCM версии 2.3, 3.x, что поддерживается большинством современных RTK приемников, то серверу не важно какая модель ровера у потребителя. Важно, что данные будут поступать в общепринятом формате.
Правда не все производители реализуют в своих RTK приемниках функцию выдачи потока "сырых" данных в порт приемника... Такие приемники не могут быть использованы в инверсном режиме RTK.

--- Сообщения объединены, 11 окт 2017 ---

Да, тут есть сложности. Дело в том, что оператор такой сети должен нести ответственность за результат, в том число за преобразование координат. Т.е. параметры должны "работать правильно" на всей обслуживаемой сетью территории. В нашем государстве с "правильными параметрами преобразования координат в МСК" большая проблема. На сервере придется иметь наборы локализованных параметров, разграничивать их использование, да еще отвечать за их качество. Для таких площадей как субъект это будет проблематично, а вот для локальной области (района, города) это вероятно проще.
Есть конечно и выход: предоставять в инверсном режиме только координаты в WGS, а там пользователь пусть сам, сам... Но таких "операторов" и так хватает. Исключение составляет, наверно, только один МГГТ, который выдает параметры своим клиентам, причем при этом несет ответственность за их качество.

 

Я почему-то думал, что информация о местоположении ровера передается в начале работы (для определения ближайших БС сети), а в процессе обновляется редко. А поправки идут с частотой 1 Гц. И нестабильная связь делает решение неточным или оно просто не вычисляется. Допустим, интернет "лагает" и пакет с ровера на сервер передается за секунду. Получается, что данные для расчета уже неактуальны. А на прием GSM-модемы работают более уверенно, поэтому больше шансов зафиксировать решение. Или я где-то ошибаюсь?

А если выносит границы в натуру без тахеометра или снимает координаты линейного объекта, то потеряет много времени.

 

Параметры системы можно получить через измерения с помощью Вашего будущего сервиса.Можно ли на основе RTCM двух приемников получать решение в виде координат?Как будет управляться приемник, он будет запускаться в режиме базовой станции, ведь, что бы его заставить транслировать RTCM, то нужно либо запрограммировать его на работу в качестве базовой станции и включать его с кнопки, либо с помощью ПО контроллера, где оно если я не ошибаюсь просит вводить координаты базы?

 

Возможно. В данном случае все будет зависеть от скорости передачи данных в сотовой сети, частоты и продолжительности возникающих задержек.
Кстати, еще аргументом против данного режима является недостаточная скорость мобильного интернета. Надо проанализировать хватит ли скорости 3G и 4G для передачи "сырых" данных (фазовые измерения GPS+ГЛОНАСС по RTCM).

 

Если сервер сохраняет весь поток от базы - то задержка не имеет значения, просто надо её учитывать при синхронизации между потоками от базы и от ровера. Постобработкой же можно спустя любое кол-во времени получить решение из прошлого, так и тут.

 

Хватит. Но задержки не исключены. Не из-за большого объема данных, а из-за высокого пинга.

--- Сообщения объединены, 11 окт 2017, Оригинальное время сообщения: 11 окт 2017 ---

Ага. РТК плавно превращается в постобработку :)

 

Задержка имеет значение при выносе, да и при съемке тоже, ведь исполнитель не сможет сдвинуться с места, пока контроллер не получит решения и запомнит его, в противном случае нужно будет повторить измерение точки.

--- Сообщения объединены, 11 окт 2017, Оригинальное время сообщения: 11 окт 2017 ---

Еще один существенный недостаток это не возможность работать с помощью радио модема, так как не везде есть сотовая связь.

 

RTK- приемники Novatel, Trimble, если не ошибаюсь, можно настроить на передачу потока "сырых" данных в порт приемника (куда подключен м.б. подключен GSM модем) одновременно со съемкой. Т.е не надо запускать егов режиме "базы". Он может работать в режиме ровера, одновременно выдавая данные порт. Но тут пусть производители лучше подскажут как и что. Все модели приемников разные и логика работы управляющего ПО тоже разная.

--- Сообщения объединены, 11 окт 2017, Оригинальное время сообщения: 11 окт 2017 ---

А кто-нибудь может сказать какой объем (в байтах) может занимать "кадр" потока "сырых" спутниковых данных? Имеется в виду сколько будет весить RTCМ сообщение с предварительными координатами ровера, измерениями фазы кодов и несущих L1/L2 по GPS+ГЛОНАСС. Будем считать, что такие сообщения мы будем отправлять раз в секунду.

--- Сообщения объединены, 11 окт 2017 ---

Очень интересно. Возможно, что прочел эту стать еще и в 2012-м... Да, как я уже сказал, инверсный режим - не новость и используется в мониторинге.
Приведу выдержку из данной статьи :
"метод «обратного» RTK дает преимущество по сравнению с традиционным методом только в отношении надежности получения фиксированного решения, которое устанавливается на основе величины контраста. Иногда достигается преимущество во времени наблюдений на точке.Точность определения координат конкретной реализации при использовании этого метода повышается незначительно и лишь до определенного предела. Поэтому метод «обратного» RTK следует использовать для топографической съемки или аналогичных полевых работ. Его также можно рекомендовать при геодезическом обеспечении строительства..."

А почему Джавад или его клиенты не сделали глобальный сервис на основе данного решения?

 

По информации, которая у меня есть, «сырые» спутниковые данные 10 спутников GPS и ГЛОНАСС на одну эпоху в формате RTCM 3.1 занимают около 350 байт. Это 2.7 килобит. Скорость передачи данных системы связи стандарта GSM 2G (GPRS) до 171 килобит/сек, 3G и 4G гораздо выше, т.е. в принципе достаточно, чтобы обеспечить передачу «сырых» данных, необходимых серверу для обработки. В сети 4G скорость «в условиях загруженности Москвы обычно 10-50 Мбит/с). При этом более быстрый PING и сама технология делают 4G наиболее предпочтительным стандартом для мобильного интернета в модемах.» (Источник: http://www.mobile-networks.ru/articles/201512/standartyi_svyazi_i_skorost_interneta.html).
Можно сделать вывод, что при дальнейшем распространении сетей GSM 4G реализация инверсного RTK режима становиться более реальной. Не правда ли?

 

Правда. Но почему бы не использовать в качестве "сервера" контроллер (смартфон с Android?), если так хочется вести расчеты с помощью ПО, а не в приемнике. Или я чего-то не понимаю, или инверсный режим - узкоспециальный режим, когда требуется собрать данные со многих приемников и отобразить их взаимное местоположение с максимальной точностью в реальном времени на одной карте, особенно при долговременных наблюдениях, а не при обычной съемке/выносе.

 

3G тоже хватит.

 

вроде за бугром то есть облачное решение https://app.javad.com/jca/#/inventory/accounts