Идея - 2 дополняющих друг друга мозга на коптере!
Вообще гугл очень активно двигает ориентирование для андроид. И поверьте, те усилия, которые они в это вкладывают не потянет ни одиночка, ни маленькая контора производитель полетных мозгов.
ps. На текущий момент у меня такая связка летает Andoid<-USB->Mega1280<-PPMsum,Serial->Mwii (atmega328).
Вы посылаете с Андроида сразу команды на моторы, и датчики используются от телефона?
Какова скорость обмена получается? Что будет если на телефоне звонок позвонит или напоминалка какая-нибудь сработает, насколько эта система realtime?
Камерой управляете из отдельного потока в приложении? На скорость посылки данных фоновое сохранение фото не влияет?
Интересно было бы видеть фото “монстра” 😃
Если конечно между ними обязанности не распределить строго настрогою
Это только так и надо делать, функционал мозгов должен быть чётко разделён, иначе “лебедь раком щуку”.
Но и одна башка все может сама сделать достойно
Если просто полетать по датчикам, то да. А вот, например, в ветке про лимон надо ещё видео обрабатывать. Теоретически можно всё одним мозгом обработать, но что то не хочеся находится рядом с летающей Виндой (андроидом, огрызком и пр). Для сильно разных задач, выполняемых одним мозгом, нужен надёжный диспетчер. В этой области много копьев переломано… Надёжней (проще, дещевле, энергоэфективней) разделить задачи между железяками.
Еще чуток фоток
Предмет особой “гордости” - универсальное крепление для телефонов и гопро.
Нет, конечно никто андроиду моторами рулить не даст - мне жалко себя и окружающих. На реалтайм он никак не тянет (imho).
Камера - да, в отдельном потоке. Запись видео сильно загружает (видимо, компрессор видео), отображение - не очень.
По функционалу они так планируют делиться:
android - общая координация, задание маршрута
mega - базовые “рефлексы” короткого времени
mwii - стабилизация
Обработка и агрегирование данных от сенсоров будут разбросаны ровным слоем, похоже… Не получается все в одно место сгрести из-за невысокой скорости линков, а использовать хочется все имеющиеся сенсоры, включая дублирующиеся (например, акселерометры на mwii и в андрофоне).
“что будет если телефон позвонит” - что напишу, то и будет. можно снять трубку и сказать железным голосом “все улетели, перезвоните позже” - синтез все равно уже используется (болтает на префлай чеке). Шутка. Это отдельная симка.
ps. одна большая контора уже принимает предзаказы на фотоаппараты с андроидом внутри.
Всем добрый день.
Я может не совсем в тему, она куда то к айфонам скатилась, но не знаю где еще идею высказать.
Суть в следующем: два мозга может быть и не надо, а вот 3-4 акселя(в зависимости от того квадрик или трикоптер) мне кажется не помешало бы.
Сейчас все доступные мозги предполагают что центр приложения внешних сил находится в центре собственно чипа датчика(ну если он 6 или 9 осевой), таким образом при перекосе, возникшее внешнее усилие делится на 2(имеется ввиду в одной плоскости) и после этого мозг уже пытается выправить ситуацию. А это в корне не верно, ибо вероятность того, что ось перекоса находится именно в центре платы(чипа) изчезающе мала.
Если бы на каждом луче стоял свой собственный аксель то мы могли бы более адекватно реагировать на внешние воздействия типа ветра, как минимум пропала бы проблема с изменением высоты при корректировке, так как на каждый луч(ну на мотор) подавалась бы коррекция именно для него, а не усредненная как для центра.
Для гир эта фишка не нужна, так как угол наклона не зависит от месторасположения гиры.
Несколько сумбурно получилось. если не понятно потом в картинках поясню )))
Если бы на каждом луче стоял свой собственный аксель
Скольки осевой ?
3х конечно, они не настолько дорогие что бы экономить. Но для теста пошел бы и одноосевой, типа вверх/вниз
У меня нет запаса железок, иначе бы сам попробовал )
Всем добрый день.
Я может не совсем в тему, она куда то к айфонам скатилась, но не знаю где еще идею высказать.
Суть в следующем: два мозга может быть и не надо, а вот 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. если вы все-таки прочитаете по ссылкам, то и код вия будет читать проще (если, конечно, Вы собираетесь проверять свою идею на реальном коптере)