Идея - 2 дополняющих друг друга мозга на коптере!
снимаем хотябы часть нагрузки с атмеги и задействуем её на максимальной частоте
вот набор датчиков с 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, его датчики и интерфейсы, а также среда разработки для него и библиотеки позволяют делать то, что вы и близко не сделаете на других платформах.
Я всегда подозревал что мы летаем на ущербных платформах, нам явно не хватало яйфона на коптерах, чтобы можно было фотки с коптера сразу в ФБ постить) Константин, возьметесь за разработку?
Мозги iPhone, его датчики и интерфейсы, а также среда разработки для него и библиотеки позволяют делать то, что вы и близко не сделаете на других платформах.
Ну как минимум:
- скорость чтения датчиков в iOS невелика, если не ошибаюсь, не более 100Гц, обычно и то используют 10
- с интерфейсами у айфона как раз все плохо, даже чтобы достучаться до serial port нужен Jailbreak и шаманства с правами доступа, Bluetooth тоже залочен, прямой доступ к USB Вы также вряд ли получите
- использовать айфон ценой в 700$ в качестве замены платы датчиков за 50$, не очень оптимальное решение.
- даже чтобы заливать и отлаживать программу на айфоне, нужна лицензия на разработку, стоимостью 100$ в год
В общем, летать оно если и будет, то очень плохо, но если есть твердое желание реализовать, то конечно никто отговаривать не будет 😃
А проще взять плату типа такой, со всем набором датчиков, под нее есть и открытый исходный код, и среда разработки и пр.
Ну я же не предлагаю управлять с айфона непосредственно моторами. На мой взгляд вполне можно айфону на основе своих датчиков (которые вполне даже неплохи) принимать общие полетные решения (аля автопилот), которые будут через ардуино передаваться в назу. Облет по маршруту, завис/фото в гео точке и пр. Стоимость айфона от 200$. Кабель для TTL = 60$ и работает без джейла официально. USB, bluetooth уже тогда и не нужны. Лицензия нужна только для разработчика. Зато сколько плюсов, бридж, маяк, фото, стриминг, маршруты и т.д.
В общем, закажу такой кабель и попробую как-то для начала научить айфон через ардуино понимать, что выдает приемник по PWM и уметь пихать свои команды в SBUS для назы. С программированием под iOS проблем нет, а вот про ардуино надо почитать…
Кабель для TTL = 60$ и работает без джейла официально. USB, bluetooth уже тогда и не нужны.
Уже не работает.
Начиная с iOS5, при попытке открытия “/dev/tty.iap” выдается Operation not permitted.
Найдете способ как обойти без джейла, было б интересно.
Найдете способ как обойти без джейла, было б интересно.