GPS и эхолот

Тема выделена из темы http://geodesist.ru/forum/threads/obs-и-nav.5446/page-2

Приветствую!
Товарищ chnav обратил мое внимание на этот топик, спасибо ему! Внесу и я свои 5 копеек.
Для меня эта тема актуальна, т.к. при создании своего комплекса "GPS+Эхолот логгер" я столкнулся с подобными проблемами.

Сейчас я реализовал следующий алгоритм работы комплекса:
Микроконтроллер принимается за "черный ящик" - в том плане, что его не интересует какие процессы и как долго происходят снаружи. Микроконтроллер не имеет на борту собственных часов реального времени - RTC, но имеется микропроцессорное время (отсчеты) в миллисекундах или микросекундах. В "черный ящик" приходят события (NMEA-сообщения) от двух устройств - GPS-модуля и Эхолота. Т.к. события от Эхолота не имеют меток RTC, то было принято решение не завязываться на время, приходящее в сообщениях GPS, а просто фиксировать разницу микропроцессорного времени (dT, в миллисекундах) прихода сообщений (допустим RMC и DPT, кстати, RMC тоже имеет дату) по получении всего сообщения полностью (это неправильно, см. выше chnav).

Сейчас в файл трека OziExplorer записываются следующие псевдосинхронные измерения (в одну строку):
Lat, Lon, Depth, dT, Speed, Date/Time, <плюс другие измерения>

Т.о. у текущего алгоритма есть возможность апостериорно (а можно и в программе на микроконтроллере) учесть асинхронность поступления данных от GPS и Эхолота, используя измерение dT (ошибка асинхронности описана в моей статье в разделе Ошибки измерений вносимые комплексом).

В текущем алгоритме осталось учесть вот это:

Оценку начала передачи сообщения следует проводить и для GPS и для Эхолота!

Но... можно ведь фиксировать время приема сообщения сразу по символу начала сообщения - "$", тогда следует ли проводить оценку времени начала передачи сообщения, учитывая его длину (ведь передан был только один символ, а это 1 мс и меньше)?

 

Добрый день!

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


Итоги с ветки форума:

1) <Цитата с ветки форума>
Вывод такой: для открытых пространств старые приемники точнее новых по факту.
Конечно, если есть возможность программно перенастроить приемник, чтоб он не просчитывал данные от спутников близких к горизонту,
в новых будет не хуже. В Sirf3 такая возможность есть, но я этим не занимался.
<>

Мой вывод: в GPS-модуле u-blox NEO-6M есть параметр для настройки минимального угла спутников над горизонтом для принятия навигационного решения.
<Цитата из документации>
minElev - Minimum elevation of a satellite above the horizon in order to be used in the navigation
solution. Low elevation satellites may provide degraded accuracy, due to the long signal path through the atmosphere.
<>

Вопрос: Есть возможность реализовать в настройках комплекса параметр "минимальный угол видимости спутников над горизонтом",
какое значение угла следует выставить в параметре?


2) Вопрос: стоит ли принудительно перевести GPS-приемник в режим работы - 2D, улучшит это точность определения координат?

(сейчас стоит режим Auto 2D/3D - приемник в автоматическом режиме принимает решение о режиме по количеству спутников и еще чему-то)
(высота над уровнем моря при передвижении на водоеме не изменяется)


3) Какую динамическую модель выбрать для GPS-модуля u-blox NEO-6M (для использования в комплексе на водоеме)?

а) Pedestrian - Applications with low acceleration and speed, e.g. how a pedestrian would move. Low
acceleration assumed. MAX Altitude [m]: 9000, MAX Velocity [m/s]: 30, MAX Vertical
Velocity [m/s]: 20, Sanity check type: Altitude and Velocity, Max Position Deviation: Small

б) At sea - Recommended for applications at sea, with zero vertical velocity. Zero vertical velocity
assumed. Sea level assumed. MAX Altitude [m]: 500, MAX Velocity [m/s]: 25, MAX Vertical
Velocity [m/s]: 5, Sanity check type: Altitude and Velocity, Max Position Deviation: Medium


4) Формулы для вычисления дистанции между двумя географическими точками (расстояние между точками - несколько метров):

Вопрос: Если GPS выдает мне данные в WGS-84, то я должен в формулах использовать параметры эллипсоида WGS-84?

Вопрос: Т.к. я передвигаюсь по поверхности водоема (озера), то "высоту над уровнем моря" я могу принять за константу = высоте над уровнем моря в исследуемой местности и не брать ее с GPS-приемника (например, сделать настраиваемый параметр в комплексе)?

Вопрос: Формула для вычисления дистанции должна обеспечивать до-метровую точность (допустим погрешность: максимум +/-1 м),
в Инете полно формул, какую формулу выбрать?

(для формул с примерно одинаковой точностью будет приоритет на наименьшее время вычислений)


5) Скорость передвижения полученная от GPS ($GPRMC / $GPVTG):

Вопрос: Как она вычисляется в GPS? Усредненная она или нет?
Слышал темы про Эффект Доплера и фазовые измерения, но не понял, относится измерение скорости подобным методом к бытовым GPS-приемникам с единственной частотой L1 C/A code?


6) Для повышения точности определения координат в текущей версии комплекса, использующего GPS-модуль u-blox NEO-6M, могу воспользоваться технологией A-GPS от компании u-blox - AssistNow. Без дополнительного оборудования (типа GSM) мне доступна реализация AssistNow Offline.

Кратко поясню: перед поездкой на водоем на SD карту комплекса помещается скачанный с сервиса u-blox файл с "Differential almanac correction data" (как приведено в документе выше). Данные за 1-14 дней, но реально могут потребоваться данные за 1-3 дня. При старте комплекса данные из файла запихиваются в память GPS-модуля, он начинает использовать механизм AssistNow Offline.

Вопрос: Могут данные о "Differential almanac correction data" повлиять на точность определения координат после старта комплекса (при дальнейшей работе комплекса), или реально они повлияют только на TTFF, а все остальное - маркетинговый ход компании?


7) Мне пригрезилось или я реально видел в программе u-center (прога от u-blox для изучения GPS-модулей) спутник EGNOS под номером 126 (на тот момент я еще не оперировал сущностями типа системы SBAS и т.п. и только сейчас зрительная память подает сигнал, а GPS под рукой нет проверить)?

Что можно сказать о возможности использования спутников EGNOS в Карелии (или СЗ регионе России)?
Не будет ли ухудшения точности определения координат из-за них (слышал, что для России спутники низко над горизонтом, к вопросу (1))?


8) Что можно сказать о следующих характеристиках, заявленных в документации на модули u-blox серии NEO-6:

Horizontal position accuracy (сноска 6):
GPS - 2.5 m
SBAS - 2.0 m
SBAS + PPP (сноска 7) < 1 m (2D, R50) (сноска 8)
SBAS + PPP (сноска 7) < 2 m (3D, R50) (сноска 8)

Velocity accuracy (сноска 6) - 0.1 m/s
Heading accuracy (сноска 6) - 0.5 degrees

Сноски:
(сноска 6): CEP, 50%, 24 hours static, -130dBm, SEP: <3.5m
(сноска 7): NEO-6P only
(сноска 8): Demonstrated under following conditions: 24 hours, stationary, first 600 seconds of data discarded. HDOP < 1.5 during measurement period, strong signals. Continuous availability of valid SBAS correction data during full test period.

Вопрос: что это за параметры методик измерения: CEP, 50%, R50, SEP ?


Заранее благодарю!

 

1. 10° стандарт де факто для GPS/DGPS

2. Нет, этот режим для тяжёлых условий приёма, когда спутников совсем мало. К промеру обычно не относится т.к. обзор 360°

3. В идеале нужен минимум фильтрации т.к. отфильтровать данные Вы сможете либо в своей программе, либо при обработке дома. В данном случае, как ни странно, это Pedestrian Может хотя бы Car есть ?

4. Обычно работы ведутся в прямоугольной проекции. Т.е. выбираете зону UTM и переводите координаты в прямоуголку (метры). Вся остальная математика в программе после этого сильно упрощается.

5. Да, в бытовых приемниках также используется смещение Доплера, а в случае очень слабого сигнала от спутников - PRR (pseudo-range rate). Но в конечном итоге скорость - это одно из решений на выходе фильтра Кальмана, т.е. есть это отфильтрованное/усредненное значение, на которое влияют настройки из п.3

6. Скорее всего это действительно простое ускорение холодного старта, хотя надо почитать внимательнее. Сомневаюсь что кто-то станет выкладывать точные эфемериды realtime. На этом делаются огромные деньги, причем требуется постоянный канал связи. Знаю что C-Nav позволяет сохранять приемлемую точность при пропадании коррекций до 15 минут. А тут на несколько суток... Сказки.

7. Все спутники SBAS - геостационарные, отсюда и низкая высота над горизонтом. В данном случае они используются только как канал передачи SBAS-данных. Насколько я помню, их навигационный сигнал всё ещё низкого качества и не используется в качестве псевдодальности. Должно изменяться в настройках или жестко прошито в firmware. Who knows...
Использовать SBAS не рекомендуется т.к. Ionospheric Grid генерируется только для Европы. За пределами этой сети параметры ионосферы рассчитать невозможно.

8. Circular Error Probability, ЕМНИП в данном случае означает что за 24 часа непрерывной записи 50% измерений попали в окружность с радиусом 2.5m от настоящей координаты (т.к. антенна установлена на известном пункте). Что это означает для обычного пользователя - в идеальных условиях приёма, с уровнем сигнала на входе приёмника выше -130dBm каждая отдельная измеренная координата имеет ошибку менее 2.5m с вероятностью 50%. Соответственно в остальных 50% случаев она врёт больше 2.5m. Что такое SEP я не помню.
Вот тут (ссылка) есть простая табличка соответствия разных параметров точности и их соотношения

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

 

Спасибо за оперативные ответы сразу на все вопросы!

Несколько уточняющих моментов:

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

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

Мои подозрения еще переплетаются с настройкой частоты принятия навигационного решения: если я выставлю 5 Гц, то все меньше времени остается для вычислений в фильтре Калмана, т.о. я могу получить неточный результат навигационного решения (опять мои подозрения) ?

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

Я мыслю в правильном направлении или не совсем?

Dynamic Platform Model:

Portable - Default setting. Applications with low acceleration, e.g. portable devices. Suitable for most
situations. MAX Altitude [m]: 12000, MAX Velocity [m/s]: 310, MAX Vertical Velocity [m/s]:
50, Sanity check type: Altitude and Velocity, Max Position Deviation: Medium

Stationary - Used in timing applications (antenna must be stationary) or other stationary applications.
Velocity restricted to 0 m/s. Zero dynamics assumed. MAX Altitude [m]: 9000, MAX
Velocity [m/s]: 10, MAX Vertical Velocity [m/s]: 6, Sanity check type: Altitude and Velocity, Max Position Deviation: Small

Pedestrian - Applications with low acceleration and speed, e.g. how a pedestrian would move. Low
acceleration assumed. MAX Altitude [m]: 9000, MAX Velocity [m/s]: 30, MAX Vertical
Velocity [m/s]: 20, Sanity check type: Altitude and Velocity, Max Position Deviation: Small

Automotive - Default setting for ADR. Used for applications with equivalent dynamics to those of a
passenger car. Low vertical acceleration assumed. MAX Altitude [m]: 6000 (5000 for
firmware versions 6.00 and below), MAX Velocity [m/s]: 84 (62 for firmware versions 4.00
to 5.00), MAX Vertical Velocity [m/s]: 15, Sanity check type: Altitude and Velocity, Max Position Deviation: Medium

At sea - Recommended for applications at sea, with zero vertical velocity. Zero vertical velocity
assumed. Sea level assumed. MAX Altitude [m]: 500, MAX Velocity [m/s]: 25, MAX Vertical
Velocity [m/s]: 5, Sanity check type: Altitude and Velocity, Max Position Deviation: Medium

Airborne <1g - Used for applications with a higher dynamic range and vertical acceleration than a
passenger car. No 2D position fixes supported. MAX Altitude [m]: 50000, MAX Velocity
[m/s]: 100, MAX Vertical Velocity [m/s]: 100, Sanity check type: Altitude, Max Position Deviation: Large

Airborne <2g - Recommended for typical airborne environment. No 2D position fixes supported. MAX
Altitude [m]: 50000, MAX Velocity [m/s]: 250, MAX Vertical Velocity [m/s]: 100, Sanity
check type: Altitude, Max Position Deviation: Large

Airborne <4g - Only recommended for extremely dynamic environments. No 2D position fixes supported.
MAX Altitude [m]: 50000, MAX Velocity [m/s]: 500, MAX Vertical Velocity [m/s]: 100,
Sanity check type: Altitude, Max Position Deviation: Large

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

Я имел в виду вычисления 3D координат XYZ на аппроксимированной сфере Земли или эллипсоиде WGS-84. Дальше там идет вычисление длины хорды между пунктом А и пунктом В, но для моих целей (расстояние между измерениями от 2 до 10 метров) хорда не нужна, принимаем ее за прямую линию.

Для понимания темы пару ссылок: тут с картинками Geographic Distance and Azimuth Calculations и тут проще.
Но в сторону проекций тоже гляну.

Так может там выдают не "очень точные" данные!?

Плюс к этому из документа:
AssistNow Online - Ephemeris, almanac, time, health
AssistNow Offline - Differential almanac correction data (обратите внимание, что речь тут идет только об альманахе, максимум на 14 дней, хм...)

Вопрос: не понимаю, как можно рассчитать точную орбиту спутника наперед, ведь он будет двигаться все равно не так?
Вопрос: мне больше хотелось понять, могут ли данные только об альманахе увеличить точность измерения координат или для этого нужны эфемериды и прочие данные, которые доступны только при AssistNow Online ?

Плюс к этому из документа:
Free and premium service options
AssistNow data is collected by u-blox’ global array of satellite receivers, and maintained in real-time on u-blox AssistNow servers accessible via the Internet.
For best-effort applications, u-blox provides AssistNow free-of-charge to its customers.
For applications requiring a guaranteed minimum Quality of Service (QoS), u-blox provides AssistNow Premium which provides guaranteed availability based on a service level agreement and 24/7 support.

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

 

С доступом к AssistNow Offline разобрался, ссылка для загрузки альманаха!

 

От настроек фильтра время расчетов не увеличивается. Если брать динамические модели - всего лишь меняется коэффициент для фильтра. Кроме того расчеты производятся в firmware приёмника и нагрузки для пользователя не добавляют никакой.

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

Нет, мощности встроенного процессора должно хватать, раз производитель указывает в спецификации 5 Герц.

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

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


ИМХО Вам следует копать в сторону RTCM-станции. Это первый шаг к точности в реальном времени. По-моему uBlox умеет использовать RTCM-коррекции, хотя надо уточнять, у них разные линейки приборов имеют разные функции.

 

Спасибо!
Хорошо, буду теперь анализировать ответы.

 

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

Точные эфемериды всех спутников выкладываются через несколько дней. Геодезисты их редко применяют, так как при работе в два приемника на расстояниях до 50 км неточности предсказанных эфемерид компенсируются. Решение с точными эфемеридами, как правило, до миллиметров совпадает решением от "плохих" эфемерид. При работе одним приемником точность немного повышается.

Да, так будет лучше. Не на сфере, а на эллипсоиде WGS. Этим вы подстрахуетесь от "подводных камней".

Да!. Или использовать поправки со второго, неподвижного приемника. Можно достичь субметровой точности в плане. Для улучшения точности высоты можно использовать барометрический высотомер (но на водной поверхности точная высота вряд ли нужна)

 

Во блин, оказывается наши запускают "Лучи" (SBAS для ГЛОНАСС и GPS) и организуют сеть российских станций. Ещё не совсем понятно какие приёмники с ними работают.
http://gps-club.ru/gps_news/detail.php?ID=86533
http://ru.wikipedia.org/wiki/СДКМ