Institut für Angewandte Informatik
und Formale Beschreibungsverfahren
Karlsruher Institut für Technologie
Forschungsgruppe...
Inhaltsverzeichnis
1 Einleitung 3
2 Lichtberechnung 6
2.1 Schattenmodell . . . . . . . . . . . . . . . . . . . . . . . . ....
1 Einleitung
Das Ziel dieser Seminararbeit ist es, eine indirekte Fitness für den Simulationsapparat
FMG (Finite Moore Gen...
und direkte Fitness ergeben daher zusammen die auf Hamiltons Überlegun-
gen (1964a, b) basierende Gesamtfitness.
Zusammen m...
Durch die vorgegebene Implementierung des Plugins „stirbt“ aber leider auch ein pas-
siver Überlebenskämpfer mit der Zeit,...
2 Lichtberechnung
2.1 Schattenmodell
Zur Erstellung der Lichtintensitätsmatrix (LIM), die alle Lichtintensitätswerte der v...
Fall1: Die Gerade verläuft entlang der X-Achsenrichtung:
∆x, ∆y =
∆x = 1; ∆y = m∆x = m1 = m, |m| ≤ 1
∆y = 1; ∆x = ∆y
m
= 1...
Listing 1: Methode pixelStatus
1 public byte pixelStatus ( int pixelX , int pixelY ){
2 i f ( pixelX >= 0
3 && pixelX < al...
3 Plugin - SolarReproduction
Das in Java geschriebene Plugin besteht im Wesentlichen aus zwei Hauptkomponenten.
Durch die ...
Für die Temperatur des Roboterkorpus wurde jedoch noch kein Sensor implementiert,
da der Wärmewert der Roboter noch nicht ...
3.2 Ablauf
Der Ablauf des Plugins gliedert sich in drei Abschnitte.
Zuerst erfolgt die Berechnung der neuen Werte der Spei...
Roboterroboteri
m¨ogl.PPartner = { roboterj
radius} ∩ { roboterj
untersch. Erbgut zu i}
mit j = i (3.14)
roboterj
radius ˆ...
Nachdem die erste Selektion stattgefunden hat, kann es bei der erfolgreichen Festle-
gung der Paarungspartner roboteri, ro...
3.2.3 Aktion
Der Akku- und Wärmestand kann ganz am Ende des Zyklus noch die Invisible Hand
(I.H.)s und die Robo-Resets aus...
2. dateiAuslesen: Hier wird der Namen der LIM in Dateiform angegeben, die man
davor schon erstellt haben muss.
3. lichtque...
9. sensorLightEvolvable: Hier kann der LichtsensorInt bei der Verhaltensautomaten-
Mutation mit eingebunden werden.
10. se...
19. invisibleHand: Die I.H. beschleunigt die Simulation ungemein, kann aber die Ergeb-
nisse verzerren, da sie eine Einmis...
4 Auswertung
4.1 Parameterauswertung
Mit Joschka (ein Programm zur Jobverteilung in heterogenen und unzuverlässigen Um-
ge...
Tabelle 3: Parameterauswertung2 - Joschka
XML α #R r I.H. Reset in% minE pEv E.Gw Cluster
10_01 0,4 60 10 FALSE TRUE FALSE...
Tabelle 4: Parameterauswertung3 - Joschka
XML α #R r I.H. Reset in% minE pEv E.Gw Cluster
FMG 0,1 100 10 FALSE TRUE TRUE 1...
4.2 Instabile Clusterbildung
Als Ergebnis stellte sich heraus, dass sich die Roboter in nur wenigen Zyklen im lichtin-
ten...
Sascha Friedrich, Yuguang Lin:
Szenarien mit impliziter Fitnessberechnung
17 30.07.10
AIFB
Auswertung: Bsp. 1 - Mutation n...
Sascha Friedrich, Yuguang Lin:
Szenarien mit impliziter Fitnessberechnung
19 30.07.10
AIFB
Auswertung: Bsp. 1 - Mutation n...
Sascha Friedrich, Yuguang Lin:
Szenarien mit impliziter Fitnessberechnung
21 30.07.10
AIFB
Auswertung: Bsp. 2 - Mutation n...
Sascha Friedrich, Yuguang Lin:
Szenarien mit impliziter Fitnessberechnung
23 30.07.10
AIFB
Anzahl der Roboter: 30
Startseq...
4.3 Sonderfälle
4.3.1 Wanderkennung
In der nachfolgenden Szenariobetrachtung die Joschka mit permutierten Parameterwer-
te...
4.3.2 Kollisionsvermeidung
Ein ebenso interessantes Verhalten einiger Roboter ergab eine Simulation mit folgenden
Paramete...
Abbildung 17: Kollsionsvermeidung: Trajektoren
28
5 Zusammenfassung
Abschließend zu dieser Seminararbeit kann man sagen, dass eine indirekte Fitnessfunk-
tion durch das Plu...
Abbildungsverzeichnis
1 Aufbau und Ablauf des Plugins: SolarReproduction . . . . . . . . . . . . 5
2 Scanconversion, Reflex...
Literatur
[1] P. D. H. Schmeck, L. König, and D. S. Mostaghim. Decentralized evolution of robotic
behavior using finite sta...
Nächste SlideShare
Wird geladen in …5
×

SeminarOC_final_korr1

309 Aufrufe

Veröffentlicht am

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
309
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
16
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

SeminarOC_final_korr1

  1. 1. Institut für Angewandte Informatik und Formale Beschreibungsverfahren Karlsruher Institut für Technologie Forschungsgruppe Effiziente Algorithmen Prof. Dr. Hartmut Schmeck Seminar „Organic Computing: Learning Robots“, Sommersemester 2010 Einflüsse von Szenario und Fitnessbewertung Szenarien mit impliziter Fitnessberechnung Autor: Sascha Friedrich Matrikelnr.: 1100672 Betreuer: Lukas König
  2. 2. Inhaltsverzeichnis 1 Einleitung 3 2 Lichtberechnung 6 2.1 Schattenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Scanconversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Kollisionerkennung & Optimierung . . . . . . . . . . . . . . . . . . . . . 7 2.4 Lichtintensitätsmatrix (LIM) . . . . . . . . . . . . . . . . . . . . . . . . . 8 3 Plugin - SolarReproduction 9 3.1 Sensoren & Speicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1 Speicher für Elektrizität und Wärme . . . . . . . . . . . . . . . . 11 3.2.2 Selektion und Paarung . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3 Aktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3 Eingriffe in die Evolution und Umgebung . . . . . . . . . . . . . . . . . . 14 3.4 Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4 Auswertung 18 4.1 Parameterauswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 Instabile Clusterbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3 Sonderfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.1 Wanderkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.2 Kollisionsvermeidung . . . . . . . . . . . . . . . . . . . . . . . . . 27 5 Zusammenfassung 29 2
  3. 3. 1 Einleitung Das Ziel dieser Seminararbeit ist es, eine indirekte Fitness für den Simulationsapparat FMG (Finite Moore Generator1 ) von Lukas König bereit zu stellen, um das Verhalten von Roborterschwärmen, die durch eine indirekte Fitness in ihrer Evolutionsentwicklung beeinflusst werden, zu analysieren, ein bestimmtes zuvor grob definiertes Verhalten zu erzeugen und u.U. gewisse Auffälligkeiten zu beobachten. Das nachfolgend besprochene Szenario besteht aus mehreren simulierten Robotern, die mit einem Speicher für Elektrizität, einem Roboterkorpus der sich erwärmen kann(und somit auch ein Speicher darstellt), einem Licht- und Akkustandsensor, einem energie- verbrauchenden Elektromotor und einer Solarzelle zur Stromerzeugung ausgerüstet sind. Zudem können die Roboter innerhalb der Umgebung per Hand versetzt und die Verhal- tensautomaten auf ihren initialisierten Wert zurückgesetzt bzw. zu einem vorgegebenen Verhaltensautomaten umgeändert werden. Das erwünschte Verhalten soll in diesem Fall der Aufenthalt der Roboter in einem Gebiet mit hoher Lichtintensität sein, bzw. dass die simulierten Roboter versuchen ihre Akkumulatoren auf einem möglich hohen Energieniveau zu halten. Die implizite Fitness wird durch jeweils einen Speicher für Elektrizität und Wärme realisiert. Diese Speicher wirken indirekt über ihre jeweiligen Pegel in den Paarungsver- lauf ein. Aber zu allererst, was unterscheidet eine direkte von einer indirekten Fitness? Bei einer indirekten Fitness fließt eine potentielle Verbesserung des Verhaltens einzelner Roboter u.U. nicht komplett in das Erbgut einer Population mit ein, da gewisse Zufälligkeiten in der indirekten Fitness auch kontraproduktiv und bremsend in die Evolution einwir- ken können. Zudem ist, wie der Name es ja auch schon andeutet, diese Fitness nicht direkt berechenbar, sondern ergibt sich aus Faktoren, die das jeweilige Individuum über Umwege positiv bzw. negativ bei seinem Paarungsverhalten beeinflussen. Eine explizite Fitnessfunktion hat hingegen das Ziel, sehr gutes Erbgut möglich hoch einzustufen und somit vor allem die besten Roboter einer Population zur Vermehrung zu verhelfen. Zudem ist sie direkt ablesbar und steuert direkt das Paarungsverhalten. In diesem Zusammenhang sei noch eine Definition der indirekten Fitness im biolo- gischen Zusammenhang angegeben, auf die zwar in dieser Seminararbeit kein Bezug genommen wurde, aber dennoch einen interessanten weiteren Ansatzpunkt für künftige Simulationen enthalten könnte.2 Hier wird häufiger differenziert zwischen der direkten (Darwinsche Fitness) und indirekten Fitness. Während die direkte Fitness nur auf den Reproduk- tionserfolg eines Individuums, bemessen an der Anzahl der Nachkommen, abzielt, umfasst die indirekte Fitness denjenigen Reproduktionserfolg, der durch Verwandtenunterstützung erreicht wird (Voland 2000: S.8). Indirekte 1 Zum Verständnis von FMG sei auf „Decentralized evolution of robotic behavior using finite state machines“[1] und auf das Skript „Organic Computing: Learning Robots“ [2] verwiesen. 2 Zu dieser Thematik sei noch der Artikel: „Current indirect fitness benefits associated with philopatry in juvenile prairie voles“[3] als Lektüre empfohlen. 3
  4. 4. und direkte Fitness ergeben daher zusammen die auf Hamiltons Überlegun- gen (1964a, b) basierende Gesamtfitness. Zusammen mit dieser Seminararbeit wurde zur Realisierung der Beobachtungen das Plugin SolarReproduction erstellt, dass einen großen Zufallsfaktor beinhaltet. So dürfen sich Roboter bei Beachtung nur weniger Parameter bei der Selektion (min- EnergiePaarung, selParRar) und ohne Berücksichtigung der Temperatur des Roboter- korpus, nur dann dominant paaren, wenn sie ein gewisses Mindestenergieniveau des Akkus vorweisen können. Eine dominante Paarung besteht aus der Möglichkeit den eigenen Verhaltensautoma- ten auf seinen Paarungspartner zu übertragen. Ist das Verhalten eines Roboters optimal, so sollte im Regelfall dieser optimale Verhaltensautomat sich schnell in der Population etablieren. Der Faktor Zufall kommt nun aber dadurch zu Stande, dass bei einer Paarung von zwei Robotern mit einem Energieniveau größer gleich der Paarungsgrenze zufällig einer von beiden seinen Verhaltensautomaten übergibt, auch wenn, seine Fitness an sich niedriger sein mag, als der des Paarungspartners. Die Chance hierbei beträgt 50%. Wenn man Bereiche, statt absolute Werte beobachtet, so kann man sagen, dass Robo- ter mit zwei Energieniveaus existieren. Die guten dominant paarungsbereiten Roboter und die nicht besonders guten paarungsunbereiten. Nur in diesen zwei Kategorien ge- dacht, wäre eine explizite Fitnessfunktion gegeben. Da aber alle Paarungen von zwei Robotern die über dem Paarungsmindesenergieniveau liegen, aus dem zufälligen Über- tragen eines Verhaltensautomaten bestehen, können auch weniger gute Verhaltensweisen, die an sich aber schon ein gewisses Mindestmaß an Fitness erfüllen, sich in der Popula- tion festsetzen und die Evolution u.U. ausbremsen oder beschleunigen. Als Ergebnis stellt sich heraus, dass sich die Roboter in nur wenigen Zyklen im lichtinten- siven Bereich ansammeln und dort latente Cluster bilden. Dies wird dadurch beschleu- nigt, dass optimale Verhaltensweisen auch aus dem Stehenbleiben und einer rotatorischen Bewegung um die eigene Achse im lichtintensiven Bereich bestehen können. Bei sehr kleinen Anfangs-Automaten kommt es in den ersten Mutationszyklen zudem vermehrt zur Bildung von unbeweglichen Robotern die, abhängig von den jeweiligen Aufenthaltsorten, dann schon eine optimale Strategie für sich gefunden haben. Der Nachteil dieser zwei Strategien kann aber auch sehr gut beobachtet werden. So bilden sich durch die fehlende Bewegung der Population Cluster, die aber für einen Schneeballeffekt prädestiniert sind. Da hier viele Roboter in einem sehr engen Abstand zueinander positioniert sind, kann sich hier explosionsartig ein neues Verhalten etablieren und diese Strategien ad acta legen. Somit stellt sich auch die Frage, was ist denn eigentlich ein guter Verhaltensautomat? Ist es ein Automat, der die Paarung als Ziel definiert um sich so möglichst über die ganze Population auszubreiten, oder ist ein Automat, der versucht möglichst jeder Paarung zu entkommen um zu überleben ( jede Paarung beinhaltet hier ja auch eine u.U. 50%ige Chance zu „sterben“)? 4
  5. 5. Durch die vorgegebene Implementierung des Plugins „stirbt“ aber leider auch ein pas- siver Überlebenskämpfer mit der Zeit, da die Mutation seinen bisherigen optimalen Ver- haltensautomat erweitert oder aus dem von ihm abgeleiteten Verhalten verändert und so u.U. unbrauchbar für die Paarungsvermeidung macht. (Hier wäre als Lösung noch das Einfügen eines Reservats für solche Überlebenskünstler möglich.) Ein überraschendes Verhalten, das sich aus solch einer Überlebensstrategie in den Simulationsläufen ergibt ist z.b. die Kollisionsvermeidung. Als Paarungsstrategie ergibt sich, wie schon zuvor erwähnt, das rotatorische Bewegen um die eigene Achse, das Stehenbleiben und als neues das Erkennen von Wänden, als die Lichtquelle in der Nähe einer Wand erstellt wurde. In den weiteren Kapiteln dieser Seminararbeit wird auf die einzelnen Punkte intensi- ver eingegangen und ein Überblick über das Plugin SolarReproduction gegeben. An dieser Stelle wird zur besseren Übersicht des Plugins, dessen Bestandteile und der grobe Ablauf dargestellt: Abbildung 1: Aufbau und Ablauf des Plugins: SolarReproduction 5
  6. 6. 2 Lichtberechnung 2.1 Schattenmodell Zur Erstellung der Lichtintensitätsmatrix (LIM), die alle Lichtintensitätswerte der vorge- gebenen Umgebung beinhaltet, werden von einer punktförmigen Lichtquelle Lichtstrah- len mit einem bestimmten Energieniveau in einem regelmäßigen radialen Abstand in alle Richtungen ausgesendet. Treffen die Lichtstrahlen auf Hindernisse wie Wände (Ro- boter gelten hierbei nicht als Hindernis) werden sie an diesen reflektiert. So überlagern sich auf dem Pixelraster der Umgebung nach und nach Lichtstrahlen unterschiedlicher Lichtniveaus, die akkumuliert den Gesamtwert der Lichtintensität in dem jeweiligen Um- gebungspixel darstellen. Abgeleitet wird diese Art eines Schattenmodells von dem bekannten Phong-Modell. Exkurs Phong-Modell: 1. diffuse Reflexion 2. gerichtete Reflexion 3. ambientes Licht Das Plugin bedient sich nur der diffusen Reflexion. Trifft hier ein Lichtstrahl auf ein Hin- dernis, so werden vom Kollisionpunkt aus, in einem regelmäßigen radialen Abstand α, Strahlen wieder erneut ausgesandt. Das Energieniveau der neuen Strahlen aufsummiert ergibt dann genau den Energiewert des zuvor auf die Wand aufgetroffenen Lichtstrahls. Formal: Λ = λi; λi ∈ TeilstrahlvonΛ (2.1) 2.2 Scanconversion Damit die stetige Betrachtung in den diskreten Pixelraum überführt werden kann, ist zuvor jedoch noch eine Scanconversion (Rasterung) notwendig. Im vorliegenden Plugin wird dies dadurch realisiert, dass die Koordinate des stetigen Lichtstrahls im regelmä- ßigen x-Achsen-Abstand (je nach Ausrichtung des Lichtstrahls auch in y-Richtung) be- rechnet und dann der Abstand zu den nahe gelegenen Pixeleckpunkten ober und unter (je nach der Steigung des Lichtstrahls auch links und rechts) der berechneten Koordina- te erstellt wird. Der minimale Abstand zu einem Eckpixel determiniert dann das Pixel, welches den Lichtstrahl beinhalten soll. Steigung = m = ∆y ∆x = tan α (2.2) Pixelx = round(∆x + xi) (2.3) Pixely = round(∆y + yi) (2.4) 6
  7. 7. Fall1: Die Gerade verläuft entlang der X-Achsenrichtung: ∆x, ∆y = ∆x = 1; ∆y = m∆x = m1 = m, |m| ≤ 1 ∆y = 1; ∆x = ∆y m = 1 m , sonst . (2.5) Fall2: Die Gerade verläuft in die entgegengesetzte X-Achsenrichtung: ∆x, ∆y = ∆x = −1; ∆y = m∆x = m(−1) = −m, |m| ≤ 1 ∆y = −1; ∆x = ∆y m = − 1 m , sonst . (2.6) Abbildung 2: Scanconversion, Reflexion und Optimierung der Kollisionserkennung 2.3 Kollisionerkennung & Optimierung Zur Optimierung der Lichtstrahlenerstellung wird zunächst von der Punktlichtquelle aus, im gleichmäßig verteilten radialen Winkel getestet, ob überhaupt ein Lichtpixel gesetzt werden kann, oder ob schon eine Kollision stattfindet. Nur die kollisionsfreien ∆x und ∆y der jeweiligen α-Winkel werden in einem Iterator abgespeichert und bei der weiteren Berechnung wiederverwendet. So erspart man sich unnötige Aufrufe der Methode scanConversion(). Die Kollisionserkennung findet durch einen einfachen Farbwert-Check in der Methode pixelStatus statt. Zuvor wurde die Methode fmg.fmg8.umgebung2D.Umgebung.setzeLinie() von FMG bei den ersten Implementierungen aufgerufen, die aber die Rechenzeit deutlich verlän- gerte und daher keine weitere Verwendung hierbei fand. 7
  8. 8. Listing 1: Methode pixelStatus 1 public byte pixelStatus ( int pixelX , int pixelY ){ 2 i f ( pixelX >= 0 3 && pixelX < altesFeld . length 4 && pixelY >= 0 5 && pixelY < altesFeld [ 0 ] . length ){ 6 i f ( altesFeld [ pixelX ] [ pixelY ] 7 == Konstanten .FARBE_HGND 8 | | altesFeld [ pixelX ] [ pixelY ] 9 == Konstanten .FARBE_DURCHLAESSIG){ 10 return 0; // f r e i 11 } else return 1; // Hindernis 12 } else return 2; // ausserhalb des Feldes 13 } 2.4 Lichtintensitätsmatrix (LIM) Als Ergebnis der zuvor angesprochenen Berechnung der diffusen Reflexion, der Scancon- version und den Kollisionen, entsteht die LIM. Die LIM wird zur Beschleunigung des Programmablaufs des restlichen Plugins in einer Textdatei abgespeichert und wird von dort zu einem späteren Zeitpunkt ausgelesen. Somit muss die aufwendige Erstellung der LIM nur einmalig für eine bestimmte Umgebung und Parametereinstellung der Licht- quelle erbracht werden. Hierdurch ist eine Trennung der Berechnung der LIM von dem eigentlichen Ablauf des Programms möglich und durch den immensen Erstellungsauf- wand auch notwendig. In der Textdatei der LIM werden sowohl die Rasterdaten, die jedoch auf sechs Nach- kommastellen gekürzt wurden, als auch Metainformationen wie z.B. die Koordinaten der Punktlichtquelle und der Strahlenintensität der Anfangsstrahlen abgespeichert. Natürlich entsteht durch das Kürzen der hinteren Stellen der Fließkommazahl ein Ungenauigkeitsfaktor, der aber durch Berücksichtigung von sechs Nachkommastellen durchaus vernachlässigbar sein sollte. Abbildung 3: Lichtintensitätsmatrix (LIM) 8
  9. 9. 3 Plugin - SolarReproduction Das in Java geschriebene Plugin besteht im Wesentlichen aus zwei Hauptkomponenten. Durch die erste Haupkomponente wird die LIM erstellt, die für die weitere Simula- tion benötigt wird. Hier wird eine Textdatei erstellt, in der sämtliche Lichtwerte des Umgebungsrasters und noch einige Metadaten, die für die Erstellung der LIM benötigt werden, abgespeichert sind. Die Trennung der zwei Komponenten hat einen einfachen Hintergrund. Da die Er- stellung der LIM sehr zeit- und rechenintensiv ist, hat man so den Vorteil diesen Teil des benötigten Programms auszulagern und unabhängig vom eigentlichen Programm im Voraus berechnen zu können und für verschiedene Verhaltenssimulationen wiederzuver- wenden (vorausgesetzt man ändert weder das Umgebungs-Bitmap, noch die Lichtquelle). Die zweite Hauptkomponente befasst sich mit den Parametern, Speichern, Sensoren und dem eigentlichen Programmablauf, also mit der Berechnung der Sensorenwerte der Robo- ter, dem Paarungsverhalten und den möglichen Eingriffen in die Simulationsumgebung, die sich als Implikation aus den Sensorenwerte ergeben. Hier wird auch die LIM in Dateiform wieder in ein zweidimensionalen Feld eingebun- den und für die weiteren Berechnungen verwendet. Zerlegt man die zweite Komponente weiter in ihre Bestandteile, so ergeben sich wei- tere vier Blöcke. Der erste Block beherbergt die Allgemeinen Pluginparameter, die in der Simulation mit eingebunden werden. Der zweite Block stellt die Sensoren und Speicher der Roboter zur Verfügung, die im dritten Block, dem eigentlichen Programmablauf, in den Berechnungen genutzt und verändert werden. Der letzte Block realisiert die Eingriffe in die Umgebung, die durch den Selektionsab- lauf und den ganz am Ende des jeweiligen Zyklus stattfindenden Überprüfungen von be- stimmten Speichergrenzwerten (Akkuenergieniveau, Korpustemperatur) ausgelöst wer- den. 3.1 Sensoren & Speicher Es wird bewusst zwischen den Speichern und den Sensoren unterschieden, da sie unter- schiedliche Definitionsbereiche durch die Implementierung beinhalten. Für die interne Berechnung des Plugins wird immer der Speicher herangezogen. Die Sensoren sind aus- schließlich für die Mutation der Verhaltensautomaten relevant. Hier muss jedoch noch zwischen den Fliesskomma-Sensoren und den ganzzahligen Integer-Sensoren unterschie- den werden. Nur die ganzzahligen Integer-Sensoren spielen hierbei eine wichtige Rolle. Da FMG den ganzzahligen Definitionsbereich von [1,...,255] bei der Mutation benötigt, müssen die Definitionsbereiche der Sensoren auf diesen projiziert werden. Dies erfolgt durch Normierung, Rundung und Addition um 1. 9
  10. 10. Für die Temperatur des Roboterkorpus wurde jedoch noch kein Sensor implementiert, da der Wärmewert der Roboter noch nicht in den Mutationen mit berücksichtigt werden sollte. Dies kann man aber zukünftig noch leicht realisieren. Definitionsbereiche der Speicher und Sensoren: Akku_Speicher von roboteri ˆ= xroboteri Akku ∈ [0, 100] (3.1) W¨arme_Speicher von roboteri ˆ= xroboteri W ¨arme ∈ [0, 100] (3.2) Akku_SensorInt von roboteri ˆ= xroboteri Akku_SensorInt ∈ {[1, 255] ∩ N} (3.3) LichtsensorInt von roboteri ˆ= xroboteri LichtsensorInt ∈ {[1, 255] ∩ N} (3.4) Nachfolgend sind die Herleitungen der Sensorenwerte, die bei der Mutation der Verhal- tensautomaten verwendet werden können, aufgelistet:3 xroboteri Akku_SensorInt = xroboteri Akku · 254 100 + 1 (3.5) fLIM (punktp) : punktp ∈ {(0, 0), ..., (lX, lY )} → [1, 255] (3.6) xroboteri Lichtsensor = fMedian({ fLIM ( EProboteri 1 ) , ..., fLIM ( EProboteri 4 ) }) (3.7) xroboteri LichtsensorInt = xroboteri Lichtsensor (3.8) lx ˆ= Länge der X-Achse des bmp ly ˆ= Länge der Y-Achse des bmp EProboteri e ˆ= Eckpunkt e von Roboter i 3 Bei der Implementierung der Medianfunktion ist leider folgender Flüchtigkeitsfehler unterlaufen: So wurde fälschlich wegen der Aufzählung beginnend bei 1, statt 0 : (fLIM ( EProboteri 3 ) + fLIM ( EProboteri 4 )) · 1 2 berechnet. Der Fehler ist aber eher marginal und hat sich nicht negativ bemerkbar gemacht. 10
  11. 11. 3.2 Ablauf Der Ablauf des Plugins gliedert sich in drei Abschnitte. Zuerst erfolgt die Berechnung der neuen Werte der Speicher für Elektrizität und Wär- me. Danach findet die Selektion und Paarung, die auf den neuen Speicherständen auf- bauen, statt. Und ganz am Ende des Zyklus erfolgen noch mögliche Aktionen, falls die entsprechenden Parameter hierfür aktiviert und mit Werten belegt wurden. 3.2.1 Speicher für Elektrizität und Wärme Abschnitt 1 besteht aus der Berechnung der temporären neuen Füllstände der Speicher für Elektrizität und Wärme: xroboteri,neu Akku = xroboteri,alt Akku − mMotorEnergieV erbrauch + xroboteri Lichtsensor 100 (3.9) mMotorEnergieV erbrauch = LICHTFARBE_MAX · 4 100 · 100 (3.10) LICHTFARBE_MAX = 255 (3.11) xroboteri,neu W ¨arme = xroboteri,alt W ¨arme + min( xroboteri Lichtsensor − uueberhitz. 100 ; 0, 05) (3.12) uueberhitz. ∈ [0, 255] (3.13) 3.2.2 Selektion und Paarung Abschnitt 2 kümmert sich um die Selektion und Paarung. Der erste Schritt der Selektion besteht aus der zufälligen Auswahl eines Roboters roboteri. Sowohl der Paarungsradius, als auch der Vergleich der Verhaltensautomaten determinieren dann die nachfolgende Menge der potentiellen Paarungspartner Roboterroboteri m¨ogl.PPartner. Aus dieser Menge wird dann zufällig ein potentieller Parungspartner roboterz ausgewählt. Erfüllt nun roboteri und/oder roboterz die weiteren zwei Bedingungen, so kommt es zur Paarung und damit verbunden zu einem Austausch eines Verhaltensautomaten. Die Selektion besteht somit aus der Auswertung der vier nachfolgenden Grenz- und Wahrheitswerte: 1. Radius: Welche Roboter sind durch die maximal angegebene Reichweite potentielle Paarungspartner von roboteri ? 2. Unterschiedliches Erbgut: Welche potentiellen Paarungspartner weisen einen un- terschiedlichen Verhaltensautomaten zu roboteri auf? 3. Überhitzungslevel: Ist roboteri/roboterz überhaupt in der Lage sich dominant zu paaren, oder ist er quasi schon überhitzt? 4. Akkulevel: Ist es roboteri/roboterz energetisch überhaupt möglich, sich dominant zu paaren? Erfüllt roboteri/roboterz den minimalen Grenzwert für den Paarungs- versuch? 11
  12. 12. Roboterroboteri m¨ogl.PPartner = { roboterj radius} ∩ { roboterj untersch. Erbgut zu i} mit j = i (3.14) roboterj radius ˆ= roboterj :roboterj ist im Paarungsradius von roboteri ⇔ roboteri ist im Paarungsradius von roboterj (3.15) roboterj untersch. Erbgut zu i ˆ= roboterj :roboterj , roboteri h. untersch. Verh.aut. ⇔ roboteri , roboterj h. untersch. Verh.aut. (3.16) roboterz ∈ Roboterroboteri m¨ogl.PPartner (3.17) In der anschließend aufgeführten Tabelle4 werden sowohl der Akku- als auch der Wär- mestand bei der Selektion berücksichtigt: fPS(xroboteri Akku ) fUS(xroboteri W ¨arme ) fPS(xroboterz Akku ) fUS(xroboterz W ¨arme ) Auswirkung f f f f keine Paarung zw. i, z w f f f keine Paarung zw. i, z f w f f keine Paarung zw. i, z f f w f keine Paarung zw. i, z f f f w keine Paarung zw. i, z w w f f roboteri dominiert w f w f keine Paarung zw. i, z w f f w keine Paarung zw. i, z f f w w roboterz dominiert f w w f keine Paarung zw. i, z f w f w keine Paarung zw. i, z f w w w roboterz dominiert w f w w roboterz dominiert w w f w roboteri dominiert w w w f roboteri dominiert w w w w 50% i dominiert, sonst z Tabelle 1: Wahrheitstafel - Selektion 4 Ausführliche Erläuterung einiger Funktionen: fP S(xroboteri Akku ): Diese Funktion gibt an, ob ein roboteri mit dem aktuellen Akkustand die Paarungsschwelle (PS) erreicht. fUS(xroboteri W ¨arme ): Diese Funktion gibt an, ob ein roboteri mit dem aktuellen Wert des Wärmespeichers die Überhitzuungsschwelle (US) unterschreitet. ... 12
  13. 13. Nachdem die erste Selektion stattgefunden hat, kann es bei der erfolgreichen Festle- gung der Paarungspartner roboteri, roboterz zum Austausch eines Verhaltensautomaten kommen. Findet eine Paarung statt, sind diese zwei Roboter in diesem Zyklus für weitere Selektionen und somit auch Paarungen gesperrt. Gibt es für roboteri keinen roboterz mit dem es zu einer Paarung kommen kann, so wird roboteri gesperrt. Nun wird iterativ wieder zufällig ein nicht ausgeschlossener roboteri ausgewählt und das Verfahren beginnt von vorne, bis alle Roboter gesperrt wurden. Die Paarung setzt sich aus folgenden drei Werten zusammen: 1. Paarungsschwelle: Diesen Energiewert muss der Akku des dominanten Roboters mindestens aufweisen, damit er sich fortpflanzen kann. Dies wird durch die Selek- tion bereits gewährleistet. Dieser Wert ist der Ausgangspunkt für den Energiever- brauch. 2. Energieverbrauch: Bei der Paarung wird dieser Wert an Energie durch den Paa- rungsakt bei dem dominanten Paarungspartner verbraucht. Es wird davon ausge- gangen, dass vor allem der dominante Roboter dabei Energie verliert, da er aktiv auf Partnersuche ist. (Der Energieverbrauch kann natürlich zukünftig noch auf den anderen Partner erweitert werden.) 3. Glühwurmeffekt: Von der verbrauchten Energie geht der hier aufgeführte Wert auf den dominierten Roboter über. Für einen roboterdominant und einem roboterdominiert gilt: 100 ≥ xroboterdominant,neu Akku ≥ 0 (3.18) 100 ≥ xroboterdominiert,neu Akku ≥ 0 (3.19) xroboterdominant,neu2 Akku = xroboterdominant,neu Akku − fEV (ePS) (3.20) xroboterdominiert,neu2 Akku = xroboterdominiert,neu Akku + fGW (fEV (ePS)) (3.21) 100 ≥ xroboterdominant,neu Akku ≥ ePS ≥ fEV (ePS) ≥ fGW (fEV (ePS)) ≥ 0 (3.22) ePS ˆ= Paarungsschwelle fEV (ePS) ˆ= Energieverbrauch, abh. von der Paarungsschwelle fGW (fEV (ePS)) ˆ= Glühwurmeffekt, abh. von dem Energieverbrauch 13
  14. 14. 3.2.3 Aktion Der Akku- und Wärmestand kann ganz am Ende des Zyklus noch die Invisible Hand (I.H.)s und die Robo-Resets auslösen, falls die jeweiligen Parameter aktiv gesetzt wurden. Im Plural wird hierbei gesprochen, da sowohl der Elektrizitätswert des Akkus, als auch der Wärmewert des Roboterkorpus triggernd wirken kann. 3.3 Eingriffe in die Evolution und Umgebung Da gewisse Verhaltensweisen der Roboter umgangen werden sollen, wirkt hier die I.H. als erzieherischer Faktor. So sollen die Roboter durch das zufällige Versetzen bei der Unter- oder Überschreitung der jeweiligen Grenzwerte für den Akku oder der Temperatur des Roboterkorpus von lock-in Situationen bezüglich der Paarungsbereitschaft befreit werden(z.B. wenn Roboter einfach im Schattenbereich stehen bleiben). Zudem kann ein zufälliges Versetzen der Roboter u.U. zu einem dynamischerem Verhalten führen, da sie sich hierdurch immer wieder neuen Gegebenheiten des Umfeldes stellen müssen. Außerdem entspricht es doch ein wenig mehr der Realität, wenn ein Roboter mit leerem Akku, der sich ja dann nicht mehr bewegen könnte, zu einem lichtintensiveren Punkt gesetzt werden müsste, um dort wieder Energie aufnehmen zu können. Der negative Punkt hierbei ist jedoch, dass es einen Eingriff in das System bedeutet und u.U. das Ergebnis negativ beeinträchtigt (z.B. könnten Roboter für ein gewisses Gebiet eine perfekte Route zu fahren lernen, würden aber durch das zufällige Versetzen nun nicht mehr ihre statisch optimale Route abfahren können.) Neben der I.H. gibt es nun noch als zweite Aktion den harten Roboter-Reset. Er kann, wie auch die I.H., dafür sorgen lock-in Paarungssituationen zu vermeiden. So kann z.B. ein überhitzter Roboter, der sich momentan einfach nur um seine eigene Achse dreht, durch den Reset des Verhaltensautomaten zu einem Automaten mit einfacher translatorischer Bewegung, in weniger lichtintensive Bereiche zur Abkühlung gebracht werden. Der große und nicht zu unterschätzende Nachteil ist aber der Verlust der zuvor ent- wickelten Verhaltensautomaten. So müssen Roboter, die sich einmalig überhitzen, des- wegen noch lange keinen schlechten Automaten aufweisen. 3.4 Parameter Zum einfacheren Verständnis der vielen Parameter des Plugins werden die einzelnen Parameter auf den nächsten Seiten erläutert: 1. dateiErzeugen: Dieser Parameter gibt den Namen der zu erstellenden LIM in Datei- form an. Das Erstellen der LIM dauert je nach Art der weiteren Parameterbelegung seine Zeit. Man sollte daher für mehrere Simulationsläufe einmalig eine LIM für ein bestimmte Szenario erstellen und danach die LIM auslesen lassen. 14
  15. 15. 2. dateiAuslesen: Hier wird der Namen der LIM in Dateiform angegeben, die man davor schon erstellt haben muss. 3. lichtquellenKoordinaten: Die Koordinaten der punktförmigen Lichtquelle. 4. defaultAngle: Dies ist der Abstand der α-Winkel der ausgesendeten Strahlen der Lichtquelle bzw. des Reflexionspunktes. 5. anzahl_koll_max: Hier kann die # der Kollisionen bzw. Reflexionen der Licht- strahlen eingestellt werden. Alles über 1 ist sehr rechenintensiv und sollte vermie- den werden. 6. anzahlRoboter: Wie der Name schon sagt, kann man hier die Anzahl der Roboter für die Simulation eingeben. 7. startSequenz: Die Startsequenz stellt den duplizierten Verhaltensautomat der Ro- boter zu Beginn der Simulation ein. Zudem wird bei einem Roboter-Reset der Verhaltensautomat auf diese Startsequenz zurückgesetzt. 8. variante: Dieser Parameter ist inzwischen veraltet, da in FMG die manuell verän- derte Geschwindigkeit der Roboter mit der Auswertung der Verhaltensautomaten in die Quere kommt. Abbildung 4: Parameterübersicht 15
  16. 16. 9. sensorLightEvolvable: Hier kann der LichtsensorInt bei der Verhaltensautomaten- Mutation mit eingebunden werden. 10. sensorBatteryEnvolvable: Hier kann der Akku_SensorInt bei der Verhaltensautomaten- Mutation mit eingebunden werden. 11. selRadPar: Der Selektionsradius gibt an, bis zu welcher radialen Entfernung von einem Roboter eine Paarung möglich sein kann. Hindernisse sind hierbei durchläs- sig. 12. unterschiedlichesErbgut: Da Paarungen mit gleichem Erbgut keinen wirklichen Vorteil erbringen, kann hier die Paarung nur für Roboter mit unterschiedlichem Erbgut ermöglicht werden. 13. volleRoboterNachZeitintervallversetzen: Dieser Parameter ist vor allem für Simu- lationen gedacht, in denen die Roboter, egal von welchem Punkt aus sie starten, versuchen sollen ihren Akkumulator aufzuladen. Zudem soll hierdurch der Fahrweg der Roboter auch weniger lichtdurchflutete Bereiche enthalten. 14. alleRoboterNachZeitintervallversetzen: Hier kann, wie im vorherigen Parameter, mehr Dynamik in die Simulation gebracht werden. Roboter, die sich nur um ihre eigene Achse drehen oder einfach in lichtstarken Bereichen stehen bleiben, haben nun keine optimale Strategie mehr zur Verfügung, da sie zufällig wieder in der Umgebung umgesetzt werden. 15. inProzent: Statt absolute Werte für die Parameter minEnergiePaarung, paarun- gEnergieverbrauch und glühwurmPower anzugeben, können nun Prozentwerte ge- nutzt werden. Diese Prozentwerte beziehen sich immer auf den vorherig aufgeführ- ten Parameter. 16. minEnergiePaarung: Hier wird der minimale Grenzwert für eine mögliche Paarung bestimmt. 17. paarungEnergieverbrauch: Da in der Natur eine Paarung auch immer an den Ener- giereserven zehrt (hier sei vor allem die Fortpflanzung von Lachsen erwähnt, bei der die meisten Tiere verenden), kann dieser Wert für interessante Ergebnisse sor- gen. Dieser Wert gibt auch die Möglichkeit eine Pause zwischen den Paarungen zu erzeugen, da der Akkumulator erst wieder aufgeladen werden muss, um die minEnergiePaarung wieder aufzuweisen. 18. gluehwurmPower: In der Biologie ist zudem ein interessantes Verhalten bei der Paarung von Glühwürmchen zu beobachten. So übertragen die Glühwürmchen bei der Paarung scheinbar Licht auf den Fortpflanzungspartner, der dadurch an- fängt heller zu leuchten, bei gleichzeitiger Abnahme der Leuchtkraft des eigenen Individuums. Hier stellt man also einen Energieübertragungswert ein, der auf den dominierten Roboter übertragen wird. Der abgezogene eigene Energiewert wird schon in paarungEnergieverbrauch realisiert. 16
  17. 17. 19. invisibleHand: Die I.H. beschleunigt die Simulation ungemein, kann aber die Ergeb- nisse verzerren, da sie eine Einmischung von Außerhalb der Umgebung darstellt. Die I.H. setzt Roboter mit leerem Akku (ein Akku ist ab einem Wert von 2,5 als leer definiert!) zufällig auf eine neue Position. Dieser Vorgang wird von Zyklus zu Zyklus wiederholt, bis der Roboter wieder über den Mindestwert für einen nicht leeren Akku verfügt. 20. roboReset: Dieser Paramter erlaubt es auch ohne die I.H. Roboter mit leerem Ak- kumulator aus Schattenbereichen zu manövrieren. Hier sollte dann aber in der Startsequenz ein Verhaltensautomat angegeben werden, der eine Bewegung ge- währleistet, die aus solchen Gebieten führt. Ein sehr großer Nachteil dieses Para- meters ist jedoch der große Informationsverlust des Roboters, da sein durch die Evolution u.U. gut angepasster Verhaltensautomat, wieder komplett zurückgesetzt wird. 21. ueberhitzung: Ein anderer Weg um Roboter, die sich kaum fortbewegen, zu um- gehen, besteht in der Angabe dieses Parameter. Die Überhitzung entsteht durch das Einwirken der Lichtstrahlen auf dem Roboterkorpus. Der Temperaturwert des Roboterkorpus hat dann wiederum Auswirkungen, die in den nachfolgenen Para- metern bestimmt werden können. 22. invisibleHandueberhitzung: Dieser Wert ist spiegelbildlich zur I.H. des Akkumu- lators. Hier kann man den permanenten Aufenthalt in lichtintensiven Bereichen bestrafen bzw. das Verhalten der Roboter dynamischer machen, da sie sich nun immer wieder zufälligen Bereichen der Umgebung anpassen müssen. 23. roboresetueberhitzung: Wie der zuvor beschriebene Parameter ist dieser hier zu verstehen. Wie bei dem Robo-Reset der abhängig vom Akkuwert ist, gehen auch hier viele Informationen verloren und sollte daher eher nicht aktiviert werden. 24. ueberhitzungKeinePaarungMoeglich: Will man ohne Zurücksetzen oder zufälligem Versetzen der Roboter den permanenten Aufenthalt im Bereich hoher Lichtinten- sität bestrafen, so kann man hier die Paarung einschränken. 17
  18. 18. 4 Auswertung 4.1 Parameterauswertung Mit Joschka (ein Programm zur Jobverteilung in heterogenen und unzuverlässigen Um- gebungen)5 wurden mehrere permutierte Parametersimulationen realisiert und ausge- wertet. Die Tabellen6 auf den nächsten Seiten veranschaulichen die große Anzahl der Simulationen, bei denen es zu Clusteranordnungen der Roboter kam. Die Tabellen der nächsten Seiten stehen jeweils stellvertretend für einen permutierten Gesamtauftrag für Joschka (von einigen Ausnahmen abgesehen), die ausgewertet wur- den: Tabelle 2: Parameterauswertung1 - Joschka XML α #R r I.H. Reset in% minE pEv E.Gw Cluster 10 0,8 30 10 FALSE FALSE FALSE 0 20 0 TRUE 0 0,4 30 10 TRUE TRUE FALSE 80 0 0 TRUE 1 0,4 30 10 FALSE TRUE FALSE 80 0 0 TRUE 2 0,4 30 10 TRUE FALSE FALSE 80 0 0 FALSE 3 0,4 30 10 FALSE FALSE FALSE 80 0 0 FALSE 4 0,4 30 10 TRUE TRUE FALSE 80 20 0 TRUE 5 0,4 30 10 FALSE TRUE FALSE 80 20 0 FALSE 6 0,4 30 10 TRUE FALSE FALSE 80 20 0 FALSE 7 0,4 30 10 FALSE FALSE FALSE 80 20 0 TRUE OC10 0,8 30 10 TRUE TRUE FALSE 80 0 0 TRUE OC11 0,8 30 10 FALSE FALSE FALSE 0 20 0 TRUE 5 Weitere Informationen zu Joschka kann man dem Skript „Organic Computing: Learning Robots“[2] entnehmen. 6 Ausführliche Schreibweise einiger Spaltenbeschriftungen: #R ˆ= anzahlRoboter, r ˆ= selRadPar, I.H. ˆ= invisibleHand, Reset ˆ= roboReset, % ˆ= inProzent, minE ˆ= minEnergiePaarung, pEv ˆ= paarung- EnergieVerbrauch, E.Gw ˆ= gluehwurmPower. 18
  19. 19. Tabelle 3: Parameterauswertung2 - Joschka XML α #R r I.H. Reset in% minE pEv E.Gw Cluster 10_01 0,4 60 10 FALSE TRUE FALSE 80 0 0 TRUE 10_04 0,4 60 10 TRUE TRUE FALSE 90 0 0 TRUE 10_03 0,4 60 10 FALSE FALSE FALSE 80 0 0 TRUE 10_05 0,4 60 10 FALSE TRUE FALSE 90 0 0 TRUE 10_06 0,4 60 10 TRUE FALSE FALSE 90 0 0 TRUE 10_07 0,4 60 10 FALSE FALSE FALSE 90 0 0 TRUE 10_08 0,4 60 10 TRUE TRUE FALSE 100 0 0 TRUE 10_09 0,4 60 10 FALSE TRUE FALSE 100 0 0 TRUE 10_10 0,4 60 10 FALSE TRUE FALSE 100 0 0 TRUE 10_12 0,4 60 10 TRUE TRUE FALSE 80 10 0 TRUE 10_13 0,4 60 10 FALSE TRUE FALSE 80 10 0 TRUE 10_14 0,4 60 10 TRUE FALSE FALSE 80 10 0 TRUE 10_15 0,4 60 10 FALSE FALSE FALSE 80 10 0 TRUE 10_16 0,4 60 10 TRUE TRUE FALSE 90 10 0 TRUE 10_17 0,4 60 10 FALSE TRUE FALSE 90 10 0 TRUE 10_18 0,4 60 10 TRUE FALSE FALSE 90 10 0 TRUE 10_19 0,4 60 10 FALSE FALSE FALSE 90 10 0 TRUE 10_20 0,4 60 10 TRUE TRUE FALSE 100 10 0 TRUE 10_21 0,4 60 10 FALSE TRUE FALSE 100 10 0 TRUE 10_22 0,4 60 10 TRUE FALSE FALSE 100 10 0 TRUE 10_23 0,4 60 10 FALSE FALSE FALSE 100 10 0 FALSE 10_24 0,4 60 10 TRUE TRUE FALSE 80 20 0 TRUE 10_25 0,4 60 10 FALSE TRUE FALSE 80 20 0 TRUE 10_26 0,4 60 10 TRUE FALSE FALSE 80 20 0 TRUE 10_27 0,4 60 10 FALSE FALSE FALSE 80 20 0 FALSE 10_28 0,4 60 10 TRUE TRUE FALSE 90 20 0 TRUE 10_29 0,4 60 10 FALSE TRUE FALSE 90 20 0 TRUE 10_30 0,4 60 10 TRUE FALSE FALSE 90 20 0 TRUE 10_31 0,4 60 10 FALSE FALSE FALSE 90 20 0 TRUE 10_32 0,4 60 10 TRUE TRUE FALSE 100 20 0 TRUE 10_33 0,4 60 10 FALSE TRUE FALSE 100 20 0 TRUE 10_34 0,4 60 10 TRUE FALSE FALSE 100 20 0 TRUE 10_35 0,4 60 10 FALSE FALSE FALSE 100 20 0 FALSE 19
  20. 20. Tabelle 4: Parameterauswertung3 - Joschka XML α #R r I.H. Reset in% minE pEv E.Gw Cluster FMG 0,1 100 10 FALSE TRUE TRUE 100 100 50 FALSE evo00 0,01 30 10 TRUE TRUE TRUE 80 50 50 TRUE evo01 0,01 60 10 TRUE TRUE TRUE 80 50 50 TRUE evo02 0,01 100 10 TRUE TRUE TRUE 80 50 50 TRUE evo03 0,01 30 10 FALSE TRUE TRUE 80 50 50 TRUE evo04 0,01 60 10 FALSE TRUE TRUE 80 50 50 TRUE evo05 0,01 100 10 FALSE TRUE TRUE 80 50 50 TRUE evo06 0,01 30 10 TRUE FALSE TRUE 80 50 50 TRUE evo07 0,01 60 10 TRUE FALSE TRUE 80 50 50 TRUE evo08 0,01 100 10 TRUE FALSE TRUE 80 50 50 TRUE evo09 0,01 30 10 FALSE FALSE TRUE 80 50 50 TRUE evo10 0,01 60 10 FALSE FALSE TRUE 80 50 50 TRUE evo11 0,01 100 10 FALSE FALSE TRUE 80 50 50 TRUE evo12 0,01 30 10 TRUE TRUE TRUE 80 0 50 TRUE evo13 0,01 60 10 TRUE TRUE TRUE 80 0 50 TRUE evo14 0,01 100 10 TRUE TRUE TRUE 80 0 50 TRUE evo15 0,01 30 10 FALSE TRUE TRUE 80 0 50 TRUE evo16 0,01 60 10 FALSE TRUE TRUE 80 0 50 TRUE evo17 0,01 100 10 FALSE TRUE TRUE 80 0 50 TRUE evo18 0,01 30 10 TRUE FALSE TRUE 80 0 50 TRUE evo19 0,01 60 10 TRUE FALSE TRUE 80 0 50 FALSE evo20 0,01 100 10 TRUE FALSE TRUE 80 0 50 FALSE evo21 0,01 30 10 FALSE FALSE TRUE 80 0 50 TRUE evo22 0,01 60 10 FALSE FALSE TRUE 80 0 50 TRUE evo23 0,01 100 10 FALSE FALSE TRUE 80 0 50 TRUE 20
  21. 21. 4.2 Instabile Clusterbildung Als Ergebnis stellte sich heraus, dass sich die Roboter in nur wenigen Zyklen im lichtin- tensiven Bereich ansammeln und dort latente Cluster bilden. Dies wird dadurch beschleunigt, dass optimale Verhaltensweisen auch aus dem Ste- hen bleiben und einer rotatorischen Bewegung (um die eigene Achse) im lichtintensiven Bereich bestehen können. Bei sehr kleinen Anfangs-Automaten kommt es in den ersten Mutationszyklen zudem vermehrt zur Bildung von unbeweglichen Robotern die, abhängig von den jeweiligen Auf- enthaltsorten, dann schon eine optimale Strategie für sich gefunden haben. Ein Grund für dieses Verhalten, ist die Bildung von Robotern mit idl- und stopp-Zuständen, die dann bewegungslos in diesen Ausprägungen verharren. Den nachfolgenden Momentaufnahmen kann man deutlich die instabile Clusterbildung und das Erreichen der Zielvorgabe entnehmen: Abbildung 5: Clusterbildung: Verteilung der Roboter gegen Beginn der Simulation Abbildung 6: Clusterbildung: Verteilung der Roboter nach x-Zyklen 21
  22. 22. Sascha Friedrich, Yuguang Lin: Szenarien mit impliziter Fitnessberechnung 17 30.07.10 AIFB Auswertung: Bsp. 1 - Mutation nach 300 Zyklen 4200: Clusterbildung 5200 5400: Rasche Auflösung eines Clusters 55005300 Abbildung 7: Instabile Clusterbildung: Mutation nach 300 Zyklen I Sascha Friedrich, Yuguang Lin: Szenarien mit impliziter Fitnessberechnung 18 30.07.10 AIFB Auswertung: Bsp. 1 - Mutation nach 300 Zyklen 47500 48500 49800 49900: Instabilität des Clusters 45400 Abbildung 8: Instabile Clusterbildung: Mutation nach 300 Zyklen II 22
  23. 23. Sascha Friedrich, Yuguang Lin: Szenarien mit impliziter Fitnessberechnung 19 30.07.10 AIFB Auswertung: Bsp. 1 - Mutation nach 300 Zyklen 6760059300: Instablität des Clusters 82600: Ab hier Cluster stabil 253400 299900: Ergebnis: Cluster im L.B. Abbildung 9: Instabile Clusterbildung: Mutation nach 300 Zyklen III Sascha Friedrich, Yuguang Lin: Szenarien mit impliziter Fitnessberechnung 20 30.07.10 AIFB Auswertung: Bsp. 2 - Mutation nach 700 Zyklen 39003400: Beginnende Bildung eines Clusters... 5600 7900: ...das nach 4000 Zyklen verschwunden ist 10000 Abbildung 10: Instabile Clusterbildung: Mutation nach 700 Zyklen I 23
  24. 24. Sascha Friedrich, Yuguang Lin: Szenarien mit impliziter Fitnessberechnung 21 30.07.10 AIFB Auswertung: Bsp. 2 - Mutation nach 700 Zyklen 16100: Entstehung des Clusters unten links 13400: Cluster oben rechts instabil 17700: Zwei Cluster ab hier stabil (etwa doppelte Zeit wie bei Bsp. 1, bei doppelter Mutationsdauer) 299900: Ergebnis: zwei Cluster im L.B. Abbildung 11: Instabile Clusterbildung: Mutation nach 700 Zyklen II Sascha Friedrich, Yuguang Lin: Szenarien mit impliziter Fitnessberechnung 22 30.07.10 AIFB Auswertung: Bsp. 3 - Mutation nach 1k Zyklen 211700: Auch jetzt noch keine Stabilität 85100 299900: Ergebnis: 1 Cluster im L.B. ... Abbildung 12: Instabile Clusterbildung: Mutation nach 1000 Zyklen 24
  25. 25. Sascha Friedrich, Yuguang Lin: Szenarien mit impliziter Fitnessberechnung 23 30.07.10 AIFB Anzahl der Roboter: 30 Startsequenz 001,003,001,001,000,000,000 Radius: 10 Sensor: true Invisible Hand: true RoboReset: false In Prozent: false Minimale Energie f. Paarung: 80.0 Energieverbrauch b. Paarung: 0.0 Glühwurmeffekt: nein Anzahl der Zyklen insgesamt: 300000 Anzahl der Zyklen zwischen zwei Mutationen: variabel Auswertung: Parameter der Beispiele Abbildung 13: Instabile Clusterbildung: Paramtereinstellungen Sascha Friedrich, Yuguang Lin: Szenarien mit impliziter Fitnessberechnung 24 30.07.10 AIFB Auswertung: Bsp. Trajektoren Clusterbildung und wenig translatorische Bewegung (XML: evo10) Abbildung 14: Instabile Clusterbildung: Trajektoren 25
  26. 26. 4.3 Sonderfälle 4.3.1 Wanderkennung In der nachfolgenden Szenariobetrachtung die Joschka mit permutierten Parameterwer- ten übergeben wurde, befand sich die punktförmige Lichtquelle in der oberen linken Ecke der Umgebung „tunnel.bmp“. Bei diesem Szenario entwickelte sich dann ein unvorgesehenes neues Verhalten der Roboter. Das Resultat war, dass die Roboter Wände aufsuchten und an ihnen stehen blieben. Da in dieser Simulation die I.H. aktiv in die Umgebung eingriff, konnten sich dadurch die Roboter schnell in den lichtdurchfluteten Bereichen ansammeln. Roboter, die im Schattenbereich an eine Wand fuhren und dort eine Pause einlegten, wurden durch die I.H. dann wieder in die besseren Regionen versetzt. Dieses Verhalten ist aber nur dadurch in dieser Simulation optimal, da die Lichtquelle in der Nähe einer Wand gesetzt wurde und die I.H. aktiv war. Weitere Informationen erlangt man über die Datei FMG0_10_evo13.xml.gz. Abbildung 15: Wanderkennung 26
  27. 27. 4.3.2 Kollisionsvermeidung Ein ebenso interessantes Verhalten einiger Roboter ergab eine Simulation mit folgenden Parameterbelegungen: ePS = 80 fEV = 40 Der LIM in Dateiform kann man folgende Metadaten entnehmen: • bmp-Datei: umgebung.bmp • Winkel: 0.01 • Lichtkoordinate: 60.0;60.0 • AnzahlKollisionen: 1 • Lichtintensitaet-Start: 9180.0 Weitere Informationen erlangt man über die Datei FMG0_10_8040Umgebung001.xml.gz. Hier entwickelte sich bei einer Minderheit der Roboter als Verhalten eine Kollisions- vermeidung. Die Roboter lernten somit andere Roboter und Hindernisse zu umgehen. Man könnte sagen, sie versuchten zu überleben, da sie Paarungsversuche vermieden. Leider konnte sich in der momentanen Implementierung des Plugins dieses Verhalten nicht über die Dauer der Simulation halten, da Mutationen dieses Verhalten überschrei- ben konnten, bzw. andere Roboter auf Kollisionskurs zu diesen Robotern gingen und eine Paarung erzwangen. An dieser Stelle sei noch einmal auf die Tabelle 1 auf Seite 12 verwiesen. Abbildung 16: Kollsionsvermeidung: AVI-Snapshot 27
  28. 28. Abbildung 17: Kollsionsvermeidung: Trajektoren 28
  29. 29. 5 Zusammenfassung Abschließend zu dieser Seminararbeit kann man sagen, dass eine indirekte Fitnessfunk- tion durch das Plugin SolarReproduction in FMG realisiert wurde. Bei darauf aufbauenden Simulation kamen erstaunliche Sonderfälle bei den Auswertun- gen, wie die Kollisionserkennung zu Tage. Als auffälligstes Merkmal der Beobachtungen stellte sich die instabile Clusterbilung heraus. Instabil insofern, da durch die räumlich sehr nahe Anordnung der Roboter in lichtintensiven Bereichen, Schneeballeffekte ermög- licht wurden, die neue Verhaltensautomaten explosionsartig in den zuvor etablierten Clustern ausbreiten ließen. Bei den Parametereinstellungen war zu beobachten, dass eine höhere Anzahl an Robo- ter im System den Paarungsdruck erhöhten (idl- und stopp-Automaten bremsten die Evolution weniger stark aus), jedoch durch Kollisionen die Ergebnisse unberechenbarer machten. Da die Paarung auch durch Wände bei zu groß gewähltem Radius stattfinden konnte, wurde schnell klar, dass dieser Wert möglichst gering gehalten werden sollte. Durch Einsatz der I.H. konnten lock-in Situationen bei der Paarung vermieden werden, falls sich Roboter im Schattenbereich festsetzen wollten. Sie machte aber auch die Ergeb- nisse abhängiger von ihr selbst und zum Teil unberechenbarer. Somit wurde sie bei den späteren Simulationen weniger stark eingesetzt. Dasselbe gilt für den harten Roboter- Reset, der einfach zu viele Informationen vernichtete. Die Möglichkeiten des Plugins und die Szenarien mit indirekter Fitnessfunktion bergen noch eine Fülle weiterer Möglichkeiten für weitere Simulationsläufe und anschließenden Auswertungen. Noch ein paar abschließende Worte am Ende dieser Ausarbeitung. In dem ersten Teil der Seminararbeit hat das Buch Computergrafik [4] von Zhigang Xiang und Roy A. Plastock wichtige Denkanstöße für die Erstellung der LIM bereitgestellt, sowie den Grundstein des Plugins gelegt und somit quasi den Stein für diese Seminararbeit ins Rollen gebracht. 29
  30. 30. Abbildungsverzeichnis 1 Aufbau und Ablauf des Plugins: SolarReproduction . . . . . . . . . . . . 5 2 Scanconversion, Reflexion und Optimierung der Kollisionserkennung . . . 7 3 Lichtintensitätsmatrix (LIM) . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Parameterübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5 Clusterbildung: Verteilung der Roboter gegen Beginn der Simulation . . . 21 6 Clusterbildung: Verteilung der Roboter nach x-Zyklen . . . . . . . . . . . 21 7 Instabile Clusterbildung: Mutation nach 300 Zyklen I . . . . . . . . . . . 22 8 Instabile Clusterbildung: Mutation nach 300 Zyklen II . . . . . . . . . . . 22 9 Instabile Clusterbildung: Mutation nach 300 Zyklen III . . . . . . . . . . 23 10 Instabile Clusterbildung: Mutation nach 700 Zyklen I . . . . . . . . . . . 23 11 Instabile Clusterbildung: Mutation nach 700 Zyklen II . . . . . . . . . . . 24 12 Instabile Clusterbildung: Mutation nach 1000 Zyklen . . . . . . . . . . . 24 13 Instabile Clusterbildung: Paramtereinstellungen . . . . . . . . . . . . . . 25 14 Instabile Clusterbildung: Trajektoren . . . . . . . . . . . . . . . . . . . . 25 15 Wanderkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 16 Kollsionsvermeidung: AVI-Snapshot . . . . . . . . . . . . . . . . . . . . . 27 17 Kollsionsvermeidung: Trajektoren . . . . . . . . . . . . . . . . . . . . . . 28 Tabellenverzeichnis 1 Wahrheitstafel - Selektion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2 Parameterauswertung1 - Joschka . . . . . . . . . . . . . . . . . . . . . . 18 3 Parameterauswertung2 - Joschka . . . . . . . . . . . . . . . . . . . . . . 19 4 Parameterauswertung3 - Joschka . . . . . . . . . . . . . . . . . . . . . . 20 30
  31. 31. Literatur [1] P. D. H. Schmeck, L. König, and D. S. Mostaghim. Decentralized evolution of robotic behavior using finite state machines. [2] P. D. H. Schmeck, L. König, and D. S. Mostaghim. Organic computing: Learning robots. [3] N. G. Solomon. Current indirect fitness benefits associated with philopatry in juvenile prairie voles. Behavioral Ecology and Sociobiology, 29:277–282, 1991. 10.1007/BF00163985. [4] Z. Xiang and R. A. Plastock. Computergrafik. mitp, 1 edition, 2003. 31

×