Comments 54
Мне кажется или серийный бюджетный dji phantom всё-таки значительно более стабилен?
В любом случае такое глубокое погружение в предмет — это всегда похвально. Удачи вам в развитии проекта!
В любом случае такое глубокое погружение в предмет — это всегда похвально. Удачи вам в развитии проекта!
Да, наша система стабилизации только приближается к «продуктовым» решениям. Надеемся, что этим летом получится это изменить.
Спасибо за напутствие!
Спасибо за напутствие!
Впечатляющее видео с демонстрацией возможностей квадов.
человеческий фактор — причина большинства аварий
Ручное управление еще очень долго будет превосходить автоматическое.
Для примера мое видео: (мозги dji naza lite, режим atti)
Ручное управление еще очень долго будет превосходить автоматическое.
Для примера мое видео: (мозги dji naza lite, режим atti)
Тут палка о двух концах ) Смогли бы вы вручную повторить, например, то, что показано в видео в предыдущем комментарии? :)
И не забывайте, без «мозгов» вы бы не смогли так полетать, да и вообще вряд ли смогли квадрокоптер поднять в воздух: основная часть работы все же приходится на «мозги» квадрокоптера, а вы уже даете высокоуровневые команды.
С развитием сенсоров, автоматический полет, подобно вашему, не будет проблемой. Другое дело, это будет не интересно )
И не забывайте, без «мозгов» вы бы не смогли так полетать, да и вообще вряд ли смогли квадрокоптер поднять в воздух: основная часть работы все же приходится на «мозги» квадрокоптера, а вы уже даете высокоуровневые команды.
С развитием сенсоров, автоматический полет, подобно вашему, не будет проблемой. Другое дело, это будет не интересно )
Кстати, видео в предыдущем комментарии демонстрирует систему стабилизации с использованием внешней камеры. В лабораторных условиях коптеры и жонглировать умеют, но стационарная камера и внешний компьютер сильно ограничивают область применения.
Для того, чтобы человек так управлял коптером, всё равно нужен опыт. В индустрии, на мой взгляд, более важны решения «из коробки». Пусть даже следующие несколько лет автоматика будет туповатой.
Но видео потрясающее, это раньше не видел.
Но видео потрясающее, это раньше не видел.
Ещё важно, чтоб пилот не отвлекался и не «зарулился». Это как с автопилотом в автомобилях: в теории, у автопилота и реакция лучше, он не устаёт, не отвлекается на телефонные звонки, способен видеть то, что не видит человек, но все же развитие техники, а именно развитие «сенсорики» тут немного отстает.
Вы летаете под проводами и над головами людей и гордитесь этим? А что будете делать, когда коптер таки заденет ветку или провод и приземлится лучём в голову водителя мопеда?
Я не понимаю, чем вы хвастаетесь. Безусловно у вас есть выработанные навыки пилотирования квадром. Но летать в густонаселенных районах, в том числе над проезжей частью через провода, растительность считаю абсолютной халатностью. Сколько весит ваш квадрокоптер?
UPD #1: Я всегда буду обновлять комментарии перед постингом.
UPD #1: Я всегда буду обновлять комментарии перед постингом.
Очень здорово, что вы решили делать с нуля, то что вы так разобрались в реализации. Но тогда совсем непонятен выбор аппаратной платформы.
Зачем плодить очередную ардуиноподелку, когда вы все равно начали разбираться с этой темой с нуля? Возьмите более подходящий контроллер, те же DSPшные STMки, нормальную микросхему мемс от них же, в которой сразу интегрированы компас, аксель и гиро.
Поставьте туда Фри-РТОС, который откроет широчайшие возможности по реализации ваших задумок по автономности.
И у вас будет продукт, который изначально более интересен и оригинален, чем сотни поделок на ардуине — зачем же добровольно выбирать позицию «догоняющих», жаться на каждом байте, чтобы «разгрузить процессор», совершенно не подходящий для этой задачи и совершенно не оправданный.
Искренне надеюсь, что ваш проект пойдет в этом направлении и-таки вырастет в автономного дрона с нормальной РТОС на борту и с нормальным ДСП-железом, у него есть все шансы.
Зачем плодить очередную ардуиноподелку, когда вы все равно начали разбираться с этой темой с нуля? Возьмите более подходящий контроллер, те же DSPшные STMки, нормальную микросхему мемс от них же, в которой сразу интегрированы компас, аксель и гиро.
Поставьте туда Фри-РТОС, который откроет широчайшие возможности по реализации ваших задумок по автономности.
И у вас будет продукт, который изначально более интересен и оригинален, чем сотни поделок на ардуине — зачем же добровольно выбирать позицию «догоняющих», жаться на каждом байте, чтобы «разгрузить процессор», совершенно не подходящий для этой задачи и совершенно не оправданный.
Искренне надеюсь, что ваш проект пойдет в этом направлении и-таки вырастет в автономного дрона с нормальной РТОС на борту и с нормальным ДСП-железом, у него есть все шансы.
Полностью поддерживаю, кроме одного, а нужна ли там ОС? Задачи же примитивнейшие, но требуют минимальных задержек, операционная система тут не нужна совершенно. Для решения задач автономности систему нужно разбить на два вычислителя. Первый будет выполнять задачи положения аппарата в пространстве и его выравнивания, вывод аппарата на заданные координаты, обработку датчиков, а уж второй может медленно рассчитывать координаты, строить маршрутный лист и так далее, уж в нем можно и ОС использовать.
И к автору поста, мне кажется у вас допущена ошибка в реализации ПИД регулятора. По сути при вычислении углов эйлера вы интегрируете данные с гироскопов и корректируете их уход по акселерометрам/магнитным датчикам. Интегрирование — это всегда накопление ошибок. Потом, в самом ПИД регуляторе, а именно в демпфирующем звене вы дифференцируете теже самые углы эйлера, тем самым опять добавляете ошибку. Зачем? Ведь гироскоп у вас уже сам по себе датчик скорости, не надо добавлять ошибку к нему и ещё задерживать его, сразу умножайте его сигнал на коэффициент и подавайте сумматор.
И к автору поста, мне кажется у вас допущена ошибка в реализации ПИД регулятора. По сути при вычислении углов эйлера вы интегрируете данные с гироскопов и корректируете их уход по акселерометрам/магнитным датчикам. Интегрирование — это всегда накопление ошибок. Потом, в самом ПИД регуляторе, а именно в демпфирующем звене вы дифференцируете теже самые углы эйлера, тем самым опять добавляете ошибку. Зачем? Ведь гироскоп у вас уже сам по себе датчик скорости, не надо добавлять ошибку к нему и ещё задерживать его, сразу умножайте его сигнал на коэффициент и подавайте сумматор.
Про архитектуры я с вами согласен. Скорее всего, когда дойдёт до следования по маршрутам, будем применять 2 вычислителя.
Насчёт ПИД-регулятора: в реализации используем как раз показания с гироскопа (когда нужна угловая скорость):
Насчёт ПИД-регулятора: в реализации используем как раз показания с гироскопа (когда нужна угловая скорость):
Поскольку D-составляющая пропорциональна угловой скорости, можно прийти к мысли подавать на вход регулятора показания гироскопа вместо того, чтобы применять дискретную разностную схему.
ОС нужна чтобы код не превращался в, извините, говно.
FreeRTOS дает необходимый минимум, при этом практически не влияя на задержки, самые критичные части могут вообще работать параллельно с системой, она на них не будет иметь влияния. При этом это полноценная ОСРВ, все задержки предсказуемы.
Поверьте, код задач РТОС намного приятнее читать, поддерживать и отлаживать, нежели код, в котором то же самое реализовано своими велосипедами и костылями — а именно переключение между задачами по средством всяких флагов в интерраптах, синхронизация глобальными переменными и прочим.
FreeRTOS дает необходимый минимум, при этом практически не влияя на задержки, самые критичные части могут вообще работать параллельно с системой, она на них не будет иметь влияния. При этом это полноценная ОСРВ, все задержки предсказуемы.
Поверьте, код задач РТОС намного приятнее читать, поддерживать и отлаживать, нежели код, в котором то же самое реализовано своими велосипедами и костылями — а именно переключение между задачами по средством всяких флагов в интерраптах, синхронизация глобальными переменными и прочим.
Если они сейчас на «Ардуино» летают, то на чипах STM32 они получат в несколько раз большие частоты и скорость обработки самих команд в 1 такт вместо нескольких. Можно легко операционку влепить, тем более, RTOS — системы реального времени, когда по событию можно остановить всё, и запустить нужный блок. Но учитывая избыточную мощность, это вряд ли понадобится.
Что у всех последнее время за желание сделать еще одну свою «прошивку» для ардуинки чтобы коптер хотя бы как нибудь летал?
Круто конечно что разобрались в теме стабилизации (я вот до сих пор на это смотрю как на магию, понимая только примерно как работает). Но, судя по видео, ваш коптер не догнал по стабильности даже самые старые версии MultiWii, не говоря уже про ArduCopter.
Делать сегодня на AVR полностью автономные системы стабилизации — так себе затея, только ради just4fun для себя и в образвательных целях. Ниша AVR давно занята и из ардуинки в то же ArduCopter уже наверное максимум вытянули, а теперь 2 ветки (AVR и ARM) начинают разделяться, например в ARM (pixhawk) версии обещают EKF, инерциалку крутую, улучшеную автоподстройку ПИДов и т.д.
Круто конечно что разобрались в теме стабилизации (я вот до сих пор на это смотрю как на магию, понимая только примерно как работает). Но, судя по видео, ваш коптер не догнал по стабильности даже самые старые версии MultiWii, не говоря уже про ArduCopter.
Делать сегодня на AVR полностью автономные системы стабилизации — так себе затея, только ради just4fun для себя и в образвательных целях. Ниша AVR давно занята и из ардуинки в то же ArduCopter уже наверное максимум вытянули, а теперь 2 ветки (AVR и ARM) начинают разделяться, например в ARM (pixhawk) версии обещают EKF, инерциалку крутую, улучшеную автоподстройку ПИДов и т.д.
На самом деле, коптер мы начали делать несколько лет назад, когда кучи готовых решений еще не существовало. Но делаем мы его в свободное от работы/учебы/жизни время, поэтому получается достаточно медленно (и только в последнее время работу над ним удалось ускорить). Из-за этого сейчас действительно кажется, что это очередной велосипед на ардуине. Несколько лет назад мы посчитали что это платформа, которая отлично подойдет для прототипа, а после посчитали, что переделывать под другую платформу нет смысла, пока не определимся с требованиями к ней, а значит надо сначала заставить относительно стабильно работать эту.
Ведь смена платформы потенциально ведет к переписыванию тучи кода, отвечающего за взаимодействие с железом. Портируя код, можно насажать новых багов. Чем более отлаженным будет высокоуровневый код, тем проще будет портировать его на новую платформу.
Ведь смена платформы потенциально ведет к переписыванию тучи кода, отвечающего за взаимодействие с железом. Портируя код, можно насажать новых багов. Чем более отлаженным будет высокоуровневый код, тем проще будет портировать его на новую платформу.
В ArduCopter ввели такое понятие как HAL (Hardware Abstract Layer), который как раз отвязывает (на сколько это возможно) логику прошивки от железа, на котором это реализуется. Если есть силы и возможности, прошу, не делайте еще один контроллер+прошивку, а помогите нынешним проектам, тем более что наконец то начался приличный переломный момент ухода от AVR.
Это, конечно, хорошо, но мы точно лучше знаем свою платформу и реализацию взаимодействия железа в ней, чем чужую. Когда отладим высокоуровневую логику, переключиться, если захотим, будет просто, и это не будет включать в себя постоянных сомнений из серии «кто же всё-таки виноват?».
Планы к переходу есть, но делать его чисто из-за любви к пуризму нам кажется, на данном этапе развития проекта, неразумным.
Планы к переходу есть, но делать его чисто из-за любви к пуризму нам кажется, на данном этапе развития проекта, неразумным.
Ваш проект — ваше право, просто судя по всем «начинателям своего» на форуме мультироторном, реально довели до конца всего один проект (и довольно успешно, но человек никак себя не показывал, а сразу вылез с офигенно летающей и всё умеющей машиной). А писателей прошивок каждую весну вылезает штук по 10-15, но от висения уровня старого multiwii мало кто уходил, хотя планы были по захвату мира.
HAL впервые реализовали ОпенПилоты :) жаль что они уже 2 раза раскололись и темпы разработки сейчас даже хуже чем раньше :(
а ведь EKF у них был еще пару лет назад
а ведь EKF у них был еще пару лет назад
Товарищи спасибо запост. Сам занимаюсь данной тематикой в научном плане. Но я иду по пути arm и «нечутких Калманов». Пока плата изготавливается, там свои ещё косяки, решил поиграться с arduino. И мне кажется или она не способна считать данные с 8 датчиков (MEMS) и передать по uart со скоростью 38400 или опрашиваю датчики слишком часто. Вообщем появляются какие-то всплески с непонятным интервалом. которые на несколько порядков превышают допустимые.
Мы сталкивались с подобной проблемы (и частично ее описали в посте). В общем случае, не зная какие у вас конкретно датчики, ничего сказать не получится, но думаю, что etoestja сможет рассказать что-то подробнее на эту тему.
имеется ввиду абзац с fifo? В плане железа, mpu 9150+HMC5883L+adxl345+l3g4200d+bmp085 и arduino Uno. А etoestja написать можно?
Наверняка у вас есть на примете ссылочка, где можно быстро и в общих словах прочитать и понять, кто это такие — нечуткие калманы и для чего применяются? :-) Их вы применяете для фильтрации гироскопов и акселей, или еще они как-то могут быть применены вместо PID-регуляторов?
Первое видео — это в лагере под Дубной?
Да, лагерь Волга. Там проходит Летняя школа, в которой наша мастерская принимает активное участие.
Я знаю, что летняя школа была от РР, Гриша Тарасевич, вот это всё, а теперь она расширалсь на естественные науки? Или это какая-то другая?
это та самая Летняя Школа. TechnoWorks будет проходить в её рамках уже четвертый год. Журналисты и Гриша на ЛШ появились не сразу, изначально там были физики, медики и социологи. Сейчас направлений около тридцати, включая поведенческую экономику и нейролингвистику.
Летняя школа РР проводилась в Максатихе под Тверью и существует больше четырёх лет.
Летняя Школа проводилась и в Максатихе, и в деревнях Рождество, Ручки и некоторых других. Сейчас заключен договор с Объединенным институтом ядерных исследований и школа проходит на базе «Волга» под Дубной, принадлежащей ОИЯИ. И существует она больше десяти лет, каждый год список мастерских меняется. TechnoWorks принимает в ней участие четвертый год.
letnyayashkola.org/about/history/
letnyayashkola.org/about/history/
Техника безопасности для трусов? Летать на кустарном прототипе над детьми, конечно, смело, но очень глупо. Не говоря уже о том, чтобы настраивать на верёвке в маленькой комнате с людьми.
Начиная такой проект «в гараже» очень сложно сразу создать обстановку, в которой вся работа будет проводиться по-уму. Так что изначально техника безопасности имела не максимальный приоритет. Но сейчас, после нескольких опасных аварий, мы пересматриваем нашу позицию. Начинаем выделять на безопасность определённую часть бюджета, разрабатываем чек-листы для пилота и т. д. К сожалению, некоторые угрозы трудно устранимы: в той же Москве найти хорошую площадку без деревьев, столбов и детей довольно сложно.
Знакомая ситуация. В Лондоне сегодня уже не полетать именно из-за аварий. И спасибо ребятам из Discovery, которым очень хотелось полетать вокруг Big Ben. Сейчас обычно еду на поезде пол часа и потом ещё 15 минут на велосипеде, чтобы полетать. Или час на машине.
Такие дела, не совершайте ту же ошибку в Москве.
Такие дела, не совершайте ту же ошибку в Москве.
Скажите, а с чем связана частота регуляции 66 Гц?
На сколько мне известно, MPU6050 умеет отдавать обработанные данные с частотой 100 гц. Можно даже увеличить до 200, но, говорят, будут слишком шумные показания. Неужели цикл обработки не влез в 10 мсек?
На сколько мне известно, MPU6050 умеет отдавать обработанные данные с частотой 100 гц. Можно даже увеличить до 200, но, говорят, будут слишком шумные показания. Неужели цикл обработки не влез в 10 мсек?
А как у вас организовано вычисление углов? Именно на этапе между данными с датчиков и ПИДом — используются ли показания всех датчиков и потом «сшиваются»/«усредняются» в некое финальное значение (фильтром Калмана или каким-то другим способом) или же берутся показания одного из датчиков, акселерометра например?
Мы использовали интегрированный датчик InvenSence MPU-6050, который по показаниям акселерометра, гироскопа и магнитометра вычисляет кватернион движения на встроенном примитивном процессоре (DMP). Это помогло нам разгрузить Arduino, которая может быть даже не Due (на ARM), а Uno (AVR 16MHz). Так что в нашем случае работы с фильтрами вообще не было — фактически готовые координаты мы получаем с самого датчика. Подозреваю, что внутри MPU-6050 сырые данные фильтруются для устранения дребезга.
Спасибо за статью! И за верные формулы для углов Эйлера отдельное спасибо! :)
Sign up to leave a comment.
Автономный квадрокоптер с нуля: PID и грабли