Идея - 2 дополняющих друг друга мозга на коптере!
Как вы из этих значений получаете линейные ускорения?
Чукча не математик однако )))
Но вот сходу, тупо и не затейливо: Смотрим на коптер сзади, А0 и А1 - правая сторона, А2 и А3 - левая сторона.
предположим что состояние покоя по всем А = 0, значить если просела например левая сторона, то на нынешних мозгах мы получим по факту А0=А1=А2=А3=100 + показания гиры.
Нынешние мозги будет выравнивать коптер исходя именно из этого(ну еще показания гиры проучаствуют в расчетах) - мы на 100 увеличим обороты моторов на левой стороне и внимание!!! на 100 же уменьшим на правой! - если не угадали будет маятник, и он таки есть, как раз из за того что ось помехи ни разу не в центре.
На новых же мозгах мы получим А0=А1=20, на А2=А3=-100, это значит что ось перекоса находится сильно ближе к правому краю коптера, простая пропорция от 0 даст нам следующее: увеличить обороты на левой стороне на 100, но на правой уменьшить только на 20!
Ну и теперь все это просчитать с учетом 3х осей ))) Это не значит что дрейфа совсем не будет, просто мы точнее реагировать будем на него а значит и уплывать девайс будет медленнее.
Чукча не математик однако )))
Вижу что математик… Еще разок. Есть показания с одноосевых акселей на лучах - A0,A1,A2,A3
Хорошо, добавили гиры - GYR1,GYR2,GYR3
Пожалуйста, найдите
- текущие углы pitch, yaw, roll
- текущие линейные ускорения по x,y,z
- чтобы висел “как прибитый” - пути по x,y,z 😉
О том куда вы дели интегрирование шума акселерометров (чтобы избежать дрифта) - вы вообще забыли…
Простите, но я плохо воспринимаю пространные рассуждения. Там кода - строчек на 30-50, не больше… Вы напишите… и демку на ютуб…
Ну и теперь все это просчитать с учетом 3х осей )))
Напоминает наших военных. “управление беспилотниками” - состоит из много-много страниц о взаимодействии подразделений и передаче данных-приказов. Математика описана как “разработана калифорнийским универом”… -)
ps. скажите мне как пилот-пилоту - вы квадрик пилотируете? На каких он мозгах, что у вас такие идеи улучшения стабилизации?
ps. если у вас проблемы с программированием - можно написать на любом псевдо-языке, я вам напишу код потом
тупо и не затейливо: Смотрим на коптер сзади
Да уж… именно так… Вы начните с “как мы определяем где у нас сейчас зад” и продолжите “в какой, собственно, системе координат”
Послушайте, уважаемый, я действительно не специалист, не математик и вообще даже не электронщик и не программист.
Поморгать светодиодом я конечно смогу, а самое сложное что я сваял на авр это контроллер для аквариума с шинной i2c архитектурой, автоопросом и авторегистрацией подключенных исполнителей, там нет сложной математики.
Я просто высказал идею, если она вам не нравится или лень ее проверять, или вы как специалист убеждены что это полный бред, то дайте свои выкладки - это не будет работать потому, что…
пять-семь лет назад коптеры вообще не летали, тем более в России, сейчас на китайской рассыпухе это может сделать каждый типа меня, но это не значит что надо тупо ждать пока производители наладят выпуск более точных акселей или гир - если бы первый человек не разобрал нунчак мы бы до сих пор не летали, всегда кто-то должен попробовать и в данном случае лично у меня нет необходимых скилов ))
Если надумаете попробовать, то скорее всего вам понадобится еще вот такая MAX7367 микрушка.
ЗЫ: квадрик у меня на мультивии и не устраивает меня в первую очередь именно горизонтальный дрейф, а во вторую нечеткое(это мягко сказано) удержание высоты )
ЗЫЫ: Более того, многие пилоты вообще не используют сейчас аксель именно по причине его бесоватости. Постулат моей идеи заключается в том что, сила противодействия должна быть равна силе внешнего воздействия, а сейчас это не так по очевидной причине. Собственно исходя из этого можно никакие скорости пока не высчитывать, ни линейные, ни какие другие а только лишь пропорционально показаниям нескольких датчиков менять обороты моторов.
Я просто высказал идею, если она вам не нравится или лень ее проверять, или вы убеждены что это полный бред, то дайте свои выкладки - это не будет работать потому, что…
Разумеется лень. Мне бы на все свои идеи рук хватало -)
Я же дал хорошую ссылку. Там _показано_ что такое интегрирование акселерометра, там рассказано почему важны текущие углы и что без них значения акселерометров бесполезны практически.
Если мы говорим о дрейфах - там его _видно_ и объяснено как с этим борются применительно к высоте.
Если Вы этому всему не верите - вот Вам видео от гугла -
(смотреть с 23:20)
Возможно, вы знаете обойти проблему шума акселерометров (и его двойного интегрирования) хитро комбинируя их показания или еще что-то - я же не знаю. Покажите. Только в виде формулы, а не объяснения “примерно как-то так”.
Если надумаете попробовать, то скорее всего вам понадобится еще вот такая MAX7367 микрушка.
Ну, я-то уже написал код интегрирования и получил перемещения по x,y,z…
квадрик у меня на мультивии и не устраивает меня в первую очередь именно горизонтальный дрейф, а во вторую нечеткое(это мягко сказано) удержание высоты )
В соседней теме (mwii) mahowik раздавал прошивку для вия со стабилизацией по высоте (он активно эту тему копает). В последнее время там правда битва за понимание лицензий и все такое.
ЗЫЫ: Более того, многие пилоты вообще не используют сейчас аксель именно по причине его бесоватости
Мне кажется у Вас проблемы с квадриком. Возможно вибрации, может настройки…
Покажите. Только в виде формулы, а не объяснения “примерно как-то так”.
Заглянул в исходники мультивия, очень многа букоф, так что не будет вам формулы )))
Правда, не разобраться с ходу вообще что к чему, надо вкуривать методично.
Пока что я могу предложить только следующее, использование данных с дополнительных акселерометров в качестве веса в микшерах, фильтры же есть уже в коде.
Видимо где то здесь вместо единичек высчитывать значение с учетом веса.
#define PIDMIX(X,Y,Z) rcCommand[THROTTLE] + axisPID[ROLL]*X + axisPID[PITCH]*Y + YAW_DIRECTION * axisPID[YAW]*Z
#ifdef QUADP
motor[0] = PIDMIX( 0,+1,-1); //REAR
motor[1] = PIDMIX(-1, 0,+1); //RIGHT
motor[2] = PIDMIX(+1, 0,+1); //LEFT
motor[3] = PIDMIX( 0,-1,-1); //FRONT
#endif
“примерно как-то так”, псевдокод: X = 1 \ Max_Additional_ACC_Value * Filtered_Additional_ACC_Value, и так же для Y и Z ))))))
X = 1 \ Max_ACC_Value * Filtered_ACC_Value
Это, простите, Вы что нашли? X - это у вас что?
Вас не смущает что ACC_Value - это массив. Прям так и умножаем?
Ps. я не могу понять - вы не согласны с тем что по ссылкам?
pps. если вы все-таки прочитаете по ссылкам, то и код вия будет читать проще (если, конечно, Вы собираетесь проверять свою идею на реальном коптере)
Я со всем согласен, просто потому что писали люди разбирающиеся лучше меня )), Мужик в видео очень красиво все рассказывает, но он какую то шпажку крутит и соответственно ему важно получить ориентацию объекта в 3D, а нам надо моторами управлять, четырьмя, и я предлагаю всего лишь управляемый микшер уже перед генерацией сигнала на регули, как дополнительную коррекцию
Вас не смущает что ACC_Value - это массив. Прям так и умножаем?
Ок, пусть будет так:
X = 1 \ Max_Additional_ACC_Value[0] * Filtered_Additional_ACC_Value[0]
Y = 1 \ Max_Additional_ACC_Value[1] * Filtered_Additional_ACC_Value[1]
Z = 1 \ Max_Additional_ACC_Value[2] * Filtered_Additional_ACC_Value[2]
Это, простите, Вы что нашли? X - это у вас что?
Это вместо единиц, т.е. вместо константы. вместо PIDMIX( 0,+1,-1) будет PIDMIX( X,Y,Z)
И если я ничего не путаю, то при нескольких датчиках проще будет вычислять не линейную скорость, а угловую - конца луча относительно точки вращения, даже не знаю лучше это или хуже :/
Ну, вы все-таки не хотите, ни читать, ни слушать, ни видео внимательно посмотреть (там графики еще есть, кроме мужика со шпажкой).
Вы не ответили даже на вопрос “что такое X” в Ваших расчетах.
Простите, но я не могу дальше вас отговаривать - это жесть какая-то. Надеюсь, Вы продолжите копать по ссылкам и поймете что-нибудь по ним.
Я честно пытаюсь вникнуть, для этого нужно время, но у меня такое ощущение что вы меня просто не понимаете, что именно я хотел бы попробовать сделать ((
потому что я говорю об одном, а в ответ получаю что не получится сделать совершенно другое
Вообще, идея с разнесенными по углам акселями теоретически возможна, но если аксели не МЕМС.
Смтрите как ведет себя аксель при вибрации(белый вектор). а если бы он нахлодился на луче рядом с мотором?
Смтрите как ведет себя аксель при вибрации(белый вектор).
Я так понимаю это raw data, что-то же отфильтруется… В общем пока не попробую сам - ничего не пойму )
Я так понимаю это raw data
Верно
что-то же отфильтруется…
Когда что-то отфильтруется, скорости системы будет не хватать…
А сама теория очень простая, если пары А0-А2 и А1-А3 датчики противолежащих лучей, при этом А0-А2 продольная ось, А1-А3 поперечная, то А0z-A2z = sin(tang), А1z-A3z = sin(kren). Вообще можно просто М0 = ТягаОбщ.+Коэфф.*А0, и тд для следующих моторов, теоритически стабилизатор будет работать, но без выравнивания в горизонт. Для выравнивания в горизонт нужно дополнительно сложить вектора всех акселей (получить среднюю “температуру по больнице”) и из этого вектора получить его наклоны в ортогональных плоскостях. Угол разворота вокруг вертикальной оси (рыск) получаем векторно складывая частные, для каждого акселя, проекции на перпендикуляры лучей в горизонтальной плоскости. Как-то так…