Создание собственной системы стабилизации
На мой взгляд, люди бы просто не переходили на инав, если бы всем хватало арду. Как мне кажется, всетаки доступный арду-полетник уже в прямом смысле весьма устарел технически а актуальные не так уж и дешевы да и размеры с весом у современных альтернативных полетников уже явно выигрывают. Плюс простота назы в полетниках в том числе стала залогом ее упеха, а гора настроек явно не способствует широкой популярности. Да и время сейчас такое стало - для большинства новичков зачастую проще купить что-то летающее из коробки - выбор сейчас огромен на любой кошелек. А копаться в платах и прошивках для аппарата “полетать вокруг, поснимать”, исключительно на мой взгляд, как подход постепенно отмирает. Гоночные аппараты здесь не беру в расчет, но на них нужно уметь летать.
у основных разработчиков папарацци не было такой цели в принципе, стать мега популярными
ну не надо лукавить! 😃 Хотим мы этого осознанно или нет, человеческая сущность такова, что признания хотят все…
но нужен он средрестатистическому юзеру то в принципе весьма ограниченно, скорее для изначальной настройки аппарата
до тех пор, пока в проекте пару пид настроек и пины переферии захардкожены
Думаю ребята из папарацци это осознавали, плюс они все работают на весьма хороших местах и им просто не нужно рвать глотку на форумах, пытаясь заглушить “конкурентов”.
Признвайтесь, вы один из них? 😃
Кстати, если не трудно, раскажите тут больше про папарации. Про его фишки, модульность, связывание модулей (xml files?), комуникация между модулями, конфигурирование параметров которых нет в ГУИ (cli, hardcode, conf files). Т.е. про архитектуру проекта, фичи, плюсы и минусы. Думаю многие тут (и я) не сильно в курсе про папарации. Будет интересно! Спасибо зарание!
Хотим мы этого осознанно или нет, человеческая сущность такова, что признания хотят все…
Хотеть одно, а достичь - другое. Не всем хватает времени и сил на разработку и продвижение одновременно. Все-таки речь об достаточно малоизвестном для широкого круга пользователей проекте безо всяких свистелок и перделок 😃 Хотя в университетских кругах проект достаточно известен, но круги эти весьма узкие.
Признвайтесь, вы один из них? 😃
Нет, я просто более менее продвинутый пользователь проекта.
А в самом проекте прошивка собирается из одного основного и четырех вспомогательных xml файлов. В основном файле по определенному синтаксису указывается под какую плату собирать, какая прошивка (коптер или самолет) и практически все дефолтные полетные настройки. Во вспомогательных описываются полетные задания, какие парамеры полета появятся для конфигурации в гуи, настройки радио и что будет передаваться по телеметрии. Эти файлы выбираются в гуи для компиляции конкретной прошивки, наборы этих файлов также сохраняются под определенными именами, между этими наборами ними можно быстро переключаться в выпадающем меню для компиляции разных прошивок. На мой взгляд со стороны более менее продвинутого пользователя все мега удобно.
А в самом проекте прошивка собирается из одного основного и четырех вспомогательных xml файлов. В основном файле по определенному синтаксису указывается под какую плату собирать, какая прошивка (коптер или самолет) и практически все дефолтные полетные настройки. Во вспомогательных описываются полетные задания, какие парамеры полета появятся для конфигурации в гуи, настройки радио и что будет передаваться по телеметрии. Эти файлы выбираются в гуи для компиляции конкретной прошивки, наборы этих файлов также сохраняются под определенными именами, между этими наборами ними можно быстро переключаться в выпадающем меню для компиляции разных прошивок.
Мне как разработчику, описанный подход вполне симпотичен. Можно сконфигурить нужные тебе фичи и ничего лишнего не будет перед глазами в ГУИ. Однако описание полетного задания (имелось ввиду задание нвигационных полетных точек?) в xml это уже хардкор! 😃 Но да, все зависит от задачи и если это университетский иследовательский проект, то наверняка удобно иметь все исходные данные в файлах, а не заморачиваться их экспортом из ГУИ тула и последующей конвертацией в какой нибудь матлаб формат…
На мой взгляд со стороны более менее продвинутого пользователя все мега удобно.
Если пользователь ИТ-ник или хотя бы самоучка хоббист имеющий понятие компилляции, то да, а иначе жжопа… Ж)
Хотя в университетских кругах проект достаточно известен, но круги эти весьма узкие.
Вот еще одно подверждение, что проект для ИТ-в гиков…
Кстати, какого типа ИНС в папарации? EKF, UKF, комплиментарники или другое что?
Плюс простота назы в полетниках в том числе стала залогом ее упеха, а гора настроек явно не способствует широкой популярности. Да и время сейчас такое стало - для большинства новичков зачастую проще купить что-то летающее из коробки - выбор сейчас огромен на любой кошелек.
Вот, нужно сделать функционал назы за малые деньги, + управление подвесом. Чтоб исчерпывающая инструкция для выполнения первого полета с базовым функционалом (удержание, возврат домой) занимала менее половины листа А4.
На мой взгляд со стороны более менее продвинутого пользователя все мега удобно.
Для любителя рукоделия ))) Для пользователя нужно просто выбрать тип носителя и 3-4 цифири настроек, не более!
Папарации кстати яркий тому пример, что без толкового мультиплатформенного гуя проект так и не стал оссобо популярным к сожалению…
У опенпилотов гуй прекрасен, у арду весьма гемороен. кого из них больше? 😉
Для чего реально нужен ГУЙ, так это для полета по точкам, и/или настройки автопосадки для самоля.
Кстати, какого типа ИНС в папарации? EKF, UKF, комплиментарники или другое что?
Есть там и калмановкие решения, но я летаю на комплиментарниках. Руки пока не дошли потестировать другие алгоритмы.
Вот, нужно сделать функционал назы за малые деньги, + управление подвесом. Чтоб исчерпывающая инструкция для выполнения первого полета с базовым функционалом (удержание, возврат домой) занимала менее половины листа А4.
Так это уже целый комплекс - полетник+прошивка. Но именно это был путь назы, и она весьма преуспела. Но в принципе я здесь абсолютно согласен, собственно к чему то похожему я пришел и сам:
Так я себе представляю удобный полетник - все в одном, микроконтроллер, сенсоры, осд на верхней плате; регули, импульсные беки на 5В и 10В, лц-фильтр - на нижней. С одной стороны входы/выходы осд с переключателем на 2 канала, шим на подвес; с другой входы для приемника и телеметрии РУ. Плюс естественно вход GPS и компаса, дополнительный уарт и набортный стандартный ардушный модуль телеметрии для настройки с гуи. Сейчас облетываю на своем новом кваде, минимум проводов, очень удобно. Под это толковую прошивку аля наза с джентльменским набором настроек - так я вижу себе оптимальный полетник для “собери сам” на сегодня.
Так это уже целый комплекс - полетник+прошивка.
дык я именно об этом, все готовое, чтоб моделист без опыта мог прикрутить и не изучая ТАУ полететь используя весь базовый функционал. И еще минимум предполетной подготовки, автодиагностика и автокалибровка. Если по каким то причинам не готов - просигналил лампочками и в лог на флешку
Под это толковую прошивку аля наза с джентльменским набором настроек - так я вижу себе оптимальный полетник для “собери сам” на сегодня.
А для совсем “конченных” пользователей за их деньги джедаи уже всё изобрели.
Так я себе представляю удобный полетник - все в одном,
Это самоделка на фото ?
Это самоделка на фото ?
Нет, распаяны платы не в китае, если вы об этом 😃
Нет, распаяны платы не в китае, если вы об этом
Я имел ввиду - это Ваша собственная разработка ?
Так я себе представляю удобный полетник
Просто, в процессе длительных проб и ошибок, я тоже пришел приблизительно к такому же функционалу и компоновке )))
Да и то это дело желания сесть и сделать - портируется там все на раз.
я сделал, но так и не попробовал…
Я имел ввиду - это Ваша собственная разработка ?
Понял. Разработка моя.
я сделал, но так и не попробовал…
А чего не хватило?
ума - шучу, новый год наступил, а сейчас другие задачи…
оставалось xml микшер под трёху написать или это уже из гуя можно?
а ещё ld сделать свой - точно…
под ф4бы - там, да, с пол пинка можно, но я не искал лёгких путей)))
всем привет. Кто может просветить по поводу ПИДов. Вот две схемы ПИДов танагажа и крена.
Первая - паралелльная, довольно странная, это схема автоквада. Причем автор хотел сделать, не то, что получилось? Ошибка? Обратите на то, что из сигнала задания в звене дифференциальной состяавляющей вычитается СНОВА показание сенсора. Наверное надо вычитать ЗАДАНИЕ? Так как коментарий противоположен, выделил жирным.
Вторая - моя текущая. Она последовательная. Я вычитаю 80 процентов задания, по-моему так правильнее.
В схемах намеренно не показывал лимиты, чтобы не загромождать.
Но к чему это я все. На форуме автоквада написано, что на заре проекта, было несколько схем (последовательная и паралелльная), в итоге Билл выбрал паралелльную, так как она оказалось лучше. forum.autoquad.org/viewtopic.php?f=31&t=4792&p=363…
Но вот смотрю я на нее и с первого взгляда, что-то нифига не лучше, вместо того, чтобы использовать напрямую угловую скорость с гиры в ПИД идет дифференциал угла. У кого какие мысли?
Код:
float pidUpdate(pidStruct_t *pid, float setpoint, float position) {
float error;
float p = *pid->pGain;
float i = *pid->iGain;
float d = (pid->dGain) ? *pid->dGain : 0.0f;
float f = (pid->fGain) ? *pid->fGain : 1.0f;
if (pid->pTrim)
p += (*pid->pTrim * p * 0.002f);
if (pid->iTrim)
i += (*pid->iTrim * i * 0.002f);
if (pid->dTrim)
d += (*pid->dTrim * d * 0.002f);
if (pid->fTrim)
f += (*pid->fTrim * f * 0.002f);
error = setpoint - position;
// calculate the proportional term
pid->pTerm_1 = p * error;
if (pid->pTerm_1 > *pid->pMax) {
pid->pTerm_1 = *pid->pMax;
}
else if (pid->pTerm_1 < -*pid->pMax) {
pid->pTerm_1 = -*pid->pMax;
}
// calculate the integral state with appropriate limiting
pid->iState += error;
pid->iTerm_1 = i * pid->iState;
if (pid->iTerm_1 > *pid->iMax) {
pid->iTerm_1 = *pid->iMax;
pid->iState = pid->iTerm_1 / i;
}
else if (pid->iTerm_1 < -*pid->iMax) {
pid->iTerm_1 = -*pid->iMax;
pid->iState = pid->iTerm_1 / i;
}
// derivative
if (pid->dGain) {
// uncomment this line if you want the D term to ignore set point changes
error = -position;
pid->dTerm_1 = (d * f) * (error - pid->dState);
pid->dState += f * (error - pid->dState);
if (pid->dTerm_1 > *pid->dMax) {
pid->dTerm_1 = *pid->dMax;
}
else if (pid->dTerm_1 < -*pid->dMax) {
pid->dTerm_1 = -*pid->dMax;
}
}
else {
pid->dTerm_1 = 0.0f;
}
pid->pv_1 = position;
pid->sp_1 = setpoint;
pid->co_1 = pid->pTerm_1 + pid->iTerm_1 + pid->dTerm_1;
if (pid->co_1 > *pid->oMax) {
pid->co_1 = *pid->oMax;
}
else if (pid->co_1 < -*pid->oMax) {
pid->co_1 = -*pid->oMax;
}
return pid->co_1;
}
Кто может просветить по поводу ПИДов.
Не совсем понял, у тебя на схемах где вход от ДУС?
справа RATE - это данные с ДУСА
Код плохо смотриться, исправь с [CODE]
Мне твой вариант больше нравится, но я бы сделал не много по другому.
Дифф составляющую я бы вообще отдельной параллельной веткой сделал от скорости и отвязал от задатчиков по скорости и тем более углу. Тогда вот эта ветка с весом 0.8 уберется. Задача дифф ветки "успокоить переходные процессы регулирования угла.
Тогда вот эта ветка с весом 0.8 уберется.
Я понял идею. Но мне именно был интересен вариант с тем, чтобы на резкое изменение задания коптер тоже резко реагировал, поэтому 20 процентов сигнала задания я подмешиваю в дифференциальную составляющую.
Мне твой вариант больше нравится
Вот Билл по-другому решил. Единственное что мне пока понравилось в паралелльной схеме это то, что коэффициенты контура угловой скорости независимы от коэффициентов контура угла, то есть по идее, на разных коптерах перенастройку делать легче или вообще не надо. Или все таки не легче и надо?
Илья, у тебя отсутвует интегральная часть на Angle. Если действует постоянная ошиба на rate, коптер никогда не займет заданного положения по углу. В схеме автоквада она есть. Но схема автоквада все равно очень странная, возможно, ее можно преобразовать к классической двухкаскадной, но лучше уже сразу от классической и идти, как у тебя.
Спасибо за интересное замечание, я об этом не задумывался. Хотя такой ситуации быть не должно, у меня на ПИД поступает скорость с ДУСа+биас (который калман считает, то есть все время обновляется), поэтому скорость поступает без смещения. Но действительно можно добавить еще интегральное звено по углу.
чтобы на резкое изменение задания коптер тоже резко реагировал, поэтому 20 процентов сигнала задания я подмешиваю в дифференциальную составляющую.
На мой взгляд это пустой расход энергии, если регули позволят, а если не позволят, то они это вообще пропустят. ДИФФ-звено это демпфер от раскачки и больше ничего.
Илья, у тебя отсутвует интегральная часть на Angle. Если действует постоянная ошиба на rate, коптер никогда не займет заданного положения по углу.
Алексей, есть у него интеграл, просто он через два коэффициента TLT_ANG_P*RTE_ANG_I.
Но действительно можно добавить еще интегральное звено по углу.
Ничего не надо, будет медленная раскачка, двойной интеграл вносит большую задержку - очень тяжело настраивать. А в данном случае и не нужно.