Создаем ROBO_API

alex-rdx

SWG писал(а):

alex-rdx писал(а):

Вас закидали за то, что вы назвали дерьмом только по причине 8 битности и малого количества памяти В САМОМ КОНТРОЛЛЕРЕ. И в той теме я вроде тоже писал, что никто вам не мешает поставить внешнюю. А по вашему определению Мега 128 - тоже то самое "дерьмо"... Не ARM, всего лишь 8 битник, и памяти в ней немножко... Флэшку же на гигобайты сейчас подключают даже, например, к хиленькой 8-ножке Тини85, и проигрывают с нее музыку...

А я уже и не спорю на эту тему. Мне лично все ясно, но каждый при своем мнении. Спорить 8 vs 32 бит - это тоже самое в нынешние времена, как спорить какой ЯП лучше...

alex-rdx

система_координат
- система_координат.размерность(1..4)
- система_координат.координата(1..4)
- система_координат.координата(1..4).вид(0 - длина, 1 - угол)
- система_координат.координата(1..4).значение

размер
- размер.система_координат

мир
- мир.система_координат
- мир.размер

объект
- мир.объект
- объект.система_координат
- объект.размер

бот
- бот.система_координат
- бот.размер
- бот.двигатся(1 - вперед, -1 - назад, расстояние | угол)
- бот.двигатся_в_точку(a, b, c)
- бот.поворот(азимут, зенит)
- закончено_выполненение_команды()

юнит
- бот.юнит(номер)
- юнит.двигатся(1 - вперед, -1 - назад, расстояние | угол)
- юнит.двигатся_в_точку(a, b, c)
- юнит.поворот(азимут, зенит)
- закончено_выполненение_команды(юнит)

привод
- юнит.привод(номер)
- привод(номер).система_координат
- закончено_выполненение_команды(привод)

датчик
- юнит.датчик(номер)
- датчик(номер).размер
- сработал_датчик(датчик)

Пока так для начала...

dcoder

Цитата:

- сработал_датчик(номер_датчика)

Дальномер, пиродатчик, датчик освещенности, термометр не могут сработать. Они могут выдавать какое-то значение. Конечно, можно установить какое-то условие по которому будет генерироваться событие "сработал", но все-равно это не есть гуд. Для каждого типа датчика придется реализовывать свой класс или пересчитывать какое-то универсальное значение (датчик.выход) в температуру, расстояние, освещенность, ect.

alex-rdx

dcoder писал(а):

Цитата:

- сработал_датчик(номер_датчика)

Дальномер, пиродатчик, датчик освещенности, термометр не могут сработать. Они могут выдавать какое-то значение.

- датчик(номер).система_координат
- датчик(номер).[система_координат].координата(1..4).значение
или может быть:
- датчик(номер).[размер.система_координат].координата(1..4).значение

Bomond

swg, а Вы выкладывали куда-нибудь видео как Ваш робот бегает, что-то не припомню. Хотелось бы посмотреть.

SWG

Bomond писал(а):

swg, а Вы выкладывали куда-нибудь видео как Ваш робот бегает, что-то не припомню. Хотелось бы посмотреть.

Да мне лень возиться с обработкой видео, его сжатием, выкладкой... Бегает, да и бегает.
И большую часть времени при отладке, например, начинки башни, он вообще не бегает, а стоит рядом на подставке, перед глазами, чтобы видно было, как что отрабатывает. Как вертится башня, как отрабатывает УЗ дальномер, подсветка камеры, и так далее. В основном я пускал его бегать при проверке радиоканала и камеры на разных расстояниях, да когда отлаживал систему датчиков бампера. И то в основном по дому. Передвижение я отладил еще года 3 назад, сейчас в основном другие задачи. Надо поставить на башню остальные датчики (пиродатчик, акустические, датчик приближения на биениях, возможно, параллаксный дальномер на TSL201), сейчас вот регистратор появился. Но в основном уже прикидываю схему, компоновку и разводку центрального контроллера. Чтобы потом его снова не переделывать, надо заранее все увязать.
На днях также надумал перелопатить заново программу контроллера бамперов. Хочу поменять опрос датчиков пола с порогового на аналоговый (через АЦП, слишком большой разброс яркостей пола), кое - что изменить также в обработке сигналов с TSOP бамперов, зашить в контроллер бамперов тоже бутлоадер (как в башне), для оперативной отладки. Ну и еще куча текущих мелочей.

