Smalltim OSD and autopilot (часть 1)
Идея красивая. Но:
Априори существует логическая связь между тангажом, креном и целевой скоростью и элеронами, элеватором, РН, и каналом газа. Но априори нет доказанной связи между одним из элементов полета и закрылками. То есть в частном случае она есть, а в виде общей модели - нет. И здесь я вижу логическое противоречие между количеством неизвестных и количеством уравнений!
И еще. Почему ты уверен, что описание системы управления исчерпывается линейными, либо дифференциальными уравнениями? И в данном частном случае - матрицой коэфиициентов данных уравнений? Я - больше склонен к процедурным решениям. 😃
Хотя идея, конечно, очень-очень красивая…
Микшер “всё со всем”, всё равно надо будет сделать - вдруг пригодится?
Это - точно пригодится. По крайней мере, любая солидная аппа РУ имеет такой микшер.
>Идея красивая. Но
-
Железка и так имеет много упрощений, самое очевидное из которых, например, - отсутствие экспонент и прочих нелинейностей. Это неизбежно и это не обсуждается. Эспонент в ближайшем будущем не будет.
Железка так или иначе генерит линейную комбинацию векторов, просто раньше в векторах везде кроме соответствующего канала стояли нули, а сейчас могут быть не нули. -
Для адекватного управления моделью мне достаточно, чтобы вектора состояний мин/макс тангажа, крена и газа были максимально ортогональными в пространстве PPM каналов. Т.е., скалярное произведение любых двух должно быть близко к нулю. Если не ноль - значит есть какие-то перекрестные связи. Если совсем не ноль - значит, такой моделью и с передатчика невозможно управлять. По моему небогатому опыту, нет моделей самолетов, которые не удовлетворяют описанному выше условию ортогональности.
Единственный минус, какой мне сейчас с ходу видится - необходимость решать систему линейных уравнений для нахождения требуемых углов крена и тангажа из входного вектора PPM в режиме стабилизации 2. Ну да что-нибудь придумаем.
А закрылки - просто отдельный вектор, как раз, не ортогональный вектору крена, и управление закрылками, кстати, в обычном полете, наверное, не используется. Потому я и задавал вопрос: а когда, кроме посадки, оно надо?
В каких режимах автономного полета (кроме посадки) железке могут понадобиться флапероны/закрылки?
В критических режимах, при удержании скорости на пределе сваливания, например.
Для адекватного управления моделью мне достаточно, чтобы вектора состояний мин/макс тангажа, крена и газа были максимально ортогональными в пространстве PPM каналов. Т.е., скалярное произведение любых двух должно быть близко к нулю. Если не ноль - значит есть какие-то перекрестные связи. Если совсем не ноль - значит, такой моделью и с передатчика невозможно управлять.
По моему, это тема для диссертации, а не для форума.
Как аппонетнт, по себе сужу: построить мат.модель управления и доказать ее непротиворечивость, или обратное - не возмусь. Максимум на что способен, - подставить под сомнение предложенный функционал. Да и то, после Дня Энергетика, много ли я помню математики? 😃
отсутствие экспонент и прочих нелинейностей.
А как-же ПИД- коэффициенты? Дифуры тоже в первом приближении апроксимируются степенными многочленами 2-3 порядка…
В критических режимах, при удержании скорости на пределе сваливания, например.
Ага, ну вот оно и попалось: просим в Контрольной Панели ввести значения бароскорости s и S для максимального и минимального отклонения флаперонов/закрылков. И делаем следующее:
- если скорость меньше s, то отклоняем максимально
- если скорость между s и S, то отклоняем пропорционально положению между s и S
- если скорость больше S, то не отклоняем.
Дополнение: тут приходят вопросы:
-
Что будет если в аппе используются нелинейные микшеры и микшеры со смещением кривой микширования?
Не пользовался, но подвоха не вижу: железка запоминает средние, минимальные и максимальные положения в каждом из каналов, так что со смещениями проблем быть не должно, а про нелинейность уже написано - нелинейности не будет . -
Что будет с триммированием в полете?
Если железка не работает в режиме стабилизации/автопилота, то на триммирование она вообще не влияет. Как хотите, так и триммируйте.
Если железка работает в режиме стабилизации 1, то как хотите, так и триммируйте.
Если железка работает в режиме стабилизации 2, то триммирование правой ручки будет менять требуемые углы крена и тангажа, и двигаться будут все управляющие плоскости, замикшированные при калибровке с передатчика.
Если железка работает в режиме автопилота, то триммирование отправляется лесом железка сама генерит PPM, не глядя на то, что приходит с приемника.
Тим, текущее время выведи плз. ну и будильник надеюсь то же имеет право на жинь.
// жаль звука нет в osd
// жаль звука нет в osd
У железки есть 2 ноги общего назначения, пищание и хрипы можно без проблем выводить в звуковой канал. Всё что нужно - 5 строк в прошивке, знать, чего настраивать в Контрольной Панели и проводок в аудиоканал передатчика.
А будут всякие варнинги по касчеству сигнала, разряде батареи, по определеной высоте и т.п.? Чтобы начинанал помаргивать соответсвующий индикатор, тогда можно было бы сделать чтоб еще и попискивал
Мысли интересные, только вот никак в толк не возьму зачем автопилоту правлять закрылками/флапами? Они либо включены, либо нет. Мы же тут не бортовую электронику для СУ 30 разрабатываем, которая управляет предкрылками/ закрылками и пилот о них даже не задумывается 😃
Единственное что я могу предложить, что бы автопилот вмешивался в управление закрылками/флапами/тормозами- это превышение максимальной скорости при большом угле тангажа на пикирование. И тогда он должен врубать все, чем самик может тормозить…
>А будут всякие варнинги по касчеству сигнала, разряде батареи, по определеной высоте и т.п.? Чтобы начинанал помаргивать соответсвующий индикатор, тогда можно было бы сделать чтоб еще и попискивал
Да.
Супер.
Вот ещё-бы на верт его поставить,что-б управлял на ССРМ…
П.З.Кстати а карбоновые лопости ЖПСу мешать не будут?
Супер.
Вот ещё-бы на верт его поставить,что-б управлял на ССРМ…
П.З.Кстати а карбоновые лопости ЖПСу мешать не будут?
Чего им мешать то? если гпс из машины неплохо работает.
А вот на вертолет нужно придумать будет отдельный алгоритм т.к. там газ-скорость угол тангажа-набор высоты не в прямой зависимости, но со временем имхо Тимофей и это доработает, был бы спрос…
Чего им мешать то? если гпс из машины неплохо работает.
А вот на вертолет нужно придумать будет отдельный алгоритм т.к. там газ-скорость угол тангажа-набор высоты не в прямой зависимости, но со временем имхо Тимофей и это доработает, был бы спрос…
спрос будет! я сам вертолятор и народ уже давно на верты все это поставить хочет, вот только боятся, управлять вертом самому то надо и при потере сигнала - ЗЕМЛЯ
>А вот на вертолет нужно придумать будет отдельный алгоритм
Он уже есть и это даже летало и не падало у одного из коллег. Но это было давно, сейчас всё вертолетное из кода выкинуто, надо переписывать и проверять еще 100 раз перед выкладыванием на публику. Когда - пока не могу даже приблизительно сказать.
подскажите, может можно где то скачать инструкцию по установке телеметрии “мини”, ато даже не знаю с какой стороны подойти к ней?
smalltim.ru/tele/docs/
А чего здесь не хватает?
подскажите, может можно где то скачать инструкцию по установке телеметрии “мини”, ато даже не знаю с какой стороны подойти к ней?
как минимум то, что это другой продукт.
Инструкции к старой телеметрии можно следовать во всем кроме расположения разъемов. Разъемы на мини подписаны, так что ошибиться практически невозможно.
Саму инструкцию под мини я было начал переделывать, но отложил - пилот сейчас важнее.
спасибо.
но может быть, кто то сможет расписать все разъемы?
просто боюсь все спалить, да и возможно еще кому то поможет…
но может быть, кто то сможет расписать все разъемы?
Я чего то не понимаю?
А у вас что, на плате разъемы не подписаны?
У меня был мини из самой первой ревизии, так через 2 недели Тим мне по своей инициативе обменял на подписанный и цветом проводов промаркированный вариант. Аргументируя это тем (гусары, молчать), что он - перфикционист 😉
За что ему - бооольшое спасибо.
Сейчас промоделировал на компуке систему с векторами состояния PPM - в режиме автопилота и стабилизации 1 всё работает как часы.
Беспокоивший меня режим стабилизации 2, в котором неочевидно, как из входного PPM вычленять требуемые пилотом углы крена-тангажа, газ, флапы и т.д. - заработал вполне сносно.
Ну, то есть, если в передатчике не намикшировано перекрестных связей типа газ-флапы, газ-элероны, газ-РВ, газ-РН и т.д., то всё работает просто идеально, и не важно что за модель - 1-канально-элеронная, 2-канально-элеронная, элевонная, V-хвостка, с РВ замикшированным с элеронами, с РВ вместо элеронов, и т.д.
Если есть перекрестные связи между параметрами “крен, тангаж, газ, флапы”, чем бы эти параметры ни рулились, то точность определения желания пилота падает пропорционально процентам в перекрестных миксах. Но это реально нечеловеческие миксы - типа элевоны, к которым еще и флапы подмешаны. Или элероны, к которым РВ подмешан.
В общем, всё пока хорошо 😃
>с РВ замикшированным с элеронами, с РВ вместо элеронов
Вру. Конечно, не РВ, а РН. 😃
Перепробовал все известные мне варианты микширования плоскостей, с полноценной симуляцией и композицией-декомпозицией векторов PPM - пока не нашел тот, с которым новый алгоритм обучения железки не работает. Вот бы так бы и дальше пёрло 😃