Идея - 2 дополняющих друг друга мозга на коптере!
Если не трудно, распишите в чем головная боль.
Про флайментор и гайку сравнение не удачное, так как стабилизировать нам ничего не надо, всю работу выполняет материнский мозг (наза например), нам надо лететь или держать позицию, тоесть только помощник человеку.
У Вас нет доступа к параметрам основного мозга, Вам придется иммитировать управляющие воздействия без знания состояния системы. (положения , скоростей и т.д.) Без требований к параметрам как то можно, но если захочется скорости реакции, устойчивости к внешним воздействиям, то дополнительный мозг должен иметь полную функциональность и НАЗа нафиг не нужна.
Да, точности ждать не приходится, поэтому удержание позиции не уверен что выполнимо, но домой (на точку старта) такая штука способна прилететь это точно, а это главная задача.
Да, точности ждать не приходится, поэтому удержание позиции не уверен что выполнимо, но домой (на точку старта) такая штука способна прилететь это точно, а это главная задача.
задача удержать позицию и прилететь домой - одно и то же. Смещаете позицию и двигаетесь.
Идея здравая, в принципе запрограммировать и настроить ардуинку несложно будет. Но работать будет хуже, чем если бы все датчики сливались в один мозг. Пара примеров:
-
GPS дает большую погрешность (в полетах не исползую, но вроде слышал что так есть). Контролироть коптер нужно будет неким подобием PID-регулятора, т.е. “лети туда пока показания GPS не станут искомыми”. Если шум GPS не давить, коптер будет метаться туда сюда в пределах погрешности… Если давить фильтром НЧ, то образуется фазовая задержка. С учетом инертности коптера, PID-регулятор начнет раскачиваться. Вот если бы был акселерометр - мы бы это исправили, введя силную D-составляющую.
-
Компас также и шумит, и врет. Также надо фильтровать. Но в стандартном IMU фильтруется только разница ошибки компаса с гироскопом, а она не дает фазовую задержку. Если гироскопа нет - опять фазовая задержка и раскачка PID.
-
Барометр - ну тут вообще без акселерометра и гироскопа не получить нормальное управление. Если вы следите за веткой MultiWii, то как только там убрали завязку определения высоты на акселерометр, стабилизация стала очень слабой, иначе по одному барометру раскачиваться начнет.
Т.е. во всех примерах, без sensor fusion - либо очень слабое регулирование либо осцилляции, т.к. датчики не идеальны.
Да, точности ждать не приходится, поэтому удержание позиции не уверен что выполнимо, но домой (на точку старта) такая штука способна прилететь это точно, а это главная задача.
Для такой задачи, если погрешность датчика стремится к нулю по сравнению с областью измерения величины, решение вполне возможно.
Почему бы не взять второй ардуиноподобный мозг с компасом и ГПС
Прям мысль мою прочитал.
Именно так и можно сделать. Я так для 30-й фишки делал. Дошел до барометра, но потом переключился на другой проект.
“лететь с таким то наклоном”
Вот это не получицца, если только компас и бародатчег. Девайс не сможет отследить задаваемый угол. Для этого гиры и аксель нуны - но это уже самомостоятельный мозг получаецца.
Да и для компаса углы нужны - компенсация наклона…
Модуль не самый обыкновенный, одно то что он поддерживает WAAS и EGNOS уже весьма сильно.
WAAS в европе как корове седло, а EGNOS можно юзать лишь на малой части Украины. зачем платить за то, что не используется?
никто не берется делать. Весь проект грит - тебе надо - бери и делай код открыт
это разве проблема? Андрей на OP-форуме взял за основу недоделанную навигацию и в итоге получил RTH (который умеет лавировать против ветра), полет в указанную точку и удержание позиции. ему было надо - он сделал.
А по поводу идеи двухголовых мозгов… ИМХО - работать не будет.
тоже есть сомнения. обе системы работают с обратной связью, если она неадекватна - корректная работа всей системы под большим вопросом.
это как пытаться включать линейные стабилизаторы в параллель, малейший разброс параметров и все заканчивается перегрузкой и бум-бумом.
это как пытаться включать линейные стабилизаторы в параллель, малейший разброс параметров и все заканчивается перегрузкой и бум-бумом.
почти во всех кетайских ESC БЭКи по такой схеме включены, мало того некоторые не перерезают красный провод что аналогично запаралеливанию паралельных ESC. И ниче, все летает и все работает.
все мои китайские BEC-и с двумя стабилизаторами подключены не параллельно, вход обратной связи одного подключен к выходу второго и наоборот.
а делать дурацкие вещи запретить невозможно.
может проще будет WIIный или пиратский код порезать на 2 половинки ???
повесить полный комплект датчиков (10 DOF) на мелкую мегу 328 (или 644) на полной тактовой 20 мгц и пускай она считает положение , а все остальное - связь с землей , матрица моторов , телеметрия , обработка данных ЖПС и автопилот повесить на вторую мегу 2560 …
Вот это не получицца, если только компас и бародатчег. Девайс не сможет отследить задаваемый угол. Для этого гиры и аксель нуны - но это уже самомостоятельный мозг получаецца.
Да и для компаса углы нужны - компенсация наклона…
А не надо отслеживать угол, Наза во-первых не даст отклонить аппой коптер более чем на определенный угол, тупо отклонение задается командой, как мы стик на аппе отклоняем на определенный угол. Да даже если это будет 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 и возвращались также, СС с ума сходил но каким-то образом умудрялся стабилизировать коптер (что кстати показывает изначально правильно выбранное направление разработки).