roboforum.ru

Технический форум по робототехнике.

Управление "роем"

Re: Управление "роем"

Angel71 » 19 авг 2012, 07:43

:) от вы шутник. примерно 10*10см или 10*15см имхо вполне неплохой вариант для дома.

Re: Управление "роем"

kran » 19 авг 2012, 10:25

Angel71 писал(а):без конкретной задачи обсуждать это смысла мало. непонятно как минимум какие нужные датчики.
Про задачу я неоднократно спрашивал, вот ответ:
setar писал(а): топик был заведен для получения информации что такое вообще рой, и как он "работает".
Чтобы ответить на этот ответ, настоящих железных агентов имхо не стоит строить. Нужен эмулятор роя. И желательно с открытым кодом, чтобы ответ был не в общих фразах, а в конкретном примере. Надо гуглить "ant simulator" или "swarm simulator", во вкусу добавляя что-то типа "open sources".

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


Я даже не против попробовать что-то такое написать самостоятельно. Красиво, впечатляет.

Добавлено спустя 1 час 10 минут 2 секунды:
Это написано на Processing, есть такой язык (по сути это Java). Со своей IDE, которая PDE называется. Похожа на Arduino IDE (точнее, наоборот, поскольку последняя унаследована от первой). Хотя мне было бы привычнее использовать что-то более традиционное, типа Eclipse, и такая возможность вроде бы есть - http://christian.liljedahl.dk/guides/processing-and-swt-in-eclipse

Re: Управление "роем"

Nesenin » 19 авг 2012, 16:58

kran писал(а):Цитирую статью по вашей ссылке:
Кстати, полную цену новинки швейцарцы пока не называют, упоминая лишь, что боты — недорогие.

Вот, назвали "полную цену" чуть попозжа - в той статье, на которую я дал ссылку. Там переписка ну с самым что ни на есть первоисточником.
Ценообразование - это такая тонкая вещь... Я вот тоже считал комплектующие PR2 по отдельности, и у меня ну никак $400000 не получалось.

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

Добавлено спустя 10 минут 7 секунд:
Nesenin писал(а):при наличии навыков\знании\инструментов, можно за день заказать все комплектующие, развести плату, заказать ее изготовление и обозначить планы на монтаж.

Кто-то про контроллер имхо забыл. И зарядник. Вроде ерунда, а тоже время и деньги. Монтаж тоже не один день, потом тестирование. Что-то ещё испоганить можно при монтаже. Какие-то баги в железе вылезут не один раз, не один раз всё переделывать. Не знаю, мне кажется дешевле 60 тысяч рублей всё это не обойдётся, особенно учитывая время работы такого специалиста. Можно, конечно, сказать, что он для себя это делает, как хобби, бесплатно. Но так вроде не совсем честно.

какое нам дело по какой цене продают швейцарцы?
конструкция там ерунда. и зарядка ерунда .
Изображение
источник напряжения 6В. Бортовой контроллер заряжает этот Li-pol аккумулятор (часовая "батарейка" с материнской платы каждого ПК).
нам даже собирать ничего не надо. все можно заказать на производстве как изготовление печатной платы.
например http://rezonit.ru/contract/ тут вам и платы изготовят и монтаж поверхностных элементов\выводных сделают и проверят если надо. все на спец. оборудовании.
на выходе получите готового Kilobot. цена будет зависить от объемов. в идеале можно заказ в китае разместить. возможно даже быстрее сделают( за счет близости всех компонентов).

Добавлено спустя 11 минут 10 секунд:
ftp://ftp.deas.harvard.edu/techreports/tr-06-11.pdf
Atmega328 там стоит. кварц внутренний.

Добавлено спустя 45 минут 9 секунд:
ахах. дык это открытый проект!
http://ssr.wikidot.com/kilobot-documents
вот архив со всеми исходниками всех частей, включая зарядку и различное ПО
http://www.eecs.harvard.edu/ssr/project ... uments.zip
This zip file contains the following..
1. Kilobot user guide, which describes how to build, configure, and program the Kilobot system.
2. Skeleton code for Kilobot
3. Code for the overhead controller
4. Code for the calibration board
5. Software to operate the overhead controller
6. Documents nessicary to build the robots, overhead controller, and calibration board. These include pcb files, Bill of material, and Schematics.

покопался я. тут есть все. и схема программатора (с использованием ИК) и все детали. даже отдельные файлы для станков (металлизация, маски, отверстия).хоть сейчас в производство отправляй.

Re: Управление "роем"

Angel71 » 19 авг 2012, 19:51

чёрный юмор: проблема недорогого навороченного мелкоробота решена

Re: Управление "роем"

kran » 19 авг 2012, 21:08

Nesenin писал(а):покопался я. тут есть все. и схема программатора (с использованием ИК) и все детали. даже отдельные файлы для станков (металлизация, маски, отверстия).хоть сейчас в производство отправляй.
Я тоже покопался. Скорее всего, с точки зрения железячника всё сделано на высшем уровне, это я не могу оценить, полагаюсь на ваше мнение. Но с точки зрения программиста...

Есть куча *.dll, *.lib, есть "KiloBot Controller.exe". А исходников на всё это добро нет.
Есть куча *.hex файлов - это же тоже что-то откомпилированное. Исходников тоже нет.

Я как-то уже сильно сомневаюсь, что проект полностью открытый. В этом архиве должны быть или исходники на всё вышеперечисленное, или ссылка на открытый репозиторий кода, типа github. Может на сайте есть? Но по-моему такие вещи прямо в Readme надо писать, этих Readme в архиве много. А в них ссылки только на лицензию (ну открытая, ну и что? - это как валяющийся на дороге ключ от замка, который хрен знает где) и на сайт. На сайте исходников тоже пока не нашёл. Там кстати полно приватных страниц. Может если зарегиться, то дадут доступ. Но как-то это не очень на open sources похоже.

Единственный исходник, который откопал в архиве - KilobotSkeleton.c, вот фрагмент:
Код: Выделить всёРазвернуть
if(special_mode_message==0x01)
{
   //stop motors and ir led
   OCR2B = 0x00;
   OCR2A = 0x00;
   PORTD &= ~(1<<4);
   enable_tx=0;
   TCCR0B=0x00;//turn off timer0
   asm("jmp 0x7000");//jump to bootloader
}
if(special_mode_message==0x02)
{
   enable_tx=0;
   wakeup=0;
   enter_sleep();//will not return from enter_sleep() untill a special mode message 0x03 is received   
}
if((special_mode_message==0x03)||(special_mode_message==0x04))
{
   //wakeup already set to 1 in timer1 interrupt

   //special_mode=0;
   set_color(0,0,0);
   OCR2B = 0x00;
   OCR2A = 0x00;
   PORTD &= ~(1<<4);
   enable_tx=0;
   while(special_mode==0)//loop untill another special mode message is received
   {   
      set_color(7,7,0);
      _delay_ms(10);
      set_color(0,0,0);
      _delay_ms(1000);


   }
   enable_tx=1;

}

Ассемблерные вставки, магические константы... Это же кошмар программиста.
Причём всё это в main(). Прямо иллюстрация "как не надо писать программы".

Описание API - смех один. Как передать int или string ещё понятно, но как получить...
Код: Выделить всёРазвернуть
//get_message();
//take oldest message off of rx buffer
//message is only new if message_rx[5]==1 !
//if so, message is in message_rx[0],message_rx[1]
//distance to transmitting robot (in mm) is in message_rx[3]
//Example:
get_message();
if(message_rx[5]==1)
{
   data=message_rx[0];
   distance=message_rx[3];
}

Ну что, всё понятно? Получили int, получили string, ага. А теперь попробуйте угадать, data это int, или первый символ string, или размер string.
Это не API, а какая-то нелепая заготовка API, над которой ещё работать и работать, дописывать и переписывать.

Поясняю - если есть функции kprinti (пишущая int) и kprints (пишущая string), то должны быть kreadi, kreads (читающие int и string). И всё равно это ещё промежуточный слой. На верхнему уровне должна быть отправка пакетов с какой-то внутренней структурой, состоящей из нескольких string и int. Я говорю о пакетах прикладного уровня. А здесь пакет самого низкого уровня, уровня передачи - он из 6 int состоит. Даже значение каждого из этих 6 int не расписано нормально - это просто массив int[6]. Ну нельзя же так. По сути, отсутствует описание протокола передачи, и нет функций-обёрток. И как с этим работать?

Самое печальное - это скелет программы, а не готовая программа.
Вот купили вы этот рой, откалибровали, настроили, загрузили все *.hex - а хрен, ничего не работает. Т.е. рой не ведёт себя как рой. По командам контроллера всё работает - агенты дружно вертятся на месте, дружно мигают светодиодом. Но ничего умного они сделать не могут, никакого роевого интеллекта в них не заложено. Пустышки.

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

Re: Управление "роем"

Dmitry__ » 19 авг 2012, 21:21

Хм, я увидел только одну асмовскую вставку - прыжок на бутлоадер, совершенно нормальный стиль.
Еще обьяснять кривому компилятору где бутлоадер...

Re: Управление "роем"

kran » 19 авг 2012, 21:40

Dmitry__ писал(а):Хм, я увидел только одну асмовскую вставку - прыжок на бутлоадер, совершенно нормальный стиль.
Еще обьяснять кривому компилятору где бутлоадер...
Возможно, мне надо было ещё несколько примеров "нормального стиля" подкинуть:
Код: Выделить всёРазвернуть
asm volatile("nop\n\t");
asm volatile("nop\n\t");

Или вот:
Код: Выделить всёРазвернуть
asm volatile("wdr\n\t");
SMCR|= (1<<SE);
asm volatile("sleep\n\t");

Там такого добра много.

Поймите правильно - для железячника, который с микроконтроллерами работает, это может и нормально - работа вручную с регистрами, работа с битовыми флагами смещением... Но для людей, которые пишут на Java, на C++, на C# - это же полный бред. Даже если без таких вещей не обойтись, их надо прятать в функции или макросы, которые надо убирать из файла программы. Это библиотечные функции должны быть, глубоко закопанные под API. А тут они наружу торчат.

Даже на аккуратном Си так не пишут. Я даже аккуратный ассемблер видел, где все концы спрятаны, и код выглядел очень понятным - это мне-то, которому ассемблер вообще незнаком. Я там кое-что подправил, откомпилил, первый раз в жизни запустив ассемблер - и всё заработало. Вот что значит хороший стиль программирования. А здесь всё мрачно.

Повторюсь, главного-то нет - самой программы агента. Только пустой скелет.

Re: Управление "роем"

Dmitry__ » 19 авг 2012, 21:50

Ну, дык, программирование и делится на программирование железа (оно у вас есть в роботе?) и программирование остального.

kran писал(а):asm volatile("nop\n\t");

Совершенно нормально, чтоб компилятор не убрал нужный ноп после определенных настроек железа (ну надо так)
kran писал(а):asm volatile("wdr\n\t");
SMCR|= (1<<SE);
asm volatile("sleep\n\t");

Вот яркий пример программирования железа.
Не знает СЫ всех прелестей жизни...

Если тебя это пугает, значит вас должно быть 2: Ембеддед программист и программист белоручка.

Добавлено спустя 2 минуты 8 секунд:
kran писал(а):Даже если без таких вещей не обойтись, их надо прятать в функции или макросы, которые надо убирать из файла программы.

Нельзя спрятать прыжок на бутлоадер в функцию, т.к. потом этот бутлоадер делает харакири всем стекам и кучам СЫ :)

Re: Управление "роем"

Nesenin » 19 авг 2012, 21:50

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

Re: Управление "роем"

Duhas » 19 авг 2012, 22:01

kran писал(а):Возможно, мне надо было ещё несколько примеров "нормального стиля" подкинуть:

Абсолютно согласен с Дмитрием, оно ж железяка.. это не то железо под которое на плюсах писать надо..

Re: Управление "роем"

Angel71 » 19 авг 2012, 22:31

kran, не бойтесь ассемблерных вставок :) в одном из вариантов это отличный способ оптимизации кода или возможность добраться до чего-то, что невозможно/затруднительно другими способами. в том же c# асмовские вставки (в данном случае я совсем не про il ассемблер) это не " :shock: ааааааааааааааааааа" - когда они действительно нужны, использовать их совсем не проблема.
почему же я выше и писал, что очень мелкие не очень хороший вариант для начала экспериментов. делаем "чуть" поболее, чем cr2032 и уже прекрасно влезет хоть простенькая мега, хоть арм, хоть mitx мать c десктопным процом + намного проще датчики всякие и на поряки более ёмкий акум.

Re: Управление "роем"

boez » 19 авг 2012, 22:54

А я соглашусь с kran - не должно быть видно асмовых вставок в main! Токо не надо путать "не видно" и "не используется". Должно быть какое-нить HalWaitOneTick() и HalResetWDAndSleep(), обычные сишные макросы. Пусть оно внутри содержит те же асм вставки - и hex в итоге получится тот же самый с точночтью до байта, но писать в main asm() - чересчур.

Re: Управление "роем"

Angel71 » 19 авг 2012, 22:55

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

повозится с алгоритмами у меня желание есть, но абсолютно нет идей для чего полезного можно применить. да, можно мелких на вибрах наклепать, пусть в лабиринте выход ищут или ещё чего подобное. но лично мне такое не интересно, это всё можно и без железа реализовать. это вообще хоть в виде скринсейвера ( :oops: я его уже начал делать)

Re: Управление "роем"

kran » 19 авг 2012, 23:12

Dmitry__ писал(а):Ну, дык, программирование и делится на программирование железа (оно у вас есть в роботе?) и программирование остального.
Если тебя это пугает, значит вас должно быть 2: Ембеддед программист и программист белоручка.
Ясен перец, что программистов должно быть два. API (интерфейс прикладного уровня) - это то, что разделяет работу embeded программиста, и прикладного программиста. Только в данном случае embedded программист схалтурил, и на места его халтуры я и указываю. API кривой, документация на API крайне неполная. Я, как программист-прикладник, крайне возмущён :) И каждый программист "белоручка" меня поймёт, надеюсь. А некоторые embeded программисты будут защищать собрата, типа "да и так сойдёт".

Dmitry__ писал(а):
kran писал(а):Даже если без таких вещей не обойтись, их надо прятать в функции или макросы, которые надо убирать из файла программы.
Нельзя спрятать прыжок на бутлоадер в функцию, т.к. потом этот бутлоадер делает харакири всем стекам и кучам СЫ :)
Я же написал - "в функции ИЛИ МАКРОСЫ". Я понимаю, что не всё можно запихать в функцию. Хотя в данном случае, если постараться... Есть соглашения о вызовах, где можно стека избежать. Есть такие функции, которые не предусматривают возврата из них. С этим в Си всё нормально, не надо на него капать.

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

Ладно, без обид, это вечный спор железячников и "белоручек", не будем холивар разводить. Пришли вроде к общему мнению, что это пока заготовка, именно как заготовка она совсем не плоха, может даже и вполне себе хороша. Работать с этим можно, но вот именно что надо не просто дорабатывать, а "с нуля" (со скелета) писать готовую программу. Потому что программы-то там и нет. Никакой логики роя нет ещё пока. С этим моим умозаключением все согласны, товарищи железячники?

А на счёт того, что такие вещи на C++ не пишут... Ну вообще-то надо к этому стремиться (и даже к более высокоуровневым языкам, скриптовым, специальным, заточенным под прикладную область). С++ потом можно транслировать в Си, который AVR прожуёт. Программа от этого только выиграет, по-моему, в смысле понятности для простых смертных. Опять же, если места в памяти будет мало, и оптимизирующий компилятор не справится, то квалифицированный embedded программист может вручную оптимизировать то, что "накорявит белоручка".

В данном же конкретном случае я не против писать на аккуратном Си. Где все магические константы и ассемблерные вставки будут определены через макросы, снабжены понятными комментариями. Аккуратный Си очень похож на C++, вместо классов можно делать структуры с функторами, и разница почти незаметна. Прикладник должен иметь возможность писать как-то так (очень примерно):
Код: Выделить всёРазвернуть
turn(LEFT, 5);
int red1 = saw_light(RED);
if (red1 > red0)
{
   say("Saw %s %d", RED, red1);
   move(FORWARD, 10);
}
else
{
   turn(RIGHT, 10);
}

А если вместо этого расставлять битовые флаги со смещением, ассемблерные вставки делать, массивы заполнять... За всем этим очень сложно будет увидеть чистую логику поведения. Неужели тут есть желающие с этим поспорить? Всем ведь очевидно, что вышеупомянутый код понятнее, чем вот такое:
Код: Выделить всёРазвернуть
kprints("Saw ");
kprints(RED);
kprints(", ");
kprinti(itoa(red1));

set_motor(cw_motor,ccw_motor);
_delay_ms(10 * 1000);
set_motor(0,0);
Это я ещё не весь фрагмент искорявил, а только содержимое секции if, где всего две строчки.

Re: Управление "роем"

Dmitry__ » 19 авг 2012, 23:50

kran писал(а):Ладно, без обид, это вечный спор железячников и "белоручек", не будем холивар разводить. Пришли вроде к общему мнению, что это пока заготовка, именно как заготовка она совсем не плоха, может даже и вполне себе хороша.

Вот и фигушки :)
Тогда тебе еще нужны: механики, электронщики, 5 типов программистов, 3д модельщики и.т.д.
Вот ты и не доведешь начатый проект, т.к. от совмещенного программиста ембеддед/белоручка тебя колбасит, в 3д моделировании не бум-бум и электронщик - никакой, а сколько было замыслов...
Вот твой топор и не заварится. Ты должен быть человеком-оркестром :)


Rambler\'s Top100 Mail.ru counter