Search in topic

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

Например, удержание позиции по переходу управляющего канала в положение 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 странички.
А нам нужно другое…

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

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

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

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

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

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

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

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

то есть вся реализация “языка” сводится к 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 просто младшая версия. Прошу прощения.