Акселерометр vs гироскоп
А я думал весна мозгоделов закончилась…
- не разобрались что и как измеряют MEMS датчики, привет банальные вопросы, которые обсасывали на форуме раза 4 точно в таких темах
- делать с нуля самая большая ошибка, если нет команды крутых физиков/математиков/программистов, в 70% закончится тем что не полетит, еще 29% что кого-ниубдь поколечит (если естественный отбор сработает, то на этом всё закончится)
- зачем снова делать то что уже и так летает? на да фиг с ним, пусть даже коптер будет стабильно висеть (что умеет даже самый древний multiwii, влезающий на старенькую ардуинку), а дальше что? какие планы для развития?
- один сонар - идея на уровне коптера без (MEMS) гироскопа, смотреть надо в сторону точных барометров, а сонаром (как акселерометром) только корректировать ошибки (в данном случае землю)
- компас для Z, на сколько я помню медленная штука (т.е. аналогично для корретировки гиры), да и любой проводок рядом и коптер будет совсем не предсказуемо крутиться
если всё это для себя и just4fun, то ИМХО не стоит плодить темы, благо тут есть уже готовые и для новичков, и для тех кто пишет свои прошивки и делает свои контроллеры
зы: что то Сергей добрый последнее время, ни банов, ни блокировок ярых не видно, в соседней ветке человек всё свой сайт с полетами на коптере пиарит и ничего…
А я думал весна мозгоделов закончилась…
- не разобрались что и как измеряют MEMS датчики, привет банальные вопросы, которые обсасывали на форуме раза 4 точно в таких темах
- делать с нуля самая большая ошибка, если нет команды крутых физиков/математиков/программистов, в 70% закончится тем что не полетит, еще 29% что кого-ниубдь поколечит (если естественный отбор сработает, то на этом всё закончится)
- зачем снова делать то что уже и так летает? на да фиг с ним, пусть даже коптер будет стабильно висеть (что умеет даже самый древний multiwii, влезающий на старенькую ардуинку), а дальше что? какие планы для развития?
- один сонар - идея на уровне коптера без (MEMS) гироскопа, смотреть надо в сторону точных барометров, а сонаром (как акселерометром) только корректировать ошибки (в данном случае землю)
- компас для Z, на сколько я помню медленная штука (т.е. аналогично для корретировки гиры), да и любой проводок рядом и коптер будет совсем не предсказуемо крутиться
Намекал же, что пока я отрезвевшей головой не взгляну на тему еще раз, не комментировать. Все равно спасибо. Уважаю людей, ставящих на путь истинный.
Итак, собрав мозги в кулак я понял, что это все-таки сложное занятие. Вернусь-ка пока к ручному управлению. У знакомого есть игровой штурвал. Предлагаю вот что. Написав драйвер под Linux, я привяжу эту штуку к своей программе, которая с компа будет передавать информацию на коптер. Если не получится нормально использовать штурвал, выведу отдельно потенциометр для регулирования тяги. Тестировать буду как МФТИ-шники по ссылке выше. Благо под двором недопарк с обалденной травой(не для курения:)).
P.S. может вообще все в драйвер засуну. Хоть не Unix-way, зато логично.
[offtop]
программистов
Это те которым я за бабки курсовые пишу? Нафиг они нужны. Покупают дипломы, и парят людям мозги антивирусами. Нынче сложно нормальных программистов найти.[/offtop]
родился очередной гений.
родился очередной гений.
Это намек на то, через семнадцать лет меня здесь кто-то подменит? Не, ошибаетесь. Я не гений, а простой лентяй, который ищет отходные пути. У меня ведь экзамены на носу… Если Вам не нравится моя мысль, так срубите ее на корню. Одной фразы слишком мало. Так все, молчу, а то я вообще оборзел. Пойду пока за штурвалом.
Эта тема не вяжется с этой - rcopen.com/forum/f20/topic360862
Ардуина Нано + МПУ6050 + Мультивий 2.х = бюджетный коптер
Пойду пока за штурвалом.
Зачем штурвал ?
АрдуКоптером точно можно с сотика по БТ рулить. Софт для андроида DroidPlaner, AndroPilot.
Про Multiwii и управление с сотика не скажу.
АрдуКоптером можно рулить и с компа, подключив джойстик, на сколько я помню. В 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. Еше спасибо за напоминание о Мультивий.