Bomond

ну Вы уж запишите видос как нибудь все-таки. Ничего обрабатывать не надо, зальете на youtube, он сам все обработает.

alex-rdx

SWG писал(а):

как отрабатывает УЗ дальномер

УЗ дальномер, круто. Простое решение задачи анализа образов, т.к. это 3-х мерное изначально зрение. Видео-камера - 2-х мерное зрение, 2-х мерный образ 3-х мерного окружающего мира, но с высокой разрешающей способностью. А какая разрешающая способность у УЗ дальномера. И как он ваще устроен, видимо дорогущая штука?

Bomond

уже писали про этот дальномер, в соседней ветке "Робот SWG"/ Не особенно она дорогая, есть куча датчиков УЗ, на которых можно реализовать дальномер.

alex-rdx

УЗ - это как у дельфина. Жалко, что главный мозг хотите на AVR делать, а так можно было в дельфина посадить "пингвина" )))

Bomond

ну тогда уж взять материнку nano itx, поставить туда win XP, по USB подключать датчики и моторчики, да и писать не напрягаясь на чем угодно. А что, тоже вполне себе вариант.

alex-rdx

Bomond писал(а):

ну тогда уж взять материнку nano itx, поставить туда win XP, по USB подключать датчики и моторчики, да и писать не напрягаясь на чем угодно. А что, тоже вполне себе вариант.

А так все и будет года через 2-3 ))) Будут в Китае шлепать такие платы за 700-100 рэ. И все покатится на смарку - и хобби, и усилия, и затраты ))) Все, как всегда... Но пока этого нет, мне лично интересны МК - там всё ПО всех видов по вертикали, и его можно самому сделать таким "игрушечным", но настоящим и охватываемым глазом, понятным. А на верхах винды и линукса ПО городить - мне лично не интересно.

Над виндой смеялись, а линукс уже распух сам, как свинья. И еще и расклонировался на 1000 видов. Хорошо, что в МК еще эти 2-е толстожопых заразы не проникли полностью. В старшие арм-ы уже влезли ...

masterok

alex-rdx писал(а):

Bomond писал(а):

И все покатится на смарку - и хобби, и усилия, и затраты )))

Не всё. МК, компы, это всего лишь железки. Главное это алгоритмы и программы.

sim

alex-rdx писал(а):

Bomond писал(а):

ну тогда уж взять материнку nano itx, поставить туда win XP, по USB подключать датчики и моторчики, да и писать не напрягаясь на чем угодно. А что, тоже вполне себе вариант.

А так все и будет года через 2-3 ))) Будут в Китае шлепать такие платы за 700-100 рэ. И все покатится на смарку - и хобби, и усилия, и затраты ))) Все, как всегда... Но пока этого нет, мне лично интересны МК - там всё ПО всех видов по вертикали, и его можно самому сделать таким "игрушечным", но настоящим и охватываемым глазом, понятным. А на верхах винды и линукса ПО городить - мне лично не интересно.

Над виндой смеялись, а линукс уже распух сам, как свинья. И еще и расклонировался на 1000 видов. Хорошо, что в МК еще эти 2-е толстожопых заразы не проникли полностью. В старшие арм-ы уже влезли ...

nano ITX потребляют много, на них много других применений делают, видеорегистраторы например.

Линукс насколько я понимаю гибкий, без графической оболочки легкая операционная система, замечательно подходит контроллерам, типа как раньше DOS был. Из плюсов например готовый TCP стек, USB и т.п.

