Почитал статью, спасибо за веру в мой проект и использование в образовательном процессе МАИ! Описан опыт использования довольно интересно и качественно.
Это не просто возможно, это и используется, в том числе в моем проекте. Среда Gazebo, которую я использую для симуляции, использует физический движок ODE для расчетов. Моя модель сейчас не идеально точна, но ее было достаточно для отладки кода.
Посмотрел. Со структурой и стилем кода, конечно, есть проблемы. Но если все это действительно работает и летает, и действительно сделано с нуля, тогда поздравляю, отличный результат!
В приоритете все-таки алгоритмы управления БПЛА в фундаментальном смысле, но не фичи, хотя эта фича не особенно сложная. Но в текущей версии ее сделать не получится: я не организовывал в дроне схему для измерения заряда батареи.
Интересное уточнение. Вообще я не изучал подробно, как в других полетных контроллерах реализован режим ACRO. Возможно, это разнится от прошивки к прошивке. В целом, этот нюанс, наверное, очень важен для пилотов, которые летают в ACRO, но с точки зрения понимания полетного алгоритма он не столь значим. Полетный режим ACRO у меня добавлен лишь для иллюстрации идеи полетных режимов и по умолчанию отключен. Я ни разу не пробовал в нем летать.
В полетных прошивках, где есть estimation позиции, например, при помощи GPS, есть способы при помощи позиции скорректировать ориентацию. Если есть только акселерометр и гироскоп — то идеально никак. Но можно принять, что пилот скорее всего будет пилотировать дрон так, что в среднем он будет в нейтральной ориентации. И подмешивать нейтральную ориентацию с маленьким весом. Тогда ориентация не уплывет.
Суть полетного алгоритма в том, чтобы дождаться новых данных с IMU и сразу же на них среагировать. Если данных нет, мы не можем на просто забить на это, мы должны ждать, пока появятся.
Да, я пытаюсь так и сделать. Потому что есть много идей, чего можно было бы добавить, но что сильно усложнит код. Возможно, стоит разделить проекта на две части? "Базовая часть", только с текущими функциями, и "практико-ориентированная" часть со всем фаршем?
Ну под "сном" я имел в виду idle планировщика задач, в каком-то смысле это тоже сон. Честно говоря, я не знаю, что он делает на ESP32, когда задач нет — переводит CPU в какой-то особый режим или просто делает бесконечный while.
У меня используется самый простой комплементарный фильтр, который объединяет один гироскоп и один акселерометр, этого, в принципе достаточно для полета. Но при желании можно добавить и другие датчики, поскольку по сути это взвешенная сумма значений.
Чтобы отдавать CPU на другие таски, которые могут выполяться параллельно (если их добавить). В "серьезных" полетных контроллерах, как правило, для чтения IMU все же используется прерывание.
Да, это я видел, правда уже после того, как разработал свой. Но этот дрон, насколько я понимаю, не претендует на простой и наглядный исходный код, который можно использовать в качестве учебного пособия. Его код даже не опубликован на GitHub а распространяется просто в виде ZIP-архива.
Вы правы, мой способ сборки вообще не претендует на простоту, в этом его и фишка. Проще всего взять готовый полетный контроллер. Кажется nanoLongRange кидали, но посмотрю.
Почитал статью, спасибо за веру в мой проект и использование в образовательном процессе МАИ! Описан опыт использования довольно интересно и качественно.
Это не просто возможно, это и используется, в том числе в моем проекте. Среда Gazebo, которую я использую для симуляции, использует физический движок ODE для расчетов. Моя модель сейчас не идеально точна, но ее было достаточно для отладки кода.
Посмотрел. Со структурой и стилем кода, конечно, есть проблемы. Но если все это действительно работает и летает, и действительно сделано с нуля, тогда поздравляю, отличный результат!
Этот дрон все же сделан на базе прошивки Crazyflie, так что не представляет собой чего-то сильно нового в плане софта.
В приоритете все-таки алгоритмы управления БПЛА в фундаментальном смысле, но не фичи, хотя эта фича не особенно сложная. Но в текущей версии ее сделать не получится: я не организовывал в дроне схему для измерения заряда батареи.
Интересное уточнение. Вообще я не изучал подробно, как в других полетных контроллерах реализован режим ACRO. Возможно, это разнится от прошивки к прошивке.
В целом, этот нюанс, наверное, очень важен для пилотов, которые летают в ACRO, но с точки зрения понимания полетного алгоритма он не столь значим. Полетный режим ACRO у меня добавлен лишь для иллюстрации идеи полетных режимов и по умолчанию отключен. Я ни разу не пробовал в нем летать.
В полетных прошивках, где есть estimation позиции, например, при помощи GPS, есть способы при помощи позиции скорректировать ориентацию.
Если есть только акселерометр и гироскоп — то идеально никак. Но можно принять, что пилот скорее всего будет пилотировать дрон так, что в среднем он будет в нейтральной ориентации. И подмешивать нейтральную ориентацию с маленьким весом. Тогда ориентация не уплывет.
Суть полетного алгоритма в том, чтобы дождаться новых данных с IMU и сразу же на них среагировать. Если данных нет, мы не можем на просто забить на это, мы должны ждать, пока появятся.
Накопленная ошибка из-за интегрирования гироскопа, вы имеете в виду? Поскольку есть калибровка, то не очень быстро, 5-10 минут, может.
Да, я пытаюсь так и сделать. Потому что есть много идей, чего можно было бы добавить, но что сильно усложнит код. Возможно, стоит разделить проекта на две части? "Базовая часть", только с текущими функциями, и "практико-ориентированная" часть со всем фаршем?
SITL у меня используется, мой симулятор как раз и разработан по принципу SITL.
Для этого нужно добавлять estimation и позиции тоже, а не только ориентации. Я его думаю сделать — по внешней камере, которая будет находить дрон.
Ну под "сном" я имел в виду idle планировщика задач, в каком-то смысле это тоже сон. Честно говоря, я не знаю, что он делает на ESP32, когда задач нет — переводит CPU в какой-то особый режим или просто делает бесконечный while.
У меня используется самый простой комплементарный фильтр, который объединяет один гироскоп и один акселерометр, этого, в принципе достаточно для полета. Но при желании можно добавить и другие датчики, поскольку по сути это взвешенная сумма значений.
Но если таска одна, тогда да, нет никакой значимой разницы между засыпанием и просто циклом.
Чтобы отдавать CPU на другие таски, которые могут выполяться параллельно (если их добавить).
В "серьезных" полетных контроллерах, как правило, для чтения IMU все же используется прерывание.
Это я нашел, но там последний коммит 5 лет назад. В ZIP-архиве файлов намного больше. Не думаю, что это официальный репозиторий этого проекта.
Да, это я видел, правда уже после того, как разработал свой. Но этот дрон, насколько я понимаю, не претендует на простой и наглядный исходный код, который можно использовать в качестве учебного пособия. Его код даже не опубликован на GitHub а распространяется просто в виде ZIP-архива.
Тем не менее выглядит интересно.
Вы правы, мой способ сборки вообще не претендует на простоту, в этом его и фишка. Проще всего взять готовый полетный контроллер.
Кажется nanoLongRange кидали, но посмотрю.
Верное замечание, но ArduPilot все-таки изначально делали только для практических целей, а не образовательных.