Как вы считаете, что будет с программированием в недалеком-далеком будущем?
Первое, что приходит в голову - в качестве примитивов языка использовать каталог Арести,
Спасибо. Читаю.
добавлено: хорошая тема для диссера, кстати )))
Присоединяйтесь, тема была тут rcopen.com/forum/f90/topic273212, дисер Ваш (или Вашего сына). 😃
мне кажется, что это излишние ограничения.
Ограничение связано с продающимся железом, хотелось бы начать с простого, доступного немедленно.
также будет забавно рассмотреть процесс настройки/привязки такого типового пилотажного софта к конкретным моделям.
Это для наземного компа - проверка и перевод рисунка в байткод, допустимый для модели. Кажется, что решаемо, если есть сим и описание модели.
Байткод двигает уставки пид-регуляторов по 4-м каналам (в зависимости от времени,ориентации,скорости и т.д.) - это “как-бы ассемблер”.
на земле закладываем в ноут музончик с таймкодом и синхрометками,
А если соотнести характер мелодии и фигуры, то можно не рисовать, микрофон на борту - получится авто-танцор 😃
Присоединяйтесь, тема была тут FCL (Flight Contol Language) - пользовательский язык для управления автопилотом, дисер Ваш (или Вашего сына).
Спасибо, но присоединяться не буду т.к.:
- тема заглохла более года назад
- речь там идёт о языке для управления БПЛА, а не о пилотаже
- начинать такую разработку надо с семантики языка, а не с синтаксиса. Иначе получится монстр, что мы и видим, кстати.
- мне не нравится концепция бортового вычислителя на микроконтроллере
Это для наземного компа - проверка и перевод рисунка в байткод, допустимый для модели. Кажется, что решаемо, если есть сим и описание модели.
Байткод двигает уставки пид-регуляторов по 4-м каналам (в зависимости от времени,ориентации,скорости и т.д.) - это “как-бы ассемблер”.
я, вообще-то, имел в виду совершенно иное. А именно рил-тайм “обучение” программы фигурам, выполняемым живым пилотом на целевой модели.
Что же касается отладок, проверок и тестирования, то, конечно, без симулятора тут не обойтись. Причем, сим сгодится любой из хороших - AFPD, AF5, RF. Надо только соорудить простой, но не менее, чем 5-ти канальный генератор РРМ, управляемый, например, через USB. Сигнал с этого генератора надо заводить на вход сима как с обычного аналогового пульта. Вот тут какому-нибудь микроконтроллеру, кстати, самое место ))
А если соотнести характер мелодии и фигуры, то можно не рисовать, микрофон на борту - получится авто-танцор
получится “цветомузыка” - полная фигня не имеющая к искусству никакого отношения ))
А зачем для управления БПЛА или траекторией аппарата - язык? Достаточно просто жестко заданного вектора. Каждая точка - помимо пространственных координат, также содержит целевые показатели линейной скорости и угловых скоростей, а автоматика как может отрабатывает, чтобы аппарат максимально точно попадал в текущую точку.
Язык (программирования) - предполагает наличие условий и переходов, для описания траектории полета условия и переходы не нужны, да и не очень ясна цель? Анально-огородить (от кого?! разработчик не сделает плохого своему аппарату, а никто другой в коде колупаться не должен) код управления аппаратом - от остального кода автопилота и вообще бортового мозга? Так на практике будут постоянно вылезать исключение, которые будут требовать расширения функционала этого языка-скрипта. Проще сделать нечто типа фреймворка (по сути просто грамотное структурирование всего ПО, паттерны проектирования в помощь) - и тогда блок управления аппаратом на уровне плана полета или пилотажного комплекса - и так и сяк будет обособленным, но в тоже время будет использовать всю мощь того давно существующего языка, на котором сделан весь проект.
ИМХО, разные новые языки и скрипты актуальны лишь тогда, когда надо допускать к работе с железом фиг пойми кого с фиг пойми каким уровнем знаний и фиг пойми какими умыслами, и чтобы они ни в коем случае не могли ничего сломать - ни случайно, ни специально. Если же с системой работают только профессионалы - в топку скрипты.
для описания траектории полета условия и переходы не нужны, да и не очень ясна цель?
я говорил не столько о траектории полёта, сколько об описании выполнения фигур, в частности, 3Д. В этом случае “расколбас” может происходить практически в одной точке без перемещения по траектории.
Кроме того, при составлении, например, музыкальных шоу может понадобиться реально разное программирование и траекторий, и положений летательного аппарата применительно к точкам траектории. Особенно на предельно малых скоростях при “силовом” пилотаже.
Конечно, для описания траектории с названиями/обозначениями фигур в отдельных точках никакие условия и циклы не нужны, но для выполнения самих фигур при разных внешних условиях (погоде, например) и учете значений датчиков положения - они еще как понадобятся!
да, и еще: наверное, условия и циклы могут также понадобиться при воздушном бое для выполнения маневров атаки и уклонения ))
…не столько о траектории полёта, сколько об описании выполнения фигур, в частности, 3Д. В этом случае “расколбас” может происходить практически в одной точке без перемещения по траектории.
Так и в чем проблема? 😃 Пространственные координаты - не меняются, а меняются только целевые значения углов ориентации аппарата в пространстве.
Для пущего удобства в каждой точке добавить еще значение временного интервала, чтобы управлять плотностью точек при описании траектории. на прямых участках без маневрирования - две точки, в начале и в конце. В сложных фигурах - точки можно через каждые 10 мс поставить.
Кроме того, при составлении, например, музыкальных шоу может понадобиться реально разное программирование и траекторий, и положений летательного аппарата применительно к точкам траектории. Особенно на преде…
Это вопрос обработки и подготовки данных, а не формата записи.
…условия и циклы не нужны, но для выполнения самих фигур при разных внешних условиях (погоде, например) и учете значений датчиков положения - они еще как пона…
Учитывать погодные условия и прочие мешающие факторы - автопилот должен автоматически! Траектория для него - как точки маршрута для водителя. Ехать между точками и попадать в них - задача водителя, а не того, кто маршрут на бумажечке рисовал 😒
да, и еще: наверное, условия и циклы могут также понадобиться при воздушном бое для выполнения маневров атаки и у…
Чего уж там, надо сразу включить в скрипт библиотечку “искусственный интеллект” и функцию “нагнуть всех” 😃 Вызвал эту функцию в середине полета - бой выигран!
Пространственные координаты - не меняются, а меняются только целевые значения углов ориентации аппарата в пространстве.
ну, напишем мы “значения углов ориентации”, а как описать “что делать” для установки модели в эти значения? Причём, с учётом её предыдущего/текущего положения и скорости!
Короче, о разных вещах мы говорим.
Да и вообще, автопилоты никогда не занимались и не занимаются пилотажными фигурами. Их цель - траекторию и время обеспечить, а углы ориентации аппарата а пространстве и скорость - это средства достижения этой цели, а не сама цель.
ну, напишем мы “значения углов ориентации”, а как описать “что делать” для установки модели в эти значения? Причём, с учётом её предыдущего/текущего положения и скорости!
Короче, о разных вещах мы говорим.
Таки нет, как раз об одних вещах говорим 😉 Как именно выйти на нужные координаты (координаты - в самом широком смысле слова, а не только пространственные x,y,z) - т.е. соединить две точки некой плавной кривой - задача лет 50 назад еще решена. Всяческих интерполяционных полиномов - с десяток на выбор, выбирай любой!
Задача же “запихивания” нашего объекта управления в пределы этих параметров - задача из теории автоматического управления. Чуточку более сложная, чем ПИД-регулирование, но также не нова. Естественно будут определенные допуски точности попадания в требуемые параметры, ограничения на возможность или невозможность попасть в те или иные параметры (связанные с инертностью системы и другими мешающими факторами) - но в целом - это во-первых не нанотехнология, во вторых - не имеет отношения к способу задания самой траектории.
Да и вообще, автопилоты никогда не занимались и не занимаются пилотажными фигурами. Их цель - траекторию и время обеспечить, а …
Вот тут вообще в корне не согласен!
Как раз решаемые в настоящий момент задачи автопилотов - именно того-же самого типа, что задача полета по траектории пилотажного комплекса. С той лишь разницей, что в обычном маршрутном полете - точки расставлены с большими интервалами, отсутствуют требования по ориентации аппарата в контрольных точках (и то не всегда - точка типа “ворота” пролетается в определенном направлении, да и при заходе на полосу - углы очень даже конкретные), более широкие допуски по точности попадания в траекторию.
Задача автоматического полета по пилотажной траектории - таже самая, только точки стоят плотнее и требования к проворности и точности автопилота - более высокие. Но принципиальной (подчеркиваю!) разницы - нет.
т.е. для силовой бочки и РХ (в т.ч. вписанного в другие фигуры) циклы и условия тоже не нужны? ))
Если Вы действительно так считаете, то я участие в этом споре прекращаю ))
т.е. для силовой бочки и РХ (в т.ч. вписанного в другие фигуры) циклы и условия тоже не нужны? ))
Если Вы действительно так считаете, то я участие в этом споре прекращаю ))
Вы же умный человек, ну как вы не можете понять?
Траектория - это описание НЕ алгоритма, это описание конечного результата. Она говорит: в такой-то момент времени аппарат должен быть тут, повернут должен быть так, иметь такую-то скорость. Если несколько точек подряд говорят, что самолет висит вертикально мордой вверх - значит автопилот САМ интенсивно дрыгает рулями, газует двигателем, мигает навигационными огнями и пускает из ж*пы дым - так, чтобы аппарат с незначительными допусками соответствовал уставке.
Реальный пилотажный комплекс, который летят живые спортсмены - тоже, замечу, не дает никаких указаний, как двигать ручками, не содержит в себе циклов и переходов. Сказано - прямая петля с вписанными бочками - попадай в эту траекторию как хочешь!
А циклы, переходы, передаточные функции разной сложности - это внутренности самого автопилота, но никак не способа описания траектории.
Ну неужели так сложно понять?.. 😉
а я думал, что Вы давно уже поняли, что язык, о котором я говорю, включает в себя функции автопилота.
Я не рассматриваю автопилот как отдельную программу в отличие от подхода, который использовался по приведенной выше ссылке заглохшей год назад темы. Поэтому и примитивы этого языка должны быть не только координатами и положениями, а действиями с оценкой значений датчиков.
И когда я в самом начале говорил о таких примитивах, как 1/16 бочки, петли и пр, я тоже говорил о действиях, а не о координатах и скоростях.
Надеюсь, теперь понятно?
Добавлено: Вы полагаетесь на абстрактный чужой автопилот, который то ли что-то может, то ли нет. Я же говорю о средствах для создания собственного автопилота, ориентированного на пилотаж, а не на траекторию. Т.е. на описании фигур на языке его собственных примитивов.
каталог Арести
Почитал, вполне подходящая система. Если поделить фигуры из каталога на более мелкие кубики - получаются такие элементы:
- прямая с параметрами азимут,возвышение,длинна
- дуга окружности с параметрами центр,радиус,плоскость и длинна дуги
Они сопрягаются по касательной.
Для возможности “внешней синхронизации” надо к каждому элементу еще добавить параметр: скорость или время прохождения.
На каждый элемент может быть наложено элеронное вращение с параметрами угол и угловая скорость. (напр. петля с бочкой наверху = дуга+(дуга с бочкой)+дуга)
Еще бы надо для блока(набора) элементов добавить общий масштаб (по размеру и скорости) и поворот по азимуту.
Что-то из каталога Арести не сложится из таких элементов?
я, вообще-то, имел в виду совершенно иное. А именно рил-тайм “обучение” программы фигурам, выполняемым живым пилотом на целевой модели.
А решаема ли эта задача?
Примерно представляю как по логам многих полетов посчитать параметры модели - это очень большой объем данных и маш.времени.
Совершенно не представляю, что можно поменять, чтобы влезло в реалтайм. (соотв. не понимаю смысла мощного компа на борту)
при воздушном бое для выполнения маневров атаки и уклонения ))
модельные “глаза” - сложная штука.
Причем, сим сгодится любой из хороших - AFPD, AF5, RF.
Сим должен отдавать на сторону координаты,ориентацию и скорости(обычную и угловую). Желательно по сети.
А зачем для управления БПЛА или траекторией аппарата - язык? Достаточно просто жестко заданного вектора. Каждая точка -
А как лететь между точками? Три точки под прямым углом - это что, два отрезка или дуга окружности? Интерполировать надо не абы-как, а так как указано в правилах.
Аналогия - растровые и векторные рисунки. Векторные описываются языками (postscript в pdf-ах, svg, …)
Совершенно не представляю, что можно поменять, чтобы влезло в реалтайм. (соотв. не понимаю смысла мощного компа на борту)
я предполагал менять весовые коэффициенты отклонения рулей/газа и скорости их изменения. Т.е. обучение должно свестись просто к изменению чисел в таблицах пересчёта.
модельные “глаза” - сложная штука.
это точно. Но реально об этом пока речь не идёт. Скорее, это смешной аргумент, которым можно заинтересовать военных ))
Сим должен отдавать на сторону координаты,ориентацию и скорости(обычную и угловую). Желательно по сети.
Вы правы. Об этом я как-то забыл.
Что-то из каталога Арести не сложится из таких элементов?
по-моему, Арести совершенно не учитывает 3Д. Хотя, последние редакции я не смотрел (уже лет 5 как)
На каждый элемент может быть наложено элеронное вращение с параметрами угол и угловая скорость
почему только элеронное? Водпад крутят РВ, сваливание от РН используется как минимум при штопоре…
а я думал, что Вы давно уже поняли, что язык, о котором я говорю, включает в себя функции автопи…
А, кажется понял.
Но не согласен 😃 Лучше - сделать декомпозицию задачи: вот - автопилот, вот - вектора полета (маршруты, если по старому) и редактор для этих самых маршрутов.
PS: в современном мире - за то, что программисты вечно норовят максимально обобщить задачу и от частностей перейти к решению общностей с наприсаниями фрэймворков, движков и собственных скриптов - их нещадно бьют и гонят с работы 😈 Потому, что это прямой способ срыва всех сроков, а повторно и-или в других проектах этот код будет использоваться с вероятностью менее 1%. Сейчас все чаще откровенно говорят: нужен го8нокод, причесанный и структурированный ровно до того уровня, чтобы самому в нем не утонуть до сдачи проекта, но не более.
Добавлено: Вы полагаетесь на абстрактный чужой автопилот, который…
Таки не на чужой, а на отдельный. В моем варианте решения - он отделен от способов и средств описания траектории.
А как лететь между точками? Три точки под прямым углом - это что, два отрезка или дуга окружности? Интерполировать надо не абы-как, а так как у…
Не вижу никакой проблемы. Абсолютно. Во-первых - в точках можно задавать тип интерполяции. Во вторых - можно не задавать, пусть везде будет автоматически кривая второго порядка (хоть Безье, хоть билинейный сплайн или как его там) или линейная интерполяция. В обоих последних случаях для уточнения траектории - ставим просто больше точек. В случае кривой второго порядка - три точки образуют кусок, похожий на кусок окружности.
Если надо прямой угол - в районе самого угла ставим точки очень плотно. Математически-прямой угол конечно не нарисовать, но это не проблема: модель все равно не способна математически точно под прямым углом резко повернуть, какой-то минимальный радиус там будет в любом случае.
почему только элеронное? Водпад крутят РВ, сваливание от РН используется как минимум при штопоре…
Да, действительно на дуги плохо раскладывается. (проблемма в параметрах, контролируемых на борту)
Получается надо задавать траекторию оси вращения, которая не обязательно проходит через ЦТ.
Во-первых - в точках можно задавать тип интерполяции.
Вот и получился обсуждаемый язык.
в современном мире - за то, что программисты вечно норовят максимально обобщить задачу и от частностей перейти к решению общностей с наприсаниями фрэймворков, движков и собственных скриптов - их нещадно бьют и гонят с работы
“В современном мире”…
Я говорил выше, что долго сам долго руководил коллективом и системных, и прикладных программистов целого института.
В числе прочих дел я ускорял сроки реализации задач, успешно разрабатывая и создавая для них целевые языки и др. средства разработки. Поверьте, я это умею делать хорошо.
Вы решили меня поучить как надо работать?
Так имейте в виду, что мне плевать на “говнокод”, который от вас кто-то требует и на того, кто его от вас требует. Я сам лично говнокод никогда не писал и другим не давал. И впредь писать не буду.
Не зарывайтесь, Саша - не учите более опытных, чем Вы, людей.
Вы решили меня поучить как надо работать?
Нет, ни в коем случае!
Однако, коллективов, контор и областей программирования - сейчас невообразимо много. Сейчас многие задачи требуют значительно более быстрого решения, чем, к примеру, даже 10 лет назад. При этом не надо забывать, что конечный пользователь никогда не увидит код программы изнутри, лишь бы не глючило и не тормозило.
Безусловно, это не повод писать - через задницу, но надо ощущать четкую (зыбкую 😃) границу между быстротой разработки (которая важна) и “правильностью” кода (которую никто, кроме тебя, не оценит).
Так имейте в виду, что мне плевать на “говнокод”, …Я сам лично говнокод никогда не писал и другим не…
Сейчас достоверно известно, что с точки зрения совершенства кода (грамотности структурирования проекта, оптимальности реализации функций) - предела совершенства нету. Реально нету. И если столкнуть лбами двух случайных программистов, то у одного из них - код будет го8нокодом по сравнению с кодом другого, и у обоих - код будет жалким подобием кода, написанного неким третьим программистом и т.д. Но при этом все эти программисты - способны решать поставленную задачу и делать это в срок, и З\П могут получать одинаковую, никак не зависящую от красивости их кода.
PS:
Вот интересное видео по теме. Человек в конкретных практических примерах рассказывает, в том числе о важности качества кода. Просто в качестве пояснения моей позиции.
“В современном мире”…
Я говорил выше, что долго сам долго руководил коллективом и системных, и прикладных программистов целого института.
В числе прочих дел я ускорял сроки реализации задач, успешно разрабатывая и создавая для них целевые языки и др. средства разработки. Поверьте, я это умею делать хорошо.Вы решили меня поучить как надо работать?
Так имейте в виду, что мне плевать на “говнокод”, который от вас кто-то требует и на того, кто его от вас требует. Я сам лично говнокод никогда не писал и другим не давал. И впредь писать не буду.
Не зарывайтесь, Саша - не учите более опытных, чем Вы, людей.
МыслЯ вслух - это как это руководитель и сисадминов и прикладников(назовём проще - CIO) может не дать его прикладникам писать говнокод? Будет за Ними сидеть и перепроверять? У CIO на это в сутках есть максимум 30%, а у них 100%. И их на порядок больше.
Итог - задача нерешаема.
МыслЯ вслух - это как это руководитель и сисадминов и прикладников(назовём проще - CIO) может не дать его прикладникам писать говнокод? Будет за Ними сидеть и перепроверять?
-
не “сисадминов”, а системных программистов. Вы знаете, чем системный программист отличается от прикладного? - Прикладник пишет для конечного пользователя, а системщик для других программистов. “Сисадмин” - это СОВСЕМ другая специальность ))
-
“перепроверять” код построчно и не требуется. Огрехи видны по уровню структурирования и документирования кода - это видно и при беглом просмотре. И, естественно, при тестировании.
Вдогонку. Ни в коем случае никого не хочу обидеть, но в среде программистов - не принято хвастаться в духе “как красиво я пишу код” 😒
Потому, что каким бы крутым и опытным вы себя не считали, всегда найдутся еще более опытные и крутые кодеры; а даже в самом причесанном коде, но в крупном проекте - легко находятся “черезжопные” конструкции, за которые можно покраснеть как рак, если это увидит кто-то другой…
Гораздо правильнее - принять как данность, что вы (не зависимо от опыта и заслуг) - не самый крутой программист (пока общественность не потребует вас предъявить свой крутой код 😈). И сконцентрировать внимание на работе, на достижениях конкретных поставленных целей 😃
если столкнуть лбами двух случайных программистов, то у одного из них - код будет го8нокодом по сравнению с кодом другого, и у обоих - код будет жалким подобием кода, написанного неким третьим программистом и т.д
Саша, не будем заниматься бесполезным теоретизированием на пустом месте. Я лично знаю как отличить хороший код от плохого. Принцип прост и давно известен - “кто ясно мыслит, тот ясно излагает”. Но я также знаю, как можно специально сделать обычный код практически нечитаемым, например, в целях защиты.
Так что, не надо огород городить в пустоте ))
… от плохого. Принцип прост и давно известен - “кто ясно мыслит, тот ясно излагает”.
На самом деле - это соответствие уровня кода - решаемой задаче. Но ни в коем случае не надо путать это - с идеальностью кода как самобытной (мифической и недостижимой) сущностью 😃
…можно специально сделать обычный код практически нечитаемым, например, в целях защиты…
Это называется обфускация, если вы вдруг не знали 😃
Как и многие другие методы “защиты”, помогает лишь условно. От китайских ре-инженеров ничего не спасает 😃
На самом деле - это соответствие уровня кода - решаемой задаче.
ничего подобного. Вы опять не поняли.
Мы на разных языках что ли говорим?
Человек может очень грамотно рассуждать и хорошо понимать, что он делает. Но при этом может банально изобретать велосипед - что в программировании распространено сплошь и рядом. Причем велосипед - не современный спортивный, а очень качественный, но трехколесный и детский 😃 Образно говоря.
Это распространено повсеместно, а уж в обособленных коллективах, да если вдруг они не сами на рынок свои проекты выводят, а принимают задания от заказчика - это аж мхом порастает, но никто этого не замечает.
Это называется обфускация, если вы вдруг не знали
ну почему ж не знал? Сам делал обфускаторы, которыми даже другие пользовались ))
В частности, для незабвенной платформы 1С был у меня обфускатор под названием “Кирпичный заводик”. Ставший, кстати, потом очень популярным в народе ))
Код такими кирпичами укладывал - хрен прочитаешь.
не “сисадминов”, а системных программистов. Вы знаете, чем системный программист отличается от прикладного? - Прикладник пишет для конечного пользователя, а системщик для других программистов. “Сисадмин” - это СОВСЕМ другая специальность ))
“перепроверять” код построчно и не требуется. Огрехи видны по уровню структурирования и документирования кода - это видно и при беглом просмотре. И, естественно, при тестировании.
Описание можно написать любое и тестирование выявит только результат работы, а не сам код.