Создание собственной системы стабилизации
у нас маленькие ракеты сбивали маленькие самолеты на больших дистанциях во времена, когда к микросхемам прилагался ящик для переноски. на компьютерах, которые слабее и медленнее нынешних калькуляторов, летали на Венеру.
так что перестаньте жаловаться на “шумы” и идите работать (с) ;)
ракеты сбивали маленькие самолеты
Согласен, но и датчики положения были сделаны мягко говоря по другой технологии и мягко говоря из других материалов…
Тут же вопрос конкретный… есть пожелания ? советы ? (кроме идти… и работать…)
конечно есть — использовать для измерения физ. величин специально созданные для этого датчики: глонасы, датчики воздушной скорости, ультразвуковые/лазерные дальномеры.
вот по поводу жалобы, “нет никакой информации с датчика ускорения чтоб обнулить или остановить рост интеграла”. я нигде не видел, чтобы показания акселя имели некий весовой коэф. “доверия”, все берут его показания независимо от текущих пере-/недогрузок и “исправляют” результат с гиры. почему никто не “доверяет” акселю в моменты, когда измеренное им ускорение ~= G и не “слушает его совсем” когда там наизмеряли 4-8-16G?
я нигде не видел, чтобы показания акселя имели некий весовой коэф.
Кусочек рабочего кода двумя страницами выше:
// By using CF it’s possible to correct the drift of integrated accZ (velocity) without loosing the phase, i.e without delay
vel = vel * 0.985f + baroVel * 0.015f;
Обращаю внимание на то “vel” - скорость взятая именно с акселя (интеграл), а “baroVel” - скорость высчитанная из показаний барометра. Таким образом “капризный” интеграл от ускорения имеет основной вес и сглаживается непосредственно барометром…
Метод работает, НО у MS5611 достигнут собственный дрейф в 10-15 см. и от акселя толку уже практически никакого, вся эта математическая каша не может дать более точного результата с меньшим шумом…
Эту мысль я и озвучил, проделав эксперименты, а вовсе не “жаловался” на тяжелую жизнь 😃…
вот о чем и речь. барометром “поправляем” ось Y модели взятую с акселя, которая была расчитана с гироскопа и “поправлена” акселем же. а то что аксель при любом измерении не равном G неправильно “поправляет” гироскоп забыли?
у MS5611 достигнут собственный дрейф в 10-15 см
почему вы считаете что это дрейф, а не атмосфера вокруг? ветер дунул, температура изменилась, влажность повысилась — вот и изменение давления на ровном месте.
Эту мысль я и озвучил, проделав эксперименты, а вовсе не “жаловался” на тяжелую жизнь
0.994 0.06 😃 надо с коэфф баловаться, желательно постоянно в зависимости от прогноза(не гидрометцентра)… барометр нужен для коррекции если шум акселя в один бок… спрогнозировать датчик можно где-то с вероятностью разброса 68% если показания вышли за вероятность, то тупо уменьшать вес датчика - в конечном счёте если датчик нагло врёт - исключать из расчётов…
при любом измерении не равном G неправильно “поправляет” гироскоп забыли?
Чуток не так, коллега…,: за ускорение по оси Z принимается разница из “сырых” данных Z акселя и вектора G рассчитанного IMU, таким образом имеем “чистое” вертикальное ускорение при любом наклоне аппарата…
А уж потом интегрируем его и получаем скорость… а потом и расстояние (второй интеграл)…
почему вы считаете что это дрейф,
Точнее сказать - “шум”, , во первых паспорт на 5611, во вторых очевидная вещь при наблюдении графика в динамике (пользуюсь Pithon_ом), какие могут быть сомнения ?
надо с коэфф баловаться,
Так вот у меня получилось (?) что баловаться нет смысла, т.к. получить на выходе меньший “шум” чем просто с барометра не выходит… (есть предположение что алгоритм был разработан для “дубовых” барометров)…
эх блин… приведу еще пример - маховий прошивка, там как раз основное по расчету высоты - аксель, лично у меня не раз было что держал одну высоту по 10-15 мин, причем не в висении, а в полете
маховий прошивка, там как раз основное по расчету высоты - аксель
Нельзя ли на этот кусочек кода взглянуть ?? (для анализа)
за ускорение по оси Z принимается разница из “сырых” данных Z акселя и вектора G рассчитанного IMU
а IMU-то откуда данные берет? интегрирует гиру и исправляет ее дрейф показаниями акселя, которому можно доверять только когда он находится в покое.
в OP когда-то мелькала эта фишка: гира интегрируется как обычно, но чем больше цифра с акселя отличается от 1G (в любую сторону), тем меньше он участвует в коррекции гиры. образно говоря, введен динамический “коэффициент доверия” примерно так:
len = accel.lenght()
// 0 <= k <= 1
if (len > G)
k = G / len
else
k = len / G
result.x = gyro_integrated.x*(1-k) + accel.x*k
// и так далее
Точнее сказать - “шум”
шум так шум.
смотрю в даташит на MS5611, 24 бита, диапазон 10…1200 мбар, считаю разрешение — 0.000071 мбар.
они пишут сначала 0.0024, затем через строчку 0.012, как так?
Нельзя ли на этот кусочек кода взглянуть ?? (для анализа)
// apply CF with dynamic coefficient to keep the calculated altitude near real baro/sonar altitude
uint16_t altDiff = abs(alt - EstAlt);
dynK = 0.015f + ( ((altDiff > 100) && (EstAlt > 0)) ? (min(altDiff - 100, 500)/10000.0f) : 0.0f );
alt = alt * (1.0f - dynK) + sensorAlt * dynK;
это финишный кусок
они пишут сначала 0.0024, затем через строчку 0.012, как так?
Эт надо еще и в высоту пересчитывать, а там логарифмы и прочее…(лень) , короче, точность MS5611 меньше метра, это общепризнанный экспериментально доказанный факт, в отличие например от BMP85… (тут погрубее)
а IMU-то откуда данные берет?
В нашем случае это не важно, главное что на выходе мы имеем “приличный” вектор G (“гира рулит”), который и нужно вычесть из оси Z акселя… Да, так и получается, сначала Z-acs участвует в коррекции гиры в IMU, а потом из нее же и вычитается полученное G…
baro/sonar
Смущает сие… (мы о баро/аксель ведем речь)
Смущает сие… (мы о баро/аксель ведем речь)
не смущайтесь - сие только при включении сонара, который подмешивается к баро
это финишный кусок
Из представленного кода понял, что как раз используется плавающий коэфициент с предсказанием и одновременным ограничением диапазона… К сожалению неясно как считается сам “alt” и “EstAlt”…, буду “копать” источники…
c 0.46 GPS в удержании высоты не учавствует
на побаловаться www.cs.utexas.edu/~teammco/misc/kalman_filter/
GPS в удержании высоты не учавствует
Я так понял (из собственных экспериментов в полете) что GPS надежно и правильно выдает только координаты, остальные показания (высота, азимут, скорость) в разные непонятные промежутки времени могут произвольно скакануть как угодно…, нужно сильно поломать голову чтоб исключить такие ситуации…
Короче придется мне все ж магнитометр то возвращать на плату 😦 - он хотя бы стабильный, наверно замахнусь на BMX055.
на побаловаться www.cs.utexas.edu/~teammco/misc/kalman_filter/
Сергей, а можно в двух словах, что там ?
А то кроме линии, идущей за курсором, пока ничего не понятно.
Там специально входной шум задан - дабы прицел сбить 😃 точь та же байда что и в курсе…
X-Axis Random Noise: Y-Axis Random Noise: - это шум…
Там специально входной шум задан - дабы прицел сбить 😃 точь та же байда что и в курсе…
X-Axis Random Noise: Y-Axis Random Noise: - это шум…
Ну да, с этим разобрался уже.
Кстати, если в первой матрице вместо 0.2 поставить 0.11, то будут точнее показания.
А вот изменение коэффициентов во 2-й матрице ни на что не влияет, что странно.
Основная проблема со всеми этими фильтрами в том, что не показывается каким образом получить эти самые матрицы. А дают уже готовые по принципу “вот вам матрицы - поиграйтесь с коэффициентами”.
Ну поигрались, а дальше что, как на практике применить, имея конкретные датчики?
Взять тот же курс, который сейчас преподает TUM. В начале курса была надежда на то, что они взяв конкретный аппарат (Ar. Drone) на его примере расскажут как получить мат. модель, как получить матрицы состояний и т.д. А они выдают общую информацию по каждой теме и все.
А вот изменение коэффициентов во 2-й матрице ни на что не влияет
а она не используется
c = [0, 0, 0, 0] ← control vector (not used here)