МК как ни странно держатся стабильно, лет 30 уже одно и тоже по сути. Если у вас стремление к нижнему уровню вам нужно занятся программируемой логикой, это на порядок круче - вечная тема )))

sim

Bomond писал(а):

ну Вы уж запишите видос как нибудь все-таки. Ничего обрабатывать не надо, зальете на youtube, он сам все обработает.

Залить на ютуб 0.01% затрат времени от создания робота и сравнимо со временем написания ответа в форум )))

API для робота предложил бы Modbus, потому что он всёравно везде и простой, можно вручную в терминалке команды отправлять, modbus asci так точно :)

matrex

Как робототехник, я, может быть, буду нести какую ни будь ересь – опыта в этом деле практически нет, но как программер выскажу свое ИМХО.

На мой взгляд, при наличии множества конструкций и взглядов на реализацию механики роботов и их датчиков ну просто не возможно создать универсальное API подходящее для всех и каждого.

Единственная возможность реализовать хоть какую-то унификацию поступить следующим образом. Разработать, например, файл (пусть будет на си) с набором пустых, функций, реализующих элементарные действия роботов - этакий драйвер. Ну, например, условно, провернуть колесо на определенный угол, включить датчик, прочитать состояние датчика в «условных единицах» и т.д. Конкретной реализацией этих функций для своего робота должен заняться каждый желающий, который захочет использовать эту библиотеку. Элементарные функции нужно будет объединить в функции более высокого порядка (например проехать 1 метр, перевести «условные единицы» датчика в метры). Основное правило для функций высшего порядка – ни при каких условиях не использовать прямое обращение к железу, а только через драйвер…

Ну а дальше – реализация логики работы робота из этих «кирпичиков» - функций высшего порядка - вне зависимости от типа шасси конкретного робота или индивидуальных параметров датчиков…

Как то так…

Raketoman

Надеюсь, тема не завяла.
Хотелось бы поделиться своими скромными наработками по созданию виртуальной машины для робо-контроллера.
За основу взят слегка модифицированный диспетчер задач и ВМ DIHALTa.
-В диспетчер задач была добавлена функция распределения команд в очереди по приоритетам.
-При постановке в очередь системного таймера, можно добавить несколько функций с одинаковым указателем.
-Так же через очередь можно передавать конкретной функции 1 аргумент, тип аргумента можно изменить в заголовочном файле диспетчера.

О ВМ.
Формат записи байт кода примерно следующий :

Код:

#define end      0
      
static unsigned char VM_Data[] = 
{
3,      //индекс  первой операции первого процесса
25,      //индекс первой операции второго процесса
end,   //конец заголовка


//первый процесс
15,1,0,         //первая операция 
14,1,0x0,0x64,
13,1,   
15,1,1,
14,1,0x0,0x64,
13,1,   
11,1,3, 
end,          //конец первого процесса

//второй процесс
16,1,1,         //первая операция 
14,1,0x0,0x32,
13,1,   
16,1,0, 
14,1,0x0,0x32,
13,1,   
11,1,25, 
end            //конец второго процесса
};

Код:

|индекс необходимой функции в массиве VM_Func
|    |приоритет выполнения 
|    |      |первый параметр
|    |      |       |второй параметр
14, 1, 0x0, 0x64,...

В начале, программа инициализации ВМ загружает из заголовка массива байт кода, в массив счётчиков (VM_Counter) индексы процессов, до тех пор, пока не дойдёт до «end». После чего загружает VM в очередь диспетчера.

Код:

void VM_Init(void)      
   {
   int index = 0;
   
   for(index = 0; index!=AmountProcess; index++)   //чистим счётчики
      {
      VM_Counter[index]=0;
      }
   
   for(index = 0; VM_Load(index)!=0; index++)      //записываем адреса процессов 
      {
      VM_Counter[index]=VM_Load(index);
      }
      
   OS_AddTask(1, VM, 0);      //загрузка VM в очередь
   
   }

Как работает основная функция ВМ видно из кода.

Код:

