Создание собственной системы стабилизации
Товарищи, здравствуйте,
ваяю полетный контроллер на stm32f4, хочется очень иметь на борту понимание, сколько “топлива” осталось.
и вот вопрос - при 4 аккумуляторах по 3 банки получается два варианта - через делитель напряжения “смотреть” на 11.1 в или “смотреть” на напряжение в банках?
Что по Вашему мнению практичнее и полезнее?
Ножек хватает и для того чтобы смотреть 12 банок
Делать планирую через ADC Analog WatchDog
Практичней и полезней считать амперчасы при условии что акум адекватный. А напряжение ожно снимать с верхней банки, но это будет грубый контроль аварийного остатка.
ну контроль каждой банки в отдельности ессно лучше чем всех разом … но как уже правильно написали это грубый контроль …
те нужно летать так чтобы в аккумах оставалосЪ хотябы 20% заряда … просто у лития отследить по напряжению момент разряда достаточно сложно , в конце разряда напряжение падает достаточно быстро и можно банально неуспеть сесть …
если планируется летать с меньшим запасом заряда , то только ставить датчик тока и считать миллиамперчасы … ессно нужно знать точную емкость аккума …
Ну вот достиг небольших успехов в освоении STM32F3Discovery, собрал из ейного родного УСБ демо-проекта и своих кусочков демоИНС, соответственно в самом простом минимальном варианте без компаса и подсчетов линейных скоростей. Последнее проблематично, т.к. для считывания акселя использую родной демо драйвер с неисчислимым временем считывания, что размывает постоянную интеграции и соответветсвенно точность подсчёта линскорости. Продвижение на начальном этапе слишком осложнили праздники, собственная невнимательность, обновленные переф.библиотеки и отсутсвие в кейле 460 отладки (!!!) под перефирию F3. Но дальше должно пойти легче)))
Проектик прилагаю, кому недосуг но есть желание ХЕкс тожа приложен ))). Если хотите могу выложить демо-отображалку под питон сколоченную без единого гвоздя из pololu’вской.
За стиль не ругать! - это “пьяный кулак палец”
Ну вот достиг небольших успехов в освоении STM32F3Discovery, собрал из ейного родного УСБ демо-проекта и своих кусочков демоИНС, соответственно в самом простом минимальном варианте без компаса и подсчетов линейных скоростей.
я вот тоже решил добраться до освоения stm32, но заказал STM32F4Discovery… начнем сразу с F4 так сказать! 😃
кстати, по поводу вашей собственой системы стабилизации? код открыт или проект для себя/коммерческий?
если открыт, то какие фишки у вас уже летабельные? и где можно посмотреть?
В данный момент, оссобенно интересны, решения увеличения точности ГПС по акселю… по сути таже инерциалка, но с коррекцией нулей/биасов на устранение дрейфа…
я вот на днях получил X,Y ускорения горизонтальные независимые от наклонов коптера, проинтегрил в скорость, привязал к основному пид регулю и даже полетал 😃
резкие толчки отрабатывает, но блин да, без коррекции дрейф безбожный…
но заказал STM32F4Discovery… начнем сразу с F4 так сказать!
Процы F3 и F4 имеют аппартурное умножение, но Ф4 в 2 раза быстрее по такту, но мне это особо без надобности пока, Ф103й пока не догружен. Ф3Дескавери брал потому,что самому паять лень, если б китайцы прислали PX4FMU то и не брал бы)))
там ведь всё иму есть, ну кроме баро и памяти настроек, стОит копейки. На Ф4дискавери только аксель из интересного… ну и там эта… микраУСБ… для отладочной платы штука наипративнейшая…
код открыт или проект для себя/коммерческий? если открыт, то какие фишки у вас уже летабельные? и где можно посмотреть?
проект я делал для себя из-за личных комплексов (как тут в одной ветке сказали) - “сам смогу или нет?” Продовать никому не собирался, но в связи с конкурсом Крока получается “коммерческий для себя”. Но так как в самом лётном алгоритме ничего секретного нет, то летающий проект под Ф103 валяется гдето на этой ветке (лень искать ссылку).
Фишек особо нет никаких потому как цель “на слабо” с самим собой достигнута. Хотя прикрутить ГПС не составляет особого труда, но вот для того чтоб его использовать (полёты по точкам и т.п.) требуется много рутинного программирования (что лень и некогда), фишки с оптодальномерами по понятным причинам обнародовать пока не могу,а видео с удержанием высоты вверху этой страницы.
А вообще самая интересная (на мой взгляд), и не реализованная пока, фишка к коптерам не относится - автоматический пилотаж самоля, либо удержание пилотирумого делитантом (ребенком) аппарата в заданном кубе пространства (высота не выше\не ниже, и квадрат очерченный координатами). Т.е. пилот внутри этого куба творит всё что хочет, но как только аппарат приближается к границе, он от неё “отскакивает” внутрь куба. Математика под это на мат модели проверена, допилить код не долго, но вот мозга для установки на самоль я пока не сделал(((
В данный момент, оссобенно интересны, решения увеличения точности ГПС по акселю… по сути таже инерциалка, но с коррекцией нулей/биасов на устранение дрейфа…
Это у меня в коде есть,
//vAccSm += (vVins-vVabsB)* 0.007f;
//vVins -= (vVins-vVabsB)*kVcor;
в это проекте пока закоментировано,т.к. работа с акселем пока неадекватна.
На рабочем проекте практика показала что не всё так просто… какнидь покажу видео…
Нуа эту Ф3дискавери планируюиспользовать как основную в конкурсе крока.
Процы F3 и F4 имеют аппартурное умножение
там ведь всё иму есть, ну кроме баро и памяти настроек, стОит копейки
нда… проглядел я F3… тут и FPU и сенсоры все что надо есть на поиграться, но не понятно какого качества и применимы ли на вибро-платформах… также у F3 ресурсов поменьше, памяти и флеша в 4 раза…
но в связи с конкурсом Крока получается “коммерческий для себя”. Но так как в самом лётном алгоритме ничего секретного нет, то летающий проект под Ф103 валяется гдето на этой ветке (лень искать ссылку)
я уже решил отказаться от участия… времени мало и далеко от рашки… проблематично будет высылать все оборудование и дистанционно подготавливать техника-пилота к конкурсу…
А вообще самая интересная (на мой взгляд), и не реализованная пока, фишка к коптерам не относится - автоматический пилотаж самоля, либо удержание пилотирумого делитантом (ребенком) аппарата в заданном кубе пространства (высота не выше\не ниже, и квадрат очерченный координатами). Т.е. пилот внутри этого куба творит всё что хочет, но как только аппарат приближается к границе, он от неё “отскакивает” внутрь куба. Математика под это на мат модели проверена, допилить код не долго, но вот мозга для установки на самоль я пока не сделал(((
это вроде как уже есть в арду…
вопрос: как моделирование делаете? какие тулы/проги для этого удобнее… мне этого часто не хватает, но тоже руки не дошли пробить почву… вроде как матлаб можно с некоторыми из симуляторов коннектить?
На рабочем проекте практика показала что не всё так просто…
в том и дело… аксель в локальных координатах коптера (и полученная скорость с него соот-но), а гпс скорость/смещение в глобальных/абсолютных координатах… что к чему вращать и приводить я пока не определился… скорее всего аксель надо будет крутить в абсолютные координаты, т.к. (вроде… еще не разбирался хорошо) все расчеты по гпс (в том числе в его пид регулях) ведутся в абсолютных координатах и лишь результат после пид регуля (из гпс модуля) уже ворочается в локальние координаты коптера перед микшированием в основной пид регулятор на ролл/питч… это все про вий соот-но…
это вроде как уже есть в арду…
неслышал о таком, надо будет поинтересоваться…
вопрос: как моделирование делаете? какие тулы/проги для этого удобнее… мне этого часто не хватает, но тоже руки не дошли пробить почву… вроде как матлаб можно с некоторыми из симуляторов коннектить?
В матлабе есть Симулинк, в нем есть чтототам “авиакосмос”,вот в нем есть готовые объекты акселей гиро и тд, кроме того туда можно джойстик подключить и рулить матмоделькой).Я отрабатываю чисто математические модели, зачастую примитивные, но позволяющие проверить качество теории, а вот потом при переходе к практике начинается самое интересно)))
скорее всего аксель надо будет крутить в абсолютные координаты, т.к. (вроде… еще не разбирался хорошо) все расчеты по гпс (в том числе в его пид регулях) ведутся в абсолютных координатах и лишь результат после пид регуля (из гпс модуля) уже ворочается в локальние координаты коптера перед микшированием в основной пид регулятор на ролл/питч…
Всё верно, у меня всё так, ингода правда наоборот ))) всё приводится к бортовой СК, у меня методы вращений сразу в ИНС-объект вставлены
/* ïîëó÷èòü âåêòîð â áîðòîâîé ÑÊ */
vector3 INS::Vect2Bort(vector3 vVg)
{
Quaternion q(vVg.x,vVg.y,vVg.z,0);
q = qINS.conjugated()*q*qINS;
vector3 v(q.x,q.y,q.z);
return v;
}
/* ïîëó÷èòü âåêòîð â ãëîáàëüíîé ÑÊ */
vector3 INS::Vect2Glob(vector3 vVb)
{
Quaternion q(vVb.x,vVb.y,vVb.z,0);
q = qINS*q*qINS.conjugated();
vector3 v(q.x,q.y,q.z);
return v;
}
в кватернионах это просто!
вроде как матлаб можно с некоторыми из симуляторов коннектить?
я когда-то подключал симулятор AeroSimRC к CopterControl-у и прочим наземным станциям, там железо рулило симуляторной моделькой. однако интерес к опенпилоту как-то угас, но осталась не совсем законченная идейка: подключить к симу простой скриптовый язык, чтобы отрабатывать алгоритмы управления просто переписывая скрипты, без компиляций и прочего железа.
сейчас имеет передача из сима данных от акселя, гиры, GPS в Lua-плагин (данных намного больше, но выбраны только имеющие свои реальные “аналоги”), дальше все зависит только от фантазии. есть стандартные математические функции, чуть-чуть векторно-матричных преобразований, работает простейший ПИД-контроллер. практический минус только один, частота обновления не превышает 60Гц (частота развертки монитора), более синхронизироваться не на чем.
собственно, если есть интерес по отработке именно алгоритмов используя Lua (вернее, LuaJIT 2.0.0), то могу как-то это дело выложить в удобоваримом виде.
p.s.
матлаб это конечно здорово, но самолеты-коптеры модельных размеров более-менее адекватно симулирует только вышеназванный сим.
неслышал о таком, надо будет поинтересоваться…
мне знакомый ардукоптерист говорил, ток вот забыл как это мод называется…
а я вот с матрицами поворотов и кватернионами туплю пока… оссобено со знаками осей… в двух осях заблудиться можно… ))
Всё верно, у меня всё так, ингода правда наоборот ))) всё приводится к бортовой СК, у меня методы вращений сразу в ИНС-объект вставлены
тогда где демо удержания позиции как у вис.аста? 😃
а я вот с матрицами поворотов и кватернионами туплю пока… оссобено со знаками осей… в двух осях заблудиться можно… ))
Да не надо блудить. Если понимаете, что такое углы Эйлера ДСМ матрицу могу объяснить на пальцах (не путать с распальцовкой) Квартерионы это просто другое представление. Все очень просто.
Игорь, рад видеть! Давновато вас видно не было…
Да не надо блудить. Если понимаете, что такое углы Эйлера ДСМ матрицу могу объяснить на пальцах (не путать с распальцовкой) Квартерионы это просто другое представление. Все очень просто.
Накидайте ссылок полезных тогда на статьи/литературу, которая вам помогла 😃
Гуглить то я умею, но интересны именно “полезные” материалы…
Квартерионы это просто другое представление. Все очень просто.
кстати, я вполне могу объяснить использование кватернионов в 3D-графике и/или в играх, но до сих пор не понимаю, зачем они нужны в “нашем” случае. их использование дает профит только в одном случае, когда нужно повернуть одновременно больше 4-х точек в пространстве либо для построения “гладкого” пути (сплайна) между двумя положениями.
“у нас” кватернионом можно задать текущее положение аппарата плюс необходимое положение. накладные расходы (процессорное время) намного больше даже с учетом экономии памяти, по сравнению с обычным матричным расчетом. конвертация в/из углов эйлера также намного затратнее. да и от матриц все равно никуда не деться.
неслышал о таком, надо будет поинтересоваться…
Фича называется GeoFence.
Фича называется GeoFence.
судя по видосу и отличному качеству удержания в 2.9RC1 прикрутили аксель на удержание высоты?
rcopen.com/forum/f123/topic233564/1848
rcopen.com/forum/f123/topic233564/1855
судя по видосу и отличному качеству удержания в 2.9RC1 прикрутили аксель на удержание высоты?
Там не только для удержания высоты, но и по X Y еще аксель используется, правда по умолчанию отключена…
Попытки использовать аксель для оси Z у них давно в коде были, видимо только сейчас довели до ума…
Ребята там действительно толковые сидят, но распыляются по сторонам… Вот сейчас код адаптируют под платформу PX4. Правда уже давно код вылизывался под компиляцию под разные процессоры. В Версии 2.9 сделали(делают) HAL, правда все равно коряво, т.к. полной независимости все равно нет, например драйвер MPU6000 жестко завязан на интерфейс SPI? ну и т.д. 😃
но и по X Y еще аксель используется, правда по умолчанию отключена…
значит скорее всего не работает еще, т.е в альфа зачатках… чую пока Виктор (вис.аста) будет думать, что делать с его наработками, так опен сорсы не хуже летать начнут 😃
Там не только для удержания высоты, но и по X Y еще аксель используется, правда по умолчанию отключена…
Попытки использовать аксель для оси Z у них давно в коде были, видимо только сейчас довели до ума…
тут похоже с появлением нормальных сенсоров (mpu6050/6000 + ms5611) стало получаться… у меня с bmp085 + bma020 раньше тоже хрен что получалось, а с mpu6050 + ms5611 почти с первой попытки…
Ребята там действительно толковые сидят, но распыляются по сторонам… Вот сейчас код адаптируют под платформу PX4. Правда уже давно код вылизывался под компиляцию под разные процессоры. В Версии 2.9 сделали(делают) HAL, правда все равно коряво, т.к. полной независимости все равно нет, например драйвер MPU6000 жестко завязан на интерфейс SPI? ну и т.д.
крута! no comment как грится…
А может нам придумать новую платку под самодельный контролер. Какие датчики счас самые актуальные?
тогда где демо удержания позиции как у вис.аста?
У меня нет “абсолютных” датчиков, т.е. баро и ГПС. Использовал чистый аксель, если посмотреть на серый вектор при включенных моторах, то всё станет понятно
У Виктора аналоговые датчики и ПХ4, которую я в руках не держал…
но до сих пор не понимаю, зачем они нужны в “нашем” случае. их использование дает профит только в одном случае
а я ничего другого не понимаю )))
А может нам придумать новую платку под самодельный контролер. Какие датчики счас самые актуальные?
Это к SergDoc, если посмотрите ветку найдете много разных вариантов.
У меня пока не получается VET6 в два слоя уложить 😦 (как ни крути переходные отверстия под процем - как серпом по я…) , вот RGT6 как раз, но, но нету у меня его… мучаю дальше, про автотрассировщик уже забыл (игл - птыц гордый, столько дырок клюёт - мама не горюй) - всё вручную…
У меня пока не получается VET6 в два слоя уложить (как ни крути переходные отверстия под процем - как серпом по я…) , вот RGT6 как раз, но, но нету у меня его… мучаю дальше, про автотрассировщик уже забыл (игл - птыц гордый, столько дырок клюёт - мама не горюй) - всё вручную…
а какие датчики ставить будете???
Накидайте ссылок полезных тогда на статьи/литературу, которая вам помогла 😃
Гуглить то я умею, но интересны именно “полезные” материалы…
Исходно про углы Эйлера почитать нужно. Матрица - это просто удобное представление для преобразования вектора при переходе из одной системы координат к другой
На Диудроне была статейка на английском по DCM матрице. А реализацию алгоритма проще всего посмотреть в ArducopterNG. Дальше ничего по существу не менялось. Вынесли DCM матрицу в библиотеку.
А может нам придумать новую платку под самодельный контролер. Какие датчики счас самые актуальные?
Уже видел MPU9150. STM тоже наваял кучу вариантов. Но учитывая что ALL IN ONE PRO Flight Controller v1.0 стоит 35 дол. с хорошими датчиками смысла свое ваять особого нет. Будет намного дороже. Я тут попытался плату датчиков сделать, но к тому моменту, когда платы изготовили стало уже неинтересно. И лежит Навстар с Глонасом - пылятся.