Создание собственной системы стабилизации
для меня всегда проблематично, считаю
Резонно, самого коробит от кучи проводов и плат никак не могу привести все в прядок, хочется чтоб выглядел аккуратно, а выглядит как комок проводов
dl.dropboxusercontent.com/u/…/IMG_4985s.jpg =((
Чет я запутался (подскажите кто может), : в цикле посчитал три ПИДа (тангаж, крен, вращ.) , а теперь надо их с разными знаками, для каждого мотора, прибавлять к общему ГАЗу и “совать” на движки ??
Правильно ? Может кусок кода у кого под рукой…
А я исходники просто так выкладываю 😃 github.com/SergDoc/…/mixer.c
static const motorMixer_t mixerQuadP[] = {
{ 1.0f, 0.0f, 1.0f, -1.0f }, // REAR
{ 1.0f, -1.0f, 0.0f, 1.0f }, // RIGHT
{ 1.0f, 1.0f, 0.0f, 1.0f }, // LEFT
{ 1.0f, 0.0f, -1.0f, -1.0f }, // FRONT
};
static const motorMixer_t mixerQuadX[] = {
{ 1.0f, -1.0f, 1.0f, -1.0f }, // REAR_R
{ 1.0f, -1.0f, -1.0f, 1.0f }, // FRONT_R
{ 1.0f, 1.0f, 1.0f, 1.0f }, // REAR_L
{ 1.0f, 1.0f, -1.0f, -1.0f }, // FRONT_L
};
ну и для моей кривой рамы:
static const motorMixer_t mixerQuadXSerg[] = {
{ 0.87f, -1.0f, 1.0f, -1.0f }, // REAR_R
{ 1.0f, -0.47f, -1.32f, 0.75f }, // FRONT_R
{ 0.87f, 1.0f, 1.0f, 1.0f }, // REAR_L
{ 1.0f, 0.47f, -1.32f, -0.75f }, // FRONT_L
};
столбцы соответственно для каждого мотора trotthle, roll, pitch и yaw 😃
а теперь надо их с разными знаками, для каждого мотора, прибавлять к общему ГАЗу и “совать” на движки ??
Совершенно верно, каждый компонент ориентации матрично приводиться к конфигу рамы, для квадры Х: ++ – -+ ±
Может кусок кода у кого под рукой…
Кода под рукой нет, но на ветке гдето валяется мой проект см. файл mixer.cpp, сама матрица в моих настройках выглядит так
...
РусИНС1.0>АП.СУММАТОР:
Матрица управления:(N Канала),Крен,Танг,Рыск,Тяга >:
Крен Танг Рыск Тяга
KAH1: 625 -625 -500 1800
KAH2: 625 625 500 1800
KAH3: -625 -625 500 1800
KAH4: -625 625 -500 1800
...
РусИНС1.0>АП.СУММАТОР:
матрично приводиться
А что, ограничений по модулю не делается ? А если условно Газ + ПИД вылезет за пределы допустимого (у меня) диапазона 1000-2000 ? (Ваш проект у меня есть, но видать старый, нет там mixer.cpp) просто подскажите, если не трудно, а то хочется полетать уже…
простое ограничение…
Для вас к прочтению обязательно!!! multiwii.p.ht/index.html
rcopen.com/forum/f123/topic267086/582 - вывод напрашивается - мосх должен быть тяжелым…
Вот такая же фигня(тока физику и термех? вспоминал), написал и отладил стабилизацию без PID.
Стабилизация без ПИД это круто, как учитываются в стабилизации ускорения и моменты инерции?
Буду отлаживать на писюке через серийник, так удобней на порядок(бряки, замедленный просмотр по логам), потом просто библиотеку к пректу подключить.
Да много удобней, но нужно владеть инструментами программирования PC, тут я не очень, только консольное что-то могу написать. Кста, на самолётной ветке есть АлексСнег, он свой мухомозг таким жа способом разрабатывал.
надо и мне разобраться с этой штукой, а то как-то начал изучать и забросил…
Да я тоже очень поверхностно знаком, отрабатываю только мат.механизмы, с визуализацией бы ещё разобраться получше.
вывод напрашивается - мосх должен быть тяжелым…
Точнее инертный, не должен воспринимать высокочастотную вибрацию некомпенсируемую математикой, но и не должен иметь резонансов на НЧ.
Да много удобней, но нужно владеть инструментами программирования PC, тут я не очень, только консольное что-то могу написать. Кста, на самолётной ветке есть АлексСнег, он свой мухомозг таким жа способом разрабатывал.
В принципе ничего сложного нет. Если знакомы с MSVC, то вообще проблем не должно быть, есть кучу сайтов где можно скачать нужные контролы для приложений если лень разбиратся и писать свои. Тем более для наших целей ничего специфичного не нужно. www.codeproject.com
http://codeguru.com
Стабилизация без ПИД это круто, как учитываются в стабилизации ускорения и моменты инерции?
Ускорения так таковые вообще не учитывються(это одно из преимуществ). А так mV=Ft(это только PD, I не делал еще), если на железе заработает потом напишу с картинками, на пальцах не объяснить.
А момент инерции, это коэф пропорциональности между m и F, т.е. соотношение силы тяги к массе. Его проще имперически подобрать,чем приводить к реальным (я в Декартовой системой координат считаю, мне так проще, чем в полярной), в int - ах все равно все попугаях .
Хотя на сферическом кирпиче вполне реальные размерности 😃
Масса 5 кг, сила тяги 100 Н, g=10 м/с*с. Ну т.е. для случая если висим на половине тяги. Отнощение момента к моменту инерции конечно больше, но проще подобрать. Если смотреть замедленно Логи, там прекрасно видно куда врем.
Да много удобней, но нужно владеть инструментами программирования PC, тут я не очень, только консольное что-то могу написать. Кста, на самолётной ветке есть АлексСнег, он свой мухомозг таким жа способом разрабатывал.
Ну а я все жизнь на PCюке 😃, мне проще так. Тем более есть C++ Builder(на нем и делаю) совместим с ansi С и виндовую форму накидать там пара минут еще пара минут COM порт прочитать.
А кажись понял про какие ускорения. От акселя на вираже, подъемах, спусках и т.п.? (ну т.е. от чего аксельный горизонт плывет?). Я просто считаю это элементами автопилота(даже стабилизация в горизонт) по этому сразу не понял о чем речь. Хочу пока сделать именно стабилизацию, то что только от ДУСа. Это намой взгляд пока самое узкое место.
В принципе ничего сложного нет. Если знакомы с 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 подвис - брр столько мути и поразным файлам 😦