Акселерометр vs гироскоп
АрдуКоптером можно рулить и с компа, подключив джойстик, на сколько я помню. В Multiwii чето было про управление через БТ с телефона.
Нахрен оно тебе не надо разрабатывать свой контроллер, Мы разрабатываем свою электронику и получается, что надо заказывать по 10 штук за раз если делать не на макетке, и получается что ты будешь либо эти все 10 плат реализовывать либо они у тебя будут валяться, в любом случае денег потратишь немерено, возьми скажем ардуино или тот же криус AIOP 2.0 или скажем если душа требует большего то у товарища SergDoc можешь поинтересоваться по поводу его контроллера F4BY который он делал сам, там стоит достаточно мощная начинка, а код напишешь сам. Этим ты избавишь себя от одной головной боли, разработки железа, и займешься вплотную софтовой частью.
По поводу информации, если у тебя на этом этапе голова пухнет, то вникнув сильнее ты поймешь что только край узрел…
Создавать отдельную тему по “своему” проекту, коптеру, или чего там выдумывается надо тогда когда есть что показать, а так только бла бла бла, которые и в дневнике можно разводить.
Написав драйвер под Linux, я привяжу эту штуку к своей программе, которая с компа будет передавать информацию на коптер. Если не получится нормально использовать штурвал, выведу отдельно потенциометр для регулирования тяги.
Т.е. так вот сразу напишете свой протокол с учётом помех, потерь сигнала - отраженных собственных сигналов, смещённых по времени, уже не говоря о смене частот в вч части дабы уходить из “зашумлённых” диапазонов т.д… Мой взгляд такой - хотите полетать (приобщиться так скажем) купите RFT - хочеться поконструировать - купите RFT и копите деньги на тесты своих изобретений - это будет съедать львиную долю… один неудачный вылет от 50 до 300 долырей только впуть - это при условии, что пострадает толька ваша комплектуха…
Нынче сложно нормальных программистов найти.
ошибаетесь - я нашел - точнее они меня нашли, ну неважно 😃
а может Вам, Владислав. влить “новую кровь” в уже действующие опенсорсные проекты типа openpilot.org и отделившейся от них недавно команды wiki.linuxdrone.org/pages/viewpage.action?pageId=3… ?
а может Вам, Владислав. влить “новую кровь” в уже действующие опенсорсные проекты типа openpilot.org и отделившейся от них недавно команды wiki.linuxdrone.org/pages/viewpage.action?pageId=3… ?
Не оптимально для настоящей цели. Не оценят.
Т.е. так вот сразу напишете свой протокол с учётом помех, потерь сигнала - отраженных собственных сигналов, смещённых по времени, уже не говоря о смене частот в вч части дабы уходить из “зашумлённых” диапазонов т.д
Уже все продумал. Писать ничего такого не придется.
Мой взгляд такой - хотите полетать (приобщиться так скажем) купите RFT
За другим зайцем гонюсь.
ошибаетесь - я нашел - точнее они меня нашли, ну неважно
Повезло… ПМЖ у нас разные. У Вас легче найти.
P.S. Реализовал поддержку джойстика. Все оказалось намного проще и, что неожиданно, кросплатформенно. Использовал библиотеку SDL. Осталось реализовать зависимость тяги от координат штурвала. (Классный на штурвале регулятор тяги 😃 не ожидал, что будет так удобно, но пока рано об этом говорить. Поживем - увидим)
Возник другой вопрос. С вашего разрешения приведу цитату своего поста.
Расчет тяг двигателей в коптере
Это опять я. Короче реализовал такую программку. Она (на скрине не видно) в консоль выводит координаты штурвала, а в графическом интерфейсе - значение тяги на штурвале. Она же передает 4 x unsigned int значения по bluetooth на контроллер (На каждый двигатель). Это программная часть.
Теперь механика. Самый логичный для меня вариант - это полет коптера крестом. Т.е. чтобы полететь вперед, нужно замедлить передний двигатель и ускорить задний. Тут и возникает вопрос: в какой зависимости это делается?
Сейчас я опишу свой вариант, а вы поправите меня. Данный метод элементарный и основан на процентах. Рассмотрим ситуацию на скриншоте. Общая тяга установлена в 75%. Штурвал может двигаться в разных направлениях, выдавая координаты X и Y. Эти значения преобразуются в -100% до +100% по оси X и от -100% до +100% по оси Y. Если значения X:0 и Y:0, значит штурвал в покое и тяга каждого двигателя будет равна общей тяге(т.е. 75%). Теперь устанавливаем константу. Пусть максимальное отклонение штурвала (например 100% по оси X) будет равно изменению тяги двигателя на 13,3% от общей тяги(Я взял такое число, потому что 13,3% от 75% - это примерно 10%). Получается, что при полном упоре штурвала вперед, тяга переднего двигателя будет 65%, а заднего 85%. Меняя константу можно будет настраивать чувствительность тяги двигателей. Аналогично реализуется движение по оси Y. Кнопки на штурвале будут регулировать реактивное вращение коптера.
Будет ли работать такой прием? Как работать с двигателями, когда тяга близка к 100%?
Передний замедлить можно, а вот ускорить задний невозможно.Заранее спасибо.
Она же передает 4 x unsigned int значения по bluetooth на контроллер (На каждый двигатель).
прямое управление двигателями через блюпуп это хреново, поток не всегда равномерный и не всегда долетает. Весь контур стабилизатора среда-датчик-стабилизатор-движитель должен быть на борту.
Сейчас я опишу свой вариант, а вы поправите меня.
в принципе всё верно, по сути сумма каналов управления на один мотор М= к1*крен+к2*тангаж+к3*рыск+к4*тяга
для Х рамы коэфиициенты такие
Крен Танг Рыск Тяга
KAH1: -625 -625 -500 1800
KAH2: -625 625 500 1800
KAH3: 625 -625 500 1800
KAH4: 625 625 -500 1800
какое дикое нежеление открыть старый код multiwii… поражен что тема еще жива
Вообще-то, в теории, достаточно 6 идеальных акселерометров что-бы все знать. 3 шт. расположить по осям и 3 шт. поперек осей.
для Х рамы коэфиициенты такие
Спасибо за ответы. Они разве нужны для моего алгоритма? Хотя в крайнем случае подобрать можно.
какое дикое нежеление открыть старый код multiwii… поражен что тема еще жива
Хочу велосипед.
Вообще-то, в теории, достаточно 6 идеальных акселерометров что-бы все знать. 3 шт. расположить по осям и 3 шт. поперек осей.
Шум все равно никуда не денешь. Хотя кто знает, может, на пару с Калманом и получится.
прямое управление двигателями через блюпуп это хреново, поток не всегда равномерный и не всегда долетает. Весь контур стабилизатора среда-датчик-стабилизатор-движитель должен быть на борту.
С контрольным значением буду отправлять. Если в течении секунды нет адекватной информации - все двигатели отключатся. В крайнем случае, если даже на десяти метрах будет худо, перейду на WiFi TCP/IP, ибо UDP - это риск.
С контрольным значением буду отправлять. Если в течении секунды нет адекватной информации - все двигатели отключатся.
Контрольное значение не улучшит равномерность данных. За секунду можно далеко улететь.
перейду на WiFi TCP/IP, ибо UDP - это риск.
Тут вообще ерунда: ТЦП при потере пакета будет его перезапрашивать, а на кой ему нужен устаревший пакет? Лучше ловить новый и проверять на целостность, если нормально - обрабатываем, если битый - отбрасываем. ЮДП однозначно!
Тут вообще ерунда: ТЦП при потере пакета будет его перезапрашивать, а на кой ему нужен устаревший пакет? Лучше ловить новый и проверять на целостность, если нормально - обрабатываем, если битый - отбрасываем. ЮДП однозначно!
Согласен. Сказал недумавши.
Контрольное значение не улучшит равномерность данных. За секунду можно далеко улететь
Не уверен, что на десяти метрах будет настолько плохая связь.
Если управлять напрямую от штурвала в двигатели - то штурвалом постоянно трясти будете в разные стороны и совсем не факт, что равновесие долго удержать сможете.
Для того и ставят датчики, чтобы внутренний быстрый контур стабилизации на борту отрабатывал обратные связи.
А сигналы от пилота/оператора - это уже внешний контур управления, формирующий команды для внутреннего контура.
тут проблема будет не только с горизонтальным удержанием. гораздо дольшая проблема будет с кручением, т.к. в ручную будет сложно добиться одинаковых оборотов противофазных двигателей
Вот что бывает, когда за дело берется программист =) без углубления в физику, математику и электронику.
- Пофиг, что акселерометр “медленный”, может корректировать положение только в состоянии равномерного движения, а при неравномерном - вектор G вращается как попало.
- И что при вибрации он дико врет, а иногда даже переполняется диапазон АЦП.
- Пофиг, что компас “медленный”, рядом с проводами (ток неравномерный, подгазовки) и металлическими частями.
- А еще вектор магнитного поля в России часто почти вертикально уходит в землю, оттого наиболее важные его проекции на оси ХУ стремятся к нулю и не позволяют точно отследить рысканье (которое, как раз, не покажет акселерометр).
Вот что бывает, когда за дело берется программист =) без углубления в физику, математику и электронику. 1. Пофиг, что акселерометр “медленный”, может корректировать положение только в состоянии равномерного движения, а при неравномерном - вектор G вращается как попало. 2. И что при вибрации он дико врет, а иногда даже переполняется диапазон АЦП. 3. Пофиг, что компас “медленный”, рядом с проводами (ток неравномерный, подгазовки) и металлическими частями. 4. А еще вектор магнитного поля в России часто почти вертикально уходит в землю, оттого наиболее важные его проекции на оси ХУ стремятся к нулю и не позволяют точно отследить рысканье (которое, как раз, не покажет акселерометр).
Что-то вы долго спали:) Я уже уточнил эти вопросы. За красочные факты спасибо.
тут проблема будет не только с горизонтальным удержанием. гораздо дольшая проблема будет с кручением, т.к. в ручную будет сложно добиться одинаковых оборотов противофазных двигателей
Значит не зря гиро с акселем заказывал.
А сигналы от пилота/оператора - это уже внешний контур управления, формирующий команды для внутреннего контура.
Люблю дельные советы. Спасибо.
P.S. Еше спасибо за напоминание о Мультивий.