Выделение вполне себе очевидно, GDOP+CLI (надо только конкретные числа подобрать), плюс некая минимальная длина сегмента.
Я сам бывший БРЭОшник, могу сказать - у летунов еще куча хрени (вроде заборников давления) и АРК вместе с VOR/DME никто не отменял, а для посадки по GPS единицы портов сертифицированы. Так что авиационный опыт не особо тут полезен.
А если сфомулировать так - информация с GPS должна лишь чуть-чуть модифицировать гироскопно-одометровый трек - чуть-чуть доворачивать гироскоп и чуть-чуть растягивать/сжимать одометр.
OverQuantum, это, по-моему, сложнее, потому что для доворачивания на основании мгновенных данных, нужно получить надежные данные от GPS на некотором отрезке. А в городе, в движении, фиксированное решение фазовым методом практически невозможно (плавающее, правда, вполне вероятно), а кодовый метод даст негодную абракадабру.
Пока посадка кривой на точки выглядит наиболее надежным решением.
сюда бы просто точный компас приделать.
А точнее?
Я может чего не знаю, но хорошие модули от того же Honeywell стоят несколько сотен.
BushmanK
Да я просто мимо проходил, увидел, что треки, записанные с помощью акселерометра плохо понимают угол поворота, вот я и предположил, что для точности угла поворота хорошо бы компас использовать.
Да, хорошо, но высокоточный компас может стоит больше высокоточного GPS, к большому сожалению (посмотрел сейчас в магазинах электроники, ширпотребные датчики стоимостью до 50 баксов дают точность явно хуже того, что дает акселерометр и датчики на колесах).
BushmanK, в порядке общего развития, расскажите пожалуйста как при помощи триангуляции Делоне притянуть один трек к другому?
Если просто построить триангуляцию минимизировав площади треугольников, как я понимаю - трек от инерциальной системы просто ляжет на трек от gpx. В чем хитрость?
dkiselev
Триангуляция Делоне в инерциальной системе - это видимо собственная разработка BushmanK. Он много чего выдумывает.
Инерциальная навигация всего лишь один из подвидов геодезии и методы там применяются соответствующие, главный и основной из которых - фильтр Кальмана + уравнивание по МНК. Если идти дальше то в геодезии есть такая область знания как “статистическое тестирование” (f-test, w-test), которая позволяет в реальном времени отбраковывать некачественные измерения. Вот только про эти тесты знают даже не все геодезисты.
PS: очень грамотное замечание в начале этой ветки
Их алгоритмы учитывают даже температурный дрейф и старение датчиков, не зря самокалибровка длится месяцами.
dkiselev, то, что я описал, не более чем наколенное решение, которое легко собирается из готовых средств (почти) без программирования и легко проверяется на жизнеспособность.
Предположим, что у нас есть трек от инерциальной системы (с накапливающейся ошибкой, которую мы, по какой-то причине, не можем учесть и скомпенсировать) и есть точки, снятые GPS. Тут надо пояснить, что SviMik засветился и в теме про RTKLib про всякие дифференциальные gps-измерения, потому речь в том, что я писал, шла не о сомнительного качества gpx-треке с бытового приемника, а о более точных измерениях, особенно учитывая, что в Эстонии доступ к государственным серверам для диф. измерений - открытый.
Ну а дальше остается выловить хорошие одиночные точки из того, что измерено GPS, и сопоставить их по времени с точками из трека инерциальной системы и “посадить” на них этот трек. То, что для получения хороших точек нужно не просто кататься по городу, а кое-где на открытых местах постоять - это я прекрасно понимаю.
chnav, со своим высокопрофессиональным подходом, шли бы вы на geodesist.ru, наконец.
Там таких как вы много, будет, наверняка, комфортнее общаться.
BushmanK
Вам не нравится когда указывают на детские ошибки ? Тогда не вводите людей в заблуждение и не пишите с таким видом словно ваши знания высечены в камне. Они скорее высосаны из пальца.
SviMik
Повторюсь, вся инерциальная навигация вертится вокруг фильтра Кальмана. У вас ситуация чуть сложнее т.к. приемник отдает уже готовые координаты GPS. На этот случай самое простое решение при уравнивании по МНК (weighted least-square) назначать измерениям вес в зависимости от какого-либо параметра, например HDOP. Т.е. чем больше HDOP тем меньше доверия координате GPS и тем больший вес остаётся для акселерометров.
Это будет решение максимально приближенное к общепринятым.
(added)
Да, ещё забыл. Кальман хорош для навигации реального времени, когда вы непосредственно собираете данные. В постобработке поступают чуть иначе - например первая и последняя точки GPS принимаются как абсолютно достоверные (точнее вы сами выбираете опорные точки - измерения, на ваш взгляд, самые качественные), а между ними идет интерполяция. Дрейф сенсоров “раскидывается” по всему треку в виде “невязок”.
chnav, мы с вами это уже раз обсуждали: вы постоянно пытаетесь всем вокруг указать на то, что они поступают не так, как положено делать у профессионалов, даже когда они не стремятся к тем же результатам, что и профессионалы.
Я прекрасно помню одно ваше замечание, которое вы потом стерли в традиционной манере, где вы, очевидно, совсем забыли, что общаетесь с энтузиастами, а не работягами, зарабатывающими на хлеб с рейкой и теодолитом.
Но почему-то мы возвращаемся к той же ситуации. Вот потому я вас на geodesist.ru и посылаю. Там “детских ошибок”, тупняка и прочего - вагон и маленькая тележка, но хоть будете в компании тех, кто исходит из того же, и кому нужно то же.
Вот кстати крутая библиотека, может кому пригодится по теме
ceres-solver
Видео:
http://www.youtube.com/watch?v=z00ORu4bU-A&feature=player_embedded
Я просто не понял причем тут ТД.
Собственно интерес возник потому, что саму ТД можно и на мобильном устройстве посчитать для рассчета есть эффективные алгоритмы. Я просто не понял куда и как триангуляцию дальше применить. Описанное наколенное решение я понял.
Глядя со стороны, я бы посоветовал попробовать сделать что-нибудь реально-наглядное. Как некую промежуточную веху. Что бы не вечно быть техно-гиком и вариться в даташитах. И обкладываться гигами сырых логов 
Например, андроид имеет возможность принимать gps-данные в “фальшивый” порт, отладочная штука. Но работает и безо всяких рутов и прочего. И совать это всё в ОсмАнд! Можно попробовать собрать поступающие данные – 1) реальные gps телефона, и 2) данные с датчиков/odb, с этой всей инерционной системы.
УРЕЗАТЬ 100 герц раз в десять, что бы андроид и навигашка не захлебнулись, и слеплять результирующий “сигнал” gps так: закладываемся на некую максимально допустимую HDOP реального gps. Каждую такую точку объявляем той самой точкой “посадки” инерционки на трек. Сажаем. То есть, изменяем относительную координату передаваемых данных от инерционной системы. И подсовываем андроиду в нашу навигашку этот, инерционный трек. (Обреженный хотя бы до 10 Гц, напомню). Пока не придёт следующая поправка от реального gps.
Ну, а дальше играемся частотой коррекции, слишком часто, может и не хорошо. Иргаемся пороговым DOP… Любуемся этим делом, играемся дальше. Понятно, что будут зримые скачки, (а может и нет), зато будет реально работающая штука. С любой навигашкой прям на телефоне! Пусть черновая. Чем вечно ходить в коротких штанишках, “лежать под машиной”, надо как-то выводить это дело в реал
Мне кажется, что предолженный черновой путь не тупиковый. Тупиковый путь чем не хорош – все наработки будут за зря. Всё потраченное время ради разового баловства. А тут много будет не за зря: Вывод на фиктивный gps андроида, Игра/настройка параметров подмешивания того и того сигнала в результирующий… Все эти наработки пригодятся в будущем. А пока нет ничего.
Такие вот ненаучные мысли меня посетили. Потому что всегда хорошо подержать в руках рабочий образчик чего-то. а) Стремиться к нему, (как к неложной цели), б) подержать, в) опереться и двигаться дальше.
ps. а, да, а гиро-данные эти ваши заводить по usb, если тел умеет usb-host (otg), или по блютузу, да или по вафле. если уж совсем по-гиковски)) да и rs-порты есть же под usb. (не знаю, по чему у вас инфа из инеруионки выходит). И всё это слеплять софтово и совать в программный Фиктивный gps Андроида.
Скажу даже больше - этот же трюк можно делать и в программах для ПК 
Причём, не только в навигаторах, но и прочем картографическом софте, который может оказаться на ноутбуке.
Открою секрет - одна из конечных целей будет создать законченное устройство, которое может использоваться вместо обычного USB приёмника (а по желанию, можно им и bluetooth приёмник изобразить, и тогда использовать на любом телефоне, не только андроид ;)).
К сожалению, выводить пока нечего. Всё на уровне идей, и некоторых пока неудовлетворительно работающих прототипах. Будем думать дальше.
Следующие замечания\предложения я рассмотрел, и вот мои соображения:
Фильтр Калмана. Штука, безусловно, крутая. Чего ей только не делают - в любой задаче, где надо из нескольких плохих источников информации сделать одну хорошую картину, это первый кандидат. Но есть некоторые но:
- Данную задачу мне не осилить. Я прочитал много статей про него (изучал вопрос где-то месяц), но любое место, где начинаются формулы, для меня абракадабра. Сказывается отсутствие высшего образования (да и на среднем я математику не любил).
- Готовой реализации фильтра калмана в общем случае не существует, т.к. существенную часть будет занимать даже не сам фильтр, а модель конкретной используемой системы.
Если есть желающие помочь (читать “сделать за меня”) фильтр Калмана - с радостью приму участие, это единственный возможный вариант развития сценария в этом направлении.
RTKLib. Повысить точность GPS приёмника - всегда хорошая идея, и не только в моей задаче. Однако,
- Нет подтверждений того, что это вообще будет работать в городе. Скорее нет чем да.
- Не уверен, что возможно обсчитывать это дело в реальном времени. Текущие обсуждения зациклились на постпроцессинге, когда иметь точный GPS сразу по месту использования гораздо интереснее. Я знаю, что в теории это не проблема, т.к. наземные станции могут выдавать коррекции в реальном времени. Но есть ли софт и успешные примеры его использования?
- Отсутствие howto. Начиная с банального какие приёмники (и где) брать, и как каждый из них патчить. Не существует даже единой таблицы приёмников, где было бы указано, что с ним можно из коробки, что можно после патчинга, а что не удалось вообще.
- Требуется соединение с интернетом для получения поправок. Без этого он превращается в обычный GPS, а значит система должна уметь работать и с этим, не надеясь на точные данные от GPS.
Вывод - RTKLib можно внедрить в готовую систему для улучшения её характеристик, но до этого надо сделать рабочую систему, способную давать вменяемый результат и без него.
SviMik
А вы составьте список проблем, вывесите его тут, будем думать над каждой отдельно. С миру по нитке… RTKLib на текущий момент я бы задвинул на последнее место. Например:
- Проблема синхронизации данных от датчиков положения (поступают почти мгновенно) и GPS (задержки до секунд), она есть и будет вылазить в самых непредвиденных местах. Это первая проблема, с которой сталкиваются все гидрографы (GPS+эхолот), с их-то скоростями… На автомобилях всё значительно хуже.
- Проблема фильтрованых координат, поступающих из GPS-приемника - выражается в заскоках на повороте. От этой проблемы никак не избавиться, т.е. надо подобные данные как-то отбрасывать (в u-Blox который в начале этого топика это решается проще т.к. GPS и инерциалка реализованы внутри одного чипа).
- Проблема дрейфа, как вы писали ранее, будет заметна при длительном отсутствии качественного GPS-сигнала. Если не связываться с постобработкой то надо делать буфер побольше и при восстановлении сигнала (например выезде из тоннеля) пересчитывать накопившиеся данные, только после этого сбрасывать их в файл.
… - Дифференциальный GPS/SBAS
- RTKLib
Кстати, HDOP вообще показывает попугаи, а не точность определения координат. Одно из объяснений можно найти в википедии:
Т.е. он вообще описывает удачность расположения спутников, а не качество приёма 
Что кстати подтверждается на практике - при ухудшении условий приёма, координаты улетают раньше, чем HDOP что-то покажет.
Но есть и положительная сторона - найдена более практичная метрика: количество спутников, участвовавших в расчёте координат. Практика показывает, что идеальный (по меркам обычного приёмника) результат будет начиная с 10 спутников. 10-12 типичное число для sirf star 4 с антеной на крыше автомобиля.
Если спутников становится меньше 8, то можно заподозрить неладное. На первый взгляд число большое, но не забываем, что приёмник специализируется на использование отражённых сигналов в городских условиях (пометка для тех, кто привык к фазовым измерениям, и может забыть про существование такого метода :D). И если даже отражёнными сигналами до приёмника что-то не дошло - скорее всего, мы куда-то заехали. Ну или приёмник ещё не раздуплился.
Показатель количества спутников бегает очень шустро, и хорошо коррелирует с точностью каждой конкретной точки трека.
К сожалению, с лимитом ublox в 1Гц, практической пользы от него для себя не вижу. Если мы хотим 100, нам опять надо возвращаться к тому, откуда начали - брать ublox в качестве GPS, к нему добавлять свою (ещё одну? :D) систему датчиков, с которыми надо (и дальше по тексту)…
HDOP я приводил исключительно из соображений что это показатель хоть какого-то качества, присутствующий в любых приемниках. Количество спутников тоже можно использовать, возвышение спутников тоже влияет. Если копать глубже то в протоколе Sirf Binary есть estimated accuracy в метрах. При хорошем созвездии и стабильном приеме она замирает на значении 5.0м и не уменьшается. Проезд под мостом - сразу скачок до 7-9 метров, секунд через 30 возвращается к 5 метрам.
Идея интересная. Правда не ясна перспектива самостоятельного высчитывания координат из сырых данных (нам ведь это надо в свой софт встроить, значит надо отыскать готовый код, который можно использовать).