Идея - 2 дополняющих друг друга мозга на коптере!
Всем добрый день.
Я может не совсем в тему, она куда то к айфонам скатилась, но не знаю где еще идею высказать.
Суть в следующем: два мозга может быть и не надо, а вот 3-4 акселя(в зависимости от того квадрик или трикоптер) мне кажется не помешало бы.
А с чем бороться-то собираетесь? -) Имеющиеся платы-алгоритмы со стабилизацией отлично справляются. Гуляние по высоте - это свойство только тех аппаратов, где yaw реализован без поворотного мотора.
3х конечно, они не настолько дорогие что бы экономить. Но для теста пошел бы и одноосевой, типа вверх/вниз
У меня нет запаса железок, иначе бы сам попробовал )
Как Вы думаете - верх-низ он до каких углов верх-низ 😉
А значит этим страдают все квадрики ))
Дело не в том с чем бороться, а в том, что при таком подходе леталка будет( должна )))) ) действительно висеть как прибитая, без гпс
Плюс скорость выравнивания должна возрасти в разы, не будет маятника
Как Вы думаете - верх-низ он до каких углов верх-низ
думаю для стабилизации ±45 было бы достаточно, я не знаю что покажет аксель при просадке луча в 45 градусов ))
Здесь будет совсем другая математика, потому что много вводных будет
Я почему и спросил “с чем боремся”. Такой обвес может дать супер-точное выравнивание в горизонт. Но оно и там вроде нареканий не вызывает… Но это никак не “висеть как прибитому без гпс” 😉
Я почему и спросил “с чем боремся”. Такой обвес может дать супер-точное выравнивание в горизонт. Но оно и там вроде нареканий не вызывает… Но это никак не “висеть как прибитому без гпс” 😉
А почему бы и нет, ведь боковое смещение будет корректироваться тоже индивидуально для луча(вернее мы более точно можем высчитать, какой луч, куда и насколько сместился) и более точно. дрейф если и не пропадет, то сильно должен уменьшиться
Собственно цена вопроса несколько баксов, если бы я умел и имел детали, реально ведь попробовать )
думаю для стабилизации ±45 было бы достаточно, я не знаю что покажет аксель при просадке луча в 45 градусов ))
Здесь будет совсем другая математика, потому что много вводных будет
Так это был намек. Пока “я не знаю что покажет аксель при просадке луча в 45 градусов” - какой смысл его ставить? Лучше поставить светодиод - это красиво смотрится.
Предлагаю для ознакомления - habrahabr.ru/post/137595/
Дальше написать чуток кода и проинтегрировать акселерометры. Дальше по результатам - желанию 😉
Предлагаю для ознакомления - habrahabr.ru/post/137595/
Ну и собственно чего? там 1 аксель, в чем фишка?
Собственно: “Акселерометр в комбинации с гироскопом может выдать линейные горизонтальные ускорения, но тут есть две проблемы: постоянно действующий огромный (по сравнению с тем, что будем измерять) вектор 1G, и отсутствие привязок для коррекции.” - при нескольких акселях нам не нужна будет привязка
Так это был намек.
Намек конечно, если есть люди у которых в загашнике валяются все необходимые детали, то им вполне по плечу попробовать ))
Ну и собственно чего? там 1 аксель, в чем фишка?
Мне кажется если вы и прочитали что написано по ссылке, то не осознали. Все ваши одноосевые идеи будут работать только при плоском расположении. При поворотах как вы собираетесь получать линейные ускорения с одноосевого акселерометра - поделитесь сокровенным знанием…
Далее - там описано все, чтобы получить перемещение по вертикали путем интегрирования акселерометра за полчаса возни с кодом. И убедиться что в чистом виде оно на фиг не надо.
Вот тут еще более разжеванна теория, но дальше от кода
we.easyelectronics.ru/…/plata-upravleniya-kvadroko…
при нескольких акселях нам не нужна будет привязка
Итак, у нас есть четыре одноосевых акселерометра на четырех лучах. Их показания - A0, A1, A2, A3. Что дальше. Как вы из этих значений получаете линейные ускорения?
Все ваши одноосевые идеи
Я же уточнил что одна ось только для теста, не более, просто датчик дешевле )
В конце концов не хотите идею, как хотите ))) Если я научусь паять эти дикие корпуса дома. обязательно попробую
Я же уточнил что одна ось только для теста, не более, просто датчик дешевле )
В конце концов не хотите идею, как хотите ))) Если я научусь паять эти дикие корпуса дома. обязательно попробую
Информации по данным ссылкам + плата mwii - вполне достаточно чтобы провести эксперимент…
Если вы не знаете как получить из этих значений линейные ускорения - Вы серьезно полагаете что проблема в пайке и корпусах?
ps. покажете математику с рабочим примером (как у вас там без дрифта все получается) - я вам спаяю что скажете. Или куплю 4 платки mwii lite и будете их использовать.
Как вы из этих значений получаете линейные ускорения?
Чукча не математик однако )))
Но вот сходу, тупо и не затейливо: Смотрим на коптер сзади, А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, и тд для следующих моторов, теоритически стабилизатор будет работать, но без выравнивания в горизонт. Для выравнивания в горизонт нужно дополнительно сложить вектора всех акселей (получить среднюю “температуру по больнице”) и из этого вектора получить его наклоны в ортогональных плоскостях. Угол разворота вокруг вертикальной оси (рыск) получаем векторно складывая частные, для каждого акселя, проекции на перпендикуляры лучей в горизонтальной плоскости. Как-то так…