void VM(void)
   {
   int index = 0;
   u08 Pr;                              //приоритет
   PNTR Pointer;   
                                 //Указатель
   for(index=0; VM_Counter[index]!=0; index++)
      {
      Pointer = VM_Func[VM_Load(VM_Counter[index])];      //загружаем указатель
      
      if(Pointer == VM_END)                        //если процесс завершился
         {
         continue;                              //смотрим следущий
         }
         
      Pr = VM_Load(VM_Counter[index]+1);               //запоминаем приоритет
      
      OS_AddTask(Pr, Pointer, index);               //закидываем функцию в очередь
      
      }
      
   OS_AddTask(1, VM, 0);                        //закидываем VM в очередь 
   
   }

Код:

u08 VM_Load(u08 index)
   {
   return VM_Data[index];
   }

При постановке задачи в очередь на исполнение, мы передаём ей в качестве параметра номер процесса который её вызвал. Это нужно для того функция знала, значение счётчика ко кого процесса ей необходимо изменить, чтобы перейти на следующую функцию.

Например функция JMP

Код:

void VM_JMP(PRMTR index)
   {
   VM_Counter[index]=VM_Counter[index]+1;            //переходим на параметр приоритета выполнения
   VM_Counter[index] = VM_Load(VM_Counter[index]+1);   //переходим на указанную функцию
   }

если функция не передвинула указатель, она будет вызываться снова и снова. Это может пригодится, если для продолжения выполнения процесса нам необходимо, например, дождаться установки ко кого либо бита.

Указатель процесса может быть передвинут и из другого процесса. Как например установка задержки.
Кусок байт кода:

Код:

15,1,0,                         //LED1, пр.1, ON                        
14,1,0x0,0x64,                //DELAY, пр.1, timeh, timel            
13,1,                                 //пустышка, пр.1                        
15,1,1,                            //LED1, приоритет 1, OFF               

При выполнении функции DELAY мы устанавливаем в очередь системного таймера функцию VM_Next, передавая ей в качестве аргумента номер процесса который вызвал саму функцию DELAY.

Код:

void VM_DELAY(PRMTR index)
   {
   VM_Counter[index]=VM_Counter[index]+1;      //переходим на параметр приоритета выполнения
   
   u08 pr = VM_Load(VM_Counter[index]);      //приоритет выполнения
   
   u16 delay;                           //время задержки
   u08 timeh = VM_Load(VM_Counter[index]+1);   //старший байт записи времени
   u08 timel = VM_Load(VM_Counter[index]+2);   //младший байт записи времени
   
   delay = timeh*100+timel;               
   
   OS_TimerTask(delay, pr, VM_Next, index);   //загружаем функцию NEXT в очередь таймеров 
   
   VM_Counter[index] = VM_Counter[index]+3;    //перематываем указатель на следующую функцию процесса
   }

Как видно из куска байт кода, сразу после функции DELAY идёт пустышка - функция которая ничего не делает, и не может передвинуть счётчик процесса дальше, таким образом она будет вызываться вновь и вновь.

Когда счётчик функции VM_NEXT до тикает, она перемотает счётчик на начало следующей за пустышкой функции, и выполнение процесса продолжиться.

Код:

void VM_Next(u08 index)
   {
   
   VM_Counter[index] = VM_Counter[index]+2;   //перематываем указатель на следующую функцию процесса
   
   }

Сохранение числовых значений производится в многомерный массив VM_RAM. В проекте так же есть коряво написанные арифметические и логические функции, которые принимают в качестве параметров индексы строк и столбцов массива VM_RAM, не обращайте на них внимание =)

Для создания ветвлений и циклов, используются две функции VM_IF и VM_JMP,

JMP принимает в качестве параметра индекс байта массива VM_DATE на который нужно перепрыгнуть.

