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

Я всего лишь хочу сказать что ветка давно скатилась в решение надуманных проблем. Никто толком не может сказать как RTKLib можно применять практически, в то же время идет изготовление фильтров, изучение choke rings, взлом всё новых модулей uBlox и пр. За мелочами давно скрылась основная идея. КАК ЭТО ПРИМЕНЯТЬ ? Как отслеживать качество материала в поле, чтобы не возвращаться туда второй раз ? Как вносить атрибутику ? Как учесть офсеты ?

Это реальные проблемы, без решения которых не пригодятся ни базы, ни фильтры. Я пытаюсь развернуть обсуждение в сторону реальной геодезии и съемки, а вы упорно возвращаетесь к тому что и так знаете хорошо - электронике.

К слову о радарах: на geodesist.ru обсуждали съемку радом с ЛЭП. Да, существует проблема, многочастотный Trimble/Topcon не в состоянии её решить текущими средствами. Поэтому просто стоят подольше или делают засечку.

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

Не вижу попыток что-то развернуть, вижу только “это все не важно”.

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

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

Trimble/Topcon определенно решают эту проблему аппаратными средствами, хотя полностью решить ее, естественно, нельзя.
Решают, потому что заставлять людей решать что-то только методологическими средствами (более длительным стоянием) и игнорировать возможности наскрести там 5%, а тут 10% - глупо. Так что если какое-то техническое решение позволяет что-то еще наскрести - это уже само по себе хорошо. А какой-то контроль нужен в любом случае.

Сдаю идею: без RTK, для постобработки - по каждому спутнику нужен счетчик phase lock, отслеживать флаги в бинарных сообщениях и вести счет в секундах.

Например принять для себя что для инициализации нам нужно 6 спутников с постоянным слежением не менее 60 секунд. Стоим статично и смотрим на счетчики. Есть 6 спутников со счетчиками 60+ ? Да - можно идти. Произошел срыв ? Остановились, ждем пока счетчики достигнут нужных значений, либо (если место совсем гиблое) принимаем решение отменить съемку в этой точке и идем инициализироваться на более открытое место.

Естественно можно упростить и сделать какой-то флажок - красный=стой, зелёный=иди, желтый=“достаточно для кодовой коррекции, сомнительно для кинематики”.

Сделать настройки (минимальное число непрерывных спутников, период непрерывного слежения), в дальнейшем, опираясь на опыт и расстояние до базы, можно менять эти параметры. Конечно чип не в состоянии отследить все срывы фазы, что-то пропустит, но это лучше чем ничего.

Также можно пересчитывать и отображать HDOP/PDOP только для тех спутников, у которых phase lock counter выше необходимого значения.

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

SviMik
Обладатели LIDAR не пользуются RTKLib и одночастотными приемниками :slight_smile: Цена несопоставима.

Я имел в виду наше, практическое применение. Rакую пользу вы можете извлечь из того что знаете координату отдельно взятой точки на автомобиле с точностью 2-10 см ? Да никакой, если не вести лог “еду в такой-то полосе, в полуметре от разделительной линии”, “объезд препятствия, игнорировать эти данные”, “переместился в такую-то полосу”. Потом это ещё обработать надо.

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

Хорошо, я немного приукрасил :slight_smile: Лидара не будет. А вот несколько бюджетных камер, IMU и RTKLib, чтобы сделать свой StreetView (с блекджеком и инструментами для обрисовки в OSM) - вполне решаемая задача.

  1. Я описал пример задачи выше.
  2. 10см - никакой. Но не забываем, что обычный приёмник не даст ни 30 см, ни 50. Так что городить что-то вроде RTKLib придётся как ни крути, если надо что-то хоть немного точнее обычного приёмника. Или я не прав?

Камеры будут вести такой “лог”.

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

chnav, то есть вы предлагаете (переводя на язык протокола UBX) проверять условие mesQI>=6 за t секунд для некоего SV>n ?
“На коленке” (то есть записывая данные на ноут) это, в принципе, реализуется глядя в u-center, хотя это неудобно, да.

Сразу вспомнилась вот такая штуковина http://facility.unavco.org/software/teqc/ она, меж тем, должна понимать данные в stdin, и UBX-протокол она тоже понимает.
Плохо знаком с ней, надо бы освоить и попробовать. Например, не врубаюсь, как задать окно для последних t секунд.

Да.

Глядя на описание тоже удивился что в бинарном протоколе нет чего-то схожего с NMEA PUBX,03…

Satellite carrier lock time, range 00..64
0 = code lock only
64 = lock for 64 seconds or more

В сёрфах надо подсчитывать поле из MID28, Phase Error Count

This is the count of the phase errors greater than 60 degrees measured in the preceding second as defined for a particular channel

Оба способа плохи тем что при перерыве в данных - например, переполнении буфера COM-порта - придется начинать отсчет заново. В этом смысле PUBX,03 надёжнее.

Ну и само собой вручную это делать невозможно, эта функция должна быть реализована непосредственно в софте для сбора данных, в данном случае RTKNav.

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

u-center при включенном NAV-SVINFO показывает QI в таблице в Message View, но глаза разбегаются на него смотреть, честно говоря, а график этого параметра он не рисует.

А в rtknavi есть RTK Monitor, который в режиме Sat GPS показывает список спутников, в котором есть столбцы “L1 lock”… “L5 lock” (и другие), в которых пусто - возможно, это просто не доделано автором, но не могу ничего сказать кроме предположений (назначения колонок даже не документированы).

Поэкспериментировал с сообщением PUBX,03 и rtknavi - решение single оно, судя по всему, выдает при условии наличия более пяти спутников не только с carrier lock time больше какой-то величины (возможно что даже меньшей чем максимальная 64 секунды), но и с SNR>45.
А еще есть такой момент, как условия приема на базе - ее нельзя считать находящейся в идеальных условиях, особенно если она установлена так, как NAGC (в тени здания). Натравленный на ее логи teqc рисует не всегда красивую картинку.

-1

-1

Ну, есть, да. Все равно нужна логика. Вариантов, собственно, три - $PUBX,03 RXM-RAW, NAV-SVINFO, везде показывается разное на одну тему, глазами смотреть неудобно на всё, но наименее неудобно на $PUBX,03.

Я не пробовал пока u-center для андроида, а win mobile устройств у меня вообще нет, но судя по документации (там есть скриншоты) он куда менее функционален, чем десктопный, и message view (который с более-менее удобной таблицей, в которой показываются расшифрованные данные из упомянутых выше сообщений) там просто отсутствует.

-1

-1

К вопросу об антеннах.

Почитал вот эту таблицу http://facility.unavco.org/kb/questions/311/Choke+Ring+Antenna+Calibrations где даны все размеры для choke ring. Повторить такую было бы плёвым делом (самодельные головы для спутникового телевидения в лохматые 90е я точил, но там размер был в разы меньше), если бы был доступ к токарному станку, куда можно было бы засунуть заготовку в 39см диаметром, но такого станка под рукой нет (как и подходящей цельной болванки из латуни или алюминия).

Второй очевидный способ повторить конструкцию - пайка из листа. В номенклатуре латунного листа нет ничего похожего на ряд 3,2…3,6 - это печально, но если геморрой не пугает, то кольца можно свернуть из двух полос, спаянных вместе - 3,0+0,6(0,5). Шлифовать потом придется до умопомрачения, да.

-1

Ниужели нет готовых антен с нужными характеристиками?

Помню я как-то баловался с баночными антенами для wifi. Имея возможность сравнивать с различными заводскими антенами, жутко разочаровался в этих консервных банках. С теми, кто пишет положительные отзывы о них, злую шутку наверное сыграло как раз отсутствие заводских изделий для сравнения :slight_smile:

С GPS разница только в том, что вам даже сравнить не с чем будет… Да и сравнивать крайне сложно в отличии от wifi. Тут же ещё и фазовые измерения идут. Значит, помимо SNR, к сигналу предъявляются и другие требования…
Впрочем, и для wifi SNR - не последняя инстанция. Переотражения могут злую шутку сыграть. Но, по крайней мере, у wifi можно пустить тест на передачу данных, замерить потерю пакетов, и т.д. А по каким показателям у GPS можно судить о качестве приёма?