Architektura

Czy poniższa interpretacja dotycząca sensorów, sygnałów i animatów jest prawidłowa ?

Animat tworzy Sygnały, które są przekazywane do Sensorów i przez nie obsługiwane.

Aktuatory mogą być modyfikowane przez Sensory, modyfikują Animaty i siebie podczas aktualizacji.

(mjoach) Nie. Z grubsza rzecz biorąc, sygnały modelują dyfundujące związki chemiczne, czyli typowe sensory są zmysłem węchu stwierdzającym koncentrację danego związku. Przy czym przypominam, że nie modelujemy dyfuzji indywiduowo (jako pływające cząsteczki) tylko po prostu oceniamy jak daleko znajduje się źródło (bo nie stać nas zrobić to inaczej). Jeśli zrobić to odpowiednio elastycznie, to można wtedy takie sygnały wykorzystać też do innych rzeczy, np. sygnalizować binarnie czy w jakimś promieniu znajduje się osobnik naszego gatunku czy też nie. Czyli: animaty (albo też jakieś obiekty w otoczeniu) wysyłają sygnały o pewnym ograniczonym zasięgu, które są postrzegane przez sensory innych animatów. Sygnały nie są ukierunkowane i są broadcastami. Ewolucja się zaś martwi, żeby sensor był dopasowany do danego źródła sygnału i na niego w ogóle reagował.

Aktuatory nie są bezpośrednio modyfikowane przez sensory. Przepływ informacji w animacie jest taki: sensor->kontroler animata->aktuator. Czyli: wejście->przetwarzanie->wyjście. Animat ma sensory, środowisko dba o uaktualnienie ich pobudzenia, a następnie zewnętrznie dostarczony kontroler animata patrzy na nie i na tej podstawie uaktualnia aktuatory. Aha, kwestia nomenklaturowa - sygnał emitowany przez animata to formalnie rzecz biorąc też aktuator - bo w ten sposób kontroler wywiera wpływ na świat zewnętrzny no i może chcieć sam kontrolować na jakim poziomie wysyła sygnał w danym momencie. Ale implementujcie sygnały chemiczne jak Wam wygodnie tj. jako osobne klasy albo podtyp aktuatorów.

Aktualizacja świata:

1. Dla każdego animata, wywołujemy metodę aktualizacji animata
   • Animat może wysłać sygnały do sensorów ( być może wywołując jakąś metody sensorów przypisanych do animata, np. zwracające sygnał, #18 ) (mjoach) w sensie nadaje w eter i są odbierane przez sensory innych stworów, patrz wyżej
   • (lRem) Sygnały mogą być wysyłane również przez inne obiekty, choćby wspomniane już drobinki jedzenia.
     • (mceier) Założyłem, że drobinkami jedzenia mogą być animaty, ale możemy stworzyć interfejs dla drobinek jedzenia, dodać listę jedzenia do świata, oraz stworzyć przykładowy sensor który szuka najbliższego jedzenia ( zamiast najbliższego animata będącego jedzeniem :p )
       • (mjoach) kosmetyka, ale chyba będzie najprościej jak takie drobinki to będzie strywializowany animat po prostu, nie mający sensorów a tylko źródło sygnału. Wtedy zżeranie jedzenia czy innych animatów będzie traktowane jednakowo.
         • (mceier) To chyba będzie najlepsze rozwiązanie

1. Dla każdego sygnału wysłanego przez animaty, dla każdego sensora, wywołujemy metodę obsługi sygnału
   • Jeżeli sensor nie obsługuje sygnału to nic nie robi
   • Jedyna sensowna optymalizacja jaka przychodzi mi na myśl, to rejestracja sensorów dla konkretnych typów sygnałów
     • Sygnał posiada typ/id/kategorię/cokolwiek
     • Lista list sensorów sygnału o konkretnym typie/id/kategorii
     • Lista sensorów pusta => ignorujemy sygnał
     • Inne ogólne rozwiązania wymagają przejrzenia wszystkich sensorów
     • (lRem) Nie wiem czy to nie będzie przedwczesna optymalizacja.
       • (mceier) od tej optymalizacji zależy jak zaprojektujemy rejestrację sensorów i aktuatorów ...
         • (mjoach) proponuję żeby dla maksymalnej elastyczności zrobić tak, że będziemy zewnętrznie dostarczać do systemu funkcję, która dla danej instancji sensora oraz sygnału mówi czy w ogóle reagują na siebie, a jeśli tak, to z jakiej maksymalnie odległości (ważne). Na tej podstawie zbuduje się optymalizacje pozwalające unikać ciągłego sprawdzania reagowania każdego sensora na każdy sygnał w systemie, np. w momencie konstrukcji nowego animata sprawdzać jakimi sygnałami ma się w ogóle interesować. Prosta implementacja tej funkcji na start byłaby taka, że sensor oraz sygnał mają ID, jak ID się zgadza to sensor reaguje. Funkcja od razu liczyłaby też pobudzenie sensora, czyli np. poziom sygnału przez kwadrat odległości. Funkcja schowa całą złożoność wynikającą z różnych możliwych koncepcji sensorów i sygnałów, a Wy będziecie myśleć o nich tylko jako o parach, które reagują ze sobą lub nie i odległości od której należy brać pod uwagę interakcję.
   • Sensor może wysyłać sygnały do aktuatorów ( #12 )
     • (lRem) Oj nie... Spięcie sensorów i aktuatorów będzie chyba wykonane przez inny program (algorytm ewolucyjny)? W każdym razie ja tak zrozumiałem poprzednie rozmowy, że zwierzątkami będzie sterowało AI spoza naszego systemu.
       • (mceier) To są szczegóły konkretnej implementacji sensora / aktuatora - jak reaguje na sygnał, czy jest tam AI czy coś innego. Jeżeli sensor nie może wysyłać sygnałów do aktuatorów, to aktuatory nie muszą obsługiwać sygnałów, i następny punkt można usunąć, wtedy zakładamy, że sensor steruje bezpośrednio aktuatorami.
         • (mjoach) nie, nie, sensory są głupie, one tylko czytają poziom sygnału, nic poza tym. Tak jak napisał lRem, resztę robi funkcja sterująca animatem, ona bierze na wejście stan sensorów i wypluwa nowy stan aktuatorów. W praktyce często sensor jest sprzężony praktycznie bezpośrednio z aktuatorem ( http://en.wikipedia.org/wiki/Braitenberg_Vehicles ), ale to wszystko jest ukryte w funkcji sterującej.

1. Dla każdego sygnału wysłanego przez sensory, dla każdego aktuatora, wywołujemy metodę obsługi sygnału
   • Jeżeli animat nie obsługuje sygnału to nic nie robi
   • Uwaga odnośnie optymalizacji taka sama jak we wcześniejszym punkcie
2. Dla każdego animata, dla każdego aktuatora animata, wywołujemy metodę aktuatora aktualizującą animata
3. OPAL->update()
   • Czy w tym miejscu powinna znajdować się aktualizacja fizyki, czy może na początku lub końcu aktualizacji świata ?

• (magic) ja myślę ze aktualizacja świata powinna być po aktualizacji aktuatorów (najpierw musimy wiedzieć jakie siły napędowe działają na animata, a później obliczać zmiane jego położenia i wektora ruchu)
• (mceier) doczytaj do końca ... "aktualizacja świata" zmieniła się kilka razy :)

1. Dla każdego aktuatora, wywołujemy metodę aktualizacji aktuatora

(mjoach) klaruję jeszcze raz - sensory są bierne, odbierają sygnały, nie wysyłają. Źródła sygnałów można natomiast uważać za rodzaj aktuatorów. Sensor = zmysł, a więc wejście, aktuator = wyjście, czyli wszystko czym mózg wpływa na świat zewnętrzny. Czyli raczej tak:

1. Dla każdego sensora każdego animata wywołujemy metodę uaktualniającą poziom jego pobudzenia, będący sumą pobudzeń od wszystkich sygnałów na które reaguje (zależne od siły sygnału i odległości)
   • później dokładamy optymalizacje polegające na tym, że sygnały mają ograniczony zasięg oraz nie każdy sensor reaguje na każdy sygnał
2. Dla każdego animata, wywołujemy metodę aktuatora aktualizującą animata
   • ona zajmuje się uaktualnieniem jego aktuatorów na podstawie jego sensorów
3. Update fizyki

#12 "(...) przegląda wszystkie obiekty w systemie w celu przejrzenia ich stanu ich sensorów, samodzielnie oblicza nowe sygnały dla aktuatorów (...)":

• sygnały tworzy programista na podstawie danych z sensora, a aktuatory je obsługują

(mjoach) damnit, chyba widzę potencjalne źródło konfuzji. Sygnały chemiczne, które sensory mogą odbierać to esencja systemu, mechanizm przez który animaty widzą świat. Jak pisałem o obliczaniu nowych sygnałów dla aktuatorów, to chodziło jedynie o ustawienie siły z jaką działa aktuator w następnym kroku symulacji fizyki. Tak jak mówimy, że mózg wysyła sygnały do mięśni (które są naszymi aktuatorami). Mam nadzieję, że to jest jasne teraz.

#18 "(...) sensor reaguje na sygnały wysyłane przez pożywienie oraz inne animaty. (...)":

• sygnały tworzy animat, a sensor je obsługuje ( "sensor reaguje na sygnały" )

(mjoach) w sensorze innego animata uaktualniany jest poziom percepcji sygnału emitowanego przez innego animata lub pożywienie. Reaguje tylko w sensie postrzega, nie w sensie sterowania reakcją animata - to robi dostarczony z zewnątrz kontroler.

(mceier) Podsumowując elementy systemu:

• Sygnał chemiczny:
  • Ma pewien ograniczony zasięg - (mjoach) a konkretniej - jego koncentracja maleje w funkcji odległości, z odcięciem przy pewnym dystansie - odcięcie to wyłącznie optymalizacja mająca odciążyć system
  • Nie jest ukierunkowany
  • Jest broadcastem - (mjoach) w sensie nie jest do nikogo konkretnie wysyłany, ale nie każdy animat musi mieć zmysł pozwalający na wykrywanie go
  • "modeluje dyfundujące związki chemiczne"
  • Ma określoną 'siłę' (moc), źródło ( w postaci animata), oraz położenie ( zaraz po wysłaniu równe położeniu źródła ) - (mjoach) położenie jest zawsze takie jak animata, który je wysyła (ale patrz później dygresja na dole)
  • Jest aktuatorem ( tzn. może zmieniać swój zasięg, moc, i położenie ) - (mjoach) - może zmieniać natężenie (czyli moc). Zasięg maksymalny to optymalizacja, więc w najprostszym wypadku ustalamy go na sztywno, w sposób niezależny od natężenia. Można rozważyć sytuację, w której zasięg maksymalny jest w funkcji aktualnego natężenia, co jest bardziej sensowne ale prawdę mówiąc nie wiem czy to nie zepsuje optymalizacji później. Jeszcze raz podkreślam - zasięg maksymalny, to optymalizacja, która ma pozwolić nie brać w ogóle pod uwagę danego sygnału jeśli nadawca jest w zupełnie innym obszarze świata niż sensor który akurat sprawdzamy. Funkcja atenuacji sygnału (np. natezenie/odleglosc²) może nadal być tak skonstruowana, że zwraca zero już przy mniejszej odległości, gdy sygnał nadawany jest z bardzo małym natężeniem. Czyli interakcja sygnału z sensorem zostanie sprawdzona jeśli animaty są w odległości w której teoretycznie mogłyby odebrać sygnał o maksymalnym natężeniu (=1), ale z racji że jest słaby to zwrócone zostanie zerowe pobudzenie sensora. To jest, przynajmniej na pierwszy rzut oka prostsze w implementacji, niż dynamicznie zmieniający się zasięg maksymalny.

• Sensor:
  • Oblicza stan na podstawie pobudzenia ( 'sumy' sygnałów chemicznych na które reaguje )
• Funkcja Sensor<->Sygnał:
  • Zwraca, czy sensor reaguje na sygnał
  • Oblicza maksymalną odległość z jakiej sensor reaguje na sygnał
  • (mjoach) może też od razu być używana do liczenia pobudzenia, czyli modeluje atenuację sygnału z odległością
  • (mjoach) jest łatwo podmieniania przez użytkowników systemu, żeby wprowadzić bardziej złożone zależności, a Was jako black-box chroni przed różnymi pokrętnymi pomysłami, które przychodzą nam do głowy
• Kontroler animata
  • Pobiera stan sensorów animata
  • Aktualizuje aktuatory animata (np. ustawia siły)
  • Jest aktuatorem - (mjoach) uh? a to skąd? aktuatory to mięśnie, silniki robota, czy źródła sygnałów. Kontroler to mózg. Spójrzcie tutaj: http://en.wikipedia.org/wiki/File:IntelligentAgent-SimpleReflex.png Hmm...z możliwych źródeł niejasności - te słowa są spokrewnione, ale 'actuator' bierze znaczenie od 'to act albo actuate' a nie od 'to actualize'. Synonimem dla aktuatora jest efektor.
• Aktuator
  • Aktualizuje animata lub siebie - (mjoach) nie, patrz wyżej. Aktuatorowi ustawia się siłę z jaką działa, a resztę robi system fizyki i on uaktualnia to co się dzieje w następnym kroku z animatem. Chyba doszukujecie się jakiegoś drugiego dna, a to jest naprawdę takie proste jak: środowisko symulacyjne uaktualnia percepcje sensorów->kontrolery animatów uaktualniają im efektory->środowisko symulacyjne uaktualnia ruch animatów.
• Animat:
  • Posiada sensory
  • Posiada aktuatory
  • Wysyła sygnały chemiczne - (mjoach) może żeby uniknąć nieporozumień powinniśmy mówić, że _ma_ pewne sygnały...tzn. sygnał nie jest sam w sobie zdarzeniem jak wysłanie SIG_KILL do procesu, on po prostu jest i ma jakieś natężenie w danym momencie czasu. Mea culpa - w nomenklaturze programistycznej sygnały chemiczne o których mowa, są bliższe properties obiektów, które mogą być czytane przez inne animaty za pomocą metody. Sygnałami są w sensie robotyki/biologii, gdzie każda informacja, którą można odebrać od drugiego obiektu, nie tylko zapach, ale też np. kolor piór na ogonie jest wysyłanym sygnałem.
  • Jedzenie jako szczególny przypadek animata - tylko wysyła sygnały chemiczne
    • (magic) czyli ogólnie jedzenie to "zdechły animat" - można chyba to osiagnąć wyłączajac sensory w animacie (zdaje sie ze aktuatory bez sensorów nie bedą pracować, a wiec animat będzie zachowywać się biernie względem otoczenia - nie będzie się ruszać ani na nic reagować... no chyba ze na zjedzenie przez innego animata :)

Aktualizacja świata:

1. Dla każdego animata, wywołujemy metodę wysyłającą sygnały chemiczne - (mjoach) jako że one nie są wysyłane na zasadzie, powiedzmy pakietów, to raczej nie potrzebujecie takiej metody w ogóle, sygnały po prostu są w animatach, uaktualnione przez kontroler i dostrzegalne przez sensory innych animatów w następnym kroku.
2. Dla każdego sensora każdego animata wywołujemy metodę uaktualniającą poziom jego pobudzenia
3. Dla każdego animata, wywołujemy metodę aktualizacji animata, klasy kontrolera animata
   • kontroler zajmuje się uaktualnieniem aktuatorów animata na podstawie jego sensorów
4. Update fizyki - (mjoach) all good

Pytania:

• Czy sygnały chemiczne pojawiają się i znikają podczas jednej iteracji, czy mogą istnieć więcej niż jedną iterację ? - (mjoach) mam nadzieję, że wyżej trochę się rozjaśniło - sygnał jest własnością nadawcy, ale ponieważ zmienia się z iteracji na iterację to można powiedzieć że jako informacja istnieje przez jedną (patrz jeszcze dygresja na dole)
  • Jeżeli mogą istnieć więcej niż jedną iterację, to:
    • Kto powinien decydować kiedy usunąć sygnał z systemu ( animat, system np. gdy moc sygnału < minimum, metoda aktualizacji sygnału ) ?
    • Czy położenie sygnału chemicznego, jest zawsze równe położeniu źródła ( animata ) ? jest to pytanie o sens istnienia właściwości 'położenie' sygnału chemicznego
    • Czy sensor albo system powinien móc wpływać na sygnał chemiczny ( np. zmieniać jego moc, zasięg ) po obliczeniu pobudzenia ?
  • Jeżeli nie mogą, wtedy nie ma sensu, by sygnały chemiczne były aktuatorami i posiadały położenie ( wystarczy tylko źródło ) - powód chyba jest oczywisty - w czasie jednej iteracji sygnał się nie zmieni - (mjoach) tak, położenie źródła to położenie animata. Ale możemy sobie wyobrazić nieanimatowe źródła sygnałów w otoczeniu, której mają zewnętrznie ustalone położenie.

mam nadzieję, że niczego nie pokręciłem ...

walcie z pytaniami, możecie też zawsze na szybko coś doraźnie wyjaśnić stukając do mnie przez Skype - user goohru albo przez jabber gmaila - ten sam login

(mjoach) dygresja na dole: Jest jedna poważna i oczywista wada przyjętego sposobu modelowania dyfundowania związków chemicznych, która może rodzić pytania. Mianowicie sygnały rozumiane jako informacja rozchodzą się natychmiast w całym systemie - tzn. to co jakiś animat sobie ustawił że wysyła jest już w następnej iteracji widziane na sensorach pozostałych animatów, niezależnie od odległości. Bardziej przypomina to więc sygnalizowanie za pomocą zapalania kolorowych światełek niż dyfundujących w wodzie chemikaliów. Na późniejszym etapie być może spróbujemy to zmienić, ale póki co uważam, że lepiej tak to zostawić i zobaczymy co i jak chodzi. W systemie który rozwijam, gdzie mamy komórki dzielące się w 3D, modeluję sygnały chemiczne między komórkami analogicznie, natomiast wprowadziłem ograniczoną prędkość dyfuzji tychże, co pozwala tworzyć mniej trywialne gradienty stężeń. Jest na to prosty sposób, który kosztuje wyłącznie pamięć - dla każdego źródła sygnału pamiętam historię natężeń emisji w poprzednich krokach. Następnie gdy liczę natężenie sygnału postrzegane w komórce odbiorcy (czyli u Was w sensorze), to nie tylko uwzględniam spadek natężenia z dystansem, ale też korzystam z wartości historycznej natężenia sygnału u producenta: im dalej od źródła, tym bardziej historyczną wartość wyciągam. Spójrzcie na przykład: http://www.youtube.com/watch?v=l5_fBCR7ncM To co widać, to komórki w centrum, które cyklicznie zmieniają natężenie sygnału z dużego na małe, co w efekcie powoduje że przez całą przestrzeń wędruje fala (halo) informacji o zmianie natężenia, zwizualizowane jako mapa gradientu (kolor kreski odpowiada odbieranemu natężeniu, długość i kierunek kreski gradientowi). Przy czym tutaj nie ma żadnego modelowania stężenia w każdym punkcie przestrzeni, jest dokładnie taka filozofia jak opisana wyżej - komórki wysyłają sygnały, a dla dowolnego punktu w przestrzeni można doraźnie policzyć natężenie zależne od odległości. Gdyby więc dla każdego źródła sygnału pamiętać paręset ostatnich poziomów natężenia oraz miejsc w przestrzeni z których były wysyłane, to można by uzyskać taką właśnie mniej trywialną dyfuzję. Miałoby to ciekawe efekty takie, że jeśli np. animat przepłynie i zostaje wywęszony przez drapieżnika, to drapieżnik nie kieruje się idąc po gradiencie na aktualne położenie ofiary, tylko na przeszłe, podobnie jak gdy patrzy się na przelatujący wysoko na niebie samolot, to dźwięk silnika wydaje się dochodzić daleko zza niego. Byłoby to trochę bardziej realistyczne, ale ponieważ to dodatkowa komplikacja to nie traktuję tego priorytetowo - najpierw upewnijmy się, że się dobrze rozumiemy, a potem ewentualnie rozważymy dodanie czegoś takiego.

(mceier) Dwa ostatnie pytania, i wszystko powinno być już jasne :)

Rozumiem, że aktuatory powinny także posiadać geometrię ...

Czy animat+aktuatory tworzą obiekt złożony: http://opende.sourceforge.net/wiki/index.php/HOWTO_composite_objects#Theory ?

Czy może są to 2 ciała połączone jakimś jointem http://opende.sourceforge.net/wiki/index.php/Manual_%28Joint_Types_and_Functions%29#Joint_parameter_setting_functions ?

Wydaje mi się, że tworzą obiekt złożony, jednak chciałbym mieć pewność ...

(mjoach) Obiekty złożone musimy odłożyć na przyszłość, bo teraz byśmy się tylko w tym zakopali. Zakładamy sferyczne animaty, a aktuatory nie mają w ogóle geometrii, są tylko punktami na sferze do których przyczepiony jest wektor siły (albo z których emitowany jest sygnał). W ten sposób skupimy się najpierw na ewolucji samego mózgu i rozkładu aktuatorów na powierzchni sfery, a gorący w ALIFE temat koewolucji geometrii ciała i mózgu będziemy ruszać uzbrojeni w doświadczenie z prostszym modelem. Wtedy dołoży się animatom podklasę opisującą ich geometrię, mogącą kodować mechaniczne aktuatory, takie jak płetwy.

(mceier) ok, nie mam więcej pytań, biorę się za aktualizację ticketów ...