IF принимает в качестве параметра следующее:
1) Первое значение для сравнения (строка, столбец - массива VM_RAM)
2) Второе значение для сравнения (строка, столбец - массива VM_RAM)
3) Как сравнивать 0 - !=, 1 - ==, 2 - >=, 3 - <=, 4 - >, 5 - <
4) Индекс байта массива VM_DATE на который нужно перепрыгнуть если TRUE
5) Индекс байта массива VM_DATE на который нужно перепрыгнуть если FALSE

В приложенном файле проект с исходниками и примером, мигание двумя светодиодами с разной частотой.

KPG

matrex писал(а):

Ну а дальше – реализация логики работы робота из этих «кирпичиков» - функций высшего порядка - вне зависимости от типа шасси конкретного робота или индивидуальных параметров датчиков…
Как то так…

Не буду оригинален, но общепринятый базис простой и расширяемой виртуальной машины, зачастую,
можно построить и строится на использовании Forth (Форт) языкового подхода без избыточного базиса JVM
Например роботы Strobotics, ПЛК контроллеры ForthLogic и др. варианты

P.S. Базис слов-команд и есть тот самый базис кирпичиков "действий"
Пример базиса слов Max-Forth контроллера

_STRATEG_

Действительно интересно, жива ли тема, т.к. в этом году это вот третье сообщение только.

Raketoman, красиво расписал всё, хотел глянуть в файлики, а их в архиве нет почему-то :(.
В целом, не против бы тебе помочь раз уж что-то начал.

Напиши куда можешь

ICQ:353788400
Mail:strateg0793@mail.ru
Skype:strateg0793

Хотябы посовещаемся, уже проще должно быть.

P.S. Си эт хорошо, всё в асму никак не начну погружаться, пока было не нужно мне.

Raketoman

_STRATEG_ писал(а):

Действительно интересно, жива ли тема, т.к. в этом году это вот третье сообщение только.

Raketoman, красиво расписал всё, хотел глянуть в файлики, а их в архиве нет почему-то :(.
В целом, не против бы тебе помочь раз уж что-то начал.

Напиши куда можешь

ICQ:353788400
Mail:strateg0793@mail.ru
Skype:strateg0793

Хотябы посовещаемся, уже проще должно быть.

P.S. Си эт хорошо, всё в асму никак не начну погружаться, пока было не нужно мне.

Простите, действительно забыл закинуть в архив файлы проекта. Исправил.

_STRATEG_

Ничего так, хорошее начало проложено.

Синтаксис прикольный немного :-) Есть отступы у операторных скобак, но нету у кода в них.

Raketoman

Третий вариант моей ВМ. Стратег написал софтину, для транслирования программы с ассемблера устройства в байт код, но её выкладывать не стану так - как она не доработана.

Влад

Топик напомнил о таких штуках (только не надо спрашивать мнение о программировании, мне они были нужны чисто справочно, в чём люди могли бы кодить некие спецификации :)):

VYRep: http://vyrep.com/ - типа Студии для коллективной разработки, но специализированной для РТС;
Robot Operation System: http://www.ros.org/browse/list.php - среда взаимодействия библиотек различных разработчиков (предоставляет оригинальный интерфейс обмена типа "шины сообщений", как в БлэкБокс);
OpenCV: http://opencv.org/ - библиотека по машинному зрению.

Наверное, это так, как отправные точки. Учитывая, что неясно, можно ли реализацию в килобайты впихнуть... ;) В общем они так или иначе показались похожими на систему, описанную в этой статье:

http://www.cta.ru/cms/f/432219.pdf

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

Ещё можно такого рода сведения найти тут:

http://www.cta.ru/cms/f/342704.pdf

ну и тут, пожалуй:

http://www.cta.ru/cms/f/443117.pdf

P.S. Да, ещё книга такая:

http://forum.oberoncore.ru/viewtopic.php?p=79493#p79493

Может, на какие идеи натолкнёт...

ieremeev

Тоже хотел сказать про ROS, чем он не устраивает? Очень интересная и удобная штука. Море пакетов под нее и большое сообщество. Там вам и системы координат и команды для робота и много чего.

Easyelectronics.ru

Создаем ROBO_API

Кто сейчас на конференции