Стабилизация квадрокоптера (PID)
Пропы должны быть жесткие. Я ранее потратил много времени не понимая что гибкие пропы на 11" у меня флатерят.
Думал что у меня наводки или вибрации на ПК. Он периодически резко вздрагивал по осям.
Вот я усредняю данные потому что заметил от гироскопа мощные импульсы 1-2 раза в секунду на оборотах 40%. Далее вроде учащаются случаи. И подергивается немного коптер от каждого импульса. После усреднения проблема пропала. Думал отложить решение этой проблемы, но лучше сразу найти причину.
На счет безопасности, у меня через 2 секунды ПК отключает мотор, если не получил команду с “земли”. Плавный спуск потом уж добавлю, когда выше 10см взлетит)
Стенд с шарниром - отличное решение!
Не представляю реальные задачи для таких маневров. Например при 5м/сек и радиусе в 50 метров ускорение 0.5м/сек.кв
Это даст погрешность в угле 2-3 гр всего atan2(100,2000) , Просто довернём рысканьем по Z и все.
Можно подумать на это способен в автоматическом режиме стандартный ПК, приведите пример.
Выложу ещё одну фичу. У меня на ПК через делитель сопротивления идёт бортовое питание.
U = analogRead(0)*0.0251;
Сразу получаем напряжение батареи в вольтах . Если умножить напряжение на газ висения , получим отличную переменную.
Я даю газ чтобы зависнуть , нажимаю кнопку и эту переменную записываю в память.
В любой момент времени деля переменную на текущее питание батареи получаем газ висения.
Пригодится для любых случаев.
Пригодится для любых случаев.
Те рекомендации реально помогли, спасибо! Реализовал с кватернионами и при вращении по одной оси ошибок почти нет, а при вращении по кругу (x,y,-x,-y) появляется ошибка 3-8 градусов наверное за 8 секунд. Это нормально? И калибровку акселерометра по z не сделать внутри коптера? Стенд надо городить?насколько это критично?
Кроме того, что было Вами сказано, в ПК больше ничего не надо добавлять?
Кватернионы взял из статьи: m.habr.com/ru/post/255005/
Вращение по кругу это как ? Если вокруг оси с пульта или руками то гиры по х и у не должны выдавать данные наклона.
Если только сам чип гироскопа не в центре осей коптера . Проведи эксперимент крути ПК на столе вокруг оси и смотри что даёт гира по дгугим осям.
Если ПК наклонить ровно на 90 гр по X или Y , что выдаст софт ? Если опросов с гир мало , могут быть пропуски данных и углы будут с ошибками.
Ошибку можно уменьшить по акселю , изменив фильтр. Стенд нужен только для калибровки осей X и Y акселерометра , чтобы знать точный горизонт.
По Z акселерометра калибровка не нужна. Калибровка X и Y акселерометра критична . Если ног нет можно положить на пол, проверив уровнем .
В принципе можно и без калибровки , использовать триммер. Тример на пульте, и пульт всегда шлёт угол на нужную ось.
Но лучше тример в мозгах , запоминаем переменную и её вычитаем из PID
oshibka_x =ug_xg - dx - trim_x
Без калибровки по гирам не обойтись совсем , главное в момент калибровки не трогать , положение коптера любое.
Попробу включи ПК и не трогай , посмотри что по осям .
В ПК добавлять ничего не надо , он висит и летает только за счет софта . Софт самое главное.
Если ПК наклонить ровно на 90 гр по X или Y , что выдаст софт ?
Выдаст 90 гр, как и должно быть. когда кручу по 1-2 осям - всё ОК. А когда по трем, то начинаются смещения.
Например, если плата в самолете, то держу за хвост и кручу за передний мотор по кругу. получается если не кренить, то задействованы оси x и z. И когда самолет возвращаю к начальному состоянию, все смещения показывают 0.
Но если при кручении добавить крен (ось y), то когда самолет возвращаю в начальное состояние, то по оси y будет не ноль, как должно быть, а там копится ошибка.
Так и должно быть или что-то ни так?
zealot01 ранее писал что при движении по кругу аксель начинает показывать
центростремительное ускорение .Появляется ложный угол наклона, который
вносит ошибку в коррекцию гироскопа. Как выриант можно уменьшать переменную коррекции гир по акселю в зависимости от данных Z пульта ( Курс, Yaw) . Но у тебя при отсутствии крена ошибка 0,
что непонятно. И в реале такие манёвры не возможны, очень маленький радиус вращения. Таже все данные верны если вращения идут через центр чипа гироскопа. При центре вращения сбоку гиры могут выдавать что угодно.
И только от софта зависит как это правильно обработать. И некоторые гироскопы могут выдавать ложные данные по X Y при вращении по Z.
Проведи эксперимент. Плата на столе , всё по 0. Подними наклони по X Y ( не более 40 гр ) с одновременным вращение по Z ( один оборот ) и верни на стол, что будет по осям.
Так и должно быть или что-то ни так?
Если считал только по калиброванному гироскопу, то дрейф от шумов и вибраций будет уводить показания. Нужно также поправлять по акселерометру. И даже тогда вектор направления будет крутиться вокруг оси z, нужно поправлять по компасу.) И таки да, ускорения негативно влияют на показания гироскопа.
Проведи эксперимент. Плата на столе , всё по 0. Подними наклони по X Y ( не более 40 гр ) с одновременным вращение по Z ( один оборот ) и верни на стол, что будет по осям.
Если вернуть плату “на место”, то по Y и Z будут отклонения.
Я перепроверил и оказалось, что ошибки не появляется только в случае вращения по одной оси.
Без исходного кода тут не разобраться. Я делал сначала глобальную переменную кватерниона нулевого вращения в памяти. Потом в цикле луптайма читал гироскоп по трем осям и определял по времени между циклами куда все отклонилось на последнем цикле, формировал по этим данным кватернион цикла. Потом перемножал глобальный кватернион и кватернион цикла и перезаписывал глобальный кватернион произведением. И так далее по циклу…
Здравствуйте, если кому интересно тоже написал прогу для стабализации на меге8 и двухстороннюю связь с пультом, тоже со со своей прогой. Обмен 32 байтами на скорости 1мб/с. На пульте отображаются любые параметры коптера, которые умещаются в 32 байта и в экран 16×4 символов. Правда изза того что у пульта не работал стик по рысканью, то управление только по 2 осям. И когда наконец когда понял что для полноцеенного управления по 3 осям нужны матрицы поворота или кватернионы, то понял что сил и времени не хватит. Кстати вычисления с плавающей точкой, время цикла 3 мс при 8 мгц.
Работа с nrf24l01 по spi на аппаратном прерывании, могу выложить, если интересно
У меня получилось без матриц. Тупо обычная тригонометрия и синусами и тангенсами . Давайте обсудим как стабильно удерживать высоту. У меня подозрение что в мавиках используют оптическую стабилизацию. Ну как в оптических мышах. Сравнивают кадры и по вектору смещения выдают перемещение по Х и Y. Вопрос где происходит сравнение в камере или отдельный процессор. И эти данные ПК использует для удержания позиции.
Ну просто не возможно висеть не подвижно в ветер в одной точке. Ни аксель ни барометр на такое не способен. Вот если камеру там закрыть и проверить на удержание , то все станет понятно. Что скажете.
Вот если камеру там закрыть и проверить на удержание все станет понятно. Что скажете.
Зачем закрывать? Мавик держит позицию в ветер ночью на любой высоте. Камера там точно не работает
Загуглил мавик эир, пишут:
точность позиционирования в вертикальной плоскости: ±0,1 м (визуальное) или ±0,5 м (спутниковое);
точность позиционирования в горизонтальной плоскости: ±0,1 м (визуальное) или ±1,5 м (спутниковое);
Там же сонар для определения высоты. Он по идее должен при любом освещении работать. Хотя както ночью чуть об землю не приложил. А вот позиция работает только при хорошем освещении и хорошо отличимом «рисунке» на земле.
У меня получилось без матриц.
И что, летает хорошо в маневрах полицейского разворота? Я просто уперся в то что если поднять квадр на бок, повернуть и положить на пол, то по факту он повернулся по z, а гироскоп естественно по y вернулся в то же положение, повернулся по х, а по Z гироскоп не поворачивался. Получается на боку вращение по х должно превращаться во вращение по Z. Просто жаль, что получилась очень не плохая телеметрия для визуального полета, но не уверен что это будет летать по 3 плоскостям.
Там же сонар для определения высоты. Он по идее должен при любом освещении работать.
Так сонар и работает при любом освещении, но только до высоты 15 метров. И сонар только определяет высоту, в отличии от камер, которые могут “зацепиться” за точку на поверхности.
Мне кажется, что у Мавиков все вычисления производятся мощным процессором, без помощи камер и сонаров - просто по данным с IMU
А вот позиция работает только при хорошем освещении и хорошо отличимом «рисунке» на земле.
Вот с этим “рисунком на земле” чуть не приложил один раз Мавик к дереву…
Ситуация была такая: Мавик плавно снижался на точку взлета и на высоте около метра что то на поверхности не понравилось, и он резко рванул в бок. После чего я отключил точное позиционирование от греха подальше
И что, летает хорошо в маневрах полицейского разворота? Я просто уперся в то что если поднять квадр на бок, повернуть и положить на пол, то по факту он повернулся по z, а гироскоп естественно по y вернулся в то же положение, повернулся по х, а по Z гироскоп не поворачивался. Получается на боку вращение по х должно превращаться во вращение по Z. Просто жаль, что получилась очень не плохая телеметрия для визуального полета, но не уверен что это будет летать по 3 плоскостям.
Надо добавить всего три формулы для переводя вращения по Z в изменения по осям X и Y. К примеру наклонили в право по X на 30 гр. Если развернём по Z на 90 гр по часовой стрелке по по X будет 0 гр. а на Y 30 гр. Вот это преобразование и надо реализовать в формулах. В них учитывать угол поворота по Z , квадрант и угол наклона по X и Y.
Мне кажется, что у Мавиков все вычисления производятся мощным процессором, без помощи камер и сонаров - просто по данным с IMU
Дело не в мощном процессоре, а в дополнительных вводных данных получаемых с сонаров и камер.
Ситуация была такая: Мавик плавно снижался на точку взлета и на высоте около метра что то на поверхности не понравилось, и он резко рванул в бок. После чего я отключил точное позиционирование от греха подальше
Не было никогда таких проблем. Только иногда мог ругаться на поверхность и запрашивал посадку.
Надо добавить всего три формулы для переводя вращения по Z в изменения по осям X и Y. К примеру наклонили в право по X на 30 гр. Если развернём по Z на 90 гр по часовой стрелке по по X будет 0 гр. а на Y 30 гр. Вот это преобразование и надо реализовать в формулах. В них учитывать угол поворота по Z , квадрант и угол наклона по X и Y.
Это все верно, но проблема в том, что оси гироскопа по сути математически равнозначны и вращение вокруг одной оси вызывает вращение двух других. Если мы рассуждаем, что вращение по Z переводит X в Y, мы также должны принять, что вращение по X меняет положение осей Z и Y, а вращение по Y меняет X и Z. Если этого не учитывать, то к дрейфу гироскопа прибавится ошибка вычислений.
Я думал насчет преобразований в этом смысле. То есть степень перехода одной оси в другую зависит от наклона третьей, типа синусов-косинусов. То есть если по Х у нас 45 градусов, то есть он стоит на полу на двух моторах под углом 45 к полу по осиХ. Я его вращаю не отрывая от пола и не меняя угла по Х. Получаю что относительно самого себя по Z я его не вращал, потому что оба мотора на полу, а показывает что вращал, хотя по факту вращал и по У и по Z… Я когда его крутил во все стороны и смотрел углы именно чисто гироскопа на экране пульта, то что то складывалось , а сейчас чот кружится все в голове от 3д картинок, надо мож было попробовать все таки управление по 3ей оси дописать и попробовать его в деле…
Такое ощущение что мы с вами крутимся вокруг этих матриц поворота только своими словами. Вообще заметил что все улучшения сейчас сводятся к введению зависимостей пидов от газа, угла наклона ручек, скорости их наклона, даже от ускорения их наклона и фильтрации шумов. Мне в принципе хватило бы и своей проги, но было желание летать в очках, но без осд думаю это не просто. Поэтому к сожалению уже дошел до матека 722 и прям балдею от кучи параметров полета в очках. Помню как еще во времена мультивия(господина Маховия) чуть ли не всем форумом пытались дотачивали его, хотя 90% писал он. Были времена…