Идея - 2 дополняющих друг друга мозга на коптере!
Вот это не получицца, если только компас и бародатчег. Девайс не сможет отследить задаваемый угол. Для этого гиры и аксель нуны - но это уже самомостоятельный мозг получаецца.
Да и для компаса углы нужны - компенсация наклона…
А не надо отслеживать угол, Наза во-первых не даст отклонить аппой коптер более чем на определенный угол, тупо отклонение задается командой, как мы стик на аппе отклоняем на определенный угол. Да даже если это будет crius hobby в полном комплекте за $80 да гпс за $50, это будет все равно дешевле чем будет продавать производитель.
полный комплект датчиков (10 DOF) на мелкую мегу 328
а она справится? если 100Гц сможет выдать, по моему это уже достижение.
на Pololu есть стобаксовый модуль (без барометра), работает на килогерц, но выдать полное положение может только 300 раз в секунду, хотя там полноценный Cortex-M3 стоит. для использования горячо любимых тут “400Гц регуляторов” AHRS должна работать с неменьшей частотой.
а она справится? если 100Гц сможет выдать, по моему это уже достижение.
на Pololu есть стобаксовый модуль (без барометра), работает на килогерц, но выдать полное положение может только 300 раз в секунду, хотя там полноценный Cortex-M3 стоит. для использования горячо любимых тут “400Гц регуляторов” AHRS должна работать с неменьшей частотой.
ну для такой скорости либо STM32F4xx либо ждать mpu-9150 и задействовать внутренний DMP …
а так мы снимаем хотябы часть нагрузки с атмеги и задействуем её на максимальной частоте … при необходимости мелкие меги можно спокойно разогнать на 24 МГЦ а с внешним генератором и на 28-32 мгц …
А не надо отслеживать угол
Если будем использовать компас, то для вычисления курса (хеадинг) нужны углы наклона по роллу и питчу. Даже небольшие углы без компенсации заставляют врать огого.
хотя там полноценный Cortex-M3 стоит
Там полный фильтр Калмана. И даже кортекс его тянет не быстрее 300гц.
а она справится? если 100Гц сможет выдать,
Лехко!
снимаем хотябы часть нагрузки с атмеги и задействуем её на максимальной частоте
вот набор датчиков с Polulu
а вот готовая либа для ардуины (проверено на Arduino Uno with ATmega328 and Arduino Duemilanove with ATMega168) - github.com/pololu/MinIMU-9-Arduino-AHRS
максимум что там выжали - 50Гц.
Если будем использовать компас, то для вычисления курса (хеадинг) нужны углы наклона по роллу и питчу.
есть такое дело, как огромный вертикальный вектор магнитного поля (по сравнению с горизонтальной составляющей). при желании можно его использовать для определения “низа” 😉
Упс. Вот че. У назы есть выход на пан-тилт камеры! А там прёт PWM пропорциональный углу наклона! Вот вам и углы!
А их хоть для осды, хоть для со-мозга можно заюзать.
вот набор датчиков с Polulu
Имею таких 3 штуки.
Товарищи, а ни кто из вас не может поднять подобную тему на rcgroups, скажем обозвать ее “naza & multiwii mix”. Глядишь дело бы быстрее пошло, если бы кто сделал подобное дополнение к той же Назе, цена может быть была бы ниже на оригинальный гпс к Назе в будущем 😉 я не влдею техническим английским, не смогу сам написать.
Там полный фильтр Калмана. И даже кортекс его тянет не быстрее 300гц.
далеко не полный, всего лишь 3 типа датчиков, причем компас там почти не задействован. OpenPilot в виде первых прототипов работал на 350Гц, при этом действительно работал на полную катушку используя еще и GPS и даже рассчитывал положение модели в случае пропадания всех спутников.
но там уперлись в скорость шины, тоже было 2 платы, одна с мозгами, вторая с датчиками. поэтому 2-х и более модульные системы не прижились, вернее стали разделяться по скорости. на одной быстрые гиры/аксели, а все остальное - где-то еще.
А там прёт PWM пропорциональный углу наклона! Вот вам и углы!
с задержкой в 20мс. плюс еще 20мс для обратной передачи через PPM. тут вроде для коптеров система рассматривается, а у них такие задержки чреваты.
с задержкой в 20мс
Для компаса - это не задержка. Для удержания углов наклона с использованием этих выходов тоже не задержка.
Можно городить надстройку смело.
Весна, много идей в голове, здравых и не очень
Идея здравая. Можно сделать “подруливающее устройство”. Т.е., “помощник” будет подмешивать сигналы к управлению. Ввести ограничения (наклоны до 10 градусов, газ +_200 ), чтобы всегда можно было “перерулить” помощника со своего пульта.
Помощник может реализовать удержание по компасу, ГПС, возврат на точку, удержание высоты по сонару\баро (если не пережать его управление с пульта).
Помощник принимает сигналы с приемника, по каждому каналу подмешивает рассчитанные “дельты” и выдает на пинах.
Единственное, что высоту придёцца взять или из отдельного бародатчика, или по спутникам.
есть такой симулятор, AeroSIM RC, поддерживает подключение собственных DLL-ок со своими стабилизациями, OSD и прочими радостями. попробуйте реализовать описанный вами вариант, благо что программно можно сделать любую задержку.
я когда делал плагин для CC который в железе рулил коптером в симе перематерился из-за 13мс, которые невозможно было уменьшить. данные шли через UDP и возвращались также, СС с ума сходил но каким-то образом умудрялся стабилизировать коптер (что кстати показывает изначально правильно выбранное направление разработки).
вот набор датчиков с Polulu
а вот готовая либа для ардуины (проверено на Arduino Uno with ATmega328 and Arduino Duemilanove with ATMega168) - github.com/pololu/MinIMU-9-Arduino-AHRS
максимум что там выжали - 50Гц.
есть такое дело, как огромный вертикальный вектор магнитного поля (по сравнению с горизонтальной составляющей). при желании можно его использовать для определения “низа” 😉
На атмеге328 чтение MPU6050 (200 Hz), MS5611 (100 Hz), HMC5883(10 Hz) и расчет DCM матрицы с частотой 200 Гц rcopen.com/forum/f123/topic263186 + обработка приемника и выдача на моторы. Размер кода 26 К + фильтрация баро с акселерометром.
а 2560 от 328 по производительности не отличаются. Чтение ЖПС и обработка могут не влезть по объему памяти
Чтение датчиков занимает относительно много времени и переход на быстрый процессор всех проблем не решает
EGNOS можно юзать лишь на малой части Украины
Ну дык я то рядом с Карпатами), а с другой стороны - это не всем надо.
это разве проблема? Андрей на OP-форуме взял за основу недоделанную навигацию и в итоге получил RTH (который умеет лавировать против ветра), полет в указанную точку и удержание позиции. ему было надо - он сделал
Не проблема для тех кто разбирается в программировании, шарит в электронике и т.д. - обычному юзеру менять профиль и бросать работу что ли, и учиться?
Кто понимает и кто умеет = не проблема = вот так надо позиционировать, без сложный сентенций 😉.
обе системы работают с обратной связью, если она неадекватна - корректная работа всей системы под большим вопросом
А она и будет неадекватна при достаточной частоте работы обеих мозгов, об ином варианте вы сказали выше. Это уже две ПИД зависимые системы которые надо еще подружить…
и расчет DCM матрицы с частотой 200
интересно, интересно.
если выкинуть исполнительную часть (PPM, моторы, etc) ресурсов еще больше освободится?
для чего на моторах 500Гц, если данные обновляются в 2.5 раза реже?
Ну дык я то рядом с Карпатами)
и как, реально работает?
На атмеге328 чтение MPU6050 (200 Hz), MS5611 (100 Hz), HMC5883(10 Hz) и расчет DCM матрицы с частотой 200 Гц
MARG с кватернионом тоже 200Гц с ДУС+аскелерометр+магнетометр.
Сделал децимацию компаса и акселерометра, цикл стал 360Гц на Атмега 16МГц, но появилось дрожание.
Сейчас работает код для DMP 6DOF MPU6050 в multiiwii оболочке, там цикл еще выше. Но компас никак не прикрутить байпасом (он припаян так на FreeIMU4 и CSG_аналоге). Регистры конфигурируются или для DMP, или для байпаса компаса. Иначе глючит. Если бы удалось считать и компас, и кватернион из DMP, то можно ввести коррекцию YAW. Возможно, руки кривые. Жду 9DOF DMP, пусть хоть реверс_инженерный.
Идея отдельного модуля в целом здравая, вроде все Фишки и прочие автопилоты именно так и работают.
Правда, видится две проблемы:
- Цена вопроса. Как минимум, надо на плате иметь хороший проц, GPS, компас и баро (если универсальный блок делать, а не только под Назу). По сути получается второй мозг, сопоставимый по цене и по сложности с основным.
- Программная часть. Создатели Фишки за пару лет не смогли в ней все баги вычистить, периодически у народа самолеты валятся, Xaircraft вон только через 1.5 года сделал более-менее работающий GPS c компасом. Сделать аналогичное в свободное время, чтобы было универсально и надежно - имхо утопия. Сделать под конкретный мозг типа Назы, наверное попроще.
В итоге на правах имхо, если нужна навигация, гораздо проще тот же GPS в Wii допилить, почти все там готово уже, объем работ да и цена вопроса в разы меньше.
Еще альтернативный вариант - попросить разработчиков автопилотов (Smalltim, может еще кто) сделать вариант прошивки для коптеров. Если по цене такой продукт окажется не сильно высоким, может даже найдет коммерческий спрос.
А как вам тайой вариант цепочки: iPhone (мозг, датчики акселлерометров и углов, GPS, wi-fi bridge) - redpark TTL cable - arduino (преобразовать TTL команды iPhone в SBus пакеты) - (naza) SBus вход. Вроде должно все работать. Можно, наверное, на ардуино подать и вход с приемника, чтобы оставить возможным и ручной режим.
Что думаете, реально?
А как вам тайой вариант цепочки: iPhone
На могиле коптера будет надпись “Мама позвонила не вовремя…”
На могиле коптера будет надпись “Мама позвонила не вовремя…”
Кто мешает отключить телефонный модуль совсем или установить переадресацию? Мозги iPhone, его датчики и интерфейсы, а также среда разработки для него и библиотеки позволяют делать то, что вы и близко не сделаете на других платформах.
Я всегда подозревал что мы летаем на ущербных платформах, нам явно не хватало яйфона на коптерах, чтобы можно было фотки с коптера сразу в ФБ постить) Константин, возьметесь за разработку?