Создание собственной системы стабилизации
В принципе ничего сложного нет. Если знакомы с MSVC, то вообще проблем не должно быть, есть кучу сайтов где можно скачать нужные контролы для приложений если лень разбиратся и писать свои. Тем более для наших целей ничего специфичного не нужно.
Знаком, но нужно разбираться во многих вещах напрямую к предмету не относящихся, что крайне лень. Вот если б была установленная и настроенная среда с шаблоном проекта куда нужно встроить только предметную часть 😁
А момент инерции, это коэф пропорциональности между m и F, т.е. соотношение силы тяги к массе. Его проще имперически подобрать,чем приводить к реальным (я в Декартовой системой координат считаю, мне так проще, чем в полярной), в int - ах все равно все попугаях .
Не совсем, вы это о линейном перемещениях, момент инерции это о вращательном движении. ru.wikipedia.org/wiki/������_�������
А кажись понял про какие ускорения. От акселя на вираже, подъемах, спусках и т.п.? (ну т.е. от чего аксельный горизонт плывет?). Я просто считаю это элементами автопилота(даже стабилизация в горизонт) по этому сразу не понял о чем речь.
и эти тоже, но я о другом, ПИД выполняет компенсацию возмущений не только пропорциональной, но и дифф. частью (предотвращает резкие эволюции). без интегральной можно обойтись, однако придётся очень точно балансировать летуна, ну и о подвесе чего-то подвижного или асимметрического нужно забыть. В общем всё это в ТАУ достаточно прописано.
Хочу пока сделать именно стабилизацию, то что только от ДУСа.
Это конечно основа всего, но реализация крайне проста, можно вообще никакие матрицы не считать, подать каждую ось на свой ПИД, а результаты помноженные на коэффициент, в соответствии с расположением моторов, сложить между собой и значением тяги. Вот вам и Кук! А вот правильно интегрировать ДУС чтоб получить ориентацию объекта это уже сложнее, примерно так e-maxx.ru/sgu/files/my_kurs.pdf
А ещё сложнее правильно корректировать пространственный интеграл, в этом есть БОЛЬШАЯ проблема.
Ну и что получается? т.е. чтобы получить наибольшую точность, надо как можно меньший интервал временной, но в тоже время мы поймаем ДУС-ом ВЧ возмущения - получается надо искать золотую середину? где и ВЧ душиться будут и время цикла приемлимое с точки зрения интегрирования?
обновил исходники в гит в связи с починкой PWM, на usb драйвера не смотреть они не рабочие и не подключены к проекту - забыл выкинуть…
Ну и что получается?
В теории оно так и есть, но на практике, выигрыш за счет сильного уменьшения dt выигрыш невооруженным глазом не заметен.
Вот если б была установленная и настроенная среда
По моему даже среду ардуино “сложнее” настроить😁 Если вдруг соберетесь оращайтесь. На Билдере все еще легче.
Ну и что получается? т.е. чтобы получить наибольшую точность, надо как можно меньший интервал временной, но в тоже время мы поймаем ДУС-ом ВЧ возмущения - получается надо искать золотую середину? где и ВЧ душиться будут и время цикла приемлимое с точки зрения интегрирования?
Тут правило простое, алгоритм должен обсчитать всё что даёт датчик , иначе пропуская отсчеты можем попадать только (или преимущественно) на отклонения одного знака, соответственно будет случайный увод по этой оси.
Не совсем, вы это о линейном перемещениях, момент инерции это о вращательном движении. ru.wikipedia.org/wiki/��%...E5����
Все эти страшные кракозябры от сложного приведения моментов(от моторов и инерции) в силу через плечи, т.к. масса и тяга не сосредоточенные в одной точке, а распределены. Но все равно если все привести к силе и массе, все сократиться и закон движения будет тем же.
и эти тоже, но я о другом, ПИД выполняет компенсацию возмущений не только пропорциональной, но и дифф. частью (предотвращает резкие эволюции)
Дык писал же уже, что основная задача D уменьшать перерегулирование. Даже при малой скорости(от малой возмущающей силы), P растет быстрее чем тяга двигателя. Вообще вся стабилизация из двух частей состоит, когда ускорение и скорость в одну сторону направленны(действие возмущающей силы) и в разные(тормозим разогнанные моторы). Вот D нужно для второго 😃
Да и меня там вообще в этом смысле сурово. Если брать из состояния полного равновесия… Кот только появляется скорость (хоть 0.0001 град/сек) мозг у регулей запрашивает полуную разницу в тяге противоположных моторов, другое дело что на очень не продолжительное время. Т.е. как бы регулируем временем, а не силой тяги(очень упрощенно). Другое дело сила тяги меняется очень медленно, а команды мы даем 300 раз в секунду примерно, если недостаточно сгладит, придется LPF фильтр какойнибудь добавить.
без интегральной можно обойтись, однако придётся очень точно балансировать летуна, ну и о подвесе чего-то подвижного или асимметрического нужно забыть.
Праильный I просто не успел написать, там через работу надо(но уже придется интегрировать численно, или че хуже матан вспоминать 😃 и кинетическую энергию. I это очень не точная вещь и не правильная, как и PD.
Если на один луч подвесить грузик - коптер наклониться. Что при разнотяге и не симметричности приводит к колбасне и унитазам.
Это конечно основа всего, но реализация крайне проста, можно вообще никакие матрицы не считать, подать каждую ось на свой ПИД, а результаты помноженные на коэффициент, в соответствии с расположением моторов, сложить между собой и значением тяги. Вот вам и Кук! А вот правильно интегрировать ДУС чтоб получить ориентацию объекта это уже сложнее,
я знаю , но в вии код нормальный и переписывать не охота. Будет смысл только на float-ы “железные” да и опять же не силен я во всяких кватернионах, а изучать лень, проще чужой код стырить 😃
Тут правило простое, алгоритм должен обсчитать всё что даёт датчик , иначе пропуская отсчеты можем попадать только (или преимущественно) на отклонения одного знака, соответственно будет случайный увод по этой оси.
не я тут со своей колокольни, если брать усреднённые данные с гир на 42- герцах, выше частоту уже не имеет смысла брать, тогда смысл теряется запуска цикла по готовности 😦
не я тут со своей колокольни, если брать усреднённые данные с гир на 42- герцах, выше частоту уже не имеет смысла брать, тогда смысл теряется запуска цикла по готовности
Можно увеличить частоту гир, и такие данные брать только для интегрирования, а на P и особенно D самим дополнительно фильтровать.
мозг у регулей запрашивает полуную разницу в тяге противоположных моторов,
Пытаюсь понять (я тоже экспериментатор:)), как это “мозг” запрашивает “тягу”, что то не то… - мозг имеет только уг.ускорения ну и вектора акселя (как Вы сказали в “попугаях”, лишь бы калиброванные были), или я чего то непонял…
Вообще говоря, избавиться от алгоритма ПИД, по моему не реально… (он так прост и естественен по своей сути).
Тем не менее удачи!
А я с usb подвис - брр столько мути и поразным файлам 😦
Тем не менее удачи!
Стараюсь блин 😃. Наконецто из Дельфи перенес код на Ansi C++ и сделал библиотеку, пока с флоатами(все равно отлаживать на писюке буду). С интами потом, и так запутаюсь 😃)
как это “мозг” запрашивает “тягу”
Допустим(коптер висит на половине тяги) и клюет мордой - Мозг дает команду регулям:
передние моторы на полную
задние минимальный газ
И вычисляет когда им обратно сказать
Передние 50% тяги
Задние 50% тяги.
Так что бы к моменту их тяги 50% - скорость(и это при том что и возмущающей силы больше нет) была равно 0.
Это демпфер, а “I”(то что должно возвращать на место после внешнего воздействия) еще не делал, слона едят по частям 😃
В общем моя система с обратной связью по оборотам(пока расчетным) моторов. Будет совсем плохо, вроде выяснилось что отдельное ардуиной их померить не проблема.
PID это просто, но не правильно, его можно настроить только под конкретное возмущающие воздействие, т.к. реакция моторов не мгновенная. Если настроить на стабильно висение - расколбас например в ветер, если настроить на ветер никакущая стабилизация, ну и адово шумящий D(правда его побороть как раз элементарно). Если скорость и ускорение в одну сторону - делим DTerm на 4 например.
Т.е. математика PIDa ОЧЕНЬ не точно моделирует поведение наших жужжалок.
Наверно ничего не понятно, но я не очень представляю как колебательный процесс на пальцах можно обсуждать… 😃
хм… вы брали готовый пример? у меня тоже из-за ЮСБ прибавилась громадная куча файлов заголовочных… свою проблему решил так - взял готовый пример USB-UART на один из портов, выкинул лишнюю индикацию и собстно сам уарт, по приходу данных на эвент поставил свою процедурку записи файлов, ну и посмотрел как передается и сделал так же (единственно вместо используемой отправки/приема побайтно использую буфер )
Да точно также, но в примерах столько билиберды - ужас 😃
сейчас копаю ACopter32-STM32F4, у Vrbrain в принципе красиво сделано но мапловские библиотеки сбивают с толку…
насчет белиберды - согласен… но ее чистить - та еще морока…
я после пытался 3 раза собрать все в пару файлов, в итоге 3 дня убил а норм результата не вышло… оставил сейчас как сейчас есть и отлично работает.
если брать усреднённые данные с гир на 42- герцах, выше частоту уже не имеет смысла брать
Это если усреднение правильное, а не тупой пропуск отсчётов датчика.
Можно увеличить частоту гир, и такие данные брать только для интегрирования, а на P и особенно D самим дополнительно фильтровать.
А вот это правильно.
Наверно ничего не понятно
Как раз теперь понятно. Вы хотите мерить обороты двигателей и брать эти показания для управления. Но тут (чисто мое мнение) будет скорее всего “маленькая” бяка, дело в том что: обороты и тяговое воздействие не связаны между собой линейно из за аэродинамических свойств винта (побочные потоки, срыв потока и т.д.), так что дав (допустим) 50% на сторону Вы не получите “нейтрали” в действительности, а получите непредсказуемое положение…
А если сделать калибровочную таблицу тяги от оборотов и уже на нее опираться, хотя будет достаточно дискретные значения.
А если сделать калибровочную таблицу тяги от оборотов и уже на нее опираться, хотя будет достаточно дискретные значения.
Покурю сплайн интерполяции тады 😃)
Но тут (чисто мое мнение) будет скорее всего “маленькая” бяка, дело в том что: обороты и тяговое воздействие не связаны между собой линейно
Да никакая это не бяка. PID вообще про обороты и тягу ничего не знает, все равно должно быть лучше. Мерить истинные обороты, построить кривую зависимости и считать интегрируя, а не через формулу площади просто следующий этап. ДА и 90% регулирования происходит на 10% разнотяга, что в первом приближении можно считать линейной зависимостью. Да и переругуирование добро и у меня там это настраевается, зато расколбаса быть не может, только вздрогнет.
Все готово к пробному полету, не знаю только как управление по Yaw сделать… (крен и тангаж +/- 45 гр. от ручек управления). Его (Yaw) вообще наверно не надо “привязывать” к оси Z ??
крен и тангаж +/- 45 гр. от ручек управления
это что наклон коптера? - жутко получится - 20гр. больше ненадо, ну разве что с сильным ветром бадаться…
ну что? арду третий зохвачен:
бросать всё и подымать эклипс? - компилятор кривой блин 😦 даже родную прошиву скомпилить не получается…
или плюнуть на УСБ пока и маховий себе вкодячить?
короче на распутье я 😃
чёт смотрю а газ то товарищ не отпускает (моде1 походу)…
gcc arm-none-eabi 4.5.2 творит чудеса 😃 один раз 😦
интересно - то скомпилируется то нет, может уже просто ресурсов моей старенькой железки нехватает?
ради эксперимента залил в плату ACopter32-STM32F4 - да усб завелось как com10…
это что наклон коптера? - жутко получится - 20гр. больше ненадо, ну разве что с сильным ветром бадаться…
45 норма, у меня 60. Если получится что задумал, то углы будут вообще распущены, ибо для достижения цели все средства хороши, даже если нужно вниз винтами перевернутся.
бросать всё и подымать эклипс? - компилятор кривой блин даже родную прошиву скомпилить не получается…
или плюнуть на УСБ пока и маховий себе вкодячить?
короче на распутье я
Что мешает уйти на кейл? Одним кликом на переменой можно найти её объявление в другом файле, очень удобно складывать мозаику из разных проектов.
В своих проектах я обычно иду снизу вверх, т.е. сначала делается запуск проца, настройка портов и чтение датчиков, УСБКОМ, и только когда всё это начинает работать сверху сажу свою ИНС. Основой проекта выбираю родной СТМовский УСБ-демопроект, ибо работать с железом разных семейств можно через одни и те же вызовы библиотеки (с небольшими изменениями).
ради эксперимента залил в плату ACopter32-STM32F4 - да усб завелось как com10…
Как только появится время сделаю портируемый УСБКОМ под твою плату.
Диодные сборки на плате BAT54?