Smalltim OSD and autopilot (часть 2)

smalltim
KBV:

Tim, а как переводится значение поля baro_speed в логах в реальную скорость? У меня там цифры 3…7, на OSD баро-скорость 40-60км/ч, т.е. это не м/с.

Скорее всего, это мусор после смены формата логов. Сотрите лог целиком, после очистки будет записывать корректно.

Kozhenkov:

Всё готово, жду погоды. Настройки стоят по умолчанию. Боюсь маловаты расходы в режиме стабилизации.
Под чёткой работой понимаю стабильную и адекватную работу ИМУ. На все изменения положения в пространствае элевоны реагируют, так как надо.
Вот в нужной степени чуствительности и демпфирования - вопрос. Масса большая, площадь элевонов тоже.
Если сорвётся в штопор, то не выведешь.

По умолчанию даже многовато, не пытайтесь сравнивать отклонение элевонов в ручном режиме и то, что делает робот. У меня стоит 25 25 25 25, если правильно помню. С 50 50 50 50 на больших скоростях была раскачка около 5 Гц - слишком много демпфирования. Вам, возможно, стоит тоже начать с 25 25 25 25, но масса большая, потом, наверное, придется добавить до 30 - 40. Ну, и никто не сказал, что числа по крену и тангажу должны быть одинаковые. На крыле по тангажу как раз надо поменьше - момент инерции модели по поперечной оси сильно ниже. В общем, с 25 25 25 25 можно начинать спокойно. Будет рулиться вяло - увеличивайте 😃

Триммера, экспоненты и прочее оставляйте ровно такими, с какими летаете в ручном режиме, с ними и калибруйте.
АП не использует экспоненты, но тримера, расходы и прочее берет из того, как Вы калибруете - нейтрали, минимумы и максимумы по каналам, и команды. Встроенный микшер элевонов тоже не надо отключать, АП его понимает при калибровке.

Про штопор - занятно. Пооблетавшись, попробуйте заштопорить модель, ну, в меру, держа ситуацию под контролем Будете ооочень удивлены 😃
Дронавт не верил своим глазам, когда Скай с полностью опущенными закрылками, с коими Скай у него обычно просто не летит, сразу валится… Так вот, Скай против ветра, зависнув над землей, садился почти вертикально, как будто его на лифте везут.

baychi
Ильвир:

Мне кажется, что проще было бы оставить в КП всего два экрана. При этом иметь возможность преключать тумблером примерно так:

Я против. Хоть сам и не использую переключение экранов вообще, но, ИМХО, пербирать 2 варианта или 4 варианта разницы нет. Зато если когданить Тимофей реализует “богатые” экраны, типа “Радар” или “Карта ПКТ”, нам буде очень нехватать переключений.

SkyWorker

А мне кажется вообще жирно выделять целый канал на экраны. Тимофей, почему бы не перенять опыт зарубежных коллег? У того же икаруса. Все управление по одному каналу, куча функций при помощи микса 3 тумблеров.

smalltim
SkyWorker:

А мне кажется вообще жирно выделять целый канал на экраны. Тимофей, почему бы не перенять опыт зарубежных коллег? У того же икаруса. Все управление по одному каналу, куча функций при помощи микса 3 тумблеров.

Не у всех на аппах есть миксы трех тумблеров. А задать хоть 50 положений на управляющем канале - нивапрос, тока вы повеситесь, когда настраивать и запоминать это будете. Во всем должна быть разумная достаточность, по-моему.

Сейчас я и все мои коллеги, с кем летаю, используем 3 положения на 1м канале: мануал, стабилизация, возврат. И 2 положения на 2м: Ничего не делать, переключать экраны. Даже 5 предусмотренных положений не используем.

Если нужен круиз или пкт, то включение круиза разрешается автоматом, а пкт ставится вместо автовозврата. А автовозврат - по выключению передатчика.

baychi
SkyWorker:

мне кажется вообще жирно выделять целый канал на экраны.

Так никто и не выделяет целый канал. Переключение экранов - одна из 5-ти функцй первого или одна из 3-х второго канала.
ИМХО, логика управления от Smalltim - одна из самых продуманных на сегодняшний день.

Эд

а если переключать так- взвел тумблер - переключил экран, вернул тумблер в исходное экран остался до следующего взведения… а в КП хорошо бы настраивать кол-во экранов 2, 3, 4,…

baychi
smalltim:

Даже 5 предусмотренных положений не используем.

Я - использую. И еще мало! Было-б 7, использовал бы 7. Просто аппу надо нормальную иметь. 😃
Кстати, второй управляющий у меня 2 года как отпаян с платы АП, а теперь припаивать лень. 😃

Edward_tlt
smalltim:

Установите “Сразу занимать целевую высоту” и всё будет замечательно.

Вот кусочек видео. За качество извиняюсь, что то не стали дружить писалка с камерой… Завтра другую камеру попробую.

В настройках стоит Резкость 20%, а Допустимый тангаж при снижении -15 град. Правда теперь наверное может влиять и параметр Удерживать газ… Или ещё поприжать первые два? Просто боюсь с 1км разгонится и крылышки то не выдержат. Кстати и высоту почему то 80-90 держит, к 100 как то и не стремится особо:)

baychi
Эд:

а если переключать так-

Эд:

а в КП хорошо бы настраивать кол-во экранов 2, 3, 4,…

Что мешает продублировать 2-й на 4-й и т.п. ?

PS: Выкинуть - просто. Сложно добавить то, чего нет. 😃

smalltim
Edward_tlt:

В настройках стоит Резкость 20%, а Допустимый тангаж при снижении -15 град.

Резкость лучше не прижимать, а увеличить до 30, будет четче держать высоту. А вот тангаж при снижении можно зажать с -15 до -10. Оно при любой резкости ограничивает отрицательный тангаж до -10 и модель не понесется как больная 😃

KBV
smalltim:

Второй канал отдать управлению экранами, будет проще и понятнее. Голосуйте, сделаю моментом, ломать - не строить.

не не не, а контрольные точки как преключать? не ломайте мне любимую игрушку (ПКТ) 😃

Dareck
smalltim:

Коллеги, я только за. Второй канал отдать управлению экранами, будет проще и понятнее. Голосуйте, сделаю моментом, ломать - не строить.

Думаю как вариант сделать порезанную прошивку для жаждущих, а последующие точить из нерезанных, я к примеру пользую все 4е экрана

baychi
Edward_tlt:

Правда теперь наверное может влиять и параметр Удерживать газ…

Да, 9 А добавили скорости. Переключение режима в удержание скорости - поможет.
Но ИМХО будет еще лучше, когда Тимофей добавит в официальную прошивку режим “Газ в зависимости от тангажа”.

Dareck:

как вариант сделать порезанную прошивку для жаждущих

Зачем плодить сущьности? 😃 Все что они хотят можно получить в текущей прошивке. Разве так трудно скопировать 2 экрана в 4 или 1 в 4?

Ильвир
baychi:

Зачем плодить сущьности? 😃 Все что они хотят можно получить в текущей прошивке. Разве так трудно скопировать 2 экрана в 4 или 1 в 4?

И при этом ждать нужного экрана, держась при этом за необходимый тумблер, дабы успеть вернуть его в исходное положение.
А так, щелкнул тумблером, появился один экран, вернул его обратно - появился другой экран.

Edward_tlt
smalltim:

А вот тангаж при снижении можно зажать с -15 до -10.

А не даёт ставить, только -15:(

DmitryK

А мне гораздо важнее второй управляющий канал. экраны в полете вообще не переключаю. Или может кто подскажет, как из двух тумблеров собрать5 положений и не запутаться:). Аппа старенькая JR 388. Тумблеры жестко привязаны к функциям. Переназначений нет, логических свичей тоже нет. Есть два или три свободных микса…
Хотелось бы на одном мануал, стаб, АП, а на втором КК и ПКТ.

smalltim

Коллеги, работаю над улучшением логики АП в части навигации - реализую helmsman алгоритм для полета по прямым и кругам вокруг точек.
Помимо этого добавляю жестко задавленные I-ветви в PD-контроллеры по крену и тангажу. Будет выглядеть как самоподстраивающиеся P - чувствительность.
Помимо этого D-демпфирование собираюсь задавливать , глядя на перегрузки и колебания по крену и тангажу.
Плюс, небольшой фикс, улучшающий качество поворотов: цель - делать скоординированные повороты, а не абы как.

Dareck
DmitryK:

А мне гораздо важнее второй управляющий канал. экраны в полете вообще не переключаю. Или может кто подскажет, как из двух тумблеров собрать5 положений и не запутаться:). Аппа старенькая JR 388. Тумблеры жестко привязаны к функциям. Переназначений нет, логических свичей тоже нет. Есть два или три свободных микса…
Хотелось бы на одном мануал, стаб, АП, а на втором КК и ПКТ.

Здаётся мне батенька, на такой аппе много не слепиш, если свичи не на два положения

smalltim

В общем, идея такова: повысить качество управления, избавить вас от необходимости заботиться о перегрузках, переруливании на больших скоростях, недостаточной управляемости на маленьких,
в общем, долго подбирать чувствительность и демпфирование.

  1. Добавляю интегральные ветви в PD контроллеры по крену и тангажу. Интегральный член ведет себя как обычно, медленно растет, когда ему надо расти, и не растет, когда не надо. Нанайская хитрость в том, что он всегда ограничен величиной 2*P. То есть, теоретически, нет никакого overshoot из-за интегрального члена: он моментально нулится как только пропорциональный член нулится. Но и абсолютно точного приведения в целевой угол тоже, всё-таки, не будет - такова цена за устойчивость и безопасность. Пока меня такой вариант устраивает, может быть, придумаю еще что-нибудь похитрее.

В полете это должно выглядеть так: сильный ветер либо кривая модель либо мало чувствительности задали - модель не хочет входить в требуемый крен, скажем, 45 градусов. Входит в 20 и всё. За 2-3 секунды вырастает интегральный компонент и додавливает крен в нужную сторону. При приближении к 45 градусам, скажем, на 40 градусах, разница между текущим и требуемым креном падает до 5 градусов, уменьшается пропорциональный компонент, уменьшается и интегральный компонент - он ограничен: I всегда меньше или равно 2*P. В итоге к 45 градусам мы так и не пришли, но и не остались на 20 градусах.
По сути выглядит как адаптивный контроль чувствительности в диапазоне от стартовой, заданной в Контрольной панели, до 3*стартовая.
Пока не вижу причин, по которым введение такого интегрального должно снизить устойчивость управления и вызвать, напрмер, колебания, но прошивку АП с этой штукой обозначу как экспериментальную.

  1. По перегрузкам (по тангажу - с акселерометра, по крену - с датчика угловой скорости по крену) мониторю вибрации и раскачку. Цель - снизить коэффициенты усиления всех ветвей, P,I,D, по крену и тангажу, при возникновении перегрузок и раскачки.
    Механизм следующий. Заводится переменная, скажем, Множитель, которая по умолчанию = 1. При наличии перегрузок, раскачек и колебаний каждый цикл автопилота (~100 раз в секунду) я этот множитель уменьшаю на 0.01. При этом, чтобы сохранить управляемость, Множитель не должен опускаться ниже, скажем, 0.25.
    Помимо этого, в каждом цикле автопилота этот Множитель увеличивается обратно на 0.005 вне зависимости от всяких условий.
    В итоге Множитель в обычном полете равен 1, а на больших скоростях автоматом находится равновесие между уменьшением и увеличением Множителя и обеспечивается его величина, сохраняющая управляемость на грани раскачки - перегрузок.
    Критерием снижения Множителя является наличие мгновенных перегрузок выше 1G по вертикальной оси и интегральный уровень шума по крену, рапортуемый ИМУ, выше определенной величины.
    Если б все имели телеметрию и бародатчик скорости, то можно было бы не заморачиваться, а пересчитать коэффициенты управления, глядя на скорость модели в воздухе - есть четкая зависимость между скоростью и эффективностью рулевых плоскостей, но, к сожалалению, бародатчики скорости есть не у всех 😦

  2. На моделях типа Ская есть четкая тенденция к слишком медленным поворотам в стабилизации и автономном полете, что вызывает желание повышать допустимые углы крена, чувствительность по крену, миксовать руддер и т.д. На моделях типа летающее крыло с задней центровкой есть тенденция к потере высоты на поворотах. Проблема вылезает из 2 вещей:
    а: При наклоне стика крена АП просто выставляет требуемый угол крена, выставляет нулевой тангаж и следит за креном и тангажом. Расчет идет на то, что в крене модель начнет естественным образом поворачивать из-за аэродинамических свойств и на то, что в крене модель начнет опускать нос, что вызовет реакцию АП по тангажу в виде поднятия РВ.
    Так вот, нос опускается не всегда настолько, что реакция АП по РВ оказывает серьезную помощь в повороте. Крыло, например, может просто соскальзывать внутрь круга, не меняя тангажа но теряя высоту.
    б: Реакция АП по тангажу на данным момент задавлена с оглядкой на текущий крен: чем больше крен, тем меньше реакция по тангажу. Сделано из-за опасности войти в плотную спираль и не выйти из нее при возврате на базу с низкой высоты: РВ полнимается вверх, и не дает модели выйти из спирали. Так вот, душить надо было не реакцию АП по тангажу, а требуемый угол тангажа. Исправлено.
    Решение проблемы: добиться выполнения скоординированного поворота. Поскольку ИМУ есть не у всех, и четко вымерять угловые скорости смогут не все АП, делаю так: при требуемом крене Х я во всё, посчитанное АП для РВ, добавляю положительное отклонение вида X% * sin(текущий крен). Х задается из Контрольной Панели, он разный для разных моделей, и ожидается в районе 20-40%. В итоге РВ автоматически будет помогать делать красивые плотные повороты без потери высоты.

Ну и, напоследок: есть очень большой соблазн перейти на управление моделью не углами, а угловыми скоростями, но, пока не у всех есть ИМУ, и не запилена новая навигация, потерплю и еще поперевариваю в голове.

serj

Тим, по крену так не надо. Нет такой устойчивости по крену ( V поперечное не 45 градусов), и демпфирование очень сильное аэродинамическое.
Если мы задали недостаточный момент элеронами, например не 30 гр/с а всего 10, то ничего страшного, через 4с у нас будет 40 градусов крена а через 18- полубочка )