================================================================================================================== Вставка от =DeaD= - разработчика ORFA-терминала
Репозитарий проекта: (там можно скачать последнюю версию в пункте "zip" левого меню) Клиент репозитария: TortoiseHg ( ) Используемая среда разработки: Qt Creator ( скачать SDK можно в DOWNLOAD \ LGPL \ Qt SDK for *) Используемые дополнительные библиотеки:
QextSerialPort 1.2 ( )
OpenCV 2.1 ( под Win32 ставить в дефолтную папку - C:\OpenCV2.1, под это прописаны пути к .lib-файлам в проекте)
SDL 1.2 ( )
* Внимание! для всех библиотек надо либо включать место где лежат соотв. файлы в PATH, либо:
файлы .dll надо помещать в каталог <qt>/<YYYY.MM>/qt/bin
.a-файлы библиотек в <qt>/<YYYY.MM>/qt/lib
.h-файлы заголовков в <qt>/<YYYY.MM>/qt/include
Реализованы функции:
Отображение видеосигнала с робота
Выбора COM-порта и скорости работы;
Настройки номеров сервоприводов шасси и pan-tilt платформы;
Прямого управления шасси с кнопок формы;
Прямого управления шасси с джойстика или геймпада;
Прямого управления pan&tilt платформой с ползунков формы;
Планируется:
Привести в порядок интерфейс программы;
Навигация по подготовленным маякам;
Привести в порядок код программы, чтобы можно было использовать этот терминал как базу для любых проектов;
Сделал робота 6х6, http://roboforum.ru/viewtopic.php?f=10&t=7335 Все никак не доходят руки им порулить - нет программы. Вроде определился - писать на си билдере. Сейчас гденить скачаю и начну делать программу. Я предлагаю тем, кто юзает подобные, обеденится и набрасать основу для типовой программы и выложить исходный код для дальнейшей переделки юзерами. Т.к. я понимаю, что OFRA - неплохая штука, но эта неплохая штука есть только в МК, а для ее руления еще ничего нет. Может быть у кого-то уже есть наработки.
Сложное - правильно объявить интерфейсы с основной частью. Я пока совершенно не представляю что и каким образом будет выноситься в плагины. Сейчас навигацию прикручу, надеюсь чуть яснее станет.
Как это что? Главная программа - чистый терминал, каждая другая решаемая задача - плагин.
Сложное - правильно объявить интерфейсы с основной частью.
Плагины не должны влиять на среду где они исполняются. блин, оказывается писать плагин-ориентированные приложения довольно таки интересно, а я при изучении джавы забил на них
Последний раз редактировалось Grem 07 фев 2011, 01:06, всего редактировалось 1 раз.
Такой же, как в документации к контроллеру, или я опять не понял суть? Сделать Plugin API, точка входа каждого плагина должна реализовывать интерфейс с основными методами.
Неее... это скучно. Как минимум надо уровень выше делать - когда уже настроено какой контроллер, какие сервы за что отвечают и т.п. Иначе весь функционал этот придется в каждый плагин тащить. Поэтому 100% интерфейс не такой же.
Ну и конечно же хочется, чтобы один плагин мог пользовать другой, пусть для навигации той же. Т.е. к примеру, сделаю я навигацию по маякам, а кто-то сделает плагин, использующий мою навигацию и умеющий патрулировать квартиру.
Терминал должен быть как бы маленькой операционной системой, связующим звеном между плагинами и железом роботов а также с юзером. Чем меньше в нем будет того, что можно было бы сделать вариабельным, тем лучше. Даже внешний вид формы с изображением камеры или панель управления роботом с кнопками - все это можно вынести в плагины. И пусть народ лепит их всякие и разные. Ими мощь терминала прирастать будет. Но при этом желательно чтобы каждый плагин как можно меньше зависел от других плагинов.
Виктор Казаринов писал(а):Но при этом желательно чтобы каждый плагин как можно меньше зависел от других плагинов.
Это 100% будет вселенское зло. Надо чтобы можно было одному плагину генерить информацию, которую могут использовать другие плагины. Собственно основной вопрос - стандартизация таких интерфейсов. Скажем модуль навигации по маякам должен опираться на модуль детектирования маяков, тогда можно будет легко заменять одни маяки другими. И наоборот - можно вместо модуля опирающегося на заранее известные координаты маяков создать модуль, который будет сам гонять по квартире, запоминать какие где маяки и строить карту.
М.б. вы не так меня поняли. Я хотел сказать - плагины не должны зависеть от имплементации (конкретной реализации) других плагинов. Т.е. каждый плагин должен общаться с терминалом и другими плагинами через стандартный для данного терминала Plugins API. Вопрос - а надо ли делать свой вариант ROS? Или это будет совсем другое нечто?
Виктор Казаринов писал(а):Терминал должен быть как бы маленькой операционной системой, связующим звеном между плагинами и железом роботов а также с юзером. Чем меньше в нем будет того, что можно было бы сделать вариабельным, тем лучше. Даже внешний вид формы с изображением камеры или панель управления роботом с кнопками - все это можно вынести в плагины. И пусть народ лепит их всякие и разные. Ими мощь терминала прирастать будет. Но при этом желательно чтобы каждый плагин как можно меньше зависел от других плагинов.
Вот об этом я и говорю
Т.е. к примеру, сделаю я навигацию по маякам, а кто-то сделает плагин, использующий мою навигацию и умеющий патрулировать квартиру.
И что? Передать данные с одного плагина на другой - тривиальная задача.
свой рос это тяжко