Создание собственной системы стабилизации
у меня какой-то валяется…
Поэтому выбрал USART, он у меня есть, да в симе GPS usart лишний
Я что-то пропустил, малина чем будет заниматься?
Мысль такая: “гонять” между stm и малиной фиксированный (непрерывный для ДМА) массив озу, со стороны stm заполнять его данными датчиков и расчетными величинами ИМУ, а со стороны малины гнать в обратную настройки/коэфициенты/команды. Таким образом реалтайм петля не будет прерываться линуксом + полный набор данных для визуализации процессов питоном… короче сделать что то вроде “прозрачного доступа к памяти”…
Есть мнение что в нашем карусельном деле бывает старинная но незаменимая вещь. старый советский проигрыватель
Мысль такая: “гонять”
Какая частота обновления планируется?
тарый советский проигрыватель
Это было по секрету, да за обедом.
о стороны stm заполнять его данными датчиков и расчетными величинами ИМУ, а со стороны малины гнать в обратную настройки/коэфициенты/команды
дык тут только SPI, как питоном SPI читать надо смотреть применение питона на малине.
карусельном деле бывает старинная но незаменимая вещь. старый советский проигрыватель
Да, было бы неплохо. Но у меня нет.
Вот видео
Для максимальной реалистичности можно еще на доску регулируемый вибратор закрепить 😁
регулируемый вибратор закрепить
кто в интимный магазин пойдёт? по сути: если есть, допустим по оси z, угловая скорость, то почему нельзя на основании её убрать центростремительные ускорения из вектора акселя?
Я всё веду к тому, что какая-то там магия Калмана EKF не совсем то, что нам нужно, да нужен адаптивный фильтр с обратной связью, но что-то похожее на комплиментарник с автоматическими развесовками датчиков…
на данный момент у меня всё что делает фильтр - это более неправильные данные из “неправильных” сырых данных, точнее - графики намного плавнее чем с обычного вийного комплиментарника (и доплывают данные до истинных значений медленней) да и в полёте никак не заметно - всем рулит ПИД… и барометр куда-то запропастился … каким-то неведанным усилием воли удалил начатый и за ночь написал заново драйвер MPU6000+HMC5883 с инициализацией через регистры и т.п., а не как в вие сначало инициализируется байпасом (что в моём случае сделать нельзя), а потом читается через регистры MPU, надо ещё внедрить его в инициализацию борды и проверить, но времени нету (
чёй-то так NuttX не хватает (консоли по большому счёту), что надо как-то в арду вклинивать?
Какая частота обновления планируется?
Тут чем больше тем лучше…, вопрос - возможна ли задумка в принципе, готовый малиновский драйвер SPI, не позволяет “фулл дуплекс”, хотя блочное чтение/запись поддерживает…
допустим по оси z, угловая скорость, то почему нельзя на основании её убрать центростремительные ускорения из вектора акселя?
Чёт интуитивно наверно нельзя, при большом радиусе вращения… Тут скорей опять надо от ГНСС траекторию как то высчитывать (радиус) и со скоростью скрещивать…
при большом радиусе вращения…
математики/физики есть? чёт я картинку нарисовал, поворачивается при любом радиусе и на тот же угол и при той же скорости - угловая скорость по собственной оси одинаковая, вечером посчитаю…
а вот с ускорением - шляпа, нужно знать радиус поворота(
если есть, допустим по оси z, угловая скорость, то почему нельзя на основании её убрать центростремительные ускорения из вектора акселя?
Потому что не известна кривизна траектории, ещё нужна нужна мгновенная скорость по касательной. Вроде Алексей писал, что Арду считает центростермление по скорости ГНСС и угловой скорости.
что надо как-то в арду вклинивать?
Что вклинивать, свою ИНС в арду?
чёт я картинку нарисовал, поворачивается при любом радиусе и на тот же угол и при той же скорости - угловая скорость по собственной оси одинаковая, вечером посчитаю…
Не путай угловую скорость и линейную, линейная = 2*пи*R * угловая.
а вот с ускорением - шляпа, нужно знать радиус поворота(
Где то попадался материал по этому поводу - решалось всё установкой двух акселерометров одновременно, но там другая “шляпа” - они должны размещаться на некотором приличном расстоянии друг от друга, типа “плечо” такое получалось… на самолете можно по крыльям разнести конечно (?), а на коптере как то не знаю… короче не вариант тоже… Всё таки неспроста уже давно по пиродатчикам горизонт ловить пытались люди, видать из акселя уже ничего не выжмешь… ну или всёж видеообработка с камеры и “мой любимый” RPi (не знаю каким боком его прикрутить, но блин хочется и чую что надо… 😃)
мысль такая - уменьшение влияния акселя при увеличении угловых скоростей - раз, ПИ - регулятор - где угловая скорость = пропорция, угол=интегральная составляющая, плюс ПД, где Д - это предыдущи регулятор при этом отношение П1/П2(тут образно) - обратная связь - это два… чёт мутное получается, но интересное )))
уменьшение влияния акселя при увеличении угловых скоростей
Я думаю его (аксель) надо вообще отключать выше определенных “углов атаки” и лететь чисто на гирах, у товарища видел как трикоптер летает просто на вертолетных гирах вообще без всяких ИМУ, так что в принципе может и прокатить…
Я думаю его (аксель) надо вообще отключать выше определенных “углов атаки” и лететь чисто на гирах
Не согласен, угол 0 ничем не лучше 90 или -180
у товарища видел как трикоптер летает просто на вертолетных гирах вообще без всяких ИМУ, так что в принципе может и прокатить…
Так это простой стаб угловых скоростей, и он крайне надежен, но проблема в том, что никакой “автономки” с таким стабом не реализовать. Пилот должен видеть ориентацию ЛА визуально.
чёт мутное получается, но интересное )))
эт да)) понял только первое правило, оно может сработать. А дальше, я так понял, интегратор угловых скоростей в ориентацию? Если так, то Д там лишнее…
понял только первое правило, оно может сработать.
а я уже передумал - не сработает, при условии длительного ускорения вдоль осей без угловых скоростей 😦 тьфу - сам запутался - всё нормально - угол ушел, а по соответствующей оси нет угловой скорости или она меньше тогда да П1/П2 - коэф влияния акселя - меньшее делим на большее - получаем меньше меньшего, большее делим на меньшее - получаем больше большего - только придётся ввести пределы а вот дальше муторней но интересней П2+Д2=П2-П1+И1 почти “классический” ПИД, но в нём нет лишних интеграторов, а интегральная составляющая в зависимости от ошибки не собирает сумму ошибок (увеличивает П), а уменьшает/увеличивает диф. составляющую, что в свою очередь позволяет довернуть пропорцией П2…
уточню - управление в данном случае по угловой скорости т.е. П1= РУ+угловая скорость (которую нужно погасить)
так упорядочу мысль:
/*фильтр*/
П1=угловая скорость+сигнал управления
угол =угол предыдущий+П1 *дт // управляющий вектор надо учесть
угол =угол*(1-П1/П2) + угол акселя*П1/П2
угол предыдущий=угол
/*регулятор*/
И1=угловая скорость *дт // так наверно правильней надо подумать… дельта угла?
П1И1 = П1-И1 //они противоположны
Д2=П1И1
П2=угол
Выход=П2-Д2
И1=угловая скорость *дт // ошибка
режет глаз… ошибка полюбому это разница между чем то и чем то… мой мозг отказывается понять замысел… (слабоват наверно)))
переделал)))
/*фильтр*/
П1=угловая скорость+сигнал управления
угол =угол предыдущий+П1 *дт // управляющий вектор надо учесть
угол =угол*(1-П1/П2) + угол акселя*П1/П2
/*регулятор*/
И1=угол предыдущий // не докрутили в прошлый раз
П1И1 = П1-И1 //они противоположны
Д2=П1И1
П2=угол
Выход=П2-Д2
угол предыдущий=угол
нафиг
/*фильтр*/
угол предыдущий=угол
П=угловая скорость+сигнал управления
угол =угол предыдущий+П *дт // управляющий вектор надо учесть
угол =угол*(1-П/И) + угол акселя*П/И
/*регулятор*/
И - угол
Д= угол предыдущий
//тогда всё сводится классически
П1+Д1-И1
не нравится - пойду на бумажке писать…
угол =угол предыдущий+П *дт // управляющий вектор надо учесть
Где его надо учесть, в ИНС? Сомневаюсь, так получается дал ты стиком крен влево, и у тебя крен начал заваливаться ДАЖЕ если коптер на столе стоит. Неправильно это…
Где его надо учесть, в ИНС? Сомневаюсь, так получается дал ты стиком крен влево, и у тебя крен начал заваливаться ДАЖЕ если коптер на столе стоит. Неправильно это…
да получается, но это предсказатель шага, а дальше надо уже делать всё заново но с показаниями датчиков, могу расписать…
/**фильтр**/
/*предсказатель*/
П_угол =угол предыдущий+Д *дт // управляющий вектор надо учесть
/*вычислитель*/
угол предыдущий=угол
угол =угол предыдущий+угловая скорость *дт
угол =угол*(1-Д/(П-И)) + угол акселя*Д/(П-И) // в примере - допустим нет угловой скорости тогда И большое Д маленькое, Д/(П-И) - маленькое, есть угловая скорость Д большое И маленькое - практически получаем связку Д/П - больше доверия акселю…
/**регулятор**/
П=угол
Д= угловая скорость+сигнал управления
/*ошибка*/
И=угол-П_угол
//тогда всё сводится классически
П-Д+И
короче вчера дорисовался до двухступенчатого фильтра типа EKF и понял что ни то ни другое не исправит ситуацию, можно фильтронуть только белый шум, а тут он получается цветной причём всё время разный…
управляющий вектор надо учесть
кренпитч = комплексный угол исходя из крена и питча
управляющий вектор (длина проекции вектора в плоскости земли) = тяга создаваемая моторами * cos(кренпитч)
но тяга создаваема я моторами это даже на пвм на моторы умноженная на коэф. ибо батарея может иметь разный заряд. скорее потребляемый силовой установкой ток помноженный на кривую кпд
направление управляющего вектора должно совпадать с направлением комплексоного угла ролпитч
решение подходит для мультироторов с нулевыми выкосами моторов и центром тяжести расположенным в центре приложения тяги.
в случае выкосов моторов и смещения центра тяжести нужны поправки
управляющий вектор = тяга создаваемая моторами * cos(кренпитч)
я сейчас мыслю в том ключе, что я задаю определённым положением стика - определённую угловую скорость, не в зависимости что там на моторы подаётся - это “предполагатель” а уже ПИД решает на основе “предполагателя” чё ему делать за счёт ошибки “предполагателя” должен дотягивать интегральной составляющей до истинного угла не взирая на батарею, ветер, джедаев со своей силой…
надо только со знаками определиться (((