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

По поводу NTRIP - просто еще одна реализация, которая в этой теме вроде не упоминалась, проблемы никакой.

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

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

-1

-1

Там на сайте если смотреть график какой-то одной величины (N, E, H) видно что основной режим SBAS, когда поправок нет сваливается в standalone. Особенно хорошо видно на графике высоты, фильтрация одинаковая.
Впрочем кому как, я для себя выводы сделал.

По итогам обработки треков которые писал в выходные, есть эмпирическое наблюдение - оборудование контроля скорости (радары с камерами и радары, определяющие скорость потока для пробочных сервисов) довольно надежно вредят определению координат, решение срывается. Так что “на будущее” стоит думать об антенне для ровера не только с LNA, но и с SAW-фильтром (например, такие делает Tallysman, относительно бюджетные).

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

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

Вот пример из этого района.
Красные круги - эллипс 1 sigma (68%). Обработка в GPS Pathfinder Office, Code Only по станциии Менделеево.
У маленьких кружков SMA около 1.5м (8 спутников), у больших справа около гостиницы Кузьминки и высоток SMA=11м (6 спутников).

Поэтому я не жду от кинематики чуда при работе в подобных условиях.

chnav, вы упорно лепите из меня в своем сознании какого-то идеалиста и в то же время играете в телепата.

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

Я радиоинженер по образованию, а потому прекрасно представляю себе свойства распространения радиоволн на таких частотах и поведение приемной аппаратуры в условиях сложной радиотехнической обстановки. Но у меня нет панорамного ресивера выше 1,3 ГГц, потому конкретный масштаб помойки в районе частот GPS я могу наблюдать только вот таким эмпирическим путем.

И если у кого-то будет желание и средства помочь своему приемнику не переваривать мусор - то не вижу препятствий. Очевидно, что разница между антенной за $30 и за $90 не будет в три раза, но если кому-то не жалко +$60, то в некоторых ситуациях свои +10…15% к SNR он получит.

Опыт использования фильтров совместно с оборудованием ads-b (1090 МГц) с узкополосным МШУ и диапазонными антеннами показывает прирост успешно декодированных пакетов, различимый невооруженным глазом, так что тезис о полной бесполезности SAW-фильтров звучит бездоказательно.

Я всего лишь хочу сказать что ветка давно скатилась в решение надуманных проблем. Никто толком не может сказать как 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