Создание собственной системы стабилизации
Как и обещал запили пару тестов
А алгоритмы вы сами с нуля писали, или брали чтото готовое за базу?
Ядро UKF взял с проекта Autoquad
Mono SLAM.
если я правильно понял, камера используется только для определения маршрута следования, о 3D ориентации речь не идет, и “3D сканировании пространства” тоже…
Как и обещал запили пару тестов:
стенд ништяк! просто и надежно!
Попробую применить в INAV.
Я как понимаю, основная фишка INAV в том, что стабилизация остается четкой как на гоночных квадах. Не убьет ли эту основную особенность применение других алгоритмов вычисления положения?
Я как понимаю, основная фишка INAV в том, что стабилизация остается четкой как на гоночных квадах. Не убьет ли эту основную особенность применение других алгоритмов вычисления положения?
Основная фишка INAV в том, что у нее выше точность навигации по GPS, имеется полет по точкам, более умный возврат домой. Стабилизация как на гоночных квадах - побочный эффект борьбы за точность навигации - без четкого контроля за ориентацией коптера супер-точное вычисление позиции не даст преимуществ.
без четкого контроля за ориентацией коптера супер-точное вычисление позиции не даст преимуществ.
Так и я об этом. Если отказываться от родных алгоритмов контроля ориентации в клинфлайте и переходить на чтото другое, то и основной посыл разработки теряется. Это уже будет совсем другой проект, мало относящийся к клинфлайту.
Так и я об этом. Если отказываться от родных алгоритмов контроля ориентации в клинфлайте и переходить на чтото другое, то и основной посыл разработки теряется. Это уже будет совсем другой проект, мало относящийся к клинфлайту.
Почему будет же другой? Он уже другой. Вычисление позиции в Клинфлайт перекочевало из INAV, PID-контроллеры в INAV свои (возможно скоро сблизятся с Бетафлайтом) 😃
Другие алгоритмы не значит что мелкие гоночные коптеры станут хуже летать, а если станут - нафиг-нафиг такие алгоритмы 😁
ненужен клинфлайту инав, тяжелые алгоритмы просадят производительность, гоночному коптеру не нужно четко держать точку по жпс, ему нужно уметь вернуться с полукилометра в сторону точки старта с точностью 10м и это даже с избытком.
логику можно применить самолетную даем питч вперед, по ролу -левел, и сравниваем курс по жпс и азимут, рулим явом
ненужен клинфлайту инав, тяжелые алгоритмы просадят производительность, гоночному коптеру не нужно четко держать точку по жпс, ему нужно уметь вернуться с полукилометра в сторону точки старта с точностью 10м и это даже с избытком.
INAV и на 210-й мелочи летает отлично. В том числе в навигационных режимах. В разработке кое-какие идеи по улучшению полетных характеристик с меньшей загрузкой процессора.
Гоночные коптеры на полкилометра не летают. А если летают - то это уже не гоночные, а что-то другое.
Гоночные коптеры на полкилометра не летают. А если летают - то это уже не гоночные, а что-то другое
в руках новичка еще как улетают! для того и возврат нужен.
Привет всем. Обкатал UKF на коптере, штука своебразная. Летает без использования магнитометра. Но!! если коптер висит на месте, курс уплывает и начинаются небольшие гуляния, в процессе гуляний, курс корректируется снова. Алгоритму важно чтобы центр отсчета акселя совпадал с центром датчика ЖПС, поэтому нужно либо лепить его на плату, либо придумывать программные ухищрения с компенсацией этого явления, как в моем случае. Из плюсов UKF - можно летать в POSHOLD на больших скоростях и довольно точно удерживаться в точке. То есть диапазон скоростей и наклонов большой. Из минусов - около 60-70 процентов процессорного времени кушает именно UKF. Очень сложен в настройке и капризен в показаниях датчиков.
Из наблюдений - я ошибался, что UKF по своей природе может отбраковывать неверные показания датчиков, на самом деле он может так делать, если разработчик внесет механизм выявления неверных показаний, при этом нужно просто увеличить ковариацию шума датчика, UKF сам перестанет вносить его в расчеты.
Снял пару видосов:
Снял пару видосов
Супер
Но!! если коптер висит на месте, курс уплывает и начинаются небольшие гуляния, в процессе гуляний, курс корректируется снова.
Я так понимаю, это в безветренную погоду. А если есть ветер, который вносит дрейф?
Без разницы в какую погоду, для данного UKF главное, чтобы было движение, тогда показания будут качественными. Ветер - это внешнее возмущение, и его отработка зависит от пидов удержания.
на вид хорошо держится,
а где подробнее почитать про ваш софт и хард?
UKF - взяли от автоквада, остльное свое-арду-прочее? проц? сенсоры?
Хард - STM32f407VGT6 - оценочная плата Discovery, вообще в планах сделать порт по F4BY, не зря ж его покупал, но времени не хватает.
датчики - MPU6500, MS5611, HMC5883L, Ublox M8N.
Ну еще датчики тока на каждый движок - ACS712ELCTR-30A-T, общий ток - ACS756SCA-100B. Датчик напряжения - просто резистивный делитель. Это скорее так, для исследований.
Дополнительно стоит ардуина на один из каналов приемника, отключает и включает по щелчку тумблера пульта всю силовую часть на коптере, в качестве ключа - 3 P-канальных MOSFETа - вот эта штука меня много раз спасала.
В пульт через приемник Frsky шлется телеметрия (спутники, напряжение, состояние и тд).
Для логирования SD-карта по SPI работает через библиотеку FATfs.
Двиги - 750 KV, регули - HobbyWing 40 A. Частота PWM 490 Гц.
Вся плата стоит на резиновых демпферах.
По софту - всем заправляет FreeRTOS, приоритет ядра выше приоритета прерываний.
Вертятся основные две задачи - Control (где все пиды, микшер, конечный автомат) и UKF (один общий для ориентации и положения)
Также куча маленьких задач по обработке данных с датчиков, сбору буфера логов.
Система работает примерно так: есть некая задача запроса данных, либо по внешнему прерыванию, либо по таймеру - происходит запрос данных с датчиков. Спустя какое то время происходит прерывание соответсвующего интерфейса (SPI, I2C), в котором выдается семафор. Соответсвующая задача обработки ловит этот семафор и обрабывает данные, выдает семафор для логов или другой обработки. Потом все происходит заново. Следует все общие переменные отгараживать мьютексами, а общие с прерываниями переменные защищать критическими секциями.
С микшером есть некоторые проблемы - пока все в нормальном режиме - все ок,. НО если происходит насыщение по ЯВУ, то происходит конкуренция угловых пидов и пида высоты, из-за чего коптер теряет устойчивость. Смотрел код ARducopera, ничего не понял, больно наворочено, но наверное у них такой проблемы нет.
Для ДУСа стоит внутренний фильтр на 41 Гц, для акселя - 20 Гц. К слову все измеряют вибрации акселя, но это скорее косвенный показатель, потому как он не влияет на управление. Одним из паразитных свойств ДУСа явялеся восприимчивость к ускорениям, и чем меньше восприимчивость, тем качественее ДУС. У MPU ДУС воспринимает эти вибрации, из-за чего они прямиком попадают в ПИД, из-за чего сильно ухудшается устойчивоть, поэтому надо ставить датчик на демпфер, НО если иметь хороший ДУС, то плату можно жестко ставить на раму.
Еще одно замечание - на улице барометр гонит какую-то ерунду, а если есть порывы ветра, то полагаться на него вообще бессмысленно, можт это у меня такой барометтр. Естестно я его укрыл паралоном и защитил от солнца. Поэтому в основном полагаюсь на высоту по GPS - она довольно качественная.
Красный график - это высота используемая в ПИДе, белый - по барометру, зеленый - по ЖПС
5611 баро бывают дефектные, попробуйте заменить,
в арду баро используется для долгосрочной, медленной коррекции высоты, кратковременый показатель - проекция акселей на нормаль
но скорее всего у вас так и сделано, иначе бы у вас не держал высоту т.к. данные жпс не настолько точны чтобы давать сантиметровую точность
С микшером есть некоторые проблемы - пока все в нормальном режиме - все ок,. НО если происходит насыщение по ЯВУ, то происходит конкуренция угловых пидов и пида высоты, из-за чего коптер теряет устойчивость. Смотрел код ARducopera, ничего не понял, больно наворочено, но наверное у них такой проблемы нет.
в принципе если проблема только с превышением по яву - то тут просто можно лимитировать яв воздействие некоторой константой.
в современных арду микшерах есть приоритеты стабильность по горизонту- стабильность по высоте - стабильность по яву
тоесть если для обеспечения стабилизации по ролу и питчу не хватает диапазона пвм одного из моторов то на исправления проблем с явом отводится только разница между требуемым пвм мотора и максимально допустимым значением
к примеру калибровка регулей 1000-2000
пусть для стабилизации газ-рол-питч выходит на 1 мотор нужно 1900
для стабизации яв на 1 мотор требуется +200
но 2000 - 1900 = 100 это то что остается яву
уменьшать расчет ява только на 1 канал нельзя т.к. это отразится на стабильности по рол-питчу, поэтому лимитируют яв на все каналы пропорционально
немного упрощенная модель управления моторами в арду у трикоптера, там нет так называемого “стабилити патча” который усложняет чтение кода,
если интересно - гляньте
Спасибо! как раз такого объяснения не хватало, посмотрю на код с этой позиции.
в качестве ключа - 3 P-канальных MOSFETа
Нельзя ли поподробней про эту фишку. (схемку бы, или на словах…)
Красный график - это высота используемая в ПИДе, белый - по барометру,
Да, барометр че то шумит не по детски, (может наводки какие…) , у меня реальный шум после фильтрации простым калманом сантиметров ~10 - 15…
шум барометра проявляется при резких наклонах, при активном маневрировании и сильных порывах ветра, если просто зависнуть, то барометр нормально показывает, не знаю как у людей что то на барометре летает, но при порывах ветра, показания скачут на 2-3 метра, даже с маленькой коррекцией от баро, коптер плохо летает. Может реально барометр битый.
вот схема откл/вкл силовой части