roboforum.ru

[AlexandrY]

А применяет ли кто-нибудь в своих проектах для управления железом скриптовый язык LUA?
И насколько инфраструктура его поддержки (редакторы, дока, отладчики..) лучше или хуже других языков для этого дела?

[Сергей]

http://www.eluaproject.net/

[vadinator]

А вам конкретно он зачем?

[AlexandrY]

http://www.eluaproject.net/

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

Добавлено спустя 1 минуту 14 секунд:

А вам конкретно он зачем?

Оцениваю целесообразность портирования LUA на свою платформу.

[Сергей]

Если Вам нужен Lua под линукс для какой-нибудь платформы - пожалуйста, Вас никто не держит. Использовать можно как угодно. Если нужна "чистая" платформа с Lua - eLua. Можно выполнять скрипты, какие-нибудь автоматы простые, НО медленно на простых ARMах. То есть, для не требовательных к времени программам - самое то.

[noonv]

на всякий случай взгляните ещё в сторону urbiScript - скриптовый язык для URBI.
Подробнее можно почитать здесь и т.д.
По словам разработчиков минимальная платформа на которой они запускали URBI-сервер - это

Spykee: 2.5 MB of flash, 32 MB of RAM, 150 Mhrz ARM CPU.

[Сергей]

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

[AlexandrY]

Если Вам нужен Lua под линукс для какой-нибудь платформы - пожалуйста...

Нет, мне больше интересно, как роботостроители относятся к LUA и вообще скриптовым движкам на микроконтроллерах.
Действительно ли их сдерживает быстродействие этих движков, либо отсутствие многозадачности в известных проектах, либо реальные трудности с отладкой на железе, либо ограниченность прикладных библиотек или еще что-то.
Некоторые из недостатков вполне поправимы на сегодня.
Скажем LUA на 100..200 МГц ARM-е работает с той же скоростью, как нативный код написанный на C и скомпилированный компилятором Hi-Tech работающий на PIC16xx

[noonv]

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

верно, URBI - это клиент-серверная система, но именно о серверной части я и говорил

полная цитата:

Urbi is just a program you run on your system as a daemon. So answer C: you need an functional system with an OS, and Urbi is essentially a middleware + a scripting language + a C++ components architecture.

Basically, if your system is large enough (it has its own OS - Linux most likely - and has decent computing capabilities), you can run Urbi on it as a service. This is the approach we use on Nao for instance. The smallest robot we managed to make Urbi run on is Spykee: 2.5 MB of flash, 32 MB of RAM, 150 Mhrz ARM CPU.

If your device is too small (a controller card with a firmware, a minimal Unix system, ...), you can write UObjects which are pluggable Urbi component. The only requirement is that you have a reasonably recent C++ toolchain for your hardware. These UObjects can then be run on the device as autonomous program, which will remotely connect to an Urbi kernel on another host - which implies you need an IP connectivity. This is the approach we use for Bioloids or Lego mindstorm for instance.

I might be able you help you further if you give me details about your project and hardware.

[AlexandrY]

на всякий случай взгляните ещё в сторону urbiScript - скриптовый язык для URBI.

Однако это закрытая система. Открыли там только SDK т.е. средство создания программ для готовых платформ.
Чтобы разместить движок URBI на свое хардварной платформе нужен как минимум PDK (platform development kit)

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

[Сергей]

Я вроде видел на их сайте исходники парсера команда и прочее. Какой тип программ возможно реализовать на Urbi смотрите их видео с конференций.

Добавлено спустя 43 секунды:
А какой тип задач Вы хотите решить с помощью Lua?

[Romikgy]

Скажем LUA на 100..200 МГц ARM-е работает с той же скоростью, как нативный код написанный на C и скомпилированный компилятором Hi-Tech работающий на PIC16xx

а теперь осмыслите то , что вы написали
для луа нужно 100 Мгц на арме , когда для МК на порядок меньше частоты требуются с тем же быстродействием!!! вывод думаю сами осилите

[Виталий]

Вывод осилим. Сейчас АРМ стоит как какой-нить слабосильный AVR.

[AlexandrY]

для луа нужно 100 Мгц на арме , когда для МК на порядок меньше частоты требуются с тем же быстродействием!!!

Претензия понятна, здесь видно попытка смешать область применения скриптов и компилируемых в машинный код языков.
Вообщем-то я это и хотел узнать, в какой пропорции роботостроители применяют скрипты по отношению к машинным кодам.

Машинные коды требуют знания архитектуры, адресных пространств, регистров периферии. При их написании надо всегда помнить о конфликтах доступа к общим ресурсам типа интерфейсов I2C, SPI... или типа областей памяти и т.д. Машинные коды располагаются по фиксированным адресам в простых микроконтроллерах, их надо предварительно компилировать и линковать желательно дорогими средствами разработки, потом записывать во Flash, т.е. невозможна их быстрая замена и редактирование в реальном времени ну и т.д.

Язык типа Urbi больше подходят для описания поведения и простых state-машин. Причем как я понял он просто являтся промежуточным кодом графических представлений state машин в пакетах типа Gostai Suite. Очень похоже на технологию MATLAB-Simulink-StateFlow.

LUA имеет возможности гораздо шире чем мапинг графических моделей поведения. Поэтому как бы должен был быть интересен разработчикам управляющих программ на хардварных платформах. Кто конкуренты LUA на этом поле?

[Romikgy]

ИМХО !!!
для целей роботостроителей , скрипты интересны в тех направлениях где нужна быстрая смена команд, например самый простой пример программирование роботов машинок , сколько сделать оборотов колеса и в какую сторону повернуть . т.е. круг таких команд очень ограничен, и использовать для 10 команд "возможности гараздо шире" не имеет рационального смысла....
если же отойти от исполнения скрипта только на МК , а например в связке с ПК , тогда смысл есть , но нужна прослойка , типа исполнение скрипта на ПК , а простые команды отдавать на МК.
но это решение подходит как я понимаю для роботов типа станков с ЧПУ , есть ограничения на набор команд. А когда мысль не больно выражена у создателя робота , то смысл ставить ему рамки при использовании скриптов? если можно чуть поднапрячься и использовать все от того что дает железо...