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