roboforum.ru

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

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

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

kran » 20 авг 2012, 00:23

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

Я не против даже в меру быть человеком-оркестром. Но я всё равно не буду барабанить на трубе и дуть в барабан. Не надо называть громким словом API то, что API не является. Есть кривая заготовка API, её надо допилить, и потом уже на допиленном API писать красивую понятную программу, прикладной код.

Если кто-то один за всех пятерых программистов работает, это вовсе не повод сваливать пять слоёв приложения в одну кучу! Если это происходит, значит программист не справился ни с одной из пяти ролей. Худо-бедно, но он должен реализовать все пять слоёв, с промежуточными интерфейсами, не нарушая принципов инкапсуляции. Не оправдываясь тем, что он тут один за всех, поэтому говнокод со спагетти навалил. Хочешь быть человеком-оркестром - играй по нотам, как положено, а то будешь человеком-какофонией.

Добавлено спустя 10 минут 58 секунд:
Duhas писал(а):Абсолютно согласен с Дмитрием, оно ж железяка.. это не то железо под которое на плюсах писать надо..

Да я не про то. И на чистом Си, незамутнённом объектной ориентированностью, можно (и должно) писать аккуратнее и правильнее. Не эксплуатируя "тёмную" сторону Си, тяжёлое наследство древних врёмен. Я ведь потом привёл пример, на Си, без всякого С++. Но насколько мой код понятнее - видно же? Вот так и надо писать. А остальной "мусор" надо заметать под ковёр. Чтобы не пришлось потом обильно усыпать каждую строчку комментариями, что в ней делается.

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

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

Dmitry__ » 20 авг 2012, 00:28

Хм, занятно.
Только твой приведенный код мне меньше понятен чем тот который:
Всем ведь очевидно, что вышеупомянутый код понятнее, чем вот такое:

И кто тебе дал право тратить столько памяти на отработку семафоров?
Это микроконтроллер а не ибм писи эйти, панимаш?

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

kran » 20 авг 2012, 00:39

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

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

Давайте возвращаться, ага.

Для чего полезен? Вот именно этот, железный рой? Да ни для чего, очевидно же (окромя научных целей). Поэтому я и говорю, что для этих самых научных целей достаточно программного симулятора. Вот для сложного робота, где на борту два сервера, не считая двухсот килограмм запчастей - там эмулятора недостаточно, ходовые испытания проводят на натуре. А для этих пимпочек с embedded софтом на 50 строчек логики (вряд ли будет больше) - вполне достаточно эмулятора.

Только мне не хотелось бы писать велосипед. Думаю, эмуляторов роя уже дофига всяких написано. Может ещё поискать готовый? И я не отчаиваюсь найти уже готовую программу для Килобота. Там тоже можно посмотреть "язык взаимодействия". Настоящий, в железном воплощении. Тогда можно будет сравнить с языком эмулятора и сказать: вот, очень похоже.

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

Angel71 » 20 авг 2012, 01:06

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

:) да, не шибко дёшево, зато у нас уже есть "естественный стимулятор".
Последний раз редактировалось Angel71 20 авг 2012, 01:18, всего редактировалось 3 раз(а).

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

kran » 20 авг 2012, 01:37

Dmitry__ писал(а):Хм, занятно.
Только твой приведенный код мне меньше понятен чем тот который:
Всем ведь очевидно, что вышеупомянутый код понятнее, чем вот такое:

И кто тебе дал право тратить столько памяти на отработку семафоров?
Это микроконтроллер а не ибм писи эйти, панимаш?

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

Добавлено спустя 26 минут 22 секунды:
Angel71 писал(а):здался вам этот киллобот. эмуляторов и алгоритмов в открытом доступе немало.
Килобот дался как раз тем, что это не эмулятор. Хочется сравнить, я же писал.
Может и немало, я что-то пока не нашёл приемлемого с открытыми исходниками. Хочется что-то типа Килобота, но чисто софтового.

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

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

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

Angel71 » 20 авг 2012, 01:48

в том-то и дело, что софтово для обкатки именно модели вводить "сонар" вводить вообще незачем.
Код: Выделить всёРазвернуть
/*
Shark hunting a swarm of boids.
Author: Nils Seifert (http://vimeo.com/nilsseifert)

The boids follow three basic rules:
- do not collide with neighbors/the borders of the screen
- try to swim in the same direction as the neighbors
- don't get eaten by the shark
Every boid has a heart beat (yellow). If the boid is stressed by the shark or by being compressed by its neighbors, the heart beat gets faster. If the boid has many direct neighbors, it gets bigger.

The shark has two rules:
- swim in the direction, where the most boids are
- try to avoid the screen borders
*/


int sWidth = 800;
int sHeight = 600;
int II;

int BOID_COUNT = 180;

class shark
{
  PVector pos;
  PVector speed;
  PVector[] path;
  int pathpointer;
 
  shark(float x, float y)
  {
    pos = new PVector(x,y);
    path = new PVector[30];
    for (int i=0; i<30; i++) path[i] = new PVector(0,0);
    float dir = random(PI*2);
    speed = new PVector(cos(dir)*2,sin(dir)*2);
  }
 
  void display()
  {
    stroke(255,20,0); strokeWeight(24);
    point(pos.x,pos.y);

    for (int i=1; i<30; i++)
    {
      int j = i+pathpointer; if (j>=30) j-=30;
      int jj = j+1; if (jj>=30) jj-=30;
      if ((path[j].x + path[j].y) !=0 && (path[jj].x + path[jj].y) !=0)
      {
        stroke(255,i*2,0,i); strokeWeight(2+i/1.5); //strokeWeight(2+i/20 + iCollide/8);
        //line(path[j].x, path[j].y, path[jj].x, path[jj].y);
        point(path[j].x, path[j].y);
       
        stroke(255,i,0,i*2); strokeWeight(i/4); //strokeWeight(2+i/20 + iCollide/8);
        //line(path[j].x, path[j].y, path[jj].x, path[jj].y);
        point(path[j].x, path[j].y);
      }
    }
   
    stroke(255); strokeWeight(12);
    point(pos.x,pos.y);
  }
 
  void update(boid[] bb)
  {
    pathpointer++; if(pathpointer==30) pathpointer=0;
    path[pathpointer].x = this.pos.x;
    path[pathpointer].y = this.pos.y;
   
   
    PVector boidHunt = new PVector(pos.x,pos.y);
    int BHC = 1;
    for (int i=0; i<bb.length; i++) {if (abs(bb[i].pos.x-this.pos.x)<240 && abs(bb[i].pos.y-this.pos.y)<240)
    {
      float dd = dist(bb[i].pos.x,bb[i].pos.y,this.pos.x,this.pos.y);
      if (dd<240)
      {
        boidHunt.x += bb[i].pos.x;
        boidHunt.y += bb[i].pos.y;
        BHC++;
      }
     
      if (dd<170)
      {
        strokeWeight(2); stroke(255,50,0,100-dd/1.4);
        //line(bb[i].pos.x,bb[i].pos.y,pos.x,pos.y);
        bezier(bb[i].pos.x,bb[i].pos.y,
               bb[i].pos.x-bb[i].speed.x*8,bb[i].pos.y-bb[i].speed.y*8,
               this.pos.x-this.speed.x*2,this.pos.y-this.speed.y*2,
               this.pos.x,this.pos.y);
      }
    }}
    if (BHC>0) {boidHunt.x /= BHC; boidHunt.y /= BHC;}
   
    PVector boidHuntNow = new PVector();
    boidHunt.sub(pos);
   
    boidHuntNow.set(boidHunt);
    boidHuntNow.normalize();
    boidHuntNow.mult(15);
   
    boidHunt.mult(0.02);
    pos.add(speed);
   
    speed.add(boidHunt);
   
    stroke(255,0,0); strokeWeight(8);
    point(pos.x+boidHuntNow.x,pos.y+boidHuntNow.y);
   
    stroke(255); strokeWeight(4);
    point(pos.x+boidHuntNow.x,pos.y+boidHuntNow.y);
   
    if (pos.y<0) {speed.y*=-1; pos.y=0;}
    if (pos.x<0) {speed.x*=-1; pos.x=0;}
    if (pos.y>sHeight) {speed.y*=-1; pos.y=sHeight;}
    if (pos.x>sWidth) {speed.x*=-1; pos.x=sWidth;}
   
    if (pos.y<50 && pos.y>0) {speed.y+=0.2;}
    if (pos.y>sHeight-50 && pos.y<sHeight) {speed.y-=0.2;}
    if (pos.x<50 && pos.x>0) {speed.x+=0.2;}
    if (pos.x>sWidth-50 && pos.x<sWidth) {speed.x-=0.2;}
   
    float speedxy = dist(this.speed.x,this.speed.y,0,0);
    this.speed.x *= 6/speedxy;
    this.speed.y *= 6/speedxy;
  }
}




class boid
{
  PVector pos;
  PVector speed;
  int iCollide = 0;
  int mood = 100;
  int m = 0;
  PVector[] path;
  int pathpointer;
  float stress=0;
 
  boid(float x, float y)
  {
    pos = new PVector(x,y);
    m = 2+(int)random(70);
    path = new PVector[10];
    for (int i=0; i<10; i++) path[i] = new PVector(0,0);
   
    float dir = random(PI*2);
    speed = new PVector(cos(dir)*2,sin(dir)*2);
  }
 
  void display()
  {
    stroke(stress*800+160,160-stress*400,160-stress*400,50+iCollide*6);
    if ((m>mood) || (m==0)) {
    strokeWeight(6 + iCollide/1.5);
    } else {
    strokeWeight(3 + iCollide/1.5);
    }
   
    point(pos.x,pos.y);
    mood = 200-iCollide*2-int(stress*1200);

    noFill();
    stroke(0,20); strokeWeight(2);
    beginShape();
    for (int i=1; i<10; i++)
    {
      int j = i+pathpointer; if (j>=10) j-=10;
      int jj = j+1; if (jj>=10) jj-=10;
      if ((path[j].x + path[j].y) !=0 && (path[jj].x + path[jj].y) !=0)
      {;
        curveVertex(path[j].x, path[j].y);
        //line(path[j].x, path[j].y, path[jj].x, path[jj].y);
        //point(path[j].x, path[j].y);
      }
    }
    endShape();
    //SPEED DISPLAY
    //stroke(255,0,0); strokeWeight(2);
    //point(pos.x + speed.x*8, pos.y + speed.y*8);
    //stroke(0); strokeWeight(3+iCollide/4); point(pos.x,pos.y);
    if ((m>mood) || (m==0)) {stroke(255,220,0); strokeWeight(iCollide/1.5);}
    else {stroke(255); strokeWeight(iCollide/2);}
    point(pos.x,pos.y);
   
    m+=2;
    if (m>mood) {m=0;}
   
    iCollide=0;
    stress=0;
  }
 
  void update(boid[] bb)
  {

    pathpointer++; if(pathpointer==10) pathpointer=0;
    path[pathpointer].x = this.pos.x;
    path[pathpointer].y = this.pos.y;
    for (int i=0; i<bb.length; i++) {if (abs(bb[i].pos.x-this.pos.x)<64 && abs(bb[i].pos.y-this.pos.y)<64 && bb[i]!=this)
    {
      float dd = dist(bb[i].pos.x,bb[i].pos.y,this.pos.x,this.pos.y);
      if (dd<64)
      {
        float ff = 1/dd;
        if (ff>1) ff=1;
       
        this.speed.x = this.speed.x*(1-ff) + bb[i].speed.x*ff;
        this.speed.y = this.speed.y*(1-ff) + bb[i].speed.y*ff;
        this.iCollide++;
        bb[i].iCollide++;
       
        if (dd<30) {this.speed.x -= (bb[i].pos.x - this.pos.x)/12;
                    this.speed.y -= (bb[i].pos.y - this.pos.y)/12;
                    //m+=3;
                   
                   }

        if (dd<33) {strokeWeight(2); stroke(0,20);
                    bezier(bb[i].pos.x,bb[i].pos.y,
                           bb[i].pos.x-bb[i].speed.x*8,bb[i].pos.y-bb[i].speed.y*8,
                           this.pos.x-this.speed.x*8,this.pos.y-this.speed.y*8,
                           this.pos.x,this.pos.y);
                    //line(bb[i].pos.x,bb[i].pos.y,this.pos.x,this.pos.y);
                   }
                   
      }
    }}
   
    float ddd = dist(S.pos.x,S.pos.y,this.pos.x,this.pos.y);
    if (ddd<140)
    { stress+=10/ddd;
      this.speed.x -= (140-ddd)/1500*(S.pos.x - this.pos.x);
      this.speed.y -= (140-ddd)/1500*(S.pos.y - this.pos.y); }
         
    pos.add(speed);
    if (pos.y<0) {speed.y*=-1; pos.y=0;}
    if (pos.x<0) {speed.x*=-1; pos.x=0;}
    if (pos.y>sHeight) {speed.y*=-1; pos.y=sHeight;}
    if (pos.x>sWidth) {speed.x*=-1; pos.x=sWidth;}
   
    if (pos.y<50 && pos.y>0) {speed.y+=0.2;}
    if (pos.y>sHeight-50 && pos.y<sHeight) {speed.y-=0.2;}
    if (pos.x<50 && pos.x>0) {speed.x+=0.2;}
    if (pos.x>sWidth-50 && pos.x<sWidth) {speed.x-=0.2;}
   
    float speedxy = dist(this.speed.x,this.speed.y,0,0);
    this.speed.x *= 2/speedxy;
    this.speed.y *= 2/speedxy;
   
   
  }
}

boid[] B;
shark S;

void setup()
{
  //frameRate(25);

  B = new boid[BOID_COUNT];
  for (int i=0; i<B.length; i++) {B[i] = new boid(random(sWidth), random(sHeight));}
  S = new shark(400,400);
 
  size(sWidth,sHeight);
  background(255);
  smooth();
}

void draw()
{
  //background(255);
  fill(255,30);
  noStroke();
  rect(0,0,sWidth,sHeight);
  noFill();
  stroke(255);
  strokeWeight(6);
  for (int i=0; i<B.length; i++) {B[i].update(B);}
  for (int i=0; i<B.length; i++) {B[i].display();}
  S.update(B); S.display();
}

вот эта милая моделька в почти 300 строк в случае портирования на железо легко и непринуждённо может разроститсь в несколько тысяч строк кода, если не вообще десятков тысяч. возьмём киллоботов, вы объём работ над эмуляцией физ. модели передвижения прикинули? меня совсем не штырит модели такой сложности прописывать.

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

d3xr » 20 авг 2012, 02:09

del
Последний раз редактировалось d3xr 29 апр 2013, 23:46, всего редактировалось 1 раз.

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

Nesenin » 20 авг 2012, 02:27


хах я на этой кафедре учился. и только когда начал работать, понял что надо было на 5 факультет идти.
чего и вам рекомендую. кстати у этих же тов. (те что в графе "Проверили") диплом делал. PS если интересно в ЛС могу написать почему стоить перевестись

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

Angel71 » 20 авг 2012, 02:29

что делает код, приведенный выше, визуально можно увидеть тут:
http://vimeo.com/11814992
http://www.4dcube.de/processing/shark_and_boids/

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

kran » 20 авг 2012, 03:25

Angel71 писал(а):в том-то и дело, что софтово для обкатки именно модели вводить "сонар" вводить вообще незачем.

Не надо путать эмуляцию роя с эмуляцией агента.
Код: Выделить всёРазвернуть
void update(boid[] bb)
Вот в чём "ошибка" (если говорить о эмуляции агента). Каждый агент легко и непринуждённо узнаёт координаты всех других агентов (и всё-всё-всё про других агентов). А это в корне неправильно. Неправильно именно в контексте эмуляции агента. Потому что здесь эмулируется рой в целом, а не отдельный агент.

Я, когда писал свою экспериментальную "игрушку", специально передавал одному юниту только массив координат тех агентов, которые находились в его поле зрения. Так я эмулировал "туман войны". И не ссылки передавал, и именно координаты. Т.е. один юнит не мог знать, что видят или думают другие юниты, какое решение они приняли, в каком режиме/состоянии они находятся, куда направляются. Юнит просто "видел" других юнитов (и то это было не совсем правильно, потому что ближайшие юниты не закрывали дальних своим телом).

Angel71 писал(а):вот эта милая моделька в почти 300 строк в случае портирования на железо легко и непринуждённо может разроститсь в несколько тысяч строк кода, если не вообще десятков тысяч. возьмём киллоботов, вы объём работ над эмуляцией физ. модели передвижения прикинули? меня совсем не штырит модели такой сложности прописывать.

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

Это "плохой" эмулятор роя агентов. Просто потому что он изначально не писался как эмулятор железа. Не знаю как толково объяснить.

Настоящий эмулятор должен прежде всего среду обитания агентов эмулировать. И предоставлять каждому агенту лишь малую часть информации об этой среде - в пределах его органов чувств, ровно столько, сколько пролезет через датчики агента. Да, это сложнее, чем 300 строчек. Может быть это 3000 строчек. Но это легче, чем 30000 строчек плюс железо.

В архиве килобота десятки *hex, *.dll, *exe файлов. Вот это точно тысячи строк кода. При этом многие строчки этого кода жёстко связаны с железом. У них совсем другая цена, трудоёмкость. Это долгие человек-дни отладки, причём отладки на железе, а не на эмуляторе. Это неудобно, это элементарно МЕДЛЕННО, долго и нудно. Я тут немного понаезжал на железячников, но я прекрасно понимаю, насколько труднее пишется их код, как они стиснуты разнообразными ограничениями.

Софтовые эмуляции тем и привлекательны, что они эмулируют не только железо, но и код для этого железа. При этом софтовая эмуляция может быть 3000 строк, и заменять собой 300 строк кода для микроконтроллера. Но оно того стоит - у этих строк разная цена. А код логики вообще может занимать 30 строчек. Но за этими строчками - годы работы поколений гениальных математиков. И может быть даже биологов, которые открыли то, над чем природа сотни миллионов лет работала. Вот такая цена у этих строчек.

Добавлено спустя 26 минут 50 секунд:
d3xr писал(а):Вот курсовая работа "Трассировка межсоединений печатных плат с использованием алгоритма пчелиных колоний", финальный вариант потерялся, это можно сказать предрелиз http://vk.com/doc16679610_122495480?has ... 017be85861

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

Чтобы эмулировать язык взаимодействия, нужен некий физический барьер.
Вообще язык - это средство преодоление каких-то физических барьеров. Иначе бы мы просто мысли передавали, без потерь на время и расстояние, без барьеров взаимопонимания.

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

Кстати, потому и время работы алгоритма неудержимо растёт. В жизни так не бывает - не может за танцем каждой пчелы наблюдать весь улей. Этот танец видит только несколько соседей одной танцующей пчелы. Поэтому весь улей "не зависнет" в бесконечных вычислениях оптимального облёта поля, каким бы большим оно не было :)

Добавлено спустя 3 минуты 46 секунд:
Поэтому, ещё раз - "дальномер" эмулировать программно надо обязательно. Можно косвенно, через уменьшение чувствительности какого-нибудь датчика, через ухудшение качества связи. Уж совершенно точно через ухудшение видимости. Вплоть до полной невидимости за пределами некоего радиуса. Если этого не делать, ни о каком переносе на железо и речи быть не может. Или это какое-то слишком идеальное железо, или все софтовые наработки на эмуляторе придётся выкинуть и переделать.

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

Dmitry__ » 20 авг 2012, 03:25

Я или не догоняю или одно из двух, как можно софтово эмулировать железяку? В реальной жизни, моментов - море. Они будут по-разному вести себя в жизни и на компе.
А килобот по изготовлению подьемный, если есть hex и нет исходников, то один жопамесяц дизассемблирования и исходник есть :)
По плате: спроектировать под автоматическую набивку smd и шлепать по цене муки.
Понять бы что полезного с ними можно делать на столе :oops:

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

kran » 20 авг 2012, 03:59

Dmitry__ писал(а):Я или не догоняю или одно из двух, как можно софтово эмулировать железяку? В реальной жизни, моментов - море. Они будут по-разному вести себя в жизни и на компе.

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

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

Именно поэтому, вот именно этих железных агентов очень легко можно эмулировать. Это возвращение к истокам, так сказать.

Dmitry__ писал(а):А килобот по изготовлению подьемный, если есть hex и нет исходников, то один жопамесяц дизассемблирования и исходник есть :)
По плате: спроектировать под автоматическую набивку smd и шлепать по цене муки.
Понять бы что полезного с ними можно делать на столе :oops:

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

Добавлено спустя 21 минуту 40 секунд:
"Очень легко", в смысле эмулировать железо - это я пожалуй переборщил, да. Там например такие вещи обрабатываются, как коллизии при одновременном приёме агентом сообщений от разных агентов. Checksum передаётся, чтобы проверить целостность сообщения. В общем, есть тонкости.

Но. Это относительно легко. Относительно жопомесяца дизассемблирования. Тем более относительно долгих месяцев проектирования железа с нуля.
И килобот очень хорошая подсказка, что и как эмулировать, кстати.

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

Dmitry__ » 20 авг 2012, 04:05

В комментариях к килоботам были интересные фантазии.
Елочные игрушки и живые рекламные плакаты из килоботов.
А от роя пчел и муравьев и в жизни толку мало. Один экскаватор больше сделает :crazy:

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

Да одно падение бота - убийственная задача эмуляции, или грязь/неровность на столе.

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

kran » 20 авг 2012, 04:28

Dmitry__ писал(а):В комментариях к килоботам были интересные фантазии.
Елочные игрушки и живые рекламные плакаты из килоботов.
К сожалению, мне чаще другие планы реализации попадались. Умные мины, заделывающие проход, проделанный минёрами или подорвавшимися солдатами. Роботы-буйки, которыми засеивают весь мировой океан, чтобы ловить подводные лодки. Экскадрильи дронов на солнечных батареях, точно также равномерно захватывающие седьмой океан, чтобы ни одно неосторожное движение граждан не оставалось безнаказанным, для их же безопасности. Умный песок и умная пыль, которая будет видеть и слышать вообще ВСЁ. И прочие такого вот плана фантазии в духе Скайнет. Ёлочные игрушки... хе-хе... тоже поди в ФСБ настучат, сколько я выпил со Снегурочкой на брудершафт, и про кого ей анекдоты травил :)

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

А вот программно я пожалуй смог бы грязь эмулировать. Моторчик жужжит, а скорость падает - всё, застряли. Эмулируется на раз. Задаём некий контур, периметр, называем эту фигуру "грязь", и сравниваем координаты, кто туда попал. Просто же. Да и падение пожалуй просто - резко меняем координаты, типа отскочили куда-то, укатились. И потом сколько не жужжи мотором - будешь лежать или рандомно вращаться. Ну не будет совпадать с реальным вектором падения или реальным движением на боку. А оно принципиально так важно? Имхо нет.

Dmitry__ писал(а):А от роя пчел и муравьев и в жизни толку мало. Один экскаватор больше сделает :crazy:
Мне почему-то кажется, что куча муравьёв, по весу сравнимая с экскаватором, унесёт куда больше грунта. Но это не достоинство роевого интеллекта, это достоинство продвинутого железа муравьёв, которое они апгрейдили не один миллион лет. Вопрос только в том, как с согнать в одно место 20 тонн муравьёв, и как объяснить им, что такое кубометр... Да, и ещё - как заставить их пить бензин.

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

Dmitry__ » 20 авг 2012, 05:42

Блин, накатал такую портянку и робофорум сдох :cry:


Rambler\'s Top100 Mail.ru counter