Можно использовать, да зная массы, моменты инерций и текущую тягу моторов рассчитывать кинематику (ускорения, скорости), но: 1) сами движения коптера, зависят не только от системы управления, но и от ветра, или каких-то изменений среды, плотность воздуха, или внешних возмущений, которых никак нельзя предсказать, в таком случае, это будет мешать 2) появляется обратная связь - навигация опирается на то, что выдает система управления, а система управления опирается на, что что выдает навигация - может все развалиться 3) При наличии IMU (угловые скорости и ускорения) - уже есть реальная кинематика.
Спасибо. Кстати, в среде использующих методы нелинейной оптимизации, давно появилась крутая фича - автопроизводные. Это фича основана на переопределении типов и операторов. То есть саму нелинейную функцию мы записываем также в прямом виде, не рассчитывая матрицу Якоби или Гессе в ручную, но используем специальный тип переменных в выражениях. Алгоритм нелинейной оптимизации уже используя этот тип и переопределения операторов рассчитывает матрицы Якоби и Гессе сам! В Ceres Solver (один из фреймворков для работы с нелинейной оптимизацией), например, этот тип называется Jet. Вообще, тема с автопроизводными - крутая! Не знаю, может кто-то и придумал уже EKF с автопроизводными.
Понял, да, тут вы правы, сам ФК - это линейный алгоритм и он предполагает, что матрица F, H - константы. В самом простом случае, в версии фильтра придуманном самим Калманом, F, H - действительно постоянные матрицы. Для нелинейных систем придумали EKF, UKF фильтры, которые тоже по своей сути линейны, но линеаризацию производят каждый шаг, после чего получаются те же матрицы F, H и используются те же уравнения, что в линейном ФК. И да, линеаризация уже сама по себе своего рода костыль, в сильных нелинейных моделях, фильтр имеет расхождения и может даже развалиться. Я когда-то читал, что были версии ФК с линеаризацией с захватом большего числа порядка производных (помимо матрицы Якоби еще и Гессиан, а в случае UKF - большего числа сигма точек чем 2n+1), но широкого распространения они не нашли.
Да, единицы забыл подписать, косяк. Для всех графиков горизонтальная ось - ось времени в секундах. Вертикальные оси: для графика вектора смещений ДУСа - рад/сек; вектора смещений акселерометра - метр/сек/сек; углы Эйлера - градусы; вектор положения - метры; вектор скорости - метр/сек. Вообще да - если объект стоит - то рассчитываемый ФК угол курса может уплывать, неопределенность увеличивается. Углы тангажа и крена при этом наблюдаемы из акселерометра и их неопределенность при этом не увеличивается. На графиках неопределенность выросла в том числе - из-за того, что я увеличил дисперсию шума GNSS и коррекция стала меньше, из-за чего неопределенность увеличилась - этот промежуток на видео 1:20 - 2:25. Про константу не совсем понял - если вы говорите про то, что объект не меняет свое состояние (положение, скорость, ориентацию) - то да, константа, но смещения акселерометра и ДУСа могут уплывать (не сами расчетные значения в векторе состояния, а именно смещения в датчиках), ФК при этом будет стараться подгонять рассчитываемые оценки смещений под реальные с датчиков. В Unity можно в ручную изменить bias у IMU и посмотреть что будет.
Спасибо за комментарий, наверное я недостаточно пояснил свою мысль. Хотел прояснить разницу классических фильтров и ФК в контексте, например задачи навигации. Экстраполяцию и предсказание траектории можно также выполнить комбинациями ФВЧ и ФНЧ фильтров. Самый простой пример - получаем позицию с GPS, дифференцируем ее - получаем скорость, на основе которой можно также предсказывать и экстраполировать. Однако ключевая особенность ФК перед классическими фильтрами, то что в алгоритмах на основе классических фильтров все зависимости и выводы записаны в прямом аналитическом виде, в то время как ФК некоторые взаимозависимости находит сам, разработчик напрямую их не записывает (то есть формулу ориентация = f(GPS позиция) я нигде не записывал, ФК сам нашел эту взаимосвязь). Естественно ФК - это не панацея, и для разных задач подходит свой инструмент.
есть куча ботов в телеге, например gpt3_unlim_chatbot, вот статья на пикабу про обзор https://pikabu.ru/story/testiruyu_chatgpt_botov_v_telegram_zastavlyayu_ii_reshat_zadachki_9859191
надеюсь меня не забанят за псевдо рекламу, если что я удалю комментарий)
Спасибо за статью, а насколько быстро происходит распознавание по каждому этапу?
Можно использовать, да зная массы, моменты инерций и текущую тягу моторов рассчитывать кинематику (ускорения, скорости), но: 1) сами движения коптера, зависят не только от системы управления, но и от ветра, или каких-то изменений среды, плотность воздуха, или внешних возмущений, которых никак нельзя предсказать, в таком случае, это будет мешать 2) появляется обратная связь - навигация опирается на то, что выдает система управления, а система управления опирается на, что что выдает навигация - может все развалиться 3) При наличии IMU (угловые скорости и ускорения) - уже есть реальная кинематика.
Спасибо. Кстати, в среде использующих методы нелинейной оптимизации, давно появилась крутая фича - автопроизводные. Это фича основана на переопределении типов и операторов. То есть саму нелинейную функцию мы записываем также в прямом виде, не рассчитывая матрицу Якоби или Гессе в ручную, но используем специальный тип переменных в выражениях. Алгоритм нелинейной оптимизации уже используя этот тип и переопределения операторов рассчитывает матрицы Якоби и Гессе сам! В Ceres Solver (один из фреймворков для работы с нелинейной оптимизацией), например, этот тип называется Jet. Вообще, тема с автопроизводными - крутая!
Не знаю, может кто-то и придумал уже EKF с автопроизводными.
Понял, да, тут вы правы, сам ФК - это линейный алгоритм и он предполагает, что матрица F, H - константы. В самом простом случае, в версии фильтра придуманном самим Калманом, F, H - действительно постоянные матрицы. Для нелинейных систем придумали EKF, UKF фильтры, которые тоже по своей сути линейны, но линеаризацию производят каждый шаг, после чего получаются те же матрицы F, H и используются те же уравнения, что в линейном ФК.
И да, линеаризация уже сама по себе своего рода костыль, в сильных нелинейных моделях, фильтр имеет расхождения и может даже развалиться.
Я когда-то читал, что были версии ФК с линеаризацией с захватом большего числа порядка производных (помимо матрицы Якоби еще и Гессиан, а в случае UKF - большего числа сигма точек чем 2n+1), но широкого распространения они не нашли.
Да, единицы забыл подписать, косяк. Для всех графиков горизонтальная ось - ось времени в секундах. Вертикальные оси: для графика вектора смещений ДУСа - рад/сек; вектора смещений акселерометра - метр/сек/сек; углы Эйлера - градусы; вектор положения - метры; вектор скорости - метр/сек.
Вообще да - если объект стоит - то рассчитываемый ФК угол курса может уплывать, неопределенность увеличивается. Углы тангажа и крена при этом наблюдаемы из акселерометра и их неопределенность при этом не увеличивается. На графиках неопределенность выросла в том числе - из-за того, что я увеличил дисперсию шума GNSS и коррекция стала меньше, из-за чего неопределенность увеличилась - этот промежуток на видео 1:20 - 2:25.
Про константу не совсем понял - если вы говорите про то, что объект не меняет свое состояние (положение, скорость, ориентацию) - то да, константа, но смещения акселерометра и ДУСа могут уплывать (не сами расчетные значения в векторе состояния, а именно смещения в датчиках), ФК при этом будет стараться подгонять рассчитываемые оценки смещений под реальные с датчиков. В Unity можно в ручную изменить bias у IMU и посмотреть что будет.
Спасибо за комментарий, наверное я недостаточно пояснил свою мысль. Хотел прояснить разницу классических фильтров и ФК в контексте, например задачи навигации. Экстраполяцию и предсказание траектории можно также выполнить комбинациями ФВЧ и ФНЧ фильтров. Самый простой пример - получаем позицию с GPS, дифференцируем ее - получаем скорость, на основе которой можно также предсказывать и экстраполировать. Однако ключевая особенность ФК перед классическими фильтрами, то что в алгоритмах на основе классических фильтров все зависимости и выводы записаны в прямом аналитическом виде, в то время как ФК некоторые взаимозависимости находит сам, разработчик напрямую их не записывает (то есть формулу ориентация = f(GPS позиция) я нигде не записывал, ФК сам нашел эту взаимосвязь). Естественно ФК - это не панацея, и для разных задач подходит свой инструмент.