Создание собственной системы стабилизации
у ламп, в отличии от полупроводников, вольтамперная характеристика линейная и до сих пор профф оборудование на лампах - даже микрофоны
С изобретением обратной связи линейность уже не так актуальна (впрочем есть и вполне линейные усилители A, AB класса), а с изобретением ШИМ-усилителей транзисторные вообще вне конкуренции. Прецезионные усилители сенсору есть смысл ставить только если его точность выше точности “обычного” операционника. А я сильно сомневаюсь что MEMS имеют высокую точность. В датащитах нелинейность точно больше 1% а шумит просто ужас - так накой ему точный и малошумящий операционник с 10-ым знаком ошибки после запятой?
вычислять изменение положения по каждому отсчету АЦП за время одного отсчета .
только так
в конце концов получим тоже самое положение через тоже время
с учетом погрешности датчика и вычислений
Усреднять одномерным фильтром в любом случае надо, но он есть и в цифровых датчиках и работает на достаточно приличной скорости. чтобы ничего не пропустить. А запускать обсчет AHRS для сведения трех осей можно гораздо реже, думаю даже 100 Гц будет вполне достаточно.
Вполне вариант, но опять же нельзя пропускать отсчеты датчика, и при быстрых маневрах будет накапливаться “неучтенка” взаимовлияния осей между расчетами ориентации.
теоретически достаточно выборки с удвоеной максимальной частотой в спектре сигнала
Это теорема Котельникова
Так при любой частоте петли с датчика считаем те же самые 1000°/с, откуда тут возьмутся ошибки?
например, пропустили 2 отсчёта. Взяли в расчет 0 гр/сек, потом быстро дернули креном -650 гр/с и обратно 605 гр/с, потом пришла петля и взяла опять 0гр/с. Интегратор угла покажет 0гр, а на самом деле будет -45гр. Потому я пишу, что нужно собирать ВСЕ отсчеты физ.датчика, если не хватает скорости проца, то виде интеграла между расчетами (в т.ч. аналоговым интегралом).
у ламп, в отличии от полупроводников, вольтамперная характеристика линейная
Не только, у них нелинейность весьма “круглая” и адаптивная (при длительной перегрузке каскад “сползает” в линейный участок), а у ПП нелинейность “острая” - “клыки” ( у биполярных), и “квадратная” у полевых - насыщение.
Это теорема Котельникова
Сори, это было не патриотично 😃
например, пропустили 2 отсчёта. Взяли в расчет 0 гр/сек, потом быстро дернули креном -650 гр/с и обратно 605 гр/с, потом пришла петля и взяла опять 0гр/с. Интегратор угла покажет 0гр, а на самом деле будет -45гр.
Так вот возвращаясь к теореме Котельнкова - если на мпушке использовать фильтр (188Гц или 250Гц, как советует главный разработчик) то как бы мы не дергали, считывая с нее данные с периодом соответсвующим >500Гц (тоесть начиная с удвоеной максимальной частоты в выходном спектре сигнала 188Гц или 250Гц) мы учтем все те всплески, вызваные дерганьем.
Глобальная особенность тут в другом - разработчики и пользователи говорят на разных языках. Например, продвинутый пользователь залил последнюю прошивку с новой в два раза большей частотой петли, чуток поднапрягся, сделал пару красивых флипов и пролетов (ну а как иначе, он же продвинутый пользователь 😃 ) - значит повышеная частота работает и это уже закон! И никакие теоремы тут не докажут обратного 😃
А уж если разговор о бизнесе, то против законов тем более не попрешь 😉
Глобальная особенность тут в другом - разработчики и пользователи говорят на разных языках.
Не пользователи, а маркетологи. Выдергивают громкие фразы (“быстрей, выше, сильней!”) из речей разработчиков и вставляют в рекламные слоганы.
сделал пару красивых флипов и пролетов (ну а как иначе, он же продвинутый пользователь ) - значит повышеная частота работает и это уже закон!
Золотые слова… Чистота эксперимента и анализ результатов зачастую вызывают сомнения,
или выдаётся желаемое за действительное… всёж теорию/мат часть знать надо, и почаще к ней обращаться.
на самом деле все зависит от характеристик самого коптера … а именно от того какие максимальные угловые ( да и линейные тоже) ускорения может обеспечивать аппарат …
чем больше ускорения , тем чаще имеет смысл проводит расчеты и выдавать команды на управление …
так что по мере миниатюризации (снижении массогабаритов) , а также повышении эффективность моторов , регулей , аккумуляторов реально необходимая частота циклов обработки будет расти …
ак что по мере миниатюризации (снижении массогабаритов) , а также повышении эффективность моторов , регулей , аккумуляторов реально необходимая частота циклов обработки будет расти …
Совершенно так. Сам с проблемой недостаточной скорости регулей столкнулся только на 150м размере, 550й летал на 50Гц стандартных ХК-регулях.
F7BY начало )))
cloud.mail.ru/public/Cy9u/YM6tS559M
F7BY начало )))
Лучше сразу ARM11BY… чтоб, так сказать, “на пике прогресса”…
Привет, единомышленники! спустя год работы от начала освоения стм32 и освоения алгоритмов коптеров мне удалось наконец осуществить свою мечту - создать собственный контроллер коптера. Сразу говорю, что летает он ни чуть не лучше, а местами и хуже коммерческих аналогов. Вообщем то получен огромный опыт в отладке, программировании, поиске проблем и многом другом. Математика довольно простая, никаких фильтров Калмана (следующий этап), в основе простые П, ПИ регуляторы компенсирующие дрейф относительных датчиков абсолютными датчиками.
Теперь по платформе - летает все это на плате STM32F407Discovery, ДУС/акселерометр - MPU6500, барометр - MS5611, магнитометр - HMC5883l, ЖПС/ГЛОНАСС датчик - Ublox Neo 8n. Дополнительно установлен Bluetooth передатчик/приемник для связи с землей, Buzzer, SD-карта для записи логов. Организация логов такова - каждый интересующий меня блок пишется в свой файл в бинарном виде, разбивается по времени, с разной частотой. Платформа летает под FreeRTOS.
Хотелось бы отдельное спасибо сказать Александру Русакову (rual) за большущую помощь и подсказки в начале пути!
Несколько видео:
летает он ни чуть не лучше, а местами и хуже
Судя по видео, аппарат весьма достойно “цепляется” и за GPS и за горизонт, так что не надо скромничать…), если софт рукотворный и написан за год, то вообще просто гениально…
Привет, единомышленники! спустя год работы от начала освоения стм32 и освоения алгоритмов коптеров мне удалось наконец осуществить свою мечту - создать собственный контроллер коптера. Сразу говорю, что летает он ни чуть не лучше, а местами и хуже коммерческих аналогов. Вообщем то получен огромный опыт в отладке, программировании, поиске проблем и многом другом. Математика довольно простая, никаких фильтров Калмана (следующий этап), в основе простые П, ПИ регуляторы компенсирующие дрейф относительных датчиков абсолютными датчиками.
Теперь по платформе - летает все это на плате STM32F407Discovery, ДУС/акселерометр - MPU6500, барометр - MS5611, магнитометр - HMC5883l, ЖПС/ГЛОНАСС датчик - Ublox Neo 8n. Дополнительно установлен Bluetooth передатчик/приемник для связи с землей, Buzzer, SD-карта для записи логов. Организация логов такова - каждый интересующий меня блок пишется в свой файл в бинарном виде, разбивается по времени, с разной частотой. Платформа летает под FreeRTOS.
Хотелось бы отдельное спасибо сказать Александру Русакову (rual) за большущую помощь и подсказки в начале пути!
Здорово.
А как ваша система ведет себя в АТИ режиме ?
Если возможно сделайте видео АТИ режима.
АТИ интересует так как это наиболее сложный режим работы.
Заранее спасибо.
Судя по видео, аппарат весьма достойно “цепляется” и за GPS и за горизонт, так что не надо скромничать…), если софт рукотворный и написан за год, то вообще просто гениально…
есть некоторые моменты, например небольшие колебания, перерегулирования, унитазинг, а в конце одного из видео аппарат вообще потерял устойчивость (сейчас уже поправил), у visasta летает идеально, к тому же еще в 2012.
Здорово.
А как ваша система ведет себя в АТИ режиме ?
Если возможно сделайте видео АТИ режима.
АТИ интересует так как это наиболее сложный режим работы.
Заранее спасибо.
Под АТИ режимом понимается простое управление угловым положением? в Арду он зовется Stabilize - он проще режима удержания позиции и высоты. Другое дело, что его надо тщательно настроить, вот в этом вся сложность.
Видео есть еще полугодичной давности
Управление высотой, но наклон аппарата контролируется непосредственно стиком пульта
Платформа летает под FreeRTOS.
Ваши оценки системы: задержка прерываний, надежность, сложность в настройке ??? ну и вообще впечатления…
(я мучаю CoOS, поэтому интересно сравнить…)
Даже сравнить не с чем, вся моя работа с FreeRTOS -это несколько задач и прием и передача семафоров. Мьютексов, таймеров, динамической памяти я не юзал. По надежности ну у меня иногда зависало, но это 99 процентов мои косяки. По началу были глюки, но потом разобрался, что нужно следить за стеком задач, объемом кучи и тд. Эта РТОС достаточно популярна, так что любые баги выявляются быстро, я б сказал что надежна. Ставится легко. Но из всей работы фриртос была одной из самых простых во многом благодаря Курницу. Задержки прерываний есть, но я не замерял. Не представляю задачи, где будут ощутимы на работе задержки ядра РТОС. При том, что в моем проекте ядро имеет наибольший приоритет среди прерываний.
У меня тут идея возникла. Что можно полностью отказаться от магнитометра и акселерометра в перспективе (для коррекции горизонта). Вот если посудить что магнитометр, что акселерометр всего лишь вносят небольшую коррекцию в угловую скорость ДУСа, а по факту вносят еще и шумы и ошибку, связанную с неравномерным магнитным полем, магнитными полями от тока в случае магнитометра, линейные ускорения в случае акселерометра. Так вот если так посудить, то коррекцию угловой скорости ДУСа может выполнять любой другой АБСОЛЮТНЫЙ датчик ориентации. Идея такая - есть ЖПС датчик на борту, есть ЖПС датчик у оператора, по радиоканалу на борт передаются координаты оператора. В мозге аппарата есть свои координаты и координаты оператора, соответственно можно построить ТРЕХМЕРНЫЙ вектор, который как раз и будет служить корректирующим для скорости гир. Если применить технологию RTK для ЖПС то можно еще и отказаться от акселерометра. Может я ошибаюсь где то, как вам идейка?
Может я ошибаюсь где то, как вам идейка?
без акселя и компаса мне как-то плохо представляется переход из локальных координат к глобальным, если при движении ешё можно отказаться от компаса то в висении он нужен… а акселерометр по-моему ничему не мешает особенно при использовании либо отдельных датчиков, либо как в тех же 6500 - 9250 настраиваются они отдельно, и если с ДУС-ов мы може мзять те же 8 килогерц то аксель можно “зажать” по самое небалуйся…
и вообще у меня создаётся впечатление, что траблы с компасом преследуют только арду, хотя например в либрепилоте и таулабсе калибровка компаса вообще никакая… если кто не в курсе я добавил (сделал HAL и попросил добавить) F4BY в betaflight - выйдет в 3.0 релизе, так вот там компас намного лучще работает, и это без всяких страшных слов типа EKF… и ешё пытал betaflight чисто на 9250 без компаса и барометра - довольно приятно управляется и высоту “держит” без барометра… конечно не держит, но не дёргается как арду в стабе - вечно стиком дёргай…
Может я ошибаюсь где то, как вам идейка?
GPS это датчик не ориентации, а положения. Вне зависимости от положения и угловых скоростей коптера координаты коптера и оператора не поменяются, если коптер не меняет положения.
Плюс к тому, как быть, если GPS “потерялся” или врет?
Компас, при правильном его использовании довольно точный инструмент, про аксель я вообще молчу. Кстати, аксель - критически важная штука не только для ориентации, но и для ИНС.
Вы меня не поняли, магнитометр очень капризная штука, неровное его расположение будет давать перекосы в ориентации при наклонах аппарата, влияние наводок от токов тоже вносит лепту, к тому же чем сложнее система тем меньше надежность… У меня до сих пор затыки с компасом, хотя он на ножке стоит.
Акселерометр в ИНС я не собирался выкидывать, я же написал, что только для коррекции горизонта, я его не хочу использовать. Я же не пустыми словами кидаюсь, я сам все это прощупал…
У меня стоит датчик MPU6500 у него отдельные фильтры на гиру и на аксель… Хоть сколько аксель не зажимай - от линейных ускорений не избавиться, которые будут вносить ошибку в ориентацию.
GPS это датчик не ориентации, а положения
Вот прочтите еще раз. Две пары координат а значит есть вектор.
Идея такая - есть ЖПС датчик на борту, есть ЖПС датчик у оператора, по радиоканалу на борт передаются координаты оператора. В мозге аппарата есть свои координаты и координаты оператора, соответственно можно построить ТРЕХМЕРНЫЙ вектор, который как раз и будет служить корректирующим для скорости гир
Вектор - а значит есть направление. значит есть ориентация, причем АБСОЛЮТНЫЙ датчик.
Плюс к тому, как быть, если GPS “потерялся” или врет?
Если правильно его использовать то он не врет. У меня удержание высоты кстати только по ЖПС, без барометра. Почитайте про RTK, и вопрос о потере и вранье отпадет.
Напомню как работают большинство фильтров ориентации: берется реальный вектор (ускорения свободного падения, магнитного поля Земли или любой другой) с абсолютного датчика и сравнивается с виртуальным вектором, то есть продуктом этого фильтра, далее в зависимости от строения фильтра, рассмотрим фильтр Махони эта разность векторов поступает в ПИ регулятор, а его выход в скорости с ДУСа, после чего инегрируется до положения, потом снова выделяется интересующий нас виртуальный вектор и тд и тп.
Так вот абсолютный вектор с пары ЖПС датчиков у нас есть. А виртуальный строится чисто геометрически исходя из проинтегрированных скоростей с ДУСов и положения коптера. Примерно понятно?
Но тут я не до конца представляю все это у себя в голове, вот и спрашиваю.
обращаю еще раз внимание на то что, в расчет идет не просто координаты аппарата, а координаты оператора, то есть уже вектор.
Вот прочтите еще раз. Две пары координат а значит есть вектор.
Вектор-то есть, но толку от него… Вот представьте себе, у дома координаты, допустим (0;0;0), у коптера (10;10;5). Как повернут коптер? Как он наклонен? Я знаю где он находится относительно дома, но я ничего не знаю об ориентации самого коптера в пространстве, потому что независимо от углов крена GPS позиция оператора и коптера будет та же самая.
Фокус с магнитным полем и гравитацией в том, что направление этого вектора в система координат ЛА зависит от ориентации ЛА в пространстве. В случае с GPS ЛА и GPS дома, направление вектора от ориентации ЛА в пространстве никак не зависит.
Вы меня не поняли, магнитометр очень капризная штука, неровное его расположение будет давать перекосы в ориентации при наклонах аппарата, влияние наводок от токов тоже вносит лепту, к тому же чем сложнее система тем меньше надежность… У меня до сих пор затыки с компасом, хотя он на ножке стоит.
Правильная коррекция нуля и проблем нет. Как его на ножку не выноси, если ноль скорректирован неверно, компас будет врать. Плюс ко всему, магнитный вектор с магнетометра надо развернуть в плоскость земли - если этого не делать, направление будет плавать.
У меня стоит датчик MPU6500 у него отдельные фильтры на гиру и на аксель… Хоть сколько аксель не зажимай - от линейных ускорений не избавиться, которые будут вносить ошибку в ориентацию.
Правильная калибровка (нуля и масштаба) и фильтровать все что значительно отличается от 1G.
Если правильно его использовать то он не врет.
GPS врет по определению на несколько метров. Плюс позиция плавает на те же несколько метров. Плюс иногда GPS отключают для обслуживания над некоторыми областями.
Вектор-то есть, но толку от него… Вот представьте себе, у дома координаты, допустим (0;0;0), у коптера (10;10;5). Как повернут коптер? Как он наклонен? Я знаю где он находится относительно дома, но я ничего не знаю об ориентации самого коптера в пространстве, потому что независимо от углов крена GPS позиция оператора и коптера будет та же самая.
Фокус с магнитным полем и гравитацией в том, что направление этого вектора в система координат ЛА зависит от ориентации ЛА в пространстве. В случае с GPS ЛА и GPS дома, направление вектора от ориентации ЛА в пространстве никак не зависит.
Вот это золотые слова вот в этом есть доля правды, Но тут есть небольшой момент. Тут просто вектора немного отличаются в том плане, что аксели и магнитометры используются в локальной СК, то есть как вы и говорите от ориентации ЛА будет меняться вектор. А с ЖПС немного другая ситуация, нам нужно менять виртуальный вектор ЖПС направления таким образом, чтобы он не менялся в зависимости от ориентации аппарата, то есть рассматриваем его уже в глобальной СК, ну типа обратная задача.
Про калибровки акеселерометра и магнитометра я естественно знаю, более того у меня 9 коэффициентов на каждый датчик.
Акселерометр никаким образом не сможет отделить ускорение свободного падения (которое используется в корректировке ориентации) от линейных ускорений, как не фильтруй, как не калибруй.
Про ЖПС это вы конечно правы, но несколько метров ошибки изменят мой вектор направления на доли градуса, что не внесет большой ошибки. Но тут опять же для повышения точности можно усовершенствовать до системы RTK.
Тут еще другой вопрос - почему никто такое не придумал, или я просто не видел, может в реале я туплю, на самом деле это нереально.