Comments 24
А чем, например, вот этот парсер не устроил? Или вот этот?
Я естественно не претендую что я лучший парсер в мире продемонстрировал :) когда я занимался разработкой этого проекта в закромах сети я к сожалению не видел данные варианты, собирал информацию по частям, вот этот вариант мне понравился [https://nmea.sourceforge.net/] обязательно его проанализирую, спасибо Вам большое за информацию.
Ну я не говорил про лучше-хуже :-) Просто спросил - это старые парсеры, они давно доступны. Просто подумал - может быть были какие-то причины именно свой написать.
Бывают ситуации когда готовое по каким-то причинам не подходит...
И, кстати, заголовок сообщения выглядит так:
$[тип источника, 2 символа][тип сообщения, 3 символа]
т.е. тот же RMC может быть
$GPRMC для GPS,
$GNRMC для ГЛОНАСС
или $GLRMC, $GARMC, $GBRMC... (Gallileo, BeDow еще что-то там).
Для "мультисистемных" приемников там будет валиться дикая каша из всего подряд. По несколько штук одних и тех же сообщений от разных систем на одну точку.
Так точно, GP и GN я видел в потоках, поэтому и сделал простой алгоритм поиска по шаблону [GGA и RMC], у меня было несколько GPS-приемников, это LS23030/36 он выдает GPGGA/GPRMC, и еще один очень крутой GPS-приемник , это DGPS FORA ONE точность замечательная, вот как раз этот gps выдает GNGGA/GNRMC, тестировал свою систему и фильтр работает корректно.
А вот если Вам интересно, сравнение GPS-приемников
Да, у дорогих приемников есть внутренние алгоритмы обработки сигналов.
Вообще, это очень большая проблема. Причем, чем меньше скорость, тем более "неровный" трек получается. Там же не строго точное положение выдается, а наиболее вероятное - тот самый HDOP как раз и показывает (косвенно) радиус окружности в которой может быть расположено реальное положение. А выдается ее центр, как "наиболее вероятное".
Если стоять на месте, то точка положения будет "гулять".
В городской застройке все еще хуже т.к. там много переотраженных от стен знаний сигналов.
Современные дорогие чипы умеют сглаживать трек, избавляясь от "пилы".
Про DMA неясно написано.
Там буфер не кольцевой, а скорее переключаемый.
DMA при отсутствии полных данных просто замрет и не выдаст прерывания.
Чтобы забрать данные без прерывания придется организовать программный полинг.
Автора спасает только то, что модули GPS выдают данные безостановочно.
Но будут задержки в десятки миллисекунд на приеме.
Для быстрых движущихся средств это уже будет проблемой.
Метод приема в статье недоработан. Так лучше не делать.
Все эти сорсы тоже не несут смысла.
Claude Sonnet отлично разбирается в NMEA, и за секунды напишет полный парсер, гораздо полнее чем в этой статье и еще добавит инерциальную навигацию сверху.
Для все эти датчики по стандарту выдают строку, с данным разделенными через запятую. Просто разбиваем строку по ней, и нужный элемент из массива вставляем куда необходимо. Для нео 6м так в свое время делал. Насчет уровня напряжения, мы же на получение данных в основном работаем, тут разницы нет.
Для тех кто пишет навигацию реального времени надо учитывать время прихода сообщений. Пока приняли строку целиком на скорости 9600, пока разобрали - объект уже уехал. Я думаю многие сталкивались с тем что, например, вы уже на перекрёстке, а в старом навигаторе ещё только подъезжаете. По-хорошему надо отрабатывать PPS и делать экстраполяцию. В крайнем случае делать синхронизацию по внутреннему таймеру, отмечая время прихода первого байта '$' очередной эпохи вне зависимости от типа сообщения (GGA, RMC, ZDA).
Большое Вам спасибо, очень полезный совет, обязательно прислушаюсь к нему и произведу доработку, благодарность, еще раз.
Экстаполяция будет давать "забросы" в поворотах. Тут что-то хитрее нужно. Какое-то быстрое извлечение координат для отображения. А потом уже полный детальный разбор.
Для сложных траекторий идеальный способ - фильтр Калмана + MEMS + компас.
И ещё нужно учитывать, что приёмнику тоже нужно время (доли секунд ?) для рассчета координаты. Можно подобрать latency экспериментально и вносить в виде константы. Так что PPS всё-таки предпочтительнее.
С ФК не так просто... Я игрался со всем этим для обработки уже существующих треков. Достаточно сложно настроить ФК чтобы он более-менее корректно работал только по GPS данным. Тут практически не хуже будет работать намного более простоя и быстрый алгоритм DES - двойное экспоненциальное сглаживание. Но тоже не идеально.
ФК, наверное, будет лучше если у вас есть еще инерциальная система - независимые данные по скорости, ускорению и курсу. Вот тогда, если использовать их в предсказательной части ФК, можно добиться неплохих результатов.
С постобработкой треков всё сложно - координаты NMEA уже сглажены фильтром Калмана в приёмнике и поэтому от забросов на поворотах никак не избавиться.
В геодезии в постобработке сырых данных применяют двойной проход туда-обратно, грубо говоря вторым проходом идём от конца измерений к началу. Но опять же насколько это применимо к трекам... Так что да, ИНС это наилучший выход.
В своё время, ещё до массового распространения смартфонов с MEMS, был такой топовый навигатор TomTom Go 930 со встроеным акселерометром. Идея в том чтобы по поперечным ускорениям отслеживать ответвления в тоннелях. Грубо, но лучше чем ничего.
Уже записанный трек обрабатывать проще т.к. там уже есть все данные от начала и до конца.
Насчет ФК в чипах не сильно уверен что там он достатчоно сильный. Там же принцип фактически тот же самый, что в тривиальном ФНЧ, разница только в том, что коэффициент фильтрации (сглаживания) постоянно корректируется.
Насчет ФК в чипах не сильно уверен что там он достатчоно сильный.
Зависит от чипа. Я разные треки видел, как правило чем хуже приёмник (н-р ранние смартфоны) тем сильнее фильтр, чтобы хоть как-то сгладить данные от ущербной антенны.
В нормальных приёмниках динамическая модель настраивается (юзером) - пешеход, автомобиль, самолёт, море.
Я в своей время занимался обработкой треков, правда, уже записанных логгером.
Потом отдал исходники другому человеку, который выложил их на github Посмотрите, может что интересное найдется... Можно начать с документации - там основные алгоритмы описаны.
while (GGAbuffer[inx] != ',') inx++; // 1st ','
Опасная процедура. А если строка сильно битая будет?
Лучше сначала прочитать строку, проверить контрольную сумму, а потом уже парсить.
Данная процедура, и вообще в целом функции [decodeGGA] и [decodeRMC] не принимают исходный поток данных от GPS-приемника, данный кусок кода я Вам предоставил из функции [uart_Handler_GNSS] расположенный в модуле uartProc_GNSS.c, изначально поток идет именно в эту часть (п.1) а именно, битая строка, неполная строка и т.д. все это отфильтровывается здесь, а уже после в (п.2) я передаю в функции [decodeGGA] и [decodeRMC] чистую строку, пример ($GPGGA,112814.00,9533.8397583,N,07812.4674737,E,4,12,0.72,148.093,M,12.771,M,1.0,0000*65), даже в связи огромного количества подавления спутниковой навигации (по известным нам причинам) у меня ошибок не появлялось.
Если вашему парсеру скормить строчку без запятых в нужных местах, или с пропущенными точками, он уедет по индексу памяти в ебеня очень далеко до хард фаулта. Проверяйте длину сообщения, избегайте while().
Касаемо проверки длины сообщения, к примеру $GPGGA пакета, проблематично проверять, длина может быть разная, поэтому я и решил сделать перед отправкой в парсер decodeGGA, чтобы происходил поиск шаблона , а уже потом , шаблон отправляется в парсер, именно корректный шаблон, а так спасибо Вам больше за указание ошибки, естественно я не претендую на то что логику системы невозможно сломать:)
Прием и парсинг NMEA-данных от GPS-приемника