RTKlib/постпроцессинг

SviMik
Проверил ваш файл port14.log - после rtkconv rtklab 2.4.1 и rtklib 2.4.2: измерения по L1 должны быть,
больше 100 000 000.000 и только положительными при WAVELENGTH FACT L1/2 = 1 . К сожелению все свои
данные по u-block ANTARIS я уже стер и не могу сделать вывод, кто же неправильно считает ваш u-block
или rtkconv.

-1

Я в гараж заехал. Обрезать не стал, подумал что не мешает.

Мне было интересно решение самого приёмника тоже (иначе NMEA я бы вообще отключил). По поводу GGA не знаю, вдруг какой-то софт RMC использует, потом придётся ещё конвертить, чтобы его восстановить.

Можно последовательность действий для воспроизведения? У меня исключительно Single.

-1

http://habrahabr.ru/post/196150/ как прочитал про стремление к частоте 1Гц - подумал что SviMik шифруется.

-1

Попробовал вашу команду из командной строки, получилось. В начале есть даже 1% координат Fixed. Только почему-то они ничем не лучше float, гуляют точно также.
Я думал, что Fixed решение - это когда программа уверена в точности результата, но на деле - такая же ерунда, как float.

Также я думал, что float решение уж точно будет лучше, чем single. Но и здесь меня постигло разочарование - треки практически идентичны.

Ну и последний гвоздь в гроб: сравним float, сделанный с базовой станцией и поэтессами с решением самого приёмника, у которого никаких данных, кроме его собственных замеров, нет.


Синим - решение приёмника, жёлтым - float от rtklib.
Как видим, после поворота rtklib совсем потерялся, тогда как приёмник очень точно уложился на дорогу:

Я не знаю, кем надо быть, чтобы продолжать называть последний скрин - очковтирательством, а решение от rtklib - истинно верным.

(*последняя минута во всех треках намерянно вырезана, ибо езда внутри здания не репрезентативна, и навигация в помещении - это уже другая тема)

-1

Приёмник явно выдаёт больше информации по сравнению с rtklib, интерполяцией это не объяснить. Вероятно последний часть данных по какой-то причине отбрасывает.

Как-то так:

Чудо - имея базовую станцию, получить решение не хуже, чем делает сам приёмник и без неё?

Я поставил задачу - хоть как-то улучшить точность решения, используя дополнительные данные в виде базовой станции. Считаете эту задачу чудом? Я - нет.

По вашей ссылке - dead reckoning. У этой технологии есть свои плюсы и минусы, но в любом случае это уже другая тема (GPS с гироскопом и одометром). Здесь же я пытался выяснить, можно ли выжать ещё что-то, имея поправки с базовой станции. Логика подсказывает, что наличие таких поправок должно улучшить решение, но практика показала обратное.

Именно это я и хотел сказать! :slight_smile:

Я вижу три возможных объяснения:

  1. Несовершенство математической модели rtklib, которая неспособна давать решение в условиях хоть немного отличных от идеальных. Это несовершенство люто бешено прикрывается тюнингом собственых антенн, обсиранием антенн оппонентов, и комментариями, что rtklib создана работать именно в идеальных условиях сферического приёмника в вакууме.
  2. Приёмник выдаёт не всю информацию, которой обладает сам. Возможно, у него в наличии больше измерений, или имеются какие-то дополнительные параметры.
  3. rtklib берёт в расчёт не всю информацию, которая ему поступает, отбрасывая либо намерянно, либо не умея её учесть в своей мат. модели (что тоже является следствием из п.1).

Нет.
rtklib использует информацию о фазе сигнала. А то, что выдает приемник по NMEA - это результат кодового метода определения координат.
Кодовый метод позволяет определять координаты в более сложных условиях приема (включая наличие “обрывков” пакетов), т.е. обладает большей непрерывностью решения, однако за это приходится платить большей степенью неопределенности.
Фазовый метод более привередлив к качеству приема - сигнал от используемых в решении спутников должен какое-то время поступать непрерывно и с неким немалым уровнем, но если он поступает, то степень неопределенности - меньше.
Сами теперь можете легко объяснить, почему решение сорвалось при повороте. Потому что сменился набор видимых спутников, что не так смущает кодовый метод, но заметно смущает фазовый.
Эти два метода (особенно когда фазовый поставлен в заведомо невыгодные условия - слабая антенна, одночастотный приемник и т.п.) с разными задачами справляются по-разному.

BushmanK, благодарю за толковое объяснение!
В таком случае, имело бы смысл использовать кодовый и фазовый метод вместе, объединив их, для достижения максимально возможного результата в обоих сценариях. Странно, что до этого никто не додумался.

Кстати, есть возможность проверить теорию, заставив rtklib решить задачу кодовым методом, и посмотреть, что из этого выйдет?

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

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

Конечно додумались. В решении приемника (NMEA) фаза учитывается при сглаживании кодовых измерений (гуглите carrier smoothed pseudorange). Это добавляет немного точности даже для standalone GPS.

Попробуйте “Positioning Mode - DGPS/DGNSS : Code‐based differential GPS”. Вкупе с вышеописанным carrier smoothing (не знаю насчет uBlox, но сёрфы выдают по бинарному протоколу именно сглаженные дальности) и нормальной антенной реально вытащить 1-2 метра в динамике и дециметры в статике.

-1

rtklib вцепился в микрометр, и при виде детали, которая в него не влазит - начинает бегать вокруг, хватаясь за голову, вместо того, чтобы просто взять линейку, и посчитать как все нормальные gps приёмники, раз для фазовых измерений условия недостаточные.

Что мешает использовать оба, выдавая фазовые решения при хорошим сигнале, и кодовые при проезде под мостами\между зданиями\и т.п.?

Странно слышать от человека, который занимается программированием, приписывание каких-то эмоций программному продукту :slight_smile:
А фильтр nmea, который бы смотрел на два потока и проверял бы, какой поток лучше - это, пожалуй, функционал вообще для отдельного продукта, мне кажется.

Как программу запрограммируешь - так она вести себя и будет :wink:

Впринципе, если есть метрика, по которой определять, какой поток лучше, то это не сложно реализовать.
u-blox выдаёт вполне адекватный параметр accuracy (правда, в nmea его нет, это уже SOL сообщение).
осталось найти что-то сопоставимое в выводе rtklib.

Конечно несложно. Но как правило с наличием и корректностью подобных метрик есть проблемы.

Дело в том что RTKLib - инструмент, а не программа навигации. Его задача - выдать координату в соответствии с настройками.
Я вам посоветовал DGPS, но вы пропустили совет мимо. Выбрали режим RTK ? Значит это будет либо RTK, либо вообще ничего.
Пользователь должен знать что может доверять инструменту.

Нет таких реальных техзаданий, чтобы “требуем RTK, а если не получится - сойдет и обычный GPS” :slight_smile: Но даже если такое задание возникнет - это решается программами навигации, там можно завести хоть десяток GPS с компасами и каждому инструменту задать априорную точность.