FPV на вертолетах классической схемы.
Ну допустим, мы отдали разворот элеронам, ротор сделал наклон в сторону, но я не уверен, что хвост сам сделает поворот (по крайней мере не во всех случаях)! А что будет со стабилизацией по элеронам? Её не будет Автопилот не может контролировать величину крена, если через некоторое время не будет изменения курса по GPS координатам, то будет увеличен угол наклона… и сваливание…
Олег, разворот хвоста по потоку неизбежен, впрочем если есть сомнения, то можно поставить на него более развитое вертикальное оперение… Кстати, обратите внимание на эту позицию на многих полноразмерных вертолётах, более того Вы увидите, что на многих вертолетах применяются активные рулевые поверхности на хвосте…
Ну, да ладно… Давайте чуть о другом…
Возможно я несколько заблуждаюсь в алгоритме работы Скокума. Поправьте меня если это так…
Мне представляется, что Скокум в режиме без стабилизации горизонта (как всякая обычная FBL) действует следующим образом: от величины управляющей команды зависит угловая скорость исполнения команды. Т.Е. угловая скорость вращения, к примеру, вокруг продольной, горизонтальной оси вертолёта пропорциональна углу отклонения стика элерона. При этом при постоянно действующей команде будет происходить бесконечное вращение по данной оси, со скоростью определённой величиной команды.
А в случае работы в режиме стабилизации (включено выравнивания в горизонт): от величины управляющей команды зависит лишь некий конечный угол отклонения от горизонта. Т.Е. углу отклонения стика элерона пропорционален некий угол крена и не более того. Если стик возвращается в нейтраль, то стабилизация выравнивает верт в горизонт.
Это так?
Возможно я несколько заблуждаюсь в алгоритме работы Скокума. Поправьте меня если это так…
Мне представляется, что Скокум в режиме без стабилизации горизонта (как всякая обычная FBL) действует следующим образом: от величины управляющей команды зависит угловая скорость исполнения команды. Т.Е. угловая скорость вращения, к примеру, вокруг продольной, горизонтальной оси вертолёта пропорциональна углу отклонения стика элерона. При этом при постоянно действующей команде будет происходить бесконечное вращение по данной оси, со скоростью определённой величиной команды.
Думаю, Андрей вы ошибаетесь, так как от величины управляющей команды-стика зависит угол поворота тарелки автомата перекоса, а если бы элетронная ситема была бы настроена на угловую скорость, то летать мне не представлялось бы возможным,
например в ветер мы создаем наклон верта и держим его , причем наклон сохраняется, а стик “управляющая команда” также отклонен,
в таком случае если электронику настроить на угловую скростьверт бы медленно пытался провернуться вокруг оси ипришлось бы PWM-ить руками , то есть многократно отклонять и возвращать стик на место
Дмитрий, Вы ошибаетесь… Чтобы медленно развернуть верт, надо отклонить стик на малый угол, быстро – на большой… никаких PWM…
…то, что Вы описывате как раз похоже на Скокум в режиме стабилизации. Там для постоянного крена надо держать стик под углом…
Что же касается V-bar(а), то в нем алгоритм именно таков «Угол стика – угловая скорость вращения по соответствующей оси». Стик в нейтраль – верт держит текущую (!) позицию. Причем этот алгоритм управления имеет дифференциальную связь с выходом гироскопа, чем обеспечивается стабильность параметров контура от внешних дестабилизирующих факторов, как по угловым скоростям, так и по заданным пилотом статичным углам.
Для наглядности: При боковом ветре справа – отклоняем стик вправо, верт увеличивает правый крен с заданной угловой скоростью, когда целевой угол крена достигнут – стик в нейтраль, верт остаётся в крене до дальнейшего управления, при этом гиростабилизатор держит заданный угол крена от внешних воздействий.
Или для полета вперед – ручку от себя, создали тангаж на нос, ручку в нейтраль, верт полетел с заданным углом тангажа…
Вот так и не иначе.😃
Дмитрий, Вы ошибаетесь… Чтобы медленно развернуть верт, надо отклонить стик на малый угол, быстро – на большой… никаких PWM…
…то, что Вы описывате как раз похоже на Скокум в режиме стабилизации. Там для постоянного крена надо держать стик под угло
с хвостом понятно, а с кренами интересно было бы попробовать.
Спасибо Андрей, может в следующем году от сервооси избавлюсь, и почитаю теорию
получается после сервооси придется почти заново учиться летать ?
Вот, Дмитрий, совершенно верно, FBL ведет себя по циклическому шагу также как руддер в режиме удержания хвоста… Только контур циклика настраивается чуть «мягче», иначе есть риск возникновения автоколебаний… что кстати и с тем и с другим случается если перестараться с чувствительностями…
получается после сервооси придется почти заново учиться летать ?
Да, вроде нет… У меня особых проблем не возникло. Все становится проще и приятней!😉
Тут дело видимо в другом - Вы летаете не на “чистой” сервооси… Копилот вносит свои нюансы…
Только контур циклика настраивается чуть «мягче», иначе есть риск возникновения автоколебаний
PID -ы настраиваться ? чтото все железо на самолеты\вертолеты\квадры в последнее время сводится к одному,
в идеале если всё совместить с приемником - ничего лишнего 😃
PID -ы настраиваться ?
Ну, да… причем раздельно по каждой оси…😉
А куда ж от них деваться?! Это же системы авторегулирования, а они, в случае стремления к совершенству, везде сводятся к PID(ам)… Математика… Теория пропорционально-интегрально-дифференциального управления… Блин!😵😁
Андрей именно так! Скокум работает именно так, выставив определенную скорость вращения по оси, он ее никогда не превысит, не полное отклонение стика будет давать команду на вращение с меньшей скорости во ти все, в режиме стабилизации отклонение стика задает угол отклонения, а не скорость вращения (но для этого режима тоже настраивается скорость вращения ,что делает вертолет более резким или вялым., когда я ставил скорость вращения 200гр/сек., вертолет по команде очень лениво возвращался из инверта к примеру, когда же увеличил до 400гр/сек стало куда интереснее, и летать стало куда приятнее., т.е. помимо всего и скорость стабилизации так же привязана к этому показателю и никогда его не привысит, а наоборот можно отрегулировать только еще меньшое вмешательство функции автовыравнивания, но не больше чем установлена скорость вращения по оси! Я думаю Вы меня поняли.
В ИглТри вижу смысл отдать иглу, ну канал газа, которым он будет управлять - шаг, элеватор оставить элеватором, ну а в канал элерона со-но руддер. Там есть такое понятие при прохождении визарда, как ___— установите стики так, чтобы Ваш носитель летел прямолинейно—___ установите стики так, чтобы он набирал высоту. т.е. микширую элеватор и шаг - игл сможет адекватно рулить. Опять же, там есть такое как минимальная скорость - вот тут мы и выставляем скорость напрмиер в 30км/ч. После чего например при полете против ветра он увидит падение скорости, и добавит шагу - и мы спокойно полетим дальше! Как то так я понимаю! Все что правильно для самолета, для вертолета так же работает!
Мне представляется, что Скокум в режиме без стабилизации горизонта (как всякая обычная FBL) действует следующим образом: от величины управляющей команды зависит угловая скорость исполнения команды. Т.Е. угловая скорость вращения, к примеру, вокруг продольной, горизонтальной оси вертолёта пропорциональна углу отклонения стика элерона. При этом при постоянно действующей команде будет происходить бесконечное вращение по данной оси, со скоростью определённой величиной команды.
Да так и есть, но только пропорциональна в идеальном случае, когда нет внешних дестабилизирующих воздействий. FBL может сам менять угол тарелки для достижении целевой угловой скорости, заданной стиками.
А в случае работы в режиме стабилизации (включено выравнивания в горизонт): от величины управляющей команды зависит лишь некий конечный угол отклонения от горизонта. Т.Е. углу отклонения стика элерона пропорционален некий угол крена и не более того. Если стик возвращается в нейтраль, то стабилизация выравнивает верт в горизонт.
Это так?
В режиме стабилизации введен дополнительный коэффициент. От его величины зависит момент или степень стабилизации. Я по прежнему могу делать ролы, при максимальных отклонениях стиков, если коэффициент например 50%. Коэффициент задает порог срабатывания стабилизации и её величину. С включенной стабилизацией не получаться красивы фигуры, приходиться её преодолевать. Или при отвесном пикировании пролетев так метров 50 или более ощущается желание системы выровняться, что не совсем приятно. Если стики отпустить, то выравнивается сразу.
Ага! Вадим, Олег, спасибо!
Олег, вот к чему это было;):
Исходя из вышеизложенного, нет никакого риска в подаче игловского «руддера» в канал крена. Разумеется, его величину необходимо лимитировать на «пристойном» уровне, чтобы крен был явным, но не закритичным. Верт уйдет в боковое скольжение, хвост (по failsave без удержания) развенёт – поворот осуществлен! Исходя из алгоритма Скокума стабилизацию он не потеряет… Всё что Вами сделано для поддержания высоты и поступательного полёта остается в силе…
Вадим, канал газа – на шаг… Неее…. А если игл удумает погасить движок?😃
Элеватор игла – на ОШ, как у Олега, будет правильнее (целевая высота), безопасней… А вот скорость держать/корректировать газом – в канал элеватора верта, но очень осторожно… Надеюсь целевая скорость в иглах управляется именно газом… Тогда при развороте и переходе крена в тангаж начнет расти скорость игл убирая «газ» нормализует скорость путем коррекции по элеватору т.е. тангажу уменьшая его… Впрочем его будет уменьшать и сам Скокум стремясь нормализовать стабилизацию горизонта.
Кажись получается!😃
Хм… И что? Пробовать будем?😉
Олег, Ваши мысли?
Вадим, канал газа – на шаг… Неее…. А если игл удумает погасить движок?
Не на думает! Для этого есть значение в игле., установить газ- в нашем случае шаг в такое положение, которое игл никогда не установит меньше, рассчитано на двс моторы, чтобы не глохли. Поэтому нам стоит показать здесь например шаг в +3гр чтобы модель просто висела. Что даст нам спуск при наклоне элеватора, ведь он умеет и за коридором высоты следить, и их может быть не сколько! (коридоров, например на дистанции более 1км - такие полеты подразумевают высоту близкую к 300метрам., а например все что ближе 1км можно выставить на высоту 100метров., в случае как у меня была поломка видео можно будет спокойно и беспрепятственно перехватить управление. Конечно можно и без этого, но функция довольна удобна.
Есть идея использовать стандартную безфлайбарную систему и ИглТри для автовозврата! Для стабилизации использовать доп. плату стабилизации Гвардиан стоимостью 40 баксов для авто возврата!
Вы что то путаете! При чем здесь ИглТри…
Увы ИглТри система не идеальна…
А Игл - либо какая то другая телеметрийная плата с самолетной функцией авто возврата, может быть настроена на вертолете, в связке с такой системой виртуальной сервооси как Скоокум.
либо Копилот
Есть идея использовать стандартную безфлайбарную систему и ИглТри для автовозврата! Для стабилизации использовать доп. плату стабилизации Гвардиан стоимостью 40 баксов для авто возврата!
vadson:Вы бы уже определились, вчера - не идеально, сегодня - уже можно использовать…
наверное проще с помощью самому всё запрограммировать и спаять, чем так мучаться 😃 (мега+компас+GPS+барометр)
правда пока сам будешь делать,кто нибудь уже сделает 😃
хотя можно даже не паять а взять готовую плату с датчиками, останется только запрограммировать 😃
и спаять, чем так мучаться (мега+компас+GPS+барометр)
Еще IMU забыли…😉
Э-хе-хе… Дмитрий, если бы всё было так просто…😕
Вы следите за проектом Smalltim, как примером информационно открытого процесса? Сколько уже лет, а проблемы и задачи как снежный ком, только нарастают и усложняются, и это на самолётах…
В последнее время, несколько месяцев, занимаюсь бета-тестированием некоторых их продуктов, Вы не представляете, сколько проблем возникает там, где их и не ожидаешь… Сколько пишется альфа/бета версий… Приходится нащупывать альтернативы, изыскивать компромиссные решения…
Так что мечты о том, чтобы просто сесть, что-то спаять, сваять некую прогу и полететь, очень далеки от реальности…
Использование же готовых изделий как составных компонентов конечного, упрощенного, но всё же автопилота, дает надежду на реальность затеи…😉
мега+компас+GPS+барометр
- IMU + storm 450 + xbee телеметрия + miniOSD тестирую и разбираюсь (как удается по времени) уже 2 месяца. Пока толком не научил его даже в режиме симулятора с компом толком летать. А так, в простом режиме все работает, даже повисел немного, на улицу пока не вытаскивал т.к. далеко еще до идеала и даже до просто нормальной работы без АП. Явно требуется еще много чего дописывать и править в части логики. Тестеров как я вижу почти нет или не сезон еще, обновления конкретно для проекта heli почти не выходят. А вот как отличная и полноценная система телеметрии, независимой от ТВ, с логгером, выводом на комп в реале, независимо на OSD - просто шикарно получается. По ощущениям для запуска этой системы именно как АП на heli, нужно убирать блоки ПО отвечающего за FBL и отдать эту функцию специализированному устройству.
vadson:Вы бы уже определились, вчера - не идеально, сегодня - уже можно использовать…
Я не отрицаю его использования не в коем случае, сам пользуюсь ихними системами, но иногда проскакивают глюки! Они редки, но у меня были., и дело не одного экземпляра, у меня их было несколько! Как не дорогая альтернатива вполне! Немного зная его принцип работы думаю, что на вертолете с гваридианом будет возвращать вертолеты оборудованные обычной безфлайбарной системой работающих только на вычислениях гироскопах.
Только вот ставил гвардиан на 700 вертолета только для вывода горизонта, и наблюдал картину увода горизонта от вибраций, это хорошо проявлялась при горизонтальном спуске, когда происходит срыв потока и появляются доп. вибрации! Нужно будет городить виброразвязку для него, а так должно работать!
Э-хе-хе… Дмитрий, если бы всё было так просто…
представляю…
но вот со своим копилотом - достаточно простым устройством и флайбаром мне эта задача представляется выполнимой.
например имея компас и GPS.
в общем вкратце расскажу принцип работы копилота, когда его настраивают:
в режиме визарда создаем наклоны и крены(максимальные), а также среднее положение стиком управления креном и тангажем, таким образом копилот узнает о реверсах на сервомашинках и т.д.,
далее при работе копилот держит горизонт и при подаче команды на наклон или крен выполняет его, но верт при этом наклоняется только на небольшой угол и в 3D никогда не выходит (не крутится вокруг осей.). в идеале работа копилота - это угол наклона стика = угол наклона вертолета/5
а теперь представим некое устройство - АП, которое втыкается между копилотом и приемником (управляем всеми сервами включая хвостовую и регулем т.е. оборотами двигателя), не будем обсуждать как оно будет активироваться (файл сэйф или по кнопке).
Данное устройство также как копилот будем настраивать, только теперь ещё укажем положения тарелки автомата перекоса в 0-вом положении лопастей и максимальном, 0-вое положение хвоста ну и направление поворота хвоста,также при выключенном регуле покажем обороты какие нам надо(от нуля до максимума).
Итак теперь устройство знает все особенности управляющих сигналов (реверсы ит.д.)
Рассмотрим алгоритм работы устройства.
В момент включения АП,
выравниваем управляющие импульсы в центры, а также обороты и шаг висения, ждем время, затем
считываем текущие координаты GPS, выстраиваем линию возврата домой , определяем направление полета.
Далее по компасу вращаем хвост до нужного курса, отклоняем элеватор вперед (копилот будет держать небольшой наклон) и готово полетели,
(1) через время N,
считываем снова координаты,
определяем отклонение от линии возврата домой,
если оно за пределами определенного заданного коридора в метрах,
то корректируем кренами (влево или вправо, копилот снова отклоняет верт на немного)
и так заново в (1), пока не вернемся
в алгоритме опустил контроль высоты, чтобы не усложнять.
также далее можно написать ещё кучу всего, что бы верт не болтало, сделать фильтры, pID-ы ит.д.
весь АП в данном случае строится на выравнивающей особенности копилота и на особенности управления им.
Дмитрий, Вы правы в своих рассуждениях… И ключевой позицией в Вашей схеме является компас, т.к. только посредством него можно определить положение фюзеляжа относительно целевого вектора по азимуту.
Сами векторы считаем тригонометрией… Вроде ничего нереального…
Но ПО нужно писать/отлаживать… а это хлопотно для непрофессионалов, к примеру, в области тех же Атмег…
Если же использовать чужие (самолетные) наработки, готовые продукты, то в них нет столь необходимого нам магнитометра (компаса), и соответственно ПО позицию азимута фюзеляжа не видит и как результат прямое применение таких АП невозможно.
В предложенном же выше варианте положение фюзеляжа не определено только до начала поступательного полёта далее всё происходит само за счет флюгирования хвоста…
Применение самолетного автопилота становится возможным.
Не мудрствуя сильно применяем то что имеем в наличии.
В ИглТри вижу смысл отдать иглу, ну канал газа, которым он будет управлять - шаг, элеватор оставить элеватором, ну а в канал элерона со-но руддер. Там есть такое понятие при прохождении визарда
Уже обсуждали эту идею и по-моему в этой теме. Вывод прост: никогда, ни при каких условиях, ни при каком раскладе, как вы не извращайтесь с визардом не получится настроить ИглТри и подобный ему самолетный автопилот на возврат вертолета домой, хоть с “гуардином”, хоть со “Скукумом”. По очень просто и банальной причине, автопилот должен как минимум знать миксы HR3 тарелки перекоса и иметь каналы выхода для каждой машинки, и никакое “руление хвостом” тут ему не поможет, т.к. у вертолета “летит не модель, а ротор (с)”.
Не, Кирилл, мы тут фантазируем о чуть более полнофункциональном подходе, нежели прямое управление сервами CCPM…
Обсуждается «многослойная структура»: миксы CCPM – первый уровень, на своей железке, второй уровень – динамическая стабилизация типа FBL, третий уровень – пространственная стабилизация (горизонт), опять же своя железка, и вот наконец когда это всё само летает (висит), как же его заставить ползти в нужном направлении… 😉