Как вы считаете, что будет с программированием в недалеком-далеком будущем?
в идеале я бы хотел программировать машину тьюринга))).
не дай Бог! )))))
Конечно, чем более просты и компактны примитивы языка, тем проще он для понимания, но из этого совершенно не следует, что каждый простой язык удобен для программирования. В идеальном случае специализированный язык для какого-либо класса задач должен оперировать терминами самого этого класса задач и операциями над данными, характерными именно для этого класса. Но я уже писал выше, что создание таких языков с компактными, но мощными примитивами, является нетривиальной задачей и, вообще, сродни искусству. Язык машины Тьюринга безусловно к таким языкам не относится ))
Представьте, сколько операций такой машины, умеющей только двигать ленту взад и вперед проставляя на ней символы, Вам потребуется чтобы выполнить хотя бы элементарную программу сложения двух чисел!
Так что, машина Тьюринга - всего лишь абстракция автомата, не имеющего к практической жизни никакого отношения.
Кстати, вы не заметили тенденцию писать рекламные проспекты на хардверные и софтверные инструменты разработки как будто это конструкторы адресованные детям: “Дорогой друг, в этой коробке ты найдешь все что тебе надо чтобы построить…”
нет, не заметил.
Красота!!😈
не дай Бог! )))))
+1 . Из того что для построения любой логической схемы достаточно единственного элемента “Штрих шеффера” (2И-НЕ ) или “стрелка Пирса” (2ИЛИ-НЕ) совершенно не следует что используя его и только его удобно строить цифровые логические схемы. Скорее даже наоборот - триггеров, сумматоров и т.д. они не отменили. С програмированием аналогчно.
Красота!!
По существу практически так и есть уже сечас при програмировании FPGA. Кубики готовые библиотечные модули реализации того или иного протокола или модуля. Мало кто будет в сотый раз сам выдумывать реализацию сумматора или буфера. для этого нужны очень и очень веские основания. В програмировании аналогично.
…Мало кто будет в сотый раз сам выдумывать реализацию сумматора или буфера. для этого нужны очень и очень веские основания. В програмировании аналогично.
Вот именно в программировании бывает обратная тенденция. Сестра оверинженеринга и перфекционизма: когда программист делает что-то только потому, что он может это сделать, даже если для этого он подглядывает в код готовой, но написанной не им библиотеки 😈
за свою жизнь я создал несколько специализированных языков и написал компиляторы/интерпретаторы к ним.
Из каких областей ? (если не секрет)
А как бы мог выглядеть язык для описания пилотажного комплекса?
Т.е. на какие элементы-кубики порезать например кубинскую восьмерку или разворот на горке?
(Реализация - видимо так: форт-байткод с наземки заливается в автопилот на avr(ardupilot) или arm(cortex-m3,4).
Ограничена память, интерпретатор и скрипт не должны обмолачивать память)
Из каких областей ? (если не секрет)
в основном для работ с большими БД (примитивы работы с БД были имплементированы прямо в язык), для потоковой обработки текстовых данных, включая компилятор компиляторов, макропроцессоры и кое-какие препроцессорные расширения + библиотеки функций для игр (MSX). Это было очень давно (в эпоху ЕС ЭВМ) и сейчас практически потеряло актуальность.
Кроме мастерства, конечно, которое не пропьёшь ))
А как бы мог выглядеть язык для описания пилотажного комплекса?
Первое, что приходит в голову - в качестве примитивов языка использовать каталог Арести, но на мой взгляд он “грубоват” т.е. недостаточно детален с точки зрения исполнения элементов отдельных фигур. Нужны какие-то более мелкие примитивы + возможность рил-тайм управления ими для опционального подключения “автопилотных” и стабилизирующих средств. Причем, языки управления БПЛА тут не пригодятся, т.к. они рассчитаны не на пилотаж, а на выполнение прикладной задачи в целом.
Мне кажется, что детализация должна быть на уровне 1/8 или даже 1/16 бочки, петли и каких-то еще самых примитивных ЧАСТЕЙ (!!!) фигур. Кстати, провести исследование всех фигур ВП и 3Д и выявить минимальный набор таких примитивов - ОЧЕНЬ достойная задача! Мне кажется, что таких примитивов окажется не так уж и много. Не более 1-2 десятков, включая переходные связки. А потом уже, как следующий “над-уровень” из них можно строить сам Арести и иже с ним фигуры для 3Д.
добавлено: хорошая тема для диссера, кстати )))
Ограничена память, интерпретатор и скрипт не должны обмолачивать память
мне кажется, что это излишние ограничения. Даже для 30-50 размеров (размах 1.20-1.50) лишние 100 г мощного проца с хорошей памятью и контроллерами погоды не сделают. А что уже говорить о размахах от 2.20…
Не надо забывать также и о том, что интерпретатор вряд ли сможет обеспечить приемлемый рил-тайм для стабилизации и автопилота. Нужна какая-нибудь вполне стандартная начинка с элементной базой экономичного, но вполне производительного нетбука.
еще добавлено: также будет забавно рассмотреть процесс настройки/привязки такого типового пилотажного софта к конкретным моделям. Что-то вроде процесса “обучения” софта в руках опытного пилота на целевой модели. Еще одна тема для диссера ))
и напоследок: на земле закладываем в ноут музончик с таймкодом и синхрометками, синхрометки передаем в эфир, бортовым приемником ловим их и синхронизируем выполнение пилотажной программы с музыкой )))
Первое, что приходит в голову - в качестве примитивов языка использовать каталог Арести,
Спасибо. Читаю.
добавлено: хорошая тема для диссера, кстати )))
Присоединяйтесь, тема была тут 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нокод, причесанный и структурированный ровно до того уровня, чтобы самому в нем не утонуть до сдачи проекта, но не более.
Добавлено: Вы полагаетесь на абстрактный чужой автопилот, который…
Таки не на чужой, а на отдельный. В моем варианте решения - он отделен от способов и средств описания траектории.
А как лететь между точками? Три точки под прямым углом - это что, два отрезка или дуга окружности? Интерполировать надо не абы-как, а так как у…
Не вижу никакой проблемы. Абсолютно. Во-первых - в точках можно задавать тип интерполяции. Во вторых - можно не задавать, пусть везде будет автоматически кривая второго порядка (хоть Безье, хоть билинейный сплайн или как его там) или линейная интерполяция. В обоих последних случаях для уточнения траектории - ставим просто больше точек. В случае кривой второго порядка - три точки образуют кусок, похожий на кусок окружности.
Если надо прямой угол - в районе самого угла ставим точки очень плотно. Математически-прямой угол конечно не нарисовать, но это не проблема: модель все равно не способна математически точно под прямым углом резко повернуть, какой-то минимальный радиус там будет в любом случае.
почему только элеронное? Водпад крутят РВ, сваливание от РН используется как минимум при штопоре…
Да, действительно на дуги плохо раскладывается. (проблемма в параметрах, контролируемых на борту)
Получается надо задавать траекторию оси вращения, которая не обязательно проходит через ЦТ.
Во-первых - в точках можно задавать тип интерполяции.
Вот и получился обсуждаемый язык.
в современном мире - за то, что программисты вечно норовят максимально обобщить задачу и от частностей перейти к решению общностей с наприсаниями фрэймворков, движков и собственных скриптов - их нещадно бьют и гонят с работы
“В современном мире”…
Я говорил выше, что долго сам долго руководил коллективом и системных, и прикладных программистов целого института.
В числе прочих дел я ускорял сроки реализации задач, успешно разрабатывая и создавая для них целевые языки и др. средства разработки. Поверьте, я это умею делать хорошо.
Вы решили меня поучить как надо работать?
Так имейте в виду, что мне плевать на “говнокод”, который от вас кто-то требует и на того, кто его от вас требует. Я сам лично говнокод никогда не писал и другим не давал. И впредь писать не буду.
Не зарывайтесь, Саша - не учите более опытных, чем Вы, людей.