Search in topic

FCL (Flight Contol Language) - пользовательский язык для управления автопилотом

(Предварительная концепция)

1. Процедурный, интерпретируемый в реальном времени язык пользователя.
2. Взаимодействует с основным алгоритмом АП (в первом варианте – smalltime) через общие переменные и вызовы подпрограмм.
3. В первом варианте – не многопоточный. Единственный процесс FCL запускается по команде пользователя через РУ и управляет моделью через функции АП, пока не завершится оператором return или по команде РУ.
4. Программа на языке FCL представляет собой набор из одной или нескольких процедур-функций. Обязательной является только процедура main(n).
5. Программа существует в форме набора текстовых строк (последовательности ASCII символов, заканчивающихся символом с кодом 0). Физически размещается во внешней FLASH памяти (память лога и настроек). Максимальный размер текста программы 64 или 128 кбайт (вся память 2 Мбайт).

Синтаксис:

Общие принципы:
Программа состоит из строк символов. Одна строка реализует максимум одну команду (один оператор или описание).
Все элементы строки отделяются друг от друга символами разделителями. Основные разделители – пробел (код 0х20) и символ табуляции (0x8). Там, где допустим один разделитель, допустимо любое их количество. Символы арифметических операций (+,-,* и т.п) являются неявными разделителями и не требуют использования дополнительных пробелов. Общий вид строки
[метка:] оператор [операнды] ; комментарий

Строки программы состоят из следующих элементов:

1. Метки. Если присутствует, должна быть первым элементом строки. Заканчивается символом ‘:’ Первым символом метки должна быть буква. Далее допустимы латинские буквы, цифры и символ подчеркивания. Максимальная длина метки – 8 символов (без двоеточия). Регистр букв не различается.
2. Переменные. Существуют как предопределенные переменные (контекст АП), так и переменные пользователя. Предварительного объявления не требуют, первое использование переменной (должно быть присваиванием), добавляет ее в контекст программы. Все предопределенные переменные АП глобальны (равнодоступны из всех частей программы) и структурированы (имеют составные имена разделенные точками). Переменные пользователя локальны в пределах своей процедуры. Переменная должна начинаться с латинской буквы. Регистр букв не различается. Первая буква переменной неявно определяет ее тип. Остальные символы в названии переменных могут быть латинскими буквами, цифрами и символом подчеркивания. Максимальная различимая длина переменных – 8 символов (различение переменных производится по первым 8-ми символам). Типы переменных:

• Целые 32-х разрядные числа со знаком (int32, 4 байта). Могут принимать значения в интервале от – 2^31 до 2^31-1. Если переменная начинается с букв I,J,K,L,M,N – она является целочисленной.
• Координаты. Комплексные переменные, описывающие точки пространства в виде широты, долготы, высоты и курса. (Хранятся в виде структуры 16 байт). Если имя переменной начинается с W, она задает переменную координат;
• Текстовые переменные. Задают строку символов длиной до 255 символов. Имя переменной должно начинаться с буквы S. Необходимость введения под вопросом, так как нужны только для взаимодействия с OSD.
• Действительные числа (float, 4 байта). Все остальные переменные (не начинающиеся с I,j,k,l,m,n,s,и w) являются действительными переменными.

3. Константы. Элементы начинающиеся со знака минус или цифры и имеющие в своем составе только цифры или десятичную точку. Константы без десятичной точки считаются целочисленными. С точкой – действительными. Констант типа координаты – не существует. Константы типа строка символов – под вопросом.
4. Комментарии. Начиная от символа ‘;’ до конца строки (0-й символ) весь текст считается комментарием и интерпретатором не рассматривается. Вероятно будет реализован вариант автоматического отсечения комментариев на этапе загрузки программы во FLASH АП.
5. Операторы. Определяют действия программы. Для начала предлагается 7 простейших операторов:

• IF() …
• ELSE …
• GOTO label
• Оператор присваивания =
• RETURN – возврат из подпрограммы или завершение программы
• FUNCTION name(…) – начало описания пользовательской функции
• END – конец описания пользовательской функции

Рассматривается в ближайшей перспективе возможность введения дополнительных операторов:

• for() – в синтаксисе близком к Си
• while()
• break.

6. Процедуры. Деления на подпрограммы и функции нет. Все процедуры являются функциями. Функция может принимать от 0 до 8 (надо как-то ограничить) параметров. Количество и типы параметров определяются при описании функции в операторе function, согласно используемых имен. Функция возвращает значение с типом, определяемым ее именем (те-же правила, что и для имен переменных). Возвращаемое значение можно указать в операторе return, если не указано, возвращается 0.
7. Арифметические выражения. Набор элементов типа: переменные, константы или функции; символов операций (+,- и т.п) и круглых скобок, позволяющих вычислить одно результирующее значение. Например, в строке «Y=alt(apc.tar.wp)-alt(apc.cur.wp)+h_dop/2» является оператором присваивания, где переменной Y присваивается значение выражения «alt(apc.tar.wp)-alt(apc.cur.wp)+h_dop/2».
   Из операторов арифметических выражений допускаются:
   ‘+’ – двухместная операция сложения;
   ‘-‘ - двухместная операция вычитания;
   ‘(-…) – одноместная операция изменения знака.
   ‘*’ – двухместная операция умножения;
   ‘/‘ - двухместная операция деления;
   ‘^’ – двухместная операция возведения в степень.
   Тип результат зависит от типов операндов. Если все операнды целые, тип будет целым, в противном случае – действительным.
   Для операций с координатами выражений пока не предусмотрено. Единственно допустимая операция – это присваивание. Все остальные действия реализуются через функции.

Контекст АП и ТМ

Контекст АП представлен в виде нескольких структурированных глобальных объектов apc (AutoPilotContext), tmc (telemetry context) и osd (переменные OSD в перспективе).

FCL может воздействовать на АП в 3-х режимах (возможно будет больше).

1. Режим стабилизации (assist mode). В этом режиме предопределенные переменные АП: apc.tar.pitch, apc.tar.roll, apc.tar.yaw и apc.tar.thr , непосредственно влияют на целевой тангаж, крен, скорость поворота вокруг оси Z и текущий газ модели. Присваивание значений этим переменным аналогично воздействию на основные стики передатчика в режиме стабилизации.
2. Режим круиз-контроля. Здесь управление сводится к изменению параметров текущего режима: apc.tar.dir (курс), apc.tar.alt (высота), apc.tar.thr (газ) или apc.tar.spd (скорость), в зависимости от режима управления газ/скорость.
3. Режим ПКТ. Здесь допустимы воздействия на текущую целевую точку apc.tar.wp, например, apc.tar.wp=apc.cur.wbase; или if (isnear(apc.tar.wp,50,30)) apc.tar.wp=wseth(apc.tar.wp ,120);
4. Переключать режим работы АП можно функцией setAPmode(m).

Объект APC

Из текущего контекста АП в виде переменных доступны элементы группы tar (целевые, могут быть прочитаны и записаны) и cur (текущие параметры, только чтение):

1. Ориентация в пространстве:
   · apc.tar.pitch – требуемый тангаж в градусах. 0 – горизонтальный полет < 0 – нос опущен вниз, > 0 – нос поднят вверх. Допустимые математические пределы –180 до +180 градусов. Реально максимальное и минимальное значение ограничены настройками КП.
   · apc.tar.roll – требуемый крен в градусах. 0 –нет крена. < 0 – крен на левое крыло; >0 – на правое. Остальное как у apc.tar.pitch
   · apc.tar.yaw – целевая скорость вращения вдоль горизонтальной оси в градусах в секунду. Диапазон от –500 до +500 градусов. 0 – отсутствие вращения.
   · apc.cur.pitch – текущий (мгновенный) тангаж;
   · apc.cur.roll – текущий крен;
   · apc.cur.yaw – текущая скорость вращения по оси Z.

2. Положение и движение в пространстве
   · apc.cur.wp – текущие координаты модели;
   · apc.cur.wbase – координаты базы;
   · apc.tar.wp – координаты текущей целевой точки (возможна запись);
   · apc.tar.dir - требуемый курс;
   · apc.tar.spd – требуемая скорость;
   · apc.tar.alt – требуемая высота;
   · apc.tar.thr – текущий газ;
   · apc.cur.altg - текущая высота в м, относительно высоты базы по GPS;
   · apc.cur.altb - текущая высота в м, относительно высоты базы по баро;
   · apc.cur.spdg – текущая скорость отн. земли м/c по GPS;
   · apc.cur.spdb –текущая скорость отн. воздуха м/c по баро;
   · apc.cur.dirg – текущий курс по GPS в градусах (-180…180);
   · apc.cur.dirm – текущий курс по компасу в градусах (-180…180);
   · apc.cur.dist – текущее удаление от базы м.
   · apc.cur.climb – текущее изменение высоты м/c
   · apc.cur.nfly - время полета в секундах (идет только в полете). Целое число.
   · apc.cur.nsec - время работы всей программы в сек.
   · apс.cur.mode – текущий режим АП (0 – РУ, 1-стаб, 2 – КК, 3-ПКТ, 4-RTH);
   · apc.cur.gpss – количество спутников GPS.
   · apc.cur.gpsm – состояние GPS 0 –нет, 1 координаты считаны, и т.д…
   ·

3. Параметры телеметрии
   · tmc.u1, tmc.u2, tmc.u3 – напряжения в В по 3-м каналам.
   · tmc.amp - ток потребления в А;
   · tmc.rssi – показания RSSI в %;
   · tmc.mah – количество съеденных мАч (целое цисло);
   · tmc.temp – температура с датчика температуры в С;

Предопределенные функции

• getH(Wx) – получение высоты над уровнем моря в м из координат;
• getDir(wx) – получение курса в градусах из координат;
• getDist(w1,w2) – получение расстояния по горизонтали между 2-мя коорд.;
• wSetH(wx,alt) – задать высоту alt в точке Wx;
• wShift(wx,dx,dy) – сдвинуть текущие координаты на dx и dx метров;
• wShiftP(wx,d,ang) – сдвинуть текущие координаты на d метров в направлении ang, (аналогично wshif, но в полярных координатах);
• wSet(wx,flon,flat,falt,dir) – сформировать координаты напрямую;
• sin(x) – синус угла x (градусы);
• cos(x) – косинус угла x;
• tan(x) – тангенс;
• atan(x,y) – арктангенс соотношения (atan2 по Си);
• int(x) – ближайшее целое снизу;
• isign(x) – знак числа –1 <0; 1>0; 0 == 0;
• setMode(n) – задать режим АП;
• setwpn(n) - выбрать текущую курсовую точку из списка точек АП.
• isNear(wp,maxDx,maxDh) – определить нахождение в окрестностях точки
• waitReach(wx,ns); ; ждем попадания в точку wx но не более ns секунд (0- бесконечно)
• sleep(ms) – пауза в ms миллисекунд;
• ntick(); - таймер миллисекунд
• setMode(n) - задает режим АП
• setCC(mdir,malt,mspd) – задаем режим КК: 1 –контролируем, 0- нет по курсу, высоте и скорости.

Пример программы автоматической посадки

Function landing(wx) ; функция автопосадки в точке wx
w1=wshiftp(wx,100.0,getDir(apc.cur.wbase)+180.0) ; точка на 100 м по ветру от базы
w1=wseth(w1,getH(apc.cur.wbase) +50.0) ; высота + 50 м от базовой (!не wx)
w2= wshiftp(wx,50.0,getDir(apc.cur.wbase)+180.0) ; точка еще на 50 м по ветру
w2=wseth(w2,getH(w2) +25.0) ; высота + 25 от w1
apc.tar.wp=w2 ; установим точку последнего поворота
setMode(3) ; включим режим ПКТ
waitReach(w2,0); ; ждем попадания в точку w2 (бесконечно)
waitReach (w1,30) ; перемещаемся в w1 (ждем 30 сек)
setMode(2) ; включим режим КК
seCC(1,0,0); ; удерживаем только курс
apc.cur.thr=0; ; выключаем газ
l1: if(isNear(wx,20,10)) return; ; ждем попадания в точку
sleep(99)
goto l1
end ; конец функции landing

Function main(n) ; n- номер режима на 2-м упр. канале, для вариантов…
Landing(apc.cur.wbase) ; посадка в точке взлета
end
--------------------------------------------------------------------------------------

Предлагаю к обсуждению проект языка, с помощью которго мы сможем реализовать наши пожелания к ПО автопилотов, не напрягая их разработчика. Первый вариант планируется реализовать для АП от SmallTim (с Тимофеем есть соответствующая договороенность).

Прошу высказывать Ваши соображения и пожелания.

Александр, надо изобрести еще более простой пример, наверное, чтоб было еще понятнее. Например, удержание позиции по переходу управляющего канала в положение n.

Это будет, наверное, выставление одной контрольной точки в текущие координаты, немедленное включение полета по точкам с отключением автоперебора точек и возврата на базу по достижении последней точки.

Александр, идея интересная, правда можно было бы использовать для этих целей любой из существующих скриптовых языков, хоть любой из вариантов Tiny C, хоть LUA, хоть Ruby и т.д. Второе, какой из вариантов использования скриптового языка вы рассматриваете:

1. Скрипт интерпретируется на компе с наземной Станции и через двустороннюю телеметрию передаёт нужную текущую команду на борт; Тогда это реализуемо для любого автопилота
2. В автопилот на борту встроен интерпретатор этого языка, который собственно и выполняет всю работу. Тогда этот вариант будет неприменим к различным клонам АрдуПилота и любым другим Arduino/AVRовским автопилотам. Там на это уже просто банально не хватит ни памяти ни других ресурсов.

А так – идея здравая, позволит разработчику автопилота не тратить своё время на реализацию извращённых хотелок кастомеров.

Мы хотим 2й вариант. Интерпретатор на самом деле должен выйти очень легким. Если уместится в 32к памяти, то, например, у меня еще 32к останется для развития самой автопилотной логики - АП сейчас занимает ~64к из 128к памяти.
Байткод, сгенеренный из пользовательской программы, предполагается укладывать во внешний флеш АП, чуть урезав место для логов, если понадобится (у меня ~2.1 МБайт) или в любое внешнее хранилище типа SD карт на других автопилотах, и интерпретировать код, читаемый из внешнего флеша, не из ЦП. Таким образом, прошивка АП не меняется, меняется только содержимое внешнего хранилища.

Например, удержание позиции по переходу управляющего канала в положение n.

Основной упр. канал - твой. Для FCL можно использовать только вторй упр., как параметр - требуемой функции.
Удержание позиции - это например кружение вокруг заданной текуще точки?

Тогда примерно так:
-------------------------------------------------------------------------------------
function curCirc(radius)
wx=apc.cur.wp ; запоминаем текущие координаты
apc.tar.wp=wx ; и выставляем их в кач целевой точки
ch_mode:
setMode(1) ; ставим режим стабилизации
apc.tar.roll = 10 ; 10 градусов крена, чтоб кружиться
apc.tar.thr = 50; 50% газа

loop:
sleep(100) ; чтоб не напрягать АП
if apc.cur.mode2 != 1 return ; пока не переключили управляющий
if(isnear(wx,radius,radius) goto loop ; пока не улетели далеко
setMode(4) ; включаем ПКТ (АП должен пойти к apc.tar.wp)
waitReach(wx,60); ; даем минуту на возврат в зону точки
goto ch_mode

end
-------------------------------------------------------------------------
В реальности будет сложнее, конечно. 😃

2. В автопилот на борту встроен интерпретатор этого языка, который собственно и выполняет всю работу. Тогда этот вариант будет неприменим к различным клонам АрдуПилота и любым другим Arduino/AVRовским автопилотам. Там на это уже просто банально не хватит ни памяти ни других ресурсов.

Этот вариант. У smalltim тоже Мега, и пока свободно 50% ресурсов (64 кбай ПП свободно). Интерпретатор такого уровня займет 5-10 кбайт ИМХО.
Сама программа пользователя живет во внешней FLASHке и исполняется непоследственно оттуда.
О! Тимофей уже все разъяснил. 😃

правда можно было бы использовать для этих целей любой из существующих скриптовых языков, хоть любой из вариантов Tiny C,

Есть ссылка на проект и исходники.
Интерпретатор предлагаемого варианта я могу написать за несколько недель, опыт есть.
Понятно что понадобится еще среда для отладки на ПК…
Но и готовые решения рассмотрю с благодарностью.

У smalltim тоже Мега

Александр, вроде как раньше у Тима стоял Атмеловский ARM в автопилоте. Или я чего-то напутал? Вроде ж у него только телеметрия была на Меге.
А это две абсолютные разницы. Знаю, что различные клоны АрдуПилота фактически полностью все ресурсы у соответствующих МЕГ занимают. Вы же учтите, что и объём ОЗУ и вычислительные возможности у Меги на много меньше.
По поводу интерпретаторов:

1. Вариантов различных Tiny\Pico C немерянно, есть даже готовые под разные платформы. Когда-то юзал такой code.google.com/p/picoc/ . Но их реально много, бо язык С красив и прост.
2. LUA: www.lua.org/about.html Уже стала чуть ли не стандартом для скриптов в различных игровых движках и т.д. Даже WoW его использует. Вот список игр, где оно юзается: ru.wikipedia.org/…/Категория:Игры,_использующие_яз…

Под VLC плагины на ЛУА пишут. Говорят, что Эдоб Лайтрум его использует во всю, но я не знаю. Сырцы открыты, есть куча реализаций интерпретаторов под различные платформы, в том числе есть и JIT реализации. Вот на русском в википедии ru.wikipedia.org/wiki/Lua
3) Ruby: www.ruby-lang.org и ru.wikipedia.org/wiki/Ruby ООПишный язык, тоже опенсорснутый и мегапопулярный
4) Немерянное количество интерпретаторов Pascal под разные платформы.

Просто эти языки достаточно просты и известны. У меня даже дизайнер в своё время на ЛУА шпарил как пулемёт, хотя программированием до этого никогда не занимался.

можно было бы использовать для этих целей любой из существующих скриптовых языков, хоть любой из вариантов Tiny C, хоть LUA, хоть Ruby и т.д.

можно хоть на бейсике писать, только где есть в природе реализации перечисленных языков для AVR?

готовые решения рассмотрю

PyMite:

Requires roughly 55 KB program memory
Initializes in 4KB RAM; print “hello world” needs 5KB; 8KB is the minimum recommended RAM.
Supports integers, floats, tuples, lists, dicts, functions, modules, classes, generators, decorators and closures
Supports 25 of 29 keywords and 89 of 112 bytecodes from Python 2.6

чего нет и не будет:

A built-in compiler
Any of Python’s libraries (no batteries included)

можно хоть на бейсике писать, только где есть в природе реализации перечисленных языков для AVR?

У Тима ARM…

Александр, вроде как раньше у Тима стоял Атмеловский ARM в автопилоте. Или я чего-то напутал? Вроде ж у него только телеметрия была на Меге.

В АП стоит AT90USB1287. В OSD ATMEGA8, но нам туда не надо. 😃

По поводу интерпретаторов

Спасибо, гляну попозже. Впрочем я уже готов писать полностью свой интерепретатор. ИМХО, компактнее будет.

Просто эти языки достаточно просты и известны.

Многие из них заточены либо под текстовую обработку, либо под WEB странички.
А нам нужно другое…

можно хоть на бейсике писать

Примерно на нем и будем. 😃

Многие из них заточены либо под текстовую обработку, либо под WEB страничке.

заточены прилагаемые библиотеки, а не языки. на PHP можно хоть бинарники для любой оси делать, с гуем и сетевой поддержкой (только зачем?)

такой вопрос: задана команда “лететь в точку с такими-то координатами”, скорость ветра превышает скорость модели. кто будет обрабатывать такие ситуации, автопилот каким-то образом скажет “ну никак мне туда не долететь” или автор программы должен будет скриптово предусмотреть миллион нештатных случаев?

второй вопрос: какие команды будет поддерживать автопилот? бегло пробежался по готовым решениям, стандартный набор команд:

• лететь в точку (заданы координаты)
• лететь по маршруту (набор точек)
• лететь по кругу (задан радиус)

с вариациями типа реверса, повтора предыдущей команды или временем исполнения. то есть вся реализация “языка” сводится к 3-м функциям со своими параметрами.
стоит ли огород городить, если достаточно построчное чтение файла (утрированно)?

задана команда “лететь в точку с такими-то координатами”, скорость ветра превышает скорость модели. кто будет обрабатывать такие ситуации,

Автопилот. Точно так-же, как он отрабатывает это сейчас.

или автор программы должен будет скриптово предусмотреть миллион нештатных случаев?

Можно проверять текущее состояние и переходить в режим управления моделью уровня целевой тангаж/крен/газ.

второй вопрос: какие команды будет поддерживать автопилот?

Примерно те-же, что и сейчас доступно через РУ: стабилизация, круиз контроль, ПКТ, возврат на базу. Если что-то будет добавлено в базовый функционал (например кружение вокруг точки), этим сможет воспользоваться интрепретатор.
ИМХО в реальности лучше всего задействовать самы высокоуровневые функции, а программировать детали надо только там, где без этого никуда…
Например в первых версиях считают бесполезным физический уровень управления- вплоть до прямых команд сервовыходам.

то есть вся реализация “языка” сводится к 3-м функциям со своими параметрами.

Для многих задач - да. Ну если я хочу автоматизировать поиск термиков, к примеру? 😃

5 копеек от еще одного ковырятеля автопилотов:
Я так понял, вы хотите создать универсальный язык описания миссий. Чтобы не увязнуть в специфике конкретной “железной” реализации, не трогайте углы, ПИДы и прочие сугубо различающиеся параметры. Считайте по умолчанию, что:

1. автопилот давно настроен, и при указании ему точки с координатами он сам способен привести пепелац туда. Корректируемым параметром может являться только скорость на текущем отрезке.
2. нельзя давать команду “поднять правый элерон”, т.к. на его месте в конкретной модели может стоять V-хвост или вообще канал газа мультиротора. Все команды должны сводиться к высокоуровневым действиям, например, set_current_target (lat,lon,alt) или set_gear(on/off)
3. входными данными брать только “общие параметры”. К примеру, нафига нужны мА/ч на бензиновом аппарате? Гораздо удобнее использовать fuel_level (0…100%), который рассчитывается самим железом или из миллиампер, или от датчика уровня. И не забудьте внедрить точный тайминг, условные циклы и ветвления.

Боюсь, даже в этом случае может получиться монстр типа mavlink, чудовищного размера и сложный в адаптации. Ну, будет только один Тим его юзать, и приставку “универсальный” можно убирать.

понял, вы хотите создать универсальный язык описания миссий. Чтобы не увязнуть в специфике конкретной “железной” реализации, не трогайте углы, ПИДы и прочие сугубо различающиеся параметры.

Совершенно верно. Подменять алгоритм стабилизации я не собираюсь.

автопилот давно настроен, и при указании ему точки с координатами он сам способен привести пепелац туда. Корректируемым параметром может являться только скорость на текущем отрезке.

В самом востребованном режиме - да.

) нельзя давать команду “поднять правый элерон”,

Нельзя. Но можно дать команду текущий крен=30 градусов. АП должен это отработать, а мы можем проконтролировать.

входными данными брать только “общие параметры”.

Я не претендую на универсальность языка. Для начала, хочется улучшить конкретный проект. Принцип доступа к переменным АП простой, если то чего спрошено не существует, будет возвращаться 0 и выдаваться предупреждения на этапе предкомпиляции при загрузке программы во FLSH АП. В полете посто 0. Можно еще добавить фнку типа ifExist(var).

не забудьте внедрить точный тайминг, условные циклы и ветвления.

Тайминг - само собой. Точность ограничено несколькими мс реального цикла АП.
Ветвления - в преспективе. Пока и GOTO достаточно. 😃

Извините, я в этом деле не оч.
Но почему нельзя взять что-то готовое (напримел Lua), написать API или тп…

Но почему нельзя взять что-то готовое (напримел Lua), написать API или тп…

Цитата с главной странички сайта:
Adding Lua to an application does not bloat it. The tarball for Lua 5.2.0, which contains source code and documentation, takes 241K compressed and 950K uncompressed. The source contains around 20000 lines of C. Under Linux, the Lua interpreter built with all standard Lua libraries takes 182K and the Lua library takes 240K.

20 тыс строк кода в авиамодель мы просто не засунем. 😃
И главное: цель - не воспользоваться неким красивым языком (я бы тогда С++ портировал), а с минимальными затратами воспользоваться текущими возможностями АП.
ИМХО все процедурные языки, начиная с машины Тьюринга по сути имеют одинаковые возможности. 😃

20 тыс строк кода в авиамодель мы просто не засунем.
И главное: цель - не воспользоваться неким красивым языком (я бы тогда С++ портировал), а с минимальными затратами воспользоваться текущими возможностями АП.

100%, а вот цитата с упомянутого мной picoС code.google.com/p/picoc/ :

PicoC is a very small C interpreter for scripting. It was originally written as the script language for a UAV’s on-board flight system. It’s also very suitable for other robotic, embedded and non-embedded applications.

The core C source code is around 4000 lines of code.

Ну если я хочу автоматизировать поиск термиков, к примеру?

вариант 1: разработчик автопилота пишет отдельный модуль для решения этой задачи и предоставляет к нему доступ. что выливается в “реализацию извращённых хотелок кастомеров” самим разработчиком, а не пользователями.
вариант 2: вы сразу ориентируетесь на собственное железо, которое будет иметь универсальный протокол обмена со всяко-разными автопилотами (ну или набором протоколов).
вариант 3: скриптовое решение задачи занимает слишком много ресурсов, разработчик автопилота обязан будет предусмотреть контроль за временем исполнения скрипта, выделением памяти и прочими гадостями, в итоге изобретет свою собственную RTOS для поддержки вашего собственного интерпретатора.

не хочу разводить депрессии, но мне видится более практичный путь — если цель достаточно конкретна, то вместо изобретения попробовать реализовать уже готовое. скриптово-событийных систем для самопальных роботов уже столько, что глаза разбегаются.

скриптовое решение задачи занимает слишком много ресурсов, разработчик автопилота обязан будет предусмотреть контроль за временем исполнения скрипта, выделением памяти и прочими гадостями, в итоге изобретет свою собственную RTOS для поддержки вашего собственного интерпретатора

Не думаю, что понадобится слишком много ресурсов и проверок. Здесь нет сложных механизмов выделения памяти и т.п. Тред скрипта крутится параллельно с остальными процессами АП и четко квантуем - взять под себя больше ресурсов, чем нужно у него не выйдет. А вот прервать можно в любой момент по команде РУ или иным условиям самомго АП.

то вместо изобретения попробовать реализовать уже готовое. скриптово-событийных систем для самопальных роботов уже столько, что глаза разбегаются.

У меня ощущение, что если я начну щас искать готовое а потом портировать это в AVR СИ, времени уйдет больше, чем просто написать интерпретатор с нуля. 😃

а когда вы напишете интерпретатор для AVR, сколько времени займет его портирование под ARM, к примеру?

предлагаю авантюру. есть такой симулятор AeroSIMRC, умеет выдавать практически все полетные данные и принимать команды на управление (или даже напрямую менять положение модели). для этого сима я делал HITL-плагин для CopterControl-а (по-русски), плата полностью переключалась на данные от симулятора и рулила виртуальными сервами/моторами.

авантрюра вот в чем, я переношу всю логику CopterControl-а в сам плагин (исключаем железо), он получает данные от сима и стабилизирует модель (на худой конец можно просто использовать стабилизаторы в самом симуляторе). а вы реализуете поддержку скриптов и требуете необходимые структуры/переменные/данные. для “посмотреть что получится” по-моему вполне достаточно.

используется там чистый C (даже не плюсы), в принципе, можете использовать прилагаемый пример демо-плагина и прикрутить к нему все остальное сами.

p.s.
если интересно, вот такие структуры данных сим выдает и принимает.

а когда вы напишете интерпретатор для AVR, сколько времени займет его портирование под ARM, к примеру?

Сам интерпертатор будет на Си - и не вылезет за рамки обычных конструкций, то есть будет портироваться на любое стандартное подмножество. Другое дело привязка к конкретному АП. Здесь могут быть трудности. Поживем - увидим. 😃

предлагаю авантюру.

Интересное предложение. Давайте так, у меня по плану все равно сначла написание интрепретатора на СИ для ПК, плюс создание некой отладочной среды, а затем уже перенос на AVR Си и привязка к коду АП (совместно с Тимофеем). Возможно на этапе реализации отладочной среды предлагаемый симулятор будет весьма кстати…

AVR Си

Александр, там вы под ОСД хотите интерпретатор написать? Ибо автопилот Тима всё же на ARMе, а не на AVR. Под какой компилятор планируете?

Ибо автопилот Тима всё же на ARMе, а не на AVR.

Откуда инфа?
АП от Smalltim лежит передо мной. Там стоит AT90USB1287, и это 8-ми разрядный микроконтроллер.
На ARM от ST (STM32) сделано новое IMU (только IMU), подключаемое к этому АП.

Под какой компилятор планируете?

Atmel AVR Studio 5.0.

Там стоит AT90USB1287, и это 8-ми разрядный микроконтроллер.

Тьфу ты, чёрт, попутал. У меня их AT91SAM7S128 AU, а это ARM7 вот я с дуру и думал, что АТ90 просто младшая версия. Прошу прощения.