Ну да, навигационных комплексы от Applanix одни из лучших. PosPac, кстати, обрабатывает данные собранные исключительно от навигационного софта PosAV, вне зависимости от того, какая INS там стоит. От качества INS в реальном времени зависит например такой фактор. Если imu геодезического класса, навигационная система может начать работать из статики. Если точности imu не позволяют - придётся делать виражи и разные трюки в динамике, чтобы "завести" решение и ФК начал вычислять совместную ориентацию GNSS + imu. Для лучших imu период определения ориентации в статике составляет около минуты в горячем старте. Если прибор угнали в другое полушарие, это может составить до 25 минут. Imho. PosAV+INS это чёрный ящик. В котором не просто ФК, компьютер интегратор, GNSS. Полагаю, в такой надёжной и дорогой штуке не обходится без измерений дельта g и магнитного склонения, модели которых заложены в бортовой комп., наряду с остальными параметрами Земли. Скажу так. Если на вход PosPac подать позицию, из которой вычли высоту геоида - общее решение Sbet ( Smoothed Best Estimate of Trajectory) в лучшем случае будет иметь нарастающие ошибки, волнами. Обычно, при величине геоида 10-15 м софт помашет вам ручками. Эта штука всегда вычисляется по тем параметрам Земли, которые в INS. --- Сообщения объединены, 9 апр 2020, Оригинальное время сообщения: 9 апр 2020 --- PosPac, по крайней мере с третьего поколения, всегда имел один и тот же движок обработки GNSS с Waypoint. Кажется gnss4geo рассказывал, да. Его собственно и написали в Waypoint, который купил Novatel, однако сохранил им торговую марку, под которой нынче выпускаются GN/GN и Inertial Explorer. О нем отдельный спич. Pospac модульный, и всегда им был. До 5го поколения сидел на LPT ключе. Сейчас usb. Любой модуль пакета можно купить. Обрабатывает: - сети гнсс. Умеет также, по минимум 5 станциям мутить виртуальную станцию, даже не станцию, а поле, в любой точке которого, при вычислении кинематики, ты как бы около неё - вычислять кинематику, про пресетам - воздух, земля, вода, стоп-гоу - вычисление sbet. Не только по старинке наложением ускорения на позицию, но и как стало модно лет 7 назад - тайтли куплет - когда в ФК загоняются и данные инерциалки и по отдельности каждый наблюдаемый range-вектор до ИСЗ. - рассчитывает облако точек. Малое количество поддерживаемых фирм-производителей. Правда сейчас уже дело близко к 9 версии, её не щупал. - обрабатывает SAR. --- Сообщения объединены, 9 апр 2020 --- Одно из окошек настройки начальных условий ФК. Для взрослых imu количество времени, требующегося для надёжного решения gnss+imu составляет 60-90 сек в динамике, после первой записи. --- Сообщения объединены, 9 апр 2020 --- Извините за грамматику. --- Сообщения объединены, 9 апр 2020 --- Не силен в коммерции этих фирм - Аппланикса и Нователь, как можно развивать на одних кодах и даже GUI! конкурирующие продукты, но когда вышел Inertial Explorer, с мечтой владельца сторонней imu - прописать файл описания/ошибок линеек и софт будет обрабатывать данные как "свои" - это был маркетинг с большой буквы. В общем, обрабатывал данные и в РР и в IE, полет гуд. Цена у продуктов сопоставимая. Правда РР ещё считает калибровку фотокамер, но это ничтожная фича, тем более что в нем неудобно.
Моя организация, в пору, когда мы были на подъеме, активно использовала GN/GN для обработки результатов ГНСС+ИНС измерений в комплексе мобильного лазерного сканирования и видеосъемки железнодорожного пути. Наш комплекс, хотя и был типичным «самопалом», однако был вполне себе рабочий прототип. Планируя развитие, мы даже приобрели Inertial Explorer. Беда в том, что дальнейшего развития наши программно-аппаратные и околонаучные изыски не получили по объективным причинам. Но воспоминания греют душу… Вот тут еще один грустный мотив моего зацепа за тему. А в нашей стране свой софт на базе ФКБ для сбора и обработки геопространственных данных кто-нибудь городит и продает? Порадуйте старика позитивом, если такой имеется.
Вот прям чтоб софт из коробки не знаю. Зато продают навигационных комплексы. Например http://www.screen-co.ru Мы катали с ними в тестовом режиме их подводный интерферометр. Такая швабра, с двумя плоскими антеннами расставленными под углом, жпс, мемс, датчиком скорости звука и т. п. По сути лидар, только принцип работы другой. Измеряется угол фронта излученной волны и возвратной. Что аппаратная часть, что софт - крайне наукоёмки, поэтому пугают. За софт. Они написали программу вычисления дальностей, на основе анализа оцифрованой волны. Они написали модуль к HYPACK, который как раз и содержал ФК для обработки траектории и облака точек дна. Как сейчас помню, на вход продавались значения позиции, ускорений наклона, частые измерения скорости звука в воде и что-то там ещё. Почему модуль был к дорогому HYPACK не знаю, может инструментарий программирования им понравился, что кстати означает использования ФК из этого пакета. Могу дать контакт из того отдела, хотите?
Оффтоп (Move your mouse to the spoiler area to reveal the content) можно говорить о том, что ФК дал начало искусственному интеллекту. Не больше не меньше.
И всё-равно я не понимаю - зачем фильт Калмана (предиктивный по определению, который использует past data) нужен в постобработке, где можно пользоваться обычными фильтрами ? У нас в сейсмике так и было. В онлайне - Кальман, в постобработке какие-то оконные фильтры. А впоследствии, чтобы избавить навигаторов от постобработки, в программе ORCA сделали пост-обработку OTF - примерно с 30-секундной задержкой идёт обычная фильтрация и пишет готовые обработанные данные. Раньше это было невозможно из-за объёма данных, которые надо держать в памяти, но лет десять назад это стало неактуально.
Imho. Есть подозрение, что под это понятие попадают эти самые оконные фильтры, не имея отношения ко времени. Чуть проскользнёт фраза ковариация - сразу ФК. Насчёт постобработки. В аэросъёмке и влс стандарт точности траектории порядка 3-5 см позиции (ско), и 0.01 угловой минуты, для вычисления облака точек и прямого проектирования фото, без уравнивания! На уровне 2 пикселей. Такие точности на всей протяжённость полёта невозможно представить, если в лоб интегрировать ускорения и позиции. Не лишним будет вспомнить соотношение шумов. Как вы заметили, выше, ФК вычисляет OTF соотношение шумов! В этом его фича. Другими словами, ФК предсказывает аппарату вычисления вектора системы не имея начальных точностей линеек, при условии конечных точностей. Каждая линейка оценивается, стандарты перемножаются, второй и следующие результаты измерений сопоставляются с предсказанным на основе ковариации, делается вывод и составляется новая ковариация. Через n таких процедур решение или входит в рамки окна, ограниченным доверительным интервалом или нет. На это нужно время, которое не зависит мощностей ЭВМ, а, скорее всего от частоты дискретности данных. Но и тут есть ограничения. Вспомним теорему Котельникова! Так вот. Постобработке ФК нужен не меньше чем в реальном времени, если мы хотим уточнить каждую из линеек. Золотые слова, не помню чьи: лишних измерений не бывает.
Тк. ФК один, то, подозреваю, что мы просто пользуемся разной терминологией. "Шумы" - это я так понимаю residuals ?
Под шумами я имел ввиду веса. Это те, которые на основе мат ожидания. Впрочем, residuals там же и по тому же месту
Я скажу пару слов, которые, возможно, помогут пониманию сути обсуждаемых вопросов. В калмановской фильтрации как минимум два вида шумов - шумы модели состояния и шумы измерений. Предикторная часть фильтра -целиком строится на модели состояния и ее статистических свойствах. Поэтому она может быть не очень точной. Как только появились измерения образуются разности между измерениями и их предвычисленным значением.Они называются инновационной последовательностью. Для ИП вычисляется коэффициент усиления и находится скорректированная оценка параметров состояния и ее оценка точности(ковариация). И уже для оценки фильтрации находятся остаточные уклонения(residuals). К сожалению, при последовательной обработке поступающих измерений информация о предыдущих измерениях начинает забываться и поэтому возникает задача сглаживания - оценки параметров на какой-то прошедший момент. Например, на момент срабатывания затвора камеры или оборота головки сканера, тогда как измерения составляющих положения и скорости платформы были выполнены в другие моменты. Еще один пример - устранение многозначности фазовых измерений налету(OTF). Многозначность устраняется на некоторую эпоху и используется (стареет)до эпохи проброса циклов. Для локализации проброса и оценки многозначности выполняется сглаживание измерений на эпоху нового захвата фазы, которая может быть на несколько секунд и минут позади текущих измерений. Сорри... Я увлекся. Но очень хотел растолковать.
Вот он - правильный термин, который я ошибочно обозвал "весом". Обратно к моим "баранам" - QINSy. В ней надо явно указывать, какие обсервации являются триггером для обновления состояния системы. В 100% случаев мы задавали сырые данные Тримбла, которые тогда обновлялись раз в секунду и переваривались компами того времени. Остальные наблюдения были просто вынуждены экстраполироваться на этот момент времени. ИМО с сегодняшними мощностями можно смело обновлять состояние на каждую поступающую обсервацию - пришли данные с GPS - обновились, данные с IMU - обновились и т.д. Если люди играют в танчики на 60 fps - а мы чем хуже... ))) А в постобработке, считай, вообще никаких ограничений... И в тему нашего форума, половина которого так или иначе завязана на GNSS: появился такой приёмник Trimble R12 (и R10-2 с новой прошивкой), которые ушли от концепции fixed/float и вообще работают в лесу. Из разрозненных рекламных сообщений про него складывается впечатления, что в нём запущено несколько разных уравниваний/Калманов типа комбинации разных созвездий GPS+GLONASS/GPS+Beidou и т.д., а недостоверные обсервации в каждом уравнивании отсеиваются стстистическим тестированием. Раньше это было нереализуемо (малая избыточность), но когда у вас несколько десятков спутников, сигналов и мощный CPU (как известно, самая ресурсоёмкая операция это обращение матрицы) - вполне реально. И то что они внедрили IMU только подтверждает гипотезу. QINSy 1995 года ровно этим и занималась. Тогда ещё не было RTK, да и бесполезен он в 100 км от берега. В одно уравнивание мешали сырые данные и поправки от нескольких базовых станций. Поправкам автоматически задавался вес, чем дальше станция и чем ниже спутник - тем меньше вес. Туда же гирокомпас и все прочие данные. Даже у оффсетов есть свой a-priori SD (с точки зрения LSA/Kalman это тоже обсервация, измеренная, например, рулеткой).
Конечно не может. Если знание этого параметра дано богом и в скрижали записано. А если определено статистически по выборке нарастающего объема прилично зашумленных измерений(ровер двигается в сложных условиях) так, что флуктуации разности фаз даже выходят за ширину узкой фазовой дорожки(19см для L1), то оч-ч-чень даже стареет..
Точняк! Imho, в реальном времени точности оффсетов хватает +/- метр. Что на самолёте, что на вертушке - пофиг, прибор отлично ориентируется, а то, что он кажет на дисплее да, от этих значений зависит напрямую. Ну, забыли указать наклон по pitch, ну и будет картинка или забегать или запаздывать на эту величину, или там roll будет обманывать перпенд. оси движения. Насчет этого, и про то что я говорил - ФК уточняет все линейки. В пост обработке линейку оффсетов уточняем в суб см без рулетки. На 2-3 полётах проверяем, не больше 1.5 см - дело с концом. Начинается с полуметра, на глаз и старых данных этого ВС, и за 3-4 итерации софт предлагает величины не отличимые. А, если величины оффсетов плавают, например подвес прибора шевелится, или там хвостовая балка с антенной, или ещё чего в системе gnss-imu нестабильно - пиши пропало. В одуренно грубом доверительном интервале получишь траекторию, но данные будут гуано. Проходили. Стабильные оффеты это очень очень важная штука. По сути, это измерения, как вы правильно заметили, имеющие минимальное SD. Тема с оффсетами у меня висит хоть как-то на гвоздике в мозгу, а тема с гиро- платформой выжигает его напрочь, ибо там две imu... --- Сообщения объединены, 12 апр 2020, Оригинальное время сообщения: 12 апр 2020 --- Почему выжигает поясню. Дело в том, что ins теоретически может может определить свое положение на глобусе без gnss, просто нужно будет долго ждать, и очень желательно двигаться с запада на восток и в перпенд. направлении. Не знаю как долго, может сутки, мож неделя. Гироскоп измеряет ускорения вокруг собственных осей, пытаясь сопоставить эти значения с модельными вокруг геоцентрических, это тот frame, в котором Z направлена в истинный полюс Земли и т. п. gnss ему помогает, быстро указывая где именно тот находится и решение сходится - imu1 следит за плюсом, погнали. Первоначально, посредством оффсетов все измерения сводятся в точку пересечения осей imu1. А теперь введём ещё одну imu2, которая наклоняет прибор к первому frame. Да, мы там говорим о точности наклона доли градусов, но, пфф. Сначало нужно привести frame2 к frame1... Или наоборот.. В общем тут у меня затык, как это работает... Разумеется оффсеты строительных осей прибора известны. Но когда все крутится и вертится - ужас!
В ответе на основной вопрос - какова роль калмановской фильтрации в геодезии мы пока затронули два аспекта. Во-первых, общее теоретическое обоснование системно-кибернетического подхода к решению кинематических и динамических задач в геодезии. Здесь пока весьма не густо. Во-вторых, применение калмановской фильтрации в решении навигационно-геодезических задач, когда вектор состояния измерительных комплексов объединяет составляющие положения, скорости, параметры хода часов, углы ориентации и т.п. Здесь оказалось, что программно-аппаратная реализация комплексных средств измерений целиком на поле иностранных фирм. Чтобы нашим пользователям не выглядеть мартышками с очками, приходится вникать в непростые вопросы настройки фильтров и понимать суть результатов. На мой взгляд, остались пока нетронутыми вопросы применения фильтров в решении задач геодезического мониторинга, а также фильтрация в космической геодезии - при реализации орбитального и динамического методов космической геодезии. Последнее весьма объемно и сложно. Тем не менее, уже сейчас видно, что роль калмановской фильтрации в геодезии весьма значительна. ФКБ стал не просто модной фишкой, конкурирующей с МНК, а весьма удобным средством, расширяющим арсенал методов статистического анализа результатов геодезических измерений. Число программных средств обработки геодезических измерений с использованием ФК весьма заметно. Поэтому будет правильно, если затронутая тема найдет продолжение в сообщениях форумчан. Всем успехов! Я на некоторое время должен отключиться от обсуждения.
