Activity
Я сделал новый релиз своей версии WFB. Из нового:
- Двустороння телеметрия для mavlink.
А если допустим это будет не совсем правильный пакет мавлинка на стороне передатчика? Например у него будут неправильные CRC и контент будет в виде бинарного шума? WFB проверят что шлет или просто шлет все что пришло из UART? И на стороне приема, выловленные MAVLINK пакеты просто выкидываются для обработки в некий порт или WFB пытается их разбирать/анализировать?
Примерная схема:
“Автопилот” [оборачивает свои пакеты в MAVлинк] -> UART порт RaspPi3B
Камера + uart -> RaspPi3B [WFB] -> …радио… -> NeoFire3 -> картинка + Qt софт [разворачивает пакеты и обрабатывает их, шлет свои липовые пакеты на передачу на борт]
Это хороший вариант, но под него нужны шаблоны - “маски” вида местности. Подобный способ применяют для точного наведения СБЧ (в маневрирующем исполнении), в предыдущих поколениях томагавков, в некоторых свободно падающих бомбах. Есть “маски” на определенных высотах, вычислитель интерполирует между ними и сравнивает с текущей картинкой (обычно это или ИК или радарная).
Подразумевая универсальность “из коробки”, данный способ, к сожалению, неприемлим.
Увы, схему *предполагаемого* решения “как эффективно оптически определять высоты, и чем меньше они тем выше точность” пока не могу озвучить…
Локатор “как в настоящей авиации” скорее всего по цене равен “локатору из настоящей авиации” 😉
Глиссаду можно организовавать без всего этого барахла… Что и делается всеми уже давным давно средствами IMU/GPS… Измерение малых высот это немного другая задача, ее решить можно проще, если брать только “визуальные дневные” полеты.
Ультразвук не универсален. Малые высоты для тяжелого борта это 0…50 м, потому и выбрана оптика, как в принципе наиболее эффективное решение принятое природой для “дневных полетов”. К тому же при крене, малые высоты ультразвуком мерится будут неверно, и использование УЗ не снимает вопросов к детекции горизонта, а через него и контроля углов крена-тангажа.
Одним из принципиальных требований при любом выборе в данном проекте - масштабируемость. Если решение не применимо для реального, большого и тяжелого самолета, оно отсеивалось. Так были отложены все ультразвуковые и радиочастотные доплеровские решения для малых высот… Вот как то так…
А вот с этого места-нельзя подробнее?
Это-как?
Давайте я сначала проверю планируемое решение, а потом просто скажу получилось или не получилось. А то сейчас у меня сплошное теоритизирование в вопросе корректного расчета малых высот через оптику. Метод не тот который вы имели в виду, и неясно сработает с нужной точностью или нет.
-------------
Тепловизор? А зачем? Что не увидит камера такого что увидит тепловизор? (в дневном полете малых высот с видмостью земли) Имхо, надо не усложнять сущности… К тому же верно подмечен ценник 😃
Ультразвук - запасной вариант, если совсем с оптикой будет затык, но пока надежды на нее.
IMU есть и он активно используется алгоритмом… задача возлагаемая на оптику - коррекция уводов горизонта при долгих полетах и определение малых высот при посадке… тут без вариантов, если рассматривать среднюю серьезность (без ультразвука с одной стороны и радиовысотомера с другой 😉 )
Ветер не поменяет направление через километр на 180 град… на высотах выше 100м он примерно одинаков по направления в наших равнинных местностях на большой площади… а в горах конечно всякое может быть. но там и аварийная посадка спорна.
Ветер принимается примерно равным. Когда вы идете на безмоторном планировании, всегда видна точка куда вас несет, безотносительно турбулентности, это один из важных навыков которому обучается пилот. Да, довольно приблизительно, особенно чем дальше от земли, но вы же за ручкой, значит можете подрулить, куда надо! 😃
Алгоритм также повторяет логику работы пилота, он прогнозирует точку куда несет борт и соответственно выбирает траекторию. Но там сейчас “плохая” математика. Работаю над ней.
Вообще, до начала переноса логики на конкретное железо вычислителя осталось две основных задачи нерешенных. (Все остальное более-менее вменяемо работает) Первая - самая простая - реализовать нормальную безмоторную посадку. Весь необходимый инструментарий есть. Т.е. борт нормально управляется, и отлично ведет себя, выдерживает безопасную схему снижения с запасами по скорости. После отказа двигателя он выбирает ближайшую полосу и планирует туда. Загвоздка в логике высокого уровня. Алгоритм должен рассчитать какой у него избыток энергетики, т.е. куда он может дотянуть с текущими параметрами полета. Там два исхода. Если энергетики меньше чем надо - ну тут без вариантов, он поздоровается с землей где то по трассе. Если энергетики больше чем надо, необходимо ее рассеять, что бы к порогу глиссады он вышел с совершенно конкретными высотами и скоростями. Нужен маневр рассеяния энергии, лишний кусок траектории. И вот здесь пока как то странно получается расчет этого самого избытка энергетики, но это решаемо, собственно это текущая задача в решении…
Вторая, и куда более серьезная проблема - оптический горизонт. Для нулевой сборки алгоритма конечно не стоит никаких глобальных задач. Всего лишь определять положение линии горизонта в кадре. По умолчанию, проблем нет. Проблемы начнутся в ситуациях “летим над заснеженной поверхностью”, “летим в кучевых облаках”, “летим в горах”, и наверняка еще в туче странных комбинаций темного закатного неба и ярко освещенной подстилающей поверхности…
Жду видео с полётов
Да, конечно! Вот только до тестовых полетов в железе еще реально далеко. Проекту уделяется всего лишь по 4-5 часов в неделю… это оч мало. Пока только симулятор.
(а сам потихоньку крапаю свои бортовые мозги)
А можете чуть подробнее рассказать о вашем варианте?
Я не узнаю вас в гриме, бугагага 😃
Энви это 😃
Не так конечно как в ГТ но благодарю за удивление 😃
Очень интересный вопрос: реализация детектора горизонта. Камеру в носу борт использует для детекции горизонта и углов или это только видеоканал для наземки?
Алгоритмы корректно садят борт при полном отказе двигателя?
если делать Беспилотник типа - взлетел-забыл… то смысл от него особый?
Ниша есть под них, но это не столь важно, все равно этот проект никто никогда не будет финансировать (реакция здесь индикатор достаточно яркий), тут задача другая стоит: крайне интересно решить эту задачу “под ключ”.
оператор всё равно должен быть - задачи типа - от точки до точки можно и машине отдать с постоянным отчётом на базу
Борт дает телеметрию и подчинится командам наземки, если оператор решит их отдать…
, соответственно всё критичные решения о топливе и прочем примет человек… это проще и надёжней.
Гм, все критические решения принимает борт. Это условие автономного полета. Человеку дана возможность вмешиваться до тех пор пока не встает вопрос о безопасности. Т.е. носом в землю его не получится направить. Лететь при опасно малом запасе топлива борт тоже не даст, развернется на посадку. и т.п.
Джойнт, это ты чтоль? я в вас все время путаюсь… 😃
кстати - наш космический челнок в его первом и последнем полёте кто сажал?
Собственно опыт Молнии (КБ Молния) и вдохновил на решение задачи этой. Но там немного другое решение. Буран шел на терминальном алгоритме с решением запаса по энергетике, это слишком комплексное решение, и нуждается оно в очень точной летной модели борта. у меня конечно все проще.
Будете смеяться- я всё это уже сделал: есть и самолёт серийный и АП рабочий.
Не могли бы вы показать ваш сайт с представленным вами сабжем? 😃 Или иной PR материал позволяющий проникнуться величиной ваших достижений? (а то сча БПЛА пруд пруди на разных сайта, как то не могу вас признать без грима 😃 ) Заранее скромное спасибо.
Ой, я щаз помру со смеху, теоретик Вы наш
Эй, стоп, не помирать! Отставить смех в строю! Кто на максе вместо вас выставлять то будет? Одни иркуты что ли? 😃
Продолжаем диалог. По задачам ничего не сказали, жаль. Вторая часть - проблемы в полете. Не менее важная между прочим.
Отрабатываемые некритические аварийные ситуации на борту.
Неуборка шасси.
Борт выпускает все стойки шасси и производит нормальную посадку на аэродроме взлета или ином указанном для этой ситуации в ПЗ.
Невыпуск шасси.
Не вышли боковые стойки шасси. Борт может выполнять аварийную посадку «на брюхо» предварительно убрав вышедшие стойки шасси. Или (по указанию) садится на оставшиеся стойки по возможности парируя крен.
Не вышла носовая стойка. Борт садится нормально с выпущенными стойками, задирая нос, по мере снижения скорости пробега, до последнего.
Вышла только носовая стойка. Борт садится только с носовой стойкой.
Невыпуск-неуборка секции закрылок. (секция: сторона по крыльям)
Борт устанавливает положение закрылок в «равное» и осуществляет нормальную посадку на указанную ВПП.
Отказ ПВД.
Борт использует для расчета опорные данные GPS скорости с учетом запаса безопасности на ветер.
Отказ IMU.
Борт использует для расчета опорные данные GPS с учетом поправок оптогоризонта. При отсутствии данных с оптического горизонта (туман, сплошная облачность), борт немедленно следует к ближайшей допускаемой точке посадки используя резервную схему коррекции горизонта по магнетометрам. Посадка по данным GPS/магнетометров.
Отказ GPS.
Борт использует для расчета опорные данные IMU с учетом поправок оптогоризонта. При отсутствии данных с оптического горизонта (туман, сплошная облачность), борт немедленно следует к ближайшей допускаемой точке посадки используя резервную схему коррекции горизонта по магнетометрам. Посадка по данным IMU/магнетометров.
Отказ оптогоризонта (не туман и т.п., а именно отказ).
Борт немедленно следует к ближайшей допускаемой точке посадки используя резервную схему коррекции горизонта по магнетометрам. Посадка по данным GPS/IMU.
Отрабатываемые критические аварийные ситуации на борту.
Отказ двигателя.
Отказ двигателя рассматривается в двух ситуациях. При частичной потере мощности - будет выполнен уход к ближайшей точке посадке из перечисленных в плане полета. При полной потери мощности - с выполнением аварийной посадки (против ветра) с опциональной возможностью (т.е. при наличии достаточной высоты и путевой дальности) дотянуть до ближайшей посадочной точки из заложенных в план полета. (В качестве опциональных, борт также рассматривает точку взлета.) Если имеется переизбыток энергетики полета, БПЛА выполнит соответствующие пространственные предпосадочные маневры с целью рассеяния избыточной энергии и безопасной посадки.
Мало топлива.
При наступлении условия “Бинго” по последней достижимой из остающихся точек посадки (перечисленных в плане полета) БПЛА осуществит полет к ближайшей остающейся точке и выполнит посадку там.
Разряд батарей / отказ генератора.
БПЛА осуществляет полет к ближайшей точке посадки и садится там. В случае если значения напряжения упадет до опасно малого значения, БПЛА осуществит стандартную процедуру аварийной посадки против ветра. Неуправляемый полет БПЛА не допускается.
Пожар.
БПЛА направляется к ближайшей точке посадке из перечисленных в полетном задании. Также активируется автоматический огнетушитель. Если датчики показывают что возгорание в силе после попытки тушения, полет продолжается на малых высотах до наступления иных критических ситуаций (отказ двигателя и т.д.) Далее ситуация отрабатывается в соответствии с отказом. Уничтожение проводки управления огнем и последующая потеря управляемости в полете в настоящий момент не регламентируется.
Или Вы уже дошли до создания искусственного интеллекта? 😍
Нет, это не AI, это ближе к мозгам насекомых, если вы так хотите искусственного интеллекта.
Хотя, судя по темпам (если с 2005 г- ещё нет ничего реального), я до триумфа Вашей мысли-не доживу 😦
Буду краток. 20 тыс долл. 😃
Более длинный ответ: А что вам нужно то реальнее этого? Борт полетит в ближайшие полгода, если вы сейчас выделите мне штат программистов (2 чел), конструкторов (2 чел) и бюджет см выше только на постройку железа. 😃
Вы бы и такого не сделали, простите мне мой цинизм. 
Как все сложно и запущено…
Не верьте им! Все просто 😃
А что за ОС планируете использовать?
Неужели виндовс? Или неужели Линукс?
на мощном вычислителе по умолчанию стоит линукс… пока она сгодится на первый этап, це не ОСРВ в чистом виде, но у меня требования не велики. алгоритм изначально проектируется с учетом того что он будет в виде процесса… если найдется компилятор под микрокоды этого железа, то можно будет просто его скомпилировать, не заморачиваясь линуксом, но это дело поздних этапов. Например, драйвер видеокамеры там под линукс, и без исходного кода вроде… а без нее никак…
на микроэвм обслуживающей IMU никаких ос конечно не будет, туда просто микрокод соответствующий.
макет алгоритма сейчас под виндой, т.к. среда разработки Builder С++ под винду… но там по минимуму аппаратных функций, все через вставки, что бы их легко заменить, и чистый С, никаких С++, что бы упростить портирование и увеличить эффективность кода…
А что тут можно упустить… Аппарат должен взлететь, пролететь по маршруту и сделать посадку. Если все это уже реализовано и работает…
Эх, ну может чтото конструктивное… 😦 Что ни будь из практики! 😃 Свежий взгляд от сообщества моделистов!
По количеству виденных дров и морковок, как моделист и разработчик , могу возразить: если взлёт/посадка происходит на бетонке 6кмХ2 (как в ЛИИ им Громова),предварительно прометённой- то почти никаких проблем, ну кроме ветра 😃
Боковой ветер не проблема. Он учтен на уровне алгоритма.
Если же имеется в виду эксплуатация БПЛА в реальном мире, с кочками, ямками порывами ветра и прочими колдобинами, то АП, какой бы умнейший алгоритм в нем не был заложен, не поймёт что делать😢
А как вы то “понимаете” что делать? Почему вы отказываете алгоритму в понимании “что делать”? На каком основании? 😃
Если вдруг под колесо попала ветка, шишка или другая помеха: он что сделает- полный газ и ручку на себя?
Зачем? Если пробег - то просто парирует боковой снос если был, если взлет, то скорее всего тоже… если его конечно после этой ветки взлет не начался 😃
А если самолёт после помехи изобразил “прогрессирующего козла” и- глядит носом в землю?
алгоритм не даст этого сделать, что тут особого то?
Вы рассматривает сейчас какието желозебетонно жесткие системы, зачем? Это динамическая комплексная система, она оценивает, решает, взвешивает… Пока иногда ошибается, причем не в плане любимых “морковок” и прочего, а просто вынуждена выводить аппарат из опасных режимов. Она то выводит, но, надо добиться что бы ничего такого не было изначально.
Все рассуждения автора топика- не более, чем мнение “боксёра-заочника” выигрывающего бои “по переписке”. Но на настоящем ринге- бьют по морде 😦
Боже… Ну попробуем еще раз: АЛГОРИТМ ГОТОВ (!)
читайте по губам Г.О.Т.О.В.
сейчас идет его доводка и отладка… в свободное от зарабатывания денег время.
я не спрашиваю возможность или невозможность. я спрашиваю что упустил.
какой заочный бокс?
Offtop!
более того, вы мне начнете говорить да что я знаю о реальной динамике посадки реального борта (т.к. наверняка до этого момента нечитали что я написал много выше)
я знаю реальную динамику того что делаю.
и “учу” борт по динамике посадки соответствующей вот этой штуке (гироплан), с отказавшим мотором.
(снимку правда уже 5 лет, а за ручкой, ваш покорный слуга, “боксер-заочник” 😉 )
. Скорее это пожелания заказчика, для которых нужно составлять подробное ТЗ… И уже на основе которого, думать над алгоритмами, реализующими все хотелки заказчика… Но, как понял, именно алгоритмы сурово засекречены, и нам надо просто поверить, что они есть и работают…
UPD Пардон, я неправильно прочел. Да, вы все правильно поняли. Алгоритм есть, сурово засекречен и вам в доказательство того что вас не дурят (а зачем дурить то? вы спонсор? работодатель? 😃 ) только то мутное видео с одним из бесчисленных тестовых кружков по ссылке выше. Но какое это отношение имеет к моим вопросам, чесслово не знаю.
Это перечень того что делает алгоритм в конкретных полетных ситуациях… того что уже реализованно сейчас. не надо ничего проверять. Если я чтото упустил в этих действиях, чтото неправильно написал, поправьте, я внесу правку в логику алгоритма.
есть уже аппаратуры со связью с компом, то есть комп может рулить реальной моделью. Если Ваш алгоритм сразу же адаптировать для такой апы, то и скептицизма поубавится. Пеносамоль с приличным размахом (типа электропланер) - самое то.
Он поддерживает связь на уровне телеметрии с наземным комплексом (окно НКУ открыто на правом экране)
НКУ может отдавать команды при необходимости на борт и (или) полностью вмешиваться в управление. Но радиосвязка не отработана никак, сейчас там просто заглушки передающие данные по локальной сети и наметки протокола обмена (т.е. все вплоть до радиоканала). Один комп играет роль борта, другой нку. За доводку этой части буду браться только после начал переноса кода на физический автопилот.
Вы, прежде чем амбции то выращивать-глянули лучше, что уже летает?
Если на МАКС приедете, то сможете увидеть там Иркут-200: отлично летающий БПЛА который, тем не менее- взлетает и садится “вручную”.
Делали его профессионалы, которые намеренно отказались от автовзлёта/посадки, поскольку эти понты только усложняют эксплуатацию и снижают надёжность.
😃 я не комментирую и не спорю с работами коллег. В то же время меня они никак не касаются. У меня свое видение построения борта и алгоритмов у иркута и прочих свое. Ниша лакомая, ниша интересная, кто первым получит коммерческое решение (а не опытно-испытательное как сейчас) того и тапки. Логику заложенную в БЦВМ иркута-200 и прочих автоматичски взлетающих и садящихся комментировать тоже не вижу смысла. Аналогия: Автомобили известны начала века. Что тут можно изобрести? 4 колеса да двигатель. И нафига эти конструкторы еще чтото новое делают? Вон же есть форд (тот который с конвеера Того Самого Форда)! Ездит сам! 😃 так вот, я с уважением и пониманием отношусь к решениям коллег, но не вижу основания восхищенно опускать руки глядя как откровенно сырой аппарат раз за разом ставят на МАКС. 😃 Если сравнивать, то реальный конкурент, извинит, не Иркут, а Боинг с их автоматически садящимся челноком. (тот что давеча тихо и мирно год а автомате на орбите отлетал) 😉
Алгоритм должен не содержать элементов разного уровня “высоты”.
Алгоритм не содержит “высоты” 😃
Вы управляете бортом и находитесь в каждый момент времени в одной из этих ситуаций. Вот и все. Высота тут не при чем. Алгоритм делает то же что и вы 😃
По инерционности - тут можно всегда высчитывать на каждом этапе и коректировать “СКОРОСТЬ ОТВЕТА” самолета на каждое действие (отдельно для правых и левых и верха и низа для учета ветра и пр.) и получить таблицу исходя из которой уже и “давать рулей”, которые будут уменьшать расходы при подходе к нужному курсу и исключат раскачку и “промазывание” или даже смогут парировать это. Ну в общем то о чем писал Syberian.
Ну, при интересе, см в видео. Что там делает алгоритм…
Насколько я понял - алгоритм тот же что и у пилота RC.
Голова и руки запоминают в тренировках при какой воздушной скорости на сколько и в течении какого времени нужно махнуть управляющей плоскостью чтоб получить нужную коррекци ю положения.
Собственно с этого и начался поиск. Первый алгоритм 2005 года, был по сути специализированной экспертной системой постоянно набиравшей статистику по поведению борта в зависимости от внешних возмущений и приложенных управляющих моментов. Способ хороший. Замечательный! Работает как раз для упоминавшихся выше сферических коней, но чем более тяжелый и инерционный борт управляется им, тем выше, пардон, едет крыша у системы. Тк ей надо учитывать неизвестную ей инерцию в понимании поведения борта. 😃 А все чему надо учить на земле, не годится по начальным условиям задачи “универсального алгоритма”.
У пилота - не большая.
Именно! Нам не нужна большая частота для решения задач управления, значит, можно сделать такой же алгоритм которому тоже не нужна будет большая частота. Это тоже стало одним из “условий ТЗ”.
Тобишь вы создаёте Гомункулиса, отодвигая пилота взад?
Нажал на капу и пепелац сам летает и садится.
я его вообще исключаю. И в теории, мы говорим конечно не о пассажирских перевозках, а о грузовых. Тяжелый БПЛА должен обеспечивать весь цикл полета сам, самостоятельно разруливая все проблемы которые возникнут в полете. Да, звучит амбициозно, но на данном этапе речь идет даже не о принципиальной возможности создании подобного алгоритма управления (к счастью, он уже создан “в черновике”), а скорее о том что бы теперь медленно и верно приводить его (алгоритм) в реально летающий вид. До того как модель-прототип поднимется в воздух еще ой как много лет. (учитывая скорость работ, пара лет точно) т.к. естественно это не финансируется и не поддерживается никем, и в данном случае все работы ведуться по остаточному принципу времени. Но как ни странно все же идут, потому как задача нетривальная и интересная. Собственно до того как борт выполнил полет на симуляторе в феврале, еще были сомнения “можно-нельзя, справимся-несправимся”, сейчас сомнений нет. (а) - справимся, (б) - можно. Теперь идет кропотливая доводка. Большо количество узких мест, неправильного поведения в ситуациях и просто ошибок математики и логики. И это только на мат-модели, что уж будет всплывать когда будут полеты в железе страшно подумать 😃 Но опять таки, задача интересная, решаемая, хотя и не быстро 😃
Мне важно было знать, что они заменены, а чем именно - не очень 😃
Да, они заменены. С самого начала разработки был глубокий поиск алгоритма который будет не менее эффективным чем хороший ПИД, но при этом будет работать на низкой частоте, и не требовать предварительной адаптации, делать все в процессе полета, при этом не вызывая опасных ситуаций. Реально полтора года проб и ошибок, прежде чем стало ясно куда копать… Ну вот и выкопали вроде. 😃
Частота алгоритма обеспечивающая вменяемый полет 5 герц… Стабильного 10 Гц… (это не 50…120 как у обычных ПИД цепочек… но тут конечно много чего зависит от инерционности борта)
- при высоте 10 м и наличии штопора убить себя апстену
До штопора не доведем, а просто выровняем немедленно борт что бы брюшком плюхнуться. Т.к. такая высота отказа говорит о том что мы у ВПП 😃
Единственно было б логичней рулежку до взлета вынести отдельно с прогревами моторов, ибо взлета может не быть.
Да, конечно, просто для ранней версии точка начала работы - в начале ВПП. После первой успешной аппаратной реализации, уже можно будет думать о рулежке. Пока алгоритм проверяет двигатель перед взлетом.
И из посадки нужно убрать разрешение на посадку. Это часть полета. Ибо пока не разрешили - тупо летаем и пока не возбуждаемся… посадки может не быть если нет разрешения, если долго нет - то запасной алгоритм - это уже ЧП.
По умолчанию борт сразу идет на посадку согласно плану полета. Диспетчер может вмешаться и запретить посадку. Для обеспечения захода против ветра нужно знание ветров, которое по хорошему вместе с METAR борт должен получить в какойто момент времени до выбора ВПП с какой стороны вообще ему садится. Имеется в виду что диспетчер должен передать его на борт, или борт будет использовать то видение ветров которе у него сложилось на протяжении последнего получаса полета, что не всегда может быть верно, как показали тестовые полеты на симуляторе. Ошибка может достигать 60 градусов а обычно составляет около 30-40 градусов. А если полет протикает в горной местности или в условиях знакопеременной турбулентности, то там скорее всего вообще будет ирунда а не реальный ветер.
Ну то есть после команды взлет - любое отклонение от алгоритма ведет к возникновению ЧП и отказу от полета.
И после начала посадки любое отклонение ведет к запасному алгоритму.
Да, разумеется. Алгоритм строился по ситуационной схеме. Каждая ситуация накладывает свои ограничения. Например, садимся, снос ветрами слишком сильный, в полосу не вписываемся, откат на второй круг, но! отказывает двигатель, это накладывает требование на немедленное выполнение посадки. Борт пытается ее осуществить если не получает указание “уходить от ародрома любой ценой в указанную точку” (например, грузовым беспилотником можно пожертвовать) а дальше уже насколько высоты ему хватит… В любом случае, борт будет сохранять управляемость по критерию воздушной сокрости до последнего, и лишь перед аварийной посадкой попробует выровняться.
Сама же реализация действительно не зависит от самолета (любого летательно аппарата), просто детали меняются а суть одна. Это позволит зная суть (вбив ее в умы пилотов всего что летает) получать пилотов. Как это делается в автошколах.
Именно!
Еще в каждом шаге алгоритма должно быть ответвление на ошибки, и тут вопрос в ответвлении на ошибку должно быть еще ответвление или как? Например, на рулежке на двухмоторнике, второй мотор стал газовать, по ошибке - глушим моторы - они не глушатся-сломалась глушилка…
Потенциальные отказы прописываются в алгоритме жетско довольно таки (пока, там посмотрим), их количество довольно ограниченно по сути. (Кстати, Т-0 пока работает только с одномоторной конфигурацией, многомоторность будет уже много позднее)
Т.е. описанные проблемы можно описать так
“двигатель не развивает заданной мощности” (наш случай)
“двигатель полностью отказал”
Если дело на земле, останов, полные тормоза.
Если дело на разбеге, то зависит от того успеем или не успеем затормозить.
Если в воздухе, то прокладывается маршрут полета к ближайшей ВПП.
Это очень образно, но тем не менее, отказоустойчивость алгоритма- самое важное с чем придется столкнуться. Самик четко должен знать что делать. Без этих ответвлений получим то же самое что счас и имеется…
да, именно. Но это отдельная большая таблица ситуаций. Пока ее не рассматриваем, но она есть. Все сразу проектировалось с учетом ненормального развития событий.
Владимир, я правильно понял, что Вы не используете ПИДы в чистом виде для регулирования? Что-то в голове маячит, но сообразить не могу.
Для примера рассмотрим вывод в горизонт после выполнения бочки.
ПИД-регулятор всегда принимает решение об остановке, когда “нулевая” точка уже пройдена, т.о. колебания неизбежны, пусть треть периода. Человек-пилот может давить, преположим, крен до последнего, а потом резким “качком” руля в обратную сторону остановить вращение без перехода “нуля”.
При этом оценивается момент движения, и в итоге остается всего один динамический коэффициент, который подстраивается “автоматом” после оценки выполнения маневра. И никаких ПИДов.
У Вас такой подход?
Гм, я пока не готов говорить чем заменены ПИДы и как именно алгоритм работает с динамикой высокоинерционного тела, это изюминка и ноу-хау в данном случае.
Но в Вашем случае описан тот же ПИД, пилот “знает” насколько ему надо “дать крена” что бы точно встать в ноль, это компонента "П"пропорциональная с учетом текущего вращения борта, "И"нтегральной компоненты…
Сферический борт был, да, когда отлаживались элементы верхнего уровня. Уже давным давно его заменил чуть менее сферический flygear, который вы безусловно(?) видели на видео. Вместо него вы можете подставить любой борт, корректно описать его (если любопытно, могу дать описание требуемых констант для борта, но врятли вам интересно) и отправить в полет не меняя алгоритмов.
Но, быть может, вы перестанете обсуждать возможности (или невозможности) создания того что уже создано и работает, и перейдете к моим вопросам? 😃
Хотелось бы узнать примерные характеристики аппарата, такие как взлётный вес, объём и тип двигателя, площадь крыла.
Это неважно. Когда вы управляете реальным бортом (автомобилем, самолетом, гиропланом и прочим) вы чувствуете разницу между тем что у вас осталось в памяти от управления предыдущим аналогичным аппаратом, но принципы управления остаются теми же. Руль направо поворачивает машину направо а не налево. Ручка от себя направляет ЛА вниз а не в верх. Увеличение оборотов двигателя поднимает борт вверх. И т.п. Алгоритмы работают по тому же принципу. Задача была сделать универсальный алгоритм, которому не требуется никаких иных данных кроме тех которые получает человек пилот. Вам не нужно знать массу борта и площадь крыла что бы им управлять. Вы должны знать пределы скоростей с учетом механизации, рекомендуемые углы и скорости посадки, рекомендуемые и опасные углы разворотов и прочее. Алгоритм построен с учетом именно такого подхода 😃 Алгоритм анализирует реакции борта и подстраиватеся под них.
Вообще то, ставить телегу впереди лошади до Вас уже много раз пытались 😦
Кончалось плохо.
Автобиографическая справка: я с пониманием отношусь к позиции здорового скептицизма, но опираюсь на многолетний опыт проектирования сложных алгоритмических систем на языках высокого уровня, с 1995 примерно. 😃 В части необходимого понимания физики лирики и математики процессов сопровождающих полеты бортов, я опираюсь на знания полученные в МАИ (диплом правда на Ваш взгляд подкачал: инженер-конструктор КА и РБ)… Далее продолжаем: всю практику реального управления бортом я черпаю из своего опыта управления гиропланами разных конфигураций, средних, легких, одноместных, двухместных… А они очень, очень разные в динамике. Реальных гиропланов. Не моделей. Опыт моделизма у меня нулевой, зато энтузиазм как вы верно заметили за годы разработок не растерян. 😉
Не зная реальных характеристик самолёта (а они отличаются от расчётных-всегда!)
Не нужно расчетных характеристик! Забудьте про эти PID контроллеры! У вас в голове нет никаких PID что бы решать задачу полета.
пИсать ПО -довольно бессмысленное занятие.
вы не программист 😃
Именно ПО корректируется (что гораздо проще) под поведение ЛА в различных условиях, а не наоборот.
А если откажет двигатель? А если полкрыла улетит к бабушке? Как вы будете управлять бортом? Алгоритм должен быть универсальным, адаптирующимся в полете. Все остальные пути - принципиально тупиковые в конце.
( если пользуетесь к примеру, Протеусом)
Codegear RAD Studio BC++ пока… Сейчас этап отладки выского уровня, на средний уровень переход позднее, хотя железо окончательное для ядра борта есть, уже пришло из далекой америки и ждет своего часа. Правда этот этап еще нескоро.
Вы … должны знать, что программа, вроде как идеально в нем работающая, запросто даёт сбои при загрузке в реальный процессор.
И что тут такого? нормальный путь отладки на конкретное железо, ничего особого нет.
Почему считаете, что в гораздо более сложной системе программа-каналы связи-исполнительные механизмы-самолёт : этого не случится?
Это случится, безусловно 100%, но что мешает доводить программу до рабочего вида? Ничего особого тут нет.
Грамотные мозги ( человеческие ) вычислительную технику всерьёз “железом” никогда не назовут, потому что знают, что она определяет программы, а не наоборот 😈
Вы неправы 😃 Эволюция в природе это “железо”. Человеческое общество, это уже эволюция не “железа” а алгоритма. 😃 У вас еще есть принципиальные возражения?
Ну надо же, 6 лет назад не было, а теперь есть ? 😁
Да. (Вы, возможно, немного пропустили? 😃 ) У меня на столе лежит IMU + ядро 750 Мгц, + спецконтроллер 70 мгц со всеми интрефейсами автопилота (машинки, датчики и прочее) + GSM модуль + камера видеоканала. Они умещаются на ладоне, и весят около 200 грамм… на глазок.
Краеугольный камень проекта - оптические алгоритмы - невозможно было реализовать в легком по весу варианте в 2005 году.
Для ковра-самолёта подойдёт ?
Возможно. У вас есть летная модель для Flygear? 😃 если да, давайте, могу потестить. Пока простите б-анальная цессна. (прилинкую видео в следущий пост.)
Сборка майская, работа не стоит на месте, летает оно уже лучше (первый автономный успешный цикл полета в феврале был), но проблем еще много, адаптивности это штука интресная, и чреватая путем долго перебора методов. Собрал алгоритм, проверил - не то. Думаешь. Прикидываешь, где неправ. Снова собираешь. Гоняешь. Снова не то. Потом, о! отличная идея! Проверяешь… Вот оно! Или опять не то. 😃 Итеративность…
Собственно позвольте напомнить, что дискуссия началась с вопроса… Агрессивные сомнения, пафосный скептицизм, нападки и прочее разумное и адекватное поведение конечно приветсвуется, но все же позвольте обратить Ваше внимание на перечень задач по этапам полета. Что пропустил? Что не так? Не стесняйтесь, смелее, коллективный разум в деле отладки всегда эффективнее скромной единицы 😃
- по видео, комментарий для тех кто не проверил ссылку, там это продублировано, что бы не было недоразумений о колебаниях борта.
“Небольшое видео (4 минуты), демонстрирующее типовой цикл полета, под управлением майской сборки (201105) алгоритма. Начальные колебания на старте происходят из-за отсутствия модуля IMU, вместо него стоит блокировка принудительно заставляющая борт использовать данные GPS. Из-за разброса координат, он не сразу понимает направление своего движения, от чего и происходит рывок в сторону. Руление после посадки осуществляется дифференциальным торможением стоек шасси, что тоже не до конца отработано в этой версии, из-за отсутствия корректной имитации работы шасси в симуляторе.”
Добрый день сограждане!
В отличии от коллеги в соседней теме начавшего вести разработку с железа, а программную часть оставить “на потом”, ваш скромный слуга пошел по пути “первым делом мы построим алгоритмы” а железо на потом. Все же железо это по большому счету вторичная штука, без грамотных программных мозгов, железо не поможет 😃
Да и не было тогда железа подходящего размера… Дело было в 2005 году аж. 😃
С тех пор много воды утекло, два с лишним года разработки, далеко не законченной, с большим объемом работ впереди, но кое какие результаты есть. И они более-менее вменяемые, хотя многие с этим спорят.
Итак, вот мои мысли примерно о том что должен делать хороший алгоритм прототипа тяжелого БПЛА. Вопрос: что пропустил? Что не так?
(ПЗ - полетное задание, с описанием маршрута. ТЗ - техзадание, конструктивные ограничения конкретного физического борта)
для этапов полета:
Полная проверка борта, после подачи питания на вычислитель.
• Самотестирование вычислителя. Инициализация GPS. Инициализация и калибровка видеоканала.
• Контроль информации необходимой для полета: полетное задание, описание и характеристики борта.
• Проверка напряжения на источниках тока.
• Проверка бортовой кабельной сети и ее абонентов, получение корректных ответов и показаний от всех приводов, датчиков, рулевых машинок.
• Проверяется выпуск-уборка закрылок, работа основных элементов механизации (рули курса, крена, тангажа).
Работа после получения разрешения на полет.
• Запуск и контроль параметров работы двигателя до выхода его на нормальный холостой ход (в случае ДВС).
• Контроль нормы напряжения и силы тока подзаряда батарей (при наличии).
Сборка Т-0 начинает работу с позиции в начале ВПП. Элементы руления и маневрирования предполагаются в сборке Т-1.
Взлет.
• Установка механизации борта во взлетный режим (закрылки).
• Набор двигателем взлетной мощности.
• Маневрирование по полосе с целью удержания курса в безопасных пределах на разбеге. При серьезной необходимости (выраженный увод в сторону), применяется дифференциальное подтормаживание стоек шасси.
• В случае обнаружения критического отказа (двигатель, датчики, механизация) аварийное торможение. В зависимости от категории отказа и ситуации допускается взлет и заход на посадку. (Например, при отказе датчиков и малой длине ВПП разрешается взлет и заход на посадку. При отказе двигателя, в любом случае придется тормозить, сколько бы полосы не оставалось.)
• После отрыва от полосы и достижения безопасной высоты, уборка механизации (закрылки, шасси) и переход к следующему пункту ПЗ.
Маршрутный полет.
• Полет к точке указанной в ПЗ. Дальнее наведение на точку осуществляется по прямой, вблизи точки, начинается маневрирование (развороты) что бы выйти на точку с заданным в ПЗ курсом.
• Полет выполняется по баровысоте или физической высоте (выбирается с пульта НКУ).
• В полете осуществляется поддержание связи с НКУ. События отправляются по GSM каналу в соответствии с приоритетом важности заданным в ПЗ. («Критическое», «Внимание», «Для справки»)
• Борт периодически проходит рутинную самодиагностику на предмет детекции неочевидных отказов. (Например, ПВД)
• Борт по возможности оценивает направление и силу ветра по маршруту полета.
• В случае возникновения критического отказа (отказ двигателя и т.п.), выполняется оценка возможности аварийного (возможно планирующего) полета к ближайшей точке пригодной для посадки из ПЗ. (В том числе безмоторного полета). В случае невозможности, происходит аварийная посадка против ветра. (Более сложные алгоритмы определения точки посадки «в поле» не реализованы и планируются в сборке Т-2)
• В случае некритического но серьезного отказа, борт может следовать по маршруту или совершить посадку на ближайшую подходящую ВПП из ПЗ. (Определяется указаниями с НКУ или (при отсутствии связи или времени на принятие решения) заложенными на борт указаниями по умолчанию)
Посадка.
• Перед посадкой, при необходимости и с разрешения диспетчера, борт может попробовать определить направления и силы ветра в районе точки посадки.
• Посадка осуществляется по схеме:
а) указанной диспетчером. Если нет указаний то:
б) по схеме «против ветра». Если ветра неизвестны то:
в) выбором ближайшего к борту торца ВПП.
• Борт приводит параметры полета к безопасным для посадочной конфигурации механизации, выпускает шасси и закрылки, осуществляет снижение по глиссаде и обеспечение безопасных углов посадки вплоть до касания ВПП.
• В процессе снижения по глиссаде контролируются параметры спуска и в случае необходимости (борт не вписался в ВПП), происходит уход на второй круг вплоть до критической высоты.
• Ниже критической высоты (высота ниже которой вывод двигателя на взлетный режим не гарантирует отсутствие касания земли), борт осуществляет посадку в любом случае.
Пробег до останова.
• В процессе пробега, осуществляется маневрирование по полосе с целью удержания курса в безопасных пределах методом дифференциального растормаживания стоек шасси.
• Торможение колес осуществляется с учетом недопущения их блокировки.
• В процессе торможения, учитывается и парируется скольжение. (Актуально для обледенелых ВПП)
После останова.
Руление борта не реализовано в сборке Т-0. После достижения конца ПЗ, происходит отключение двигателя.
Да, алгоритм тестировали на flygear (через sockets), просто на тот момент ничего толкового с легкой и быстрой реализация взаимодействия с алгоритмом не было под рукой, а позднее уже не имело смысла переходить на чтото другое.