Comments 13
нашел вот такое решение:
https://github.com/mrigang04/-STM32F411CEU6-Based-Flight-Controller
ну я бы посмотрел для начала реализацию у того же ardupilot. Там несколько реализаций ядра управления, DCM простейшая, EKF (extended Kalman filter) версий 2 и 3 в текущей репе, вот например EKF3 https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_NavEKF3/AP_NavEKF3_core.cpp
И кстати, multishot разве кто-то еще использует? Я бы брал какой нибудь Dshot600 как самый распространенный и поддерживаемвый AM32
Ещё бы это заработало.
Настроить фильтр Калмана так же сложно, как и PID-регулятор: никаких «волшебных» коэффициентов и универсальных архитектур - ни у Калмана, ни у других алгоритмов - не существует.
Качество работы достигается лишь при наличии мощной и непрерывной телеметрии.
Поэтому, когда в таких проектах сразу переходят к функциям управления двигателями, это выглядит как «забег вперёд паровоза».
Любые сторонние решения без беспроводной широкополосной телеметрии, построенные на ардуино, можно смело обходить стороной: аналогичный шлаκ ChatGPT сгенерирует и сам. А вот инфраструктуру для реальных исследований он за вас не создаст.
Расскажу о одной древней своей разработки. Как то надо было сделать ПИД контроллер для управления нагревателем воды. Приступая к работе изучил теорию ПИД регулирования. Мне она показалась какой то запутанной, а от формул я вообще впал в уныние.
Я решил писать свой велосипед. И в процессе писания своего велосипеда передо мной встали проблемы которые нужно решить, я с удивление обнаружил что эти проблемы похожи на тот высоко математический абстракционизм описывающий теорию ПИД.
После этого я реализовал ПИД в программе с уже пониманием где и как и в какое время влияет на график каждый из коэффициентов ПИД. Да и сами коэффициенты - это самое главное. Обычно люди их подбирают от балды. Потому, а как их ещё выбирать не зная как устроена железяка в которой реализован ПИД алгоритм?
Также был собран параллельно тестовый стенд с нагревателем и с датчиком температуры. Написана программа считывания и визуализирующая графики. И проведено множество тестов с логированием, пониманием - каждого коэффициента ПИД регулятора.
Насколько помню проблема была в том что реальные данные с датчиков имеют невысокую разрешающую способность, а математические функции ПИД регулятора требовали математической точности. Также в реальной программе контроллера пришлось реализовывать гибрид ПИД математики который мог бы нормально работать. Под этим я понимаю точность математики контроллера и сенсоров считывания. Потому как в формулах ПИД для нормальной работы (отсутствие самовозбуждения и прочего) единица после запятой может быть весьма далеко.
В итоге была разработан контроллер который работал почти идеально, настолько насколько позволяла точность сенсоров.
Это, в общем, стандартный путь... Сначала "нафиг мне эти ваши умные слова и математика", "тут всё просто", а в процессе написания приходят к тому же ПИДу, ТАУ, устойчивости регуляторов... Не вы первый, и не вы последний... И в других отраслях часто то же самое - "да нафига какие-то там алгоритмы, тут же всё просто", "зачем мне реляционная алгебра, просто возьму две таблички". Или даже "зачем мне какие-то расчеты прочности, возьму достаточно толстую доску, должна выдержать"
Пид для нагрева самое простое. Ыункция нагрева такая же как заряд конденсатора)) ПИ регулятоиа хаатит
Наверно стоит подсмотреть исходники Betaflight, INAV или Ardupilot. По-моему у них первый уровень стабилизации по угловым скоростям, а не по ориентации в пространстве.
Вот это я наверно и упустил. Т.е получается что основа стабильности коптера это данные угловой скорости с гироскопа, а не ориентация в пространстве. В пид регулятор идет ошибка между желаемой и текущей скоростью, а ошибка в ориентации это уже вторичные данные.
Коптер вообще может летать без акселерометра, только по данным гироскопа. Само собой с какой стороны земля он знать не будет и за все управление отвечает пилот. Вообще получение искусственного горизонта это большая проблема, потому что при полете на коптер действует куча сил кроме гравитации. Я в основном летаю на самолётах под INAV, даже там как следует поупражнявшись в пилотировании искусственный горизонт можно опрокинуть набок.
Большая часть более-менее быстрых FPV коптеров летают в "Acro" режиме, в котором коптер не использует данные гироскопа и где у него горизонт он не знает, ему это даже не очень интересно. Если хотите пример максимально "палка-верёвка" реализации, смотрите исходники multiwii, ей хватало Atmega32u4 для более менее приличного полёта(но конечно на порядок хуже, чем летают современные контроллеры)
Зачем это здесь ?
Новой информации никакой не дает, вы ничего своего не придумали и не написали. Половина статьи это вообще картинки из разряда "мигаем светодиодом на STM32". Техническая ценность данной статьи околонулевая. Нет никакой информации по настройке регуляторов, фильтров и т.д.
Вся статья из разряда "Как нарисовать сову". Поэтому нисколько неудивительно, что это не летает, так как все технические моменты, которые влияют на то, чтобы летало, просто пропущены. Лет 7-8 назад на Хабре писали более полезные статьи и про настройку регуляторов для полетных контроллеров и про фильтр Калмана и про Махони.
Программируем квадрокоптер на STM32