Создание собственной системы стабилизации
убрать из данных гиры ее собственный шум
а если читать из гиры максимально возможное количество показаний и усреднять их ? если удастся вытащить из какогото датчика хотябы реальных 8000 отсчетов то для расчетов вполне можно использовать среднее между последними несколькими отсчетами. для гонок ессно такое неприемлемо.
а если читать из гиры максимально возможное количество показаний и усреднять их ? если удастся вытащить из какогото датчика хотябы реальных 8000 отсчетов то для расчетов вполне можно использовать среднее между последними несколькими отсчетами. для гонок ессно такое неприемлемо.
Мы сравнивали опрос на высокой скорости (32кГц) и самостоятельную фильтрацию в дальнейшем (усреднение, LPF-фильтры с разными настройками) - заметной выгоды по сравнению с внутренней фильтрацией нет. Видимо, там стоит достаточно адекватные филтры, максимальная частота среза по документации 250 Гц выбрана оптимально, и если ее повышать - то данные слишком шумные. Ну и решили, что опрашивать гирик чаще чем 8кГц смысла никакого нет. PID-цикл на 1250Гц.
заметной выгоды по сравнению с внутренней фильтрацией нет. Видимо, там стоит достаточно адекватные филтры
Тоже приходил к такому заключению.
Собственно поэтому и был немного удивлен рассказам о том, что в гоночных прошивках, где считают каждую микросекунду, используют внешние программные фильтры.
Так уже всё это облизывали. Там суть не в фильтрации как таковой (усреднение, медиана и т.п. ), а сбор полного интеграла сигнала за период дискретизации АЦП. Для гонщиков, в данном случае, лучше аналоговые ДУСы с внешним устройством выборки-хранения.
Для гонщиков, в данном случае, лучше аналоговые ДУСы
Да, и в идеале, сам ПИД регулятор тоже должен быть аналоговый, никакой цифры от датчика до ШИМ мотора…,
только наверно такой “концепт” никому не нужен…
Да, и в идеале, сам ПИД регулятор тоже должен быть аналоговый, никакой цифры от датчика до ШИМ мотора
Тут как раз не обязательно, главное чтоб потерь инфы в цепочке физ.датчик-АЦП не было, а далее всё сквозное вычисление с максимальной частотой.
беру свои слова обратно - запустил я mpu6000 на 2-х килогерцах - был драйвер кривой…
Там суть не в фильтрации как таковой
Да нет, на фильтрации там тоже многое завязано. Можно сколь угодно часто дискретизовать сильно фильтрованый сигнал - толку от этого будет ноль изза большой задержки. Фактически с задержками там и борются. А в случае MPU сенсоров есть определенный оптимум частоты фильтра (о чем и речь), выше которой сам сигнал будет шумнее и меньшие задержки не дадут результата. Так вот фильтровать на той частоте в любом случае выгоднее на аппаратном уровне сенсора, а не вносить дополнительные задержки в петлю софтовой фильтрацией на уровне контроллера.
сбор полного интеграла сигнала за период дискретизации АЦП.
Так именно это делает любой алгоритм вычисления положения. Или они там собирают интеграл чаще периода дискретизации АЦП? 😃
Мы сравнивали опрос на высокой скорости (32кГц) и самостоятельную фильтрацию
Не могу понять - зачем 32 кГц ?? , если данные обновляются 2 кГц максимум…, одно о тоже чтоль считывать и потом усреднять ? , тогда конечно эффекта не будет никакого… или я че то не так понимаю ?
Не могу понять - зачем 32 кГц ?? , если данные обновляются 2 кГц максимум…, одно о тоже чтоль считывать и потом усреднять ? , тогда конечно эффекта не будет никакого… или я че то не так понимаю ?
К примеру в ICM20608 есть возможность получать данные, минуя фильтры, в том виде как их получает внутренний АЦП. А 32гКц - это его частота сэмплирования по датащиту.
Для гонщиков, в данном случае, лучше аналоговые ДУСы с внешним устройством выборки-хранения.
Не вижу отличий аналогового от цифрового. В цифровом сенсоре есть внутренний фильтр на 250 Гц, и даже при низкой частоте опроса (допустим, 1 кГц) он эффективно усреднит любые выбросы, которые будут между опросами, и в итоге получаем полный интеграл. В чем могут быть преимущества аналогового датчика, ведь с ним по сути прдется делать то же самое?
по сути придется делать то же самое
или не делать вообще … без разницы усреднять показания гиры за большой промежуток времени и вычислять по результату изменение положения за этот большой промежуток или вычислять изменение положения по каждому отсчету АЦП за время одного отсчета … в конце концов получим тоже самое положение через тоже время … считать только чаще придется … выбросы будут оказывать незначительное влияние так как будут участвовать в расчетах за малый промежуток времени … очень большие единичные выбросы можно ограничивать.
или не делать вообще … без разницы усреднять показания гиры за большой промежуток времени и вычислять по результату изменение положения за этот большой промежуток или вычислять изменение положения по каждому отсчету АЦП за время одного отсчета
Усреднять одномерным фильтром в любом случае надо, но он есть и в цифровых датчиках и работает на достаточно приличной скорости. чтобы ничего не пропустить. А запускать обсчет AHRS для сведения трех осей можно гораздо реже, думаю даже 100 Гц будет вполне достаточно.
думаю даже 100 Гц будет вполне достаточно
в подавляющем большинстве случаев более чем достаточно … но … у гонщиков всетаки есть специфика …
при обычных полетах во первых относительно низкая скорость , во вторых команды на управление от пилота идут уже с учетом текущей обстановки …
в гонках просто нет времени оценивать обстановку , команды идут фактически “на опережение” , срабатывает “мышечная память” , те задача контроллера максимально четко выполнить команды заданные перемещениями стиков , а поскольку скорость полета очень большая , то даже минимальная задержка сильно меняет траекторию.
Но и 32 килогерца это уже всетаки перебор …
Вот выдержка из описания по бетафлайту:
Boris said:
gyro_lpf = OFF basically still means there is a little bit of filtering on the gyro. When setting it to EXPERIMENTAL it will remove any possible filtering and give raw data, which is extremely noisy. I don’t recommend it. I just added it to be there in case someone wants to play with it.
Тоесть сам гуру бетафлайта не советует выключать в мпу фильтр. Тоесть фактически рекомендуется фильтровать выходной сигнал на 188Гц либо 250Гц. Откуда мне лично не совсем понятна гонка килогерцев.
Опять 25 выборка и фильтр самого MPU - это разные люди. Т.е. есть сигнал с частотой допустим в 1 герц и в нём ещё один с частотой 300гц - так вот тот сигнал в 1 герц мы порубали на 1000 кусочков и собрали в интеграл - и он там есть весть а 300гц сигнал - удушили фильтром и в интеграл не пустили - нам нужна вся 1000 кусочков герцового сигнала…
нам нужна вся 1000 кусочков герцового сигнала…
Вот ну никак не следует этот вывод из того что сказано.
Вспомним теорему найквиста - теоретически достаточно выборки с удвоеной максимальной частотой в спектре сигнала для его восстановления. Возможно какуюто минимальную разницу и можно будет ощутить при переходе от 500 к 1000-2000Гц частоте выборки при сборе интеграла при неизменной частоте фильтра сигнала. 8-32КГц - это уже скорее для собственного успокоения, мол сделали все что могли, плюс, как водится у спортсменов - “быстрее, выше, сильнее!”.
Вот что скорее всего помогает, так это минимизация задержки с начала чтения сенсора до получения результата на регуляторе. Сдается мне, что при одинаковой этой задержке разницы между 500Гц и 2000Гц петли не будет заметно вообще.
Ха - допустим датчик засёк ну ни максимум, а скажем 1000 гр/сек - за цикл при 500 это уже 4 градуса исправлять, а при цикле в 2000 - 0.5 градуса - где погрешность пида будет больше? где какая задержка? если цикл в одном случае 2000 микросекунд, а в другом 500?
Так при любой частоте петли с датчика считаем те же самые 1000°/с, откуда тут возьмутся ошибки?
Но ок, тогда следуя этой логике какие же тогда ошибки будет давать тот самый рекомендованый мпушный фильтр в 250Гц или также используемые 188Гц? 😃
задержка по времени от считывания до подачи на регулятор 2000 микросекунд и приказ пиду исправление 4 - х градусов (зная что есть ошибка интегрирования) или 500 микросекунд и приказ на полградуса - что точнее?
а ведь рейсерам надо порхать как бабочка пчелой ужаленная)))
жена и вправду думала, что у нас во дворе осы завелись )))
да и вот - во время пересчёта муха в проп попала - мелочь но приятно - 4 предположительных! градуса превратились в 5 - а 0.5 пусть даже в 0.6 - при следующих итерациях, что быстрее исправится?
Если честно вообще не понял вопроса… Речь о задержке или о точности? Мухи в пропеллере? Ужаленая жена? 😃 Сформулируйте пожалуйста яснее.
Во вторых это какаято странная математика 2000/4 ≠ 500/0.5. Правильнее тогда уже на 2000мкс будет 4° ошибки, а на 500мкс - 1°.
Но ок, возьмем что моторам нужно исправить 1° за 500мкс - а успеют ли они вообще это сделать за такое время? Или проще исправить 4° за 2000мкс?
PS. Не фанат подобных разговоров, плавно (или не очень) перетекающих в выяснение отношений. Я насколько возможно аргументировано высказал свое мнение, для чего собственно этот форум и предназначен. Если разговор перетекает из конкретики в мухи, бабочки, пчелы, осы - я не вижу смысла его продолжать.
А я и не лезу в выяснение отношений - просто вы сами себе перечите - ну как может быть одинаковой задержка между считыванием и подачей на регуль при времени цикла 2000 или 500 - не 4 ну да я чёт загнался - 2 градуса - но это не точно 2 градуса, и исправлять надо 2 градуса - а за это время при времени цикла в 500 - 4 по 0.5 успеть можно… но если же подойти с не рейсерской стороны - пропы маленькие обороты большие, а к нормальным аппаратам - чем ниже скорость вращения моторов, выше инерция самих ВМГ, а следовательно ниже скорость влияния изменения частоты вращения на положение аппарата - то и смысла особого нет в завышенной частоте цикла - короче какой бы не была частота, читаем - считаем - пид - регуль - ваншот получается…