Создание собственной системы стабилизации
А я тут опенпилотовскую методику осваиваю калибровки компаса - на шару не пошло ставил примерно на глаз по осям (в смысле по сторонам света) - получил 45 градусов отклонение!!! ищу - куда же дети мой мех. компас дели - надо по нему откалиброваться… и никак не догоню термокалибровку баро и ДУС-ов, что-то я не так делаю или у меня в коде что-то не работает - короче отдельная песня…
кстати на кого бы скинуть это мероприятие, а то щас Макс придёт скажет “делом надо заниматься, девочки, делом, а развлечения потом” © )))
и параметры ПИД не оптимальны для текущей передаточной характеристики ВМГ (приёмистости).
Все еще хуже 😃) Параметры ПД(И оставим в покое) оптимальны только для определенного возмущающего воздействия. Если настроить пару ПД на импульс Х, то для импульса 2*Х регулятор говоря Вашим языком “проскочит” - т.е. перерегулирование. И соответственно наоборот.
вот тут я пытался это наглядно показать, замедлено в 10 раз
Когда то пробовал считать через mV=Ft. Но расчетные обороты моторов разбегались с истинными(еще бы 😃, а мерить реальные мне стало лень 😃 - просто сменил работу 😃
PS На всякий случай уточню. Если коптеру на луч повесить грузик с ПД - получим постоянное вращение(до неприличных углов), с П И Д наклон. Адаптацию я так ниасилил сделать. По этому в ВИЕ добавил множители на каждый мотор и настраивал в висение в горизонте без постоянного наклона с И=0. Так он себя вел на порядок лучше. Дело же не только в ЦТ - каждый китайский мотор уникален 😃)
Параметры ПД(И оставим в покое) оптимальны только для определенного возмущающего воздействия
Оптимальны - это значит обеспечивают достаточное ( входящее в окно нормы) регулирование в результате воздействия проектного (нормированного) внешнего воздействия. В нашем случае серединой этого окна является режим висения в приемлемо возмущенном воздухе.
вот тут я пытался это наглядно показать, замедлено в 10 раз
Виталий, было бы наглядно, но нужно хотя бы легенду ваших абстракций нарисовать. И было бы не плохо ещё и график во времени.
Вообще всякие регуляторы мне прививали моделировать в VisSime . Довольно удобно, просто и наглядно.
и никак не догоню термокалибровку баро и ДУС-ов
В даташитах на датчики (ms5611 не в счёт, там всё понятно) температурная компенсация по встроенному “термометру” практически не освещается… типа - “она должна быть”, а что , куда, непонятно …, приходится самому вылавливать тенденции уплывания показаний по осям… (при помощи жёнского фена, и льда из холодильника 😃)…
температурная компенсация по встроенному “термометру”
Давным-давно (в нашей голагтеке) была такая FY-21AP от фейтех… так в отличие от остальных своих поделок они зачем-то отключили калибровку гир. До +5 работала, а ниже кирдык - сумашедшее вращение. Обогревающие лампочки над гирой помню спасали. Температура с баро шла.
mV=Ft
к примеру в ардукоптре
стаб пиды: угловая ошибка * стаб P,D
рэйт пиды: ошибка угловой скорости * рэйт P,D
управляющий сигнал: стаб+рэйт
где
угловая ошибка - разница между желаемым углом рамы к горизонту и фактическим
ошибка угловой скорости: разница между текущей угловой скоростью луча и требуемой для достижения поворота на необходимый угол за константу времени
угловая скорость и инерция по вращению
что то типа
m*d*omega=Ft
в первых прошивках были только стаб пиды, настроить было крайне сложно и нестабильно было от мощности и напруги
Ну это в тему о темп компенсации. ИМХО на микроэлектромеханике это абсурд. Прецизионная она, индивидуальна для каждого экземпляра. Кстати, а чего пьезогиры 03 например вдруг одна стоит раза в три дороже мпу?
дык вот блин фен и украл, не помогло пока ))) или я уже отупел или что, надо разницу довести до 10 градусов, а потом ждать… короче щас не до того, скоро сезон, а мелкой только половина, так и хочется в иму влепить проц отдельный - парадокс в разъёмах ))) или в слоях, ещё один вопрос гложет - а воспримет ли инвертор (на XOR) PPM? тупо 1.5В по постоянке на входе или лучше отдельно пустить или поймёт - короче в голове каша, думал опенпилотом отвлечься и конвертопланом - нифига не помогает, а тупо делать на авось не катит, инвертор где-то такой лежит - надо пробовать…
а чего пьезогиры 03 например вдруг одна стоит раза в три дороже мпу?
мурата мля, классная вещь, но ацп к ней надо минимум 24 бит - раз, термокомпенсацию к ним придумывать на ходу- два или ждать пока остынут, я на них долгое время эксперименты, экспериментировал, но когда точность стм-овского ацп получается 2.6 градуса - это не есть гуд…
надо подумать как сделать стабилизатор высокого напряжения для мпу6000
там порядка 24вольт. трогаешь кондер рукой -сразу плывут гиры.
мысль если сделать точный последовательный стабилизатор пусть на вольт он придавит это опорное - зато стабильность будет
зато стабильность будет
не, не покатит внешнее… что-то мне подсказывает - генератор это и 25В - это постоянная составляющая сигнала, а вот на осцилл так и не удосужился кинуть… хотя я и 100n туда ставил вроде как стабильней себя вели…
навсякий случай еще раз глянул - постоянка
Оптимальны - это значит обеспечивают достаточное ( входящее в окно нормы) регулирование в результате воздействия
Просто по моим наблюдениям PD не очень оптимальная мат модель для коптера. Из-за сильного недорегулирования в зоне малых ВВ при гарантированном НЕ раксколбасе при больших ВВ.
Только пришел я к этому от обратного.
Есть вот такой девайс
Что бы добиться хотя бы такой стабильности, настривать пол часа, и это до первого падения. мотор чуть не ровно приклеил и все по новой.
у него очень низкая приеместость у моторов. Для вия P=2.5 всего, D=50. Но для идеального спокойного воздуха выкручивал и до 6(взлетал очень аккуратно с сетчатого покрытия), и тогда он стабильный. но это до первого заметного “порыва ветра”. Прошивать регули тогда еще не умели. Изначально он был на выпиленном ITG 3205 и ADXL 345. Вот и начал искать что там можно “математикой” сделать.
к примеру в ардукоптре
стаб пиды: угловая ошибка * стаб P,D
рэйт пиды: ошибка угловой скорости * рэйт P,D
управляющий сигнал: стаб+рэйтгде
угловая ошибка - разница между желаемым углом рамы к горизонту и фактическим
ошибка угловой скорости: разница между текущей угловой скоростью луча и требуемой для достижения поворота на необходимый угол за константу времениугловая скорость и инерция по вращению
что то типа
m*d*omega=Ftв первых прошивках были только стаб пиды, настроить было крайне сложно и нестабильно было от мощности и напруги
Да я примерно к тому же и пришел. Там мрак…
3х мерная матрица Тяга по времени, а по ось Z это все еще по просадке lipo.
Плюс все вся эта матрица работает для отдельно взятого lipo. Для нового все по новой мерить. + нужны свои регули. Что бы знать обороты моторов и управлять ими так, что бы матрица соответствовала действительности. + еще амперметр и кривая зависимости тока от напруги(для оси Z матрицы).
Все это интерполировать никакая ардуина это не потянет. Так STM32 c железной точкой в шкафу и лежит 😃 В обшем я забил - жизни не хватит 😃
Да и итоговую кривую(Р это прямая кривая) можно имперически вывести, но силенок уже не хватило 😃
Да и тут недавно почитал как NASA делала управление DC 10 без гидравлики, только дрыгаетлями. Даже они не асилили и попросили сделать honeywell(кажись) что бы управление тягой было линейным 😃)
Да смое главное забыл. Все эти ужосы нужны что бы знать кривую F(тяга мотора) по t. Как только площадь под кривой Ft = mV(измеренной гириком) меняем знак управляющего воздействия на противоположный. Вы идеале все устаканиться с первой попытки - скорость моторов с противоположных сторон и V в 0.
к примеру в ардукоптре
стаб пиды: угловая ошибка * стаб P,D
рэйт пиды: ошибка угловой скорости * рэйт P,D
управляющий сигнал: стаб+рэйт
Вот это интересная тема пошла! Самому было лень копаться в адрдупилоте, интересно послушать тех кто на нём “собаку съел”.
По сути получается в Акоптере режим “ливел” (так вроде называется, если маразм не подводит) получается добавлением стаба угла к режиму “акро” и переключением входа стаба “акро” с “ручек” на величину ошибки угла?
m*d*omega=Ft
Тут я не понял… F- тяга, t-время, omega (w) - угловая скорость, d - двойная удельная (для распределенной массы) длина плеча силы ? Тогда m*d*omega= интеграл F(t) *dt, но для постоянной F верно…
Вот опять не увидел И звено в пидах. Что будет если к одному лучу подвесить небольшой груз?
Ну это в тему о темп компенсации. ИМХО на микроэлектромеханике это абсурд.
Согласен на 100%.
мелкой только половина, так и хочется в иму влепить проц отдельный - парадокс в разъёмах )))
Серёг, это уже есть , у тебя дешевле выйдет?
а воспримет ли инвертор (на XOR) PPM?
Вообще пофиг, можно в драйвере всё предусмотреть, всё равно новую прошиву под плату клепать. Если ловит только по спаду или фронту, то вообще ничего не надо делать, будет хоть через два инвертора работать ))))
инвертор где-то такой лежит - надо пробовать…
вот это правильно!
Серёг, это уже есть , у тебя дешевле выйдет?
это не то ))) дёшево не будет, но назоводы должны кипятком писаться))) короче всё в своё время…
это не то
А это ?
Вот опять не увидел И звено в пидах. Что будет если к одному лучу подвесить небольшой груз?
ну никто не говорит о том что нужно исключить небольшую адаптивную автоподстройку пидов
указать небольшой диапазон автокоррекции и уже походу полета в зависимости от показаний сенсоров калькулировать коррекцию
О! Я смотрю тут пипками начали мерятся расчехлили линейки!
Тогда берем вот это
К нему делаем таких же размеров IO борду и вперёд!
имхо это не FMU а IMU т.е. исключительно ориентация помимо ио к нему нужен котроллер в котором будет реализвана логика управления аппаратом (стабилизации, навигации)
обычно первой приходит идея впихнуть все в интегрированный проц. но потом оказывается что и флеши у нее мало и рама только на иму
обычно первой приходит идея впихнуть все в интегрированный проц. но потом оказывается что и флеши у нее мало и рама только на иму
Именно такая идея )) Ну а что, полетнег летающий только в режиме LEVEL, наверное можно сделать. )))) Я конечно шучу, но вдруг кто нибудь забацает. Или например задействует проц в MPU…
А это ?
401-й проц (48 без лап) 9250 и5611 - минимализм - но проблема AEKF потянет герцах на 200, и юзверю интерфейсов мало, как встраиваемое решение в какой-нибудь мелкоквадрик…
но проблема AEKF потянет герцах на 200
А что там ему делать ?..
Сделал вот - просто кватернионный метод, чуток смешал магнитометер+аксель и баро+аксель, на выходе нормальные углы, высота с шумом 20 см… , все это на 500 Гц работает (хотя и впритык уже - 72 Мгц и нет fpu)
Может не совсем по теме, может кто подскажет (покажет, если не секрет), как определить длительности входных сигналов управления (6-ть или 7 и все идут в разнобой - передние фронты не совпадают). Нужно на языке С (С++, CodeVisionAVR) 😃
определить длительности входных сигналов управления
Засечь таймером? 😉 Вычислитель какой?
На Ардуине можно просто засекать время (uint32t time = millis(); ) фронта/спада прикрыванием, полученная разность будет длительностью.
А что там ему делать ?..
если рассматривать как imu то и нормально те-же 72 мегагерца только с FPU, считать углы… А чем скорости и путь пройденный считать? в принципе тоже можно особо не напряжет, потом встаёт делема - куда GPS засунуть? на второй проц и там считать INS? ПИД-ы и всю лабуду? смысл - если всё это на одном 405/407 работает… единственный плюс в процессоре в imu - унести подальше от полётника с минимумом проводов - тот же can, хотя мне больше SPI импонирует - 7 проводов (это с питанием и прерыванием готовности) в жгут с оплёткой… хотя выходя из этого всего то нафиг процу в imu что-то считать если всё равно пересчитываться будет - берём самый маленький и простенький который нам с частотой 400 + соберёт данные от датчиков и отдаст… всё вся его работа…
хотя мне больше SPI импонирует - 7 проводов (это с питанием и прерыванием готовности) в жгут с оплёткой…
7й - это какой, никак не могу придумать? Оплётка?