FCL (Flight Contol Language) - пользовательский язык для управления автопилотом
Но почему нельзя взять что-то готовое (напримел 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 просто младшая версия. Прошу прощения.