Алгоритмы тяжелого борта
Добрый день сограждане!
В отличии от коллеги в соседней теме начавшего вести разработку с железа, а программную часть оставить “на потом”, ваш скромный слуга пошел по пути “первым делом мы построим алгоритмы” а железо на потом. Все же железо это по большому счету вторичная штука, без грамотных программных мозгов, железо не поможет 😃
Да и не было тогда железа подходящего размера… Дело было в 2005 году аж. 😃
С тех пор много воды утекло, два с лишним года разработки, далеко не законченной, с большим объемом работ впереди, но кое какие результаты есть. И они более-менее вменяемые, хотя многие с этим спорят.
Итак, вот мои мысли примерно о том что должен делать хороший алгоритм прототипа тяжелого БПЛА. Вопрос: что пропустил? Что не так?
(ПЗ - полетное задание, с описанием маршрута. ТЗ - техзадание, конструктивные ограничения конкретного физического борта)
для этапов полета:
Полная проверка борта, после подачи питания на вычислитель.
• Самотестирование вычислителя. Инициализация GPS. Инициализация и калибровка видеоканала.
• Контроль информации необходимой для полета: полетное задание, описание и характеристики борта.
• Проверка напряжения на источниках тока.
• Проверка бортовой кабельной сети и ее абонентов, получение корректных ответов и показаний от всех приводов, датчиков, рулевых машинок.
• Проверяется выпуск-уборка закрылок, работа основных элементов механизации (рули курса, крена, тангажа).
Работа после получения разрешения на полет.
• Запуск и контроль параметров работы двигателя до выхода его на нормальный холостой ход (в случае ДВС).
• Контроль нормы напряжения и силы тока подзаряда батарей (при наличии).
Сборка Т-0 начинает работу с позиции в начале ВПП. Элементы руления и маневрирования предполагаются в сборке Т-1.
Взлет.
• Установка механизации борта во взлетный режим (закрылки).
• Набор двигателем взлетной мощности.
• Маневрирование по полосе с целью удержания курса в безопасных пределах на разбеге. При серьезной необходимости (выраженный увод в сторону), применяется дифференциальное подтормаживание стоек шасси.
• В случае обнаружения критического отказа (двигатель, датчики, механизация) аварийное торможение. В зависимости от категории отказа и ситуации допускается взлет и заход на посадку. (Например, при отказе датчиков и малой длине ВПП разрешается взлет и заход на посадку. При отказе двигателя, в любом случае придется тормозить, сколько бы полосы не оставалось.)
• После отрыва от полосы и достижения безопасной высоты, уборка механизации (закрылки, шасси) и переход к следующему пункту ПЗ.
Маршрутный полет.
• Полет к точке указанной в ПЗ. Дальнее наведение на точку осуществляется по прямой, вблизи точки, начинается маневрирование (развороты) что бы выйти на точку с заданным в ПЗ курсом.
• Полет выполняется по баровысоте или физической высоте (выбирается с пульта НКУ).
• В полете осуществляется поддержание связи с НКУ. События отправляются по GSM каналу в соответствии с приоритетом важности заданным в ПЗ. («Критическое», «Внимание», «Для справки»)
• Борт периодически проходит рутинную самодиагностику на предмет детекции неочевидных отказов. (Например, ПВД)
• Борт по возможности оценивает направление и силу ветра по маршруту полета.
• В случае возникновения критического отказа (отказ двигателя и т.п.), выполняется оценка возможности аварийного (возможно планирующего) полета к ближайшей точке пригодной для посадки из ПЗ. (В том числе безмоторного полета). В случае невозможности, происходит аварийная посадка против ветра. (Более сложные алгоритмы определения точки посадки «в поле» не реализованы и планируются в сборке Т-2)
• В случае некритического но серьезного отказа, борт может следовать по маршруту или совершить посадку на ближайшую подходящую ВПП из ПЗ. (Определяется указаниями с НКУ или (при отсутствии связи или времени на принятие решения) заложенными на борт указаниями по умолчанию)
Посадка.
• Перед посадкой, при необходимости и с разрешения диспетчера, борт может попробовать определить направления и силы ветра в районе точки посадки.
• Посадка осуществляется по схеме:
а) указанной диспетчером. Если нет указаний то:
б) по схеме «против ветра». Если ветра неизвестны то:
в) выбором ближайшего к борту торца ВПП.
• Борт приводит параметры полета к безопасным для посадочной конфигурации механизации, выпускает шасси и закрылки, осуществляет снижение по глиссаде и обеспечение безопасных углов посадки вплоть до касания ВПП.
• В процессе снижения по глиссаде контролируются параметры спуска и в случае необходимости (борт не вписался в ВПП), происходит уход на второй круг вплоть до критической высоты.
• Ниже критической высоты (высота ниже которой вывод двигателя на взлетный режим не гарантирует отсутствие касания земли), борт осуществляет посадку в любом случае.
Пробег до останова.
• В процессе пробега, осуществляется маневрирование по полосе с целью удержания курса в безопасных пределах методом дифференциального растормаживания стоек шасси.
• Торможение колес осуществляется с учетом недопущения их блокировки.
• В процессе торможения, учитывается и парируется скольжение. (Актуально для обледенелых ВПП)
После останова.
Руление борта не реализовано в сборке Т-0. После достижения конца ПЗ, происходит отключение двигателя.
Да, алгоритм тестировали на flygear (через sockets), просто на тот момент ничего толкового с легкой и быстрой реализация взаимодействия с алгоритмом не было под рукой, а позднее уже не имело смысла переходить на чтото другое.
Хотелось бы узнать примерные характеристики аппарата, такие как взлётный вес, объём и тип двигателя, площадь крыла.
ваш скромный слуга пошел по пути “первым делом мы построим алгоритмы” а железо на потом.
Вообще то, ставить телегу впереди лошади до Вас уже много раз пытались 😦
Кончалось плохо.
Не зная реальных характеристик самолёта (а они отличаются от расчётных-всегда!) пИсать ПО -довольно бессмысленное занятие.
Именно ПО корректируется (что гораздо проще) под поведение ЛА в различных условиях, а не наоборот.
Вы, ( если пользуетесь к примеру, Протеусом) должны знать, что программа, вроде как идеально в нем работающая, запросто даёт сбои при загрузке в реальный процессор.
Почему считаете, что в гораздо более сложной системе программа-каналы связи-исполнительные механизмы-самолёт : этого не случится?
железо это по большому счету вторичная штука, без грамотных программных мозгов, железо не поможет
Грамотные мозги ( человеческие ) вычислительную технику всерьёз “железом” никогда не назовут, потому что знают, что она определяет программы, а не наоборот 😈
не было тогда железа подходящего размера… Дело было в 2005 году аж.
Ну надо же, 6 лет назад не было, а теперь есть ? 😁
“первым делом мы построим алгоритмы” … результаты есть
Для ковра-самолёта подойдёт ?
Хотелось бы узнать примерные характеристики аппарата, такие как взлётный вес, объём и тип двигателя, площадь крыла.
Это неважно. Когда вы управляете реальным бортом (автомобилем, самолетом, гиропланом и прочим) вы чувствуете разницу между тем что у вас осталось в памяти от управления предыдущим аналогичным аппаратом, но принципы управления остаются теми же. Руль направо поворачивает машину направо а не налево. Ручка от себя направляет ЛА вниз а не в верх. Увеличение оборотов двигателя поднимает борт вверх. И т.п. Алгоритмы работают по тому же принципу. Задача была сделать универсальный алгоритм, которому не требуется никаких иных данных кроме тех которые получает человек пилот. Вам не нужно знать массу борта и площадь крыла что бы им управлять. Вы должны знать пределы скоростей с учетом механизации, рекомендуемые углы и скорости посадки, рекомендуемые и опасные углы разворотов и прочее. Алгоритм построен с учетом именно такого подхода 😃 Алгоритм анализирует реакции борта и подстраиватеся под них.
Вообще то, ставить телегу впереди лошади до Вас уже много раз пытались 😦
Кончалось плохо.
Автобиографическая справка: я с пониманием отношусь к позиции здорового скептицизма, но опираюсь на многолетний опыт проектирования сложных алгоритмических систем на языках высокого уровня, с 1995 примерно. 😃 В части необходимого понимания физики лирики и математики процессов сопровождающих полеты бортов, я опираюсь на знания полученные в МАИ (диплом правда на Ваш взгляд подкачал: инженер-конструктор КА и РБ)… Далее продолжаем: всю практику реального управления бортом я черпаю из своего опыта управления гиропланами разных конфигураций, средних, легких, одноместных, двухместных… А они очень, очень разные в динамике. Реальных гиропланов. Не моделей. Опыт моделизма у меня нулевой, зато энтузиазм как вы верно заметили за годы разработок не растерян. 😉
Не зная реальных характеристик самолёта (а они отличаются от расчётных-всегда!)
Не нужно расчетных характеристик! Забудьте про эти PID контроллеры! У вас в голове нет никаких PID что бы решать задачу полета.
пИсать ПО -довольно бессмысленное занятие.
вы не программист 😃
Именно ПО корректируется (что гораздо проще) под поведение ЛА в различных условиях, а не наоборот.
А если откажет двигатель? А если полкрыла улетит к бабушке? Как вы будете управлять бортом? Алгоритм должен быть универсальным, адаптирующимся в полете. Все остальные пути - принципиально тупиковые в конце.
( если пользуетесь к примеру, Протеусом)
Codegear RAD Studio BC++ пока… Сейчас этап отладки выского уровня, на средний уровень переход позднее, хотя железо окончательное для ядра борта есть, уже пришло из далекой америки и ждет своего часа. Правда этот этап еще нескоро.
Вы … должны знать, что программа, вроде как идеально в нем работающая, запросто даёт сбои при загрузке в реальный процессор.
И что тут такого? нормальный путь отладки на конкретное железо, ничего особого нет.
Почему считаете, что в гораздо более сложной системе программа-каналы связи-исполнительные механизмы-самолёт : этого не случится?
Это случится, безусловно 100%, но что мешает доводить программу до рабочего вида? Ничего особого тут нет.
Грамотные мозги ( человеческие ) вычислительную технику всерьёз “железом” никогда не назовут, потому что знают, что она определяет программы, а не наоборот 😈
Вы неправы 😃 Эволюция в природе это “железо”. Человеческое общество, это уже эволюция не “железа” а алгоритма. 😃 У вас еще есть принципиальные возражения?
Ну надо же, 6 лет назад не было, а теперь есть ? 😁
Да. (Вы, возможно, немного пропустили? 😃 ) У меня на столе лежит IMU + ядро 750 Мгц, + спецконтроллер 70 мгц со всеми интрефейсами автопилота (машинки, датчики и прочее) + GSM модуль + камера видеоканала. Они умещаются на ладоне, и весят около 200 грамм… на глазок.
Краеугольный камень проекта - оптические алгоритмы - невозможно было реализовать в легком по весу варианте в 2005 году.
Для ковра-самолёта подойдёт ?
Возможно. У вас есть летная модель для Flygear? 😃 если да, давайте, могу потестить. Пока простите б-анальная цессна. (прилинкую видео в следущий пост.)
Сборка майская, работа не стоит на месте, летает оно уже лучше (первый автономный успешный цикл полета в феврале был), но проблем еще много, адаптивности это штука интресная, и чреватая путем долго перебора методов. Собрал алгоритм, проверил - не то. Думаешь. Прикидываешь, где неправ. Снова собираешь. Гоняешь. Снова не то. Потом, о! отличная идея! Проверяешь… Вот оно! Или опять не то. 😃 Итеративность…
Собственно позвольте напомнить, что дискуссия началась с вопроса… Агрессивные сомнения, пафосный скептицизм, нападки и прочее разумное и адекватное поведение конечно приветсвуется, но все же позвольте обратить Ваше внимание на перечень задач по этапам полета. Что пропустил? Что не так? Не стесняйтесь, смелее, коллективный разум в деле отладки всегда эффективнее скромной единицы 😃
- по видео, комментарий для тех кто не проверил ссылку, там это продублировано, что бы не было недоразумений о колебаниях борта.
“Небольшое видео (4 минуты), демонстрирующее типовой цикл полета, под управлением майской сборки (201105) алгоритма. Начальные колебания на старте происходят из-за отсутствия модуля IMU, вместо него стоит блокировка принудительно заставляющая борт использовать данные GPS. Из-за разброса координат, он не сразу понимает направление своего движения, от чего и происходит рывок в сторону. Руление после посадки осуществляется дифференциальным торможением стоек шасси, что тоже не до конца отработано в этой версии, из-за отсутствия корректной имитации работы шасси в симуляторе.”
Это неважно.
Сферический борт в вакууме. Понятно.
Сферический борт был, да, когда отлаживались элементы верхнего уровня. Уже давным давно его заменил чуть менее сферический flygear, который вы безусловно(?) видели на видео. Вместо него вы можете подставить любой борт, корректно описать его (если любопытно, могу дать описание требуемых констант для борта, но врятли вам интересно) и отправить в полет не меняя алгоритмов.
Но, быть может, вы перестанете обсуждать возможности (или невозможности) создания того что уже создано и работает, и перейдете к моим вопросам? 😃
Тобишь вы создаёте Гомункулиса, отодвигая пилота взад?
Нажал на капу и пепелац сам летает и садится.
Весело и заманчиво, а наработки квадракоптеров чем плохи, там тоже работает программа и ОНО само летает.
Конечно интересно, но кажется это “Тепловые импеллеры часть 2”.
Вот оно! Или опять не то. Итеративность…
Нажал на капу и пепелац сам летает и садится.
М. Жванецкий ещё лет 25 назад подметил:“Половина из нас- ходит с вопросами, другая половина-с ответами…”
Всего и делов то-замкнуть накоротко и вот оно, Щастье 😃
Тут всё дело- в итеративности 😍
Владимир, я правильно понял, что Вы не используете ПИДы в чистом виде для регулирования? Что-то в голове маячит, но сообразить не могу.
Для примера рассмотрим вывод в горизонт после выполнения бочки.
ПИД-регулятор всегда принимает решение об остановке, когда “нулевая” точка уже пройдена, т.о. колебания неизбежны, пусть треть периода. Человек-пилот может давить, преположим, крен до последнего, а потом резким “качком” руля в обратную сторону остановить вращение без перехода “нуля”.
При этом оценивается момент движения, и в итоге остается всего один динамический коэффициент, который подстраивается “автоматом” после оценки выполнения маневра. И никаких ПИДов.
У Вас такой подход?
В общем идея понятная и правильная. Сам когда-то задавал вопрос “Доколе ронять самолеты будем по ошибке пилота?”
Единственно было б логичней рулежку до взлета вынести отдельно с прогревами моторов, ибо взлета может не быть.
И из посадки нужно убрать разрешение на посадку. Это часть полета. Ибо пока не разрешили - тупо летаем и пока не возбуждаемся… посадки может не быть если нет разрешения, если долго нет - то запасной алгоритм - это уже ЧП.
Ну то есть после команды взлет - любое отклонение от алгоритма ведет к возникновению ЧП и отказу от полета.
И после начала посадки любое отклонение ведет к запасному алгоритму.
Сама же реализация действительно не зависит от самолета (любого летательно аппарата), просто детали меняются а суть одна. Это позволит зная суть (вбив ее в умы пилотов всего что летает) получать пилотов. Как это делается в автошколах.
Думаю, что общее обсуждение будет не очень понятным не программистам. Ибо… Ибо.
Еще в каждом шаге алгоритма должно быть ответвление на ошибки, и тут вопрос в ответвлении на ошибку должно быть еще ответвление или как? Например, на рулежке на двухмоторнике, второй мотор стал газовать, по ошибке - глушим моторы - они не глушатся-сломалась глушилка… Это очень образно, но тем не менее, отказоустойчивость алгоритма- самое важное с чем придется столкнуться. Самик четко должен знать что делать. Без этих ответвлений получим то же самое что счас и имеется…
после команды взлет - любое отклонение от алгоритма ведет к возникновению ЧП и отказу от полета.
В РЛЭ обычно расписано много вариантов “отказа от полета” при отказе оборудования. Поэтому стоит уточнять, какой именно отказ и что при этом делать.
К примеру, возьмем отказ единственного двигателя.
Вот варианты:
- при высоте менее 100м и скорости Х осуществить посадку прямо по курсу на возможно ровный участок
- при высоте более Х и расстоянии до выхода в коридор менее Y выполнить плавный разворот и осуществить посадку на полосу
… - при высоте 10 м и наличии штопора убить себя апстену
Ну собственно да. Сложность алгоритма как раз в отказах, а такой вот ровненький алгоритм для полета, в принципе, бесполезен. А отказы сильно зависят от борта и погоды… Но пробовать все равно придется… На авто все же ездим… плохо … убиваемся но ездим… В будущем будем летать, я надеюсь, так что алгоритмы такие все -таки нужны. 😃
Единственно было б логичней рулежку до взлета вынести отдельно с прогревами моторов, ибо взлета может не быть.
Да, конечно, просто для ранней версии точка начала работы - в начале ВПП. После первой успешной аппаратной реализации, уже можно будет думать о рулежке. Пока алгоритм проверяет двигатель перед взлетом.
И из посадки нужно убрать разрешение на посадку. Это часть полета. Ибо пока не разрешили - тупо летаем и пока не возбуждаемся… посадки может не быть если нет разрешения, если долго нет - то запасной алгоритм - это уже ЧП.
По умолчанию борт сразу идет на посадку согласно плану полета. Диспетчер может вмешаться и запретить посадку. Для обеспечения захода против ветра нужно знание ветров, которое по хорошему вместе с METAR борт должен получить в какойто момент времени до выбора ВПП с какой стороны вообще ему садится. Имеется в виду что диспетчер должен передать его на борт, или борт будет использовать то видение ветров которе у него сложилось на протяжении последнего получаса полета, что не всегда может быть верно, как показали тестовые полеты на симуляторе. Ошибка может достигать 60 градусов а обычно составляет около 30-40 градусов. А если полет протикает в горной местности или в условиях знакопеременной турбулентности, то там скорее всего вообще будет ирунда а не реальный ветер.
Ну то есть после команды взлет - любое отклонение от алгоритма ведет к возникновению ЧП и отказу от полета.
И после начала посадки любое отклонение ведет к запасному алгоритму.
Да, разумеется. Алгоритм строился по ситуационной схеме. Каждая ситуация накладывает свои ограничения. Например, садимся, снос ветрами слишком сильный, в полосу не вписываемся, откат на второй круг, но! отказывает двигатель, это накладывает требование на немедленное выполнение посадки. Борт пытается ее осуществить если не получает указание “уходить от ародрома любой ценой в указанную точку” (например, грузовым беспилотником можно пожертвовать) а дальше уже насколько высоты ему хватит… В любом случае, борт будет сохранять управляемость по критерию воздушной сокрости до последнего, и лишь перед аварийной посадкой попробует выровняться.
Сама же реализация действительно не зависит от самолета (любого летательно аппарата), просто детали меняются а суть одна. Это позволит зная суть (вбив ее в умы пилотов всего что летает) получать пилотов. Как это делается в автошколах.
Именно!
Еще в каждом шаге алгоритма должно быть ответвление на ошибки, и тут вопрос в ответвлении на ошибку должно быть еще ответвление или как? Например, на рулежке на двухмоторнике, второй мотор стал газовать, по ошибке - глушим моторы - они не глушатся-сломалась глушилка…
Потенциальные отказы прописываются в алгоритме жетско довольно таки (пока, там посмотрим), их количество довольно ограниченно по сути. (Кстати, Т-0 пока работает только с одномоторной конфигурацией, многомоторность будет уже много позднее)
Т.е. описанные проблемы можно описать так
“двигатель не развивает заданной мощности” (наш случай)
“двигатель полностью отказал”
Если дело на земле, останов, полные тормоза.
Если дело на разбеге, то зависит от того успеем или не успеем затормозить.
Если в воздухе, то прокладывается маршрут полета к ближайшей ВПП.
Это очень образно, но тем не менее, отказоустойчивость алгоритма- самое важное с чем придется столкнуться. Самик четко должен знать что делать. Без этих ответвлений получим то же самое что счас и имеется…
да, именно. Но это отдельная большая таблица ситуаций. Пока ее не рассматриваем, но она есть. Все сразу проектировалось с учетом ненормального развития событий.
Владимир, я правильно понял, что Вы не используете ПИДы в чистом виде для регулирования? Что-то в голове маячит, но сообразить не могу.
Для примера рассмотрим вывод в горизонт после выполнения бочки.
ПИД-регулятор всегда принимает решение об остановке, когда “нулевая” точка уже пройдена, т.о. колебания неизбежны, пусть треть периода. Человек-пилот может давить, преположим, крен до последнего, а потом резким “качком” руля в обратную сторону остановить вращение без перехода “нуля”.
При этом оценивается момент движения, и в итоге остается всего один динамический коэффициент, который подстраивается “автоматом” после оценки выполнения маневра. И никаких ПИДов.
У Вас такой подход?
Гм, я пока не готов говорить чем заменены ПИДы и как именно алгоритм работает с динамикой высокоинерционного тела, это изюминка и ноу-хау в данном случае.
Но в Вашем случае описан тот же ПИД, пилот “знает” насколько ему надо “дать крена” что бы точно встать в ноль, это компонента "П"пропорциональная с учетом текущего вращения борта, "И"нтегральной компоненты…
чем заменены
Мне важно было знать, что они заменены, а чем именно - не очень 😃
- при высоте 10 м и наличии штопора убить себя апстену
До штопора не доведем, а просто выровняем немедленно борт что бы брюшком плюхнуться. Т.к. такая высота отказа говорит о том что мы у ВПП 😃
Мне важно было знать, что они заменены,
Насколько я понял - алгоритм тот же что и у пилота RC.
Голова и руки запоминают в тренировках при какой воздушной скорости на сколько и в течении какого времени нужно махнуть управляющей плоскостью чтоб получить нужную коррекци ю положения.
Мне важно было знать, что они заменены, а чем именно - не очень 😃
Да, они заменены. С самого начала разработки был глубокий поиск алгоритма который будет не менее эффективным чем хороший ПИД, но при этом будет работать на низкой частоте, и не требовать предварительной адаптации, делать все в процессе полета, при этом не вызывая опасных ситуаций. Реально полтора года проб и ошибок, прежде чем стало ясно куда копать… Ну вот и выкопали вроде. 😃
Частота алгоритма обеспечивающая вменяемый полет 5 герц… Стабильного 10 Гц… (это не 50…120 как у обычных ПИД цепочек… но тут конечно много чего зависит от инерционности борта)
Частота алгоритма обеспечивающая вменяемый полет 5 герц… Стабильного 10 Гц…
У пилота - не большая.
Насколько я понял - алгоритм тот же что и у пилота RC.
Голова и руки запоминают в тренировках при какой воздушной скорости на сколько и в течении какого времени нужно махнуть управляющей плоскостью чтоб получить нужную коррекци ю положения.
Собственно с этого и начался поиск. Первый алгоритм 2005 года, был по сути специализированной экспертной системой постоянно набиравшей статистику по поведению борта в зависимости от внешних возмущений и приложенных управляющих моментов. Способ хороший. Замечательный! Работает как раз для упоминавшихся выше сферических коней, но чем более тяжелый и инерционный борт управляется им, тем выше, пардон, едет крыша у системы. Тк ей надо учитывать неизвестную ей инерцию в понимании поведения борта. 😃 А все чему надо учить на земле, не годится по начальным условиям задачи “универсального алгоритма”.
У пилота - не большая.
Именно! Нам не нужна большая частота для решения задач управления, значит, можно сделать такой же алгоритм которому тоже не нужна будет большая частота. Это тоже стало одним из “условий ТЗ”.
Тобишь вы создаёте Гомункулиса, отодвигая пилота взад?
Нажал на капу и пепелац сам летает и садится.
я его вообще исключаю. И в теории, мы говорим конечно не о пассажирских перевозках, а о грузовых. Тяжелый БПЛА должен обеспечивать весь цикл полета сам, самостоятельно разруливая все проблемы которые возникнут в полете. Да, звучит амбициозно, но на данном этапе речь идет даже не о принципиальной возможности создании подобного алгоритма управления (к счастью, он уже создан “в черновике”), а скорее о том что бы теперь медленно и верно приводить его (алгоритм) в реально летающий вид. До того как модель-прототип поднимется в воздух еще ой как много лет. (учитывая скорость работ, пара лет точно) т.к. естественно это не финансируется и не поддерживается никем, и в данном случае все работы ведуться по остаточному принципу времени. Но как ни странно все же идут, потому как задача нетривальная и интересная. Собственно до того как борт выполнил полет на симуляторе в феврале, еще были сомнения “можно-нельзя, справимся-несправимся”, сейчас сомнений нет. (а) - справимся, (б) - можно. Теперь идет кропотливая доводка. Большо количество узких мест, неправильного поведения в ситуациях и просто ошибок математики и логики. И это только на мат-модели, что уж будет всплывать когда будут полеты в железе страшно подумать 😃 Но опять таки, задача интересная, решаемая, хотя и не быстро 😃
Тяжелый БПЛА должен обеспечивать весь цикл полета сам, самостоятельно разруливая все проблемы которые возникнут в полете. Да, звучит амбициозно,
Вы, прежде чем амбции то выращивать-глянули лучше, что уже летает?
Если на МАКС приедете, то сможете увидеть там Иркут-200: отлично летающий БПЛА который, тем не менее- взлетает и садится “вручную”.
Делали его профессионалы, которые намеренно отказались от автовзлёта/посадки, поскольку эти понты только усложняют эксплуатацию и снижают надёжность.
Не согласен с Blade. Именно взлет и посадку нужно отдавать роботам. По алгоритму, как программист хочу посоветовать, полностью “нормализовывать” алгоритм. Алгоритм должен не содержать элементов разного уровня “высоты”.
Например:
1.Проверка
2.Рулежка
3.Взлет
4.Полет
5.Посадка
6.Парковка
И между ними не может быть других более “низких” уровней.
3.1 Выпускаем механизацию
3.2 Добавляем газ
3.2 Убираем тормоз
… То есть в этом уровне не должно быть уровня “ниже” и “выше”, то есть на каждом уровне решаем задачу из одного логического уровня не смешивая борщ и мух.
По инерционности - тут можно всегда высчитывать на каждом этапе и коректировать “СКОРОСТЬ ОТВЕТА” самолета на каждое действие (отдельно для правых и левых и верха и низа для учета ветра и пр.) и получить таблицу исходя из которой уже и “давать рулей”, которые будут уменьшать расходы при подходе к нужному курсу и исключат раскачку и “промазывание” или даже смогут парировать это. Ну в общем то о чем писал Syberian.
По алгоритму, как программист хочу посоветовать
По количеству виденных дров и морковок, как моделист и разработчик , могу возразить: если взлёт/посадка происходит на бетонке 6кмХ2 (как в ЛИИ им Громова),предварительно прометённой- то почти никаких проблем, ну кроме ветра 😃
Если же имеется в виду эксплуатация БПЛА в реальном мире, с кочками, ямками порывами ветра и прочими колдобинами, то АП, какой бы умнейший алгоритм в нем не был заложен, не поймёт что делать😢
Если вдруг под колесо попала ветка, шишка или другая помеха: он что сделает- полный газ и ручку на себя?
А если самолёт после помехи изобразил “прогрессирующего козла” и- глядит носом в землю?
Человек (даже летящий “по камере”)- совершенно не озадачится и поправит ситуацию автоматически 😃
Все рассуждения автора топика- не более, чем мнение “боксёра-заочника” выигрывающего бои “по переписке”. Но на настоящем ринге- бьют по морде 😦
Думаю речь все же идет о нормальной полосе. Ибо ездить по бездорожью в автоцентрах тоже сразу не учат. Для этого есть другие машины и другие люди.
Сейчас задача заставить безаварийно летать тяжелую модель. Кстати, Serafimus, есть уже аппаратуры со связью с компом, то есть комп может рулить реальной моделью. Если Ваш алгоритм сразу же адаптировать для такой апы, то и скептицизма поубавится. Пеносамоль с приличным размахом (типа электропланер) - самое то.
Пеносамоль с приличным размахом (типа электропланер)
Так, для “пеносамоля” и изобретать ничего не надо: полно готовых АП в продаже 😃
В том числе- и с открытыми кодами.
Да и отрабатывать автопилот для “тяжелого БПЛА” на пенолёте- всё равно, что движок для Ф1- обкатывать на Запорожце 😂