Rescue team simulation Multiagentensystem I. M., Christian Lange, U. P.

Gliederung Aufgabe Umsetzung Entity-Package Control-Package Agenten Unterschiede/Funktion Umsetzung Entity-Package Control-Package GUI-Package

Gliederung (No)CollisionNoCoordination Agenten search-Algorithmus (No)CollisionCoordination Agenten Erweiterungen, Verbesserungen Programmvorstellung Ergebnisse der Simulation

Aufgabe MAS zum Retten von Unfallopfern Survivor Agent Verschlechtert seinen Gesundheitszustand mit einer Wahrscheinlichkeit von 60% je Zeiteinheit Ausgangsgesundheit globaler Parameter Agent Random NoCollisionNoCoordination CollisionNoCoordination NoCollisionCoordination CollisionCoordination

Agenten Random Bewegen sich zufällig Strafversetzung beim Kollidieren mit anderen Agenten Survivor gerettet durch Betreten des Feldes A S A

Agenten NoCollisionNoCoordination / CollisionNoCoordination Bewegen sich mittels intelligente Algorithmen Kollisionen Vermeiden Strafversetzung Survivor werden gerettet durch Betreten des Survivor-Feldes Einer einen rettet A S A

Agenten NoCollisionCoordination / CollisionCoordination Bewegen sich mittels intelligente Algorithmen Kollisionen Vermeiden Strafversetzung Rettet den Survivor durch Umkreisen dieses A S A S A S

Aufgabe Einstellungen Anzahl der Agenten Anzahl der Survivor Größe des Feldes Episoden Eine Episode beendet, wenn alle Survivor gerettet worden sind Statistik Durchschnittliche Rettungszeit Durchschnittliche gerettete Survivor je Agentenart

Umsetzung Erarbeiten der Agentenfunktionalität Recherche nach ähnlichen Projekten Sehr komplexe Algorithmen Klassendiagramm erstellt - Implementierung des Simulators Aufgabenverteilung

Aufgabenverteilung I. M. U. P. Christian Lange Erstellen des CollisionManager Erstellen der NoCollisionNoCoordination/ CollisionNoCoordination Agenten Implementieren der abstracten Agenten, Teams Team Agenten (NoCollisionCoordination/ CollisionCoordination Agenten) Erweiterung Rescued Manager Grafische Darstellung der Welt und der Agenten Grafische Auswertung der Ergebnisse Implementieren der abstracten Agenten, Welt, Surviors, Random Agenten, Rescued Manager

Entwicklungsumgebung Java 1.5 Update 9 Plattformunabhängig Eclipse 3.2.1 Freeware Bibliotheken JFreeChart

Entity-Package Entity-klassen sprechen (die die daten kapseln)

World Klasse, welche die Welt repräsentiert kapselt Teams und Survivor Enthält das „Spielfeld“ Field-Objekte Was befindet sich auf dem Feld? Was ist der Zustand des Feldes? explored? Klasse, welche die Welt repräsentiert indem kapselt Teams und Survivor Enthält das „Spielfeld“ Besteht aus Field-Objekte enthält/gibt an Was befindet sich auf dem Feld? (Survivor, Agent, Wand)  welcher Agent/Survivor Was ist der Zustand des Feldes? Explored/Notexplored?  am anfang alle Notexplored und immer wenn ein Agent ein Feld sihet wird es Explored

Team Ein Team für jede Agentenart Enthält die Agenten Besitzt die „TeamWorld“ Steuert Agenten und gibt Anweisungen des Systems weiter Stellt globale Teamvariablen bereit Kommunikation innerhalb des Teams Teams konkurrieren Team  hat die World Gilt für alle Für jeden Agentenart existiert ein Team Team enthält die Agenten  jeder Agent ist in einem Team (RandomAgent  RandomTeam) Dem Team gehört ebenfalls die Teamwelt.  Welt wie sie das Team es sieht, eintragungen explored in der Teamwelt, Fieldobjekte Teamwelt ist eine Art „Karte“, in der alle Ageten ihre Entdeckungen in der Welt eintragen können. (also Mauern, Survivor, ?andere –agenten? eigentl nicht?!) Dient als eine Art Kommunikationsmittel, tauschen Entdeckungen aus  jeder an alle ( Teammitlgieder)weiter, was er gefunden hat (Somit sind dem gesamten Team, also allen Agenten alle Survivor bekannt.) Das Team steuert zu dem die Agenten und gibt Anweisungen des Systems an sie weiter (besitzt dafür spezielle Methoden)  zwischenschicht zw. System und Agenten stellt für die Agenten globale Team-Parameter/Variablen bereit. Kommunikation innerhalb des Teams Teams konkurrieren  kommunizieren nicht mireinander

Agent & Survivor Agent Survivor ID Aktuelle Position Zielpositon nearestSurvivor Survivor Gesundheitszustand rescued Agent (im Team)  verschiedene Arten u.a. ID aktuelle Position nach Überlegung (optimaler survivor) Zielposition nearestSurvivor  Survivor (in der World) Gesundheitszustand  regelmäßig verhslchter Rescued  ob schon gerettet der nicht wir löschend die nicht sondenr setzen variable  warujm?  Jetzt christian gui package:

Control-Package

Control-Klassen „RescueSystem“ Manager steuert den Ablauf in einem Zeitschritt & in den Episoden ruft die Manager auf Manager „CollisionManager“ Prüft, ob Kollisionen und löst diese „RescuedManager“ Prüft, ob Survivors gerettet wurden RescueSystem steuert den Ablauf in einem Zeitschritt & in den Episoden ruft die Manager auf Manager CollisionManager Prüft, ob Kollisionen und löst diese  Collision-Agenten strafversetzen  NoCollision-Agenten Kommunikation zur Lösung RescuedManager Prüft, ob Survivors gerettet wurden:  NoCoordination: ob Agent auf Survivor draufsteht  Coordination: ob Agenten den Survivor umkreisen

„RescueSystem“ steuert den Ablauf Nachricht an die Teams Agenten „sollen sich umschauen“ & ihre „Wunschposition“ Aufruf „CollisionManager“ Agenten auf nächste Position updaten der World/TeamWorld Felder setzen (durch Teams) „RescuedManager“ Gesundheitszustand der Survivors verändern GUI neu zeichnen RescuedManager prüft ob Agenten Survivors befreit haben und nimmt diese aus dem Spiel und speichert sich für die Statistik ab wer den Befeit hat Steuert den Ablauf Nachricht an die Teams Agenten „sollen sich umschauen“ & ihre „Wunschposition“ Aufruf CollisionManager (Kollisionen bzw. Strafversetzung) geht auf eure nächste Position updaten der Welt Felder setzen RescuedManager prüft ob Survivors gerettet wurden und nimmt diese aus dem Spiel Gesundheitszustand der Survivors verändern GUI neu zeichnen

GUI-Package

GUI Swing JMenuBar JToolBar JTabbedPane JPanel

Einstellungen Anzahl der Agenten Sichtweite Wahrscheinlichkeit Gesundheitszustand Anzahl der Survivor Anzahl der Episode und die Pausenzeit

Statistiken 3 Arten Implementiert Ø gerettete Survivors je Agent pro Episode je Team pro Episode Ø Zeit für das Retten eines Survivors Exportieren und Drucken der Diagramme

(No)CollisionNoCoordinationAgent I. M. A S A Ines Moosdorf, Christian Lange, Ulrike Plötner

Einleitung NoCollisionNoCoordination & CollisionNoCoordination Beide gleiche Art, um Survivor zu befreien  haben beide gleiche Algorithmen Unterschied nur bei Kollisionskonfliktlösen Sind keine Individualisten, sondern kommunizieren NoCollisionNoCoordination/ CollsionNoCoordination zwei von den genannten Roboterarten, Sie befreien beide ihre die Survivor, indem sie auf deren Feld drauflaufen  gleiche Algorithmen (erstmal, kann später optimiert werden) Ihr unterschied besteht lediglich darin, dass NoCol Konflikte bei Collisionen löst Col  wird strafvestzt trotzdessen das NoCoordination kein Individualist, d.h. ncht jeder sieht was und entscheidet für sich, da geh ich jetzt hin, sondern sie kommunizieren gemeinsam und entscheiden, wer welchen Survivor nimmt

Ablauf Agent Sensorik Überlegung Aktorik Während einer Zeiteinheit, finden folgende Schritte statt/ tut jeder Agent folgendes: …sensorik = wahrnehemen der Umgebungupdaten der alten sensordaten, Überelegung: aus den sensordaten  entscheidung treffen bzw. nach denken was zu tun Aktorik: aufgrundlage der Übrlegung  Aktion ausführen

Sensorik Agent: lookAround() schaut sich x Kästchen weit um trägt Entdeckungen in TeamWorld ein /Sensoring dafür besitzt der Agent die methode lookAround() dabei schaut isch der Agent z.Zt. ein Kästchen weit um (globale Variable, die entfernung angibt, für alle gelich) gibt das was er gesehen hat in der Teamwelt bekannt bzw. trägt es in die Teamwelt ein  Kommuniziert über die Karte sozusagen mit dem Team, gibt es so allen Agenten bekannt

Überlegung Team: findDestinations() Agent: kürzeste Wege für alle Agenten zu allen Survivors ermittelt Utilities übergibt diese Daten dem Agenten Agent: berechnet daraus „Expected Utilities“ und bestimmt damit seinen optimalen Survivor Team besitzt eine Methode findDestinations() Am ende hat jeder Agent ein nächsten Schritt/Ziel, was er als nächstes tun wird darin zunächst: das Team ermittelt für alle Agenten die kürzesten Wege zu allen Survivern.  über einen rekursiven kürzesten Wege Algorithmus Desweiteren ermittelt er die Utilities(Wert), den die Aktion hat, wenn ein Agent einen bestimmten Survivor rettet. ( Gesundheitszustand: je schlechter desto höher Utility) Diese Informationen übergibt das Team dann den Agenten  d.h. er gibt jedem Agente nur die Information über sich selbst weiter Agent berechnen daraus seine expected Utility (aus den Utilities und den kürzesten WEgen)  abwägen kürzester Weg Gesundheitszustand Und bestimmt damir den survivor den er als nächste retten möchte

Berechnung „Expected Utility“ = Probability x Utility P.. Probability S.. Summe aller kürzesten Wege eines Agenten k.. Kürzester Weg zum aktuellen Survivor Utility.. Kehrwert des Gesundheitszustand des Survivors Probability*Utility  also nicht summe, weil sinnlos Probability = (Summe aller kürzesten Wege eines Agenten – wegZumAktuellen Survivor)/(Summer aller kürzesten Wege)  Bedeutet je näher ein Survivorist, desto höher die Probability Utility.. Kehrwert des Gesundheitszustand des Survivors ,unbekannte Felder (das evtl auch zu Probability) Evlt Wahrscheinlichkeit mit einberechen, dass sich sein zustand verschlechtert Gesundheitszustand nimmt in jede rzeit einheit mit einem bestimmten wahrscheinlichkeit ab /* Bsp: ###### S1=(15-7)/15 = 0,53333 #W#### S2=(15-3)/15 = 0,8 #WA##S S3=(15-5)/15 = 0,66667 SW#W## #W#WWW #W##S# ###### */

Kommunikation zwischen den Agenten wird vom Team angestoßen klären, wer welchen Survivor bekommt für jeden Survivor ein Agent (s=a) wenn weniger Survivor als Agenten  die besten laufen zu den Survivors & die restlichen durchsuchen andere Felder (search()) wenn noch kein Survivor  Agent ruft search()-Methode auf  Wenn Jeder Agent seinen optimalen Survivor gefunden hat: wird vom Team angestoßen klären, wer welchen Survivor bekommt fü<r jeden Survivor ein Agent (s<=a) A>s  nicht für jeden survivor ein Agent wenn weniger Survivor als Agenten  die besten laufen zu den Survivors & die restlichen durchsuchen andere Felder (search()) wenn noch kein Survivor  Agent ruft search()-Methode auf

Kommunikation zwischen den Agenten - Details jeder Agent hat seinen optimalen Survivor (weis wo er am liebsten hingehen würde) Vergleich, ob auch ein andere Agent diesen Survivor als optimalen hat (1) Alle Verglecihen („scrollen“) trifft für keinen zu (Schleife für alle durchlaufen)  Agent bekommt seinen Survivor fest zugeordnet (d.h. keiner kann ihn ihm wegnehmen) Zweiter: Findet Agent der den gleiche Survivor hat wie er Agent, den er findet hat den Survivor aber schon fest zugeordnet bekommen (aktuelle) Agent muss sich einen neuen Survivor suchen (nicht wegnehmen) neuer ja: von vorn mit allen Agentne vergleichen nein: noSurvivorfound gesetzte / bekommt keine survivor zugeordnet search, Dritter A3 findet Agentne a4 der den gleichen optimalen survivor hat Agenten a4 der noch keinen Survivor fest zugeordent bekommen hat, (hat algorithmus noch ncith durchgeführt) Dann vergleicht a3 ob a4 eine höhere eu für den survivor als erhat als er ja: a3 muss sich einen neuen survivor berechnen neuen gefunden? ja: von vorn vergleichen nein: noSurvivorFound(bekommt keien Survivor zugeordnet)  search nein (a3 besser): weiter mit den anderen vergleichen a5 … viertens Hat ein Agent beim vergleich immer eine höhere eu (zweig)  while schleivfe durhclaufen und immer er der beste dann bekommt auch er seine Survivor festzugeordnet

Nächster Schritt Agenten, die einen Survivor festzugeordnet bekommen haben: Nächste Position: Feld, welches näher am Survivor dran ist als ihr aktuelles Feld Agenten, die keinen Survivor haben: search()-Algorithmus: solange in eine Richtung gerade aus laufen, bis sie gegen eine Wand laufen Nachdem Kommunikation abgeschlossen ist: Agenten, die einen Survivor festzugeordnet bekommen haben: Nächste Position: Feld, welches näher am Survivor dran ist als ihr aktuelles Feld Agenten, die keinen Survivor haben: search()-Algorithmus: solange in eine Richtung gerade aus laufen, bis sie gegen eine Wand laufen (oder kollidieren)

Kollisionsprüfung CollisionManager Control-Klasse solveCollisions() hat jeder seienn Agenten und wie wlechen Scrhitt er machen muss um am schnellsten zu dem survivor zu kommen bzw. search hat feld ermittelt dann beginnt das system die Kollisionen zu prüfen. Mit Hilfe des CollsionManagers, Controller-Klasse solveCollisions() Collision-Agenten werden bei Kollision strafversetzt NoCollision-Agenten: nach Feldern sortiert, alle an einem Feld beteiligten kommunzieren, entscheiden nach prioritäten wer das feld bekommt und was die anderen machen legen für ihr Kollisionsfeld ein Collision-Objekt an und alle die einem bestimmten Collision-Objekt angehören,kommunizieren zusammen und lösen den Kollisionskonflikt

Aktorik Team: moveAllAgents() Agent: move() Ruft move() der Agenten auf ändert Status der Felder in der TeamWorld und in der „echten“ Welt  Änderung in der Umgebung Agent: move() Gewünschte Position wird zur aktuellen Position  Änderung im Agenten wenn alle Collsionen gelöst sind, Team: moveAllAgents() Ruft move() der Agenten auf ändert Status der Felder in der Teamwelt und in der „echten“ Welt  Änderung in der Umgebung Agent: move() Gewünschte Position wird zur aktuellen Position  Änderung im Agenten (inneren Status)

TODO – (No)CollisionNoCoordination search()-Algorithmus nicht optimal NoCollision-Agenten  Kollisionsalgorithmus Utilities Was wenn weniger Survivor als Agenten vorhanden bzw. keine Survivor entdeckt  Implementierung eines serch-Algorithums, über den Ulrike gleich erzählen wird Algorithmus für Collision-Objekt Systemanpassen, dass CollisionNoCoordination funktionsfähig

(No)CollisionCoordinationAgent U. P. A S A S A S Ines Moosdorf, Christian Lange, Ulrike Plötner

Ablauf lookAround findDestinations move

findDestination findDestination search coordinateRescue if no survivor found else search coordinateRescue

search definiere geradeaus not possible while possible laufe geradeaus

Grundgedanken Einteilung der Agenten in Rettungsteams ANIM – AgentsNotInMission SNIM – SurvivorsNotInMission SIM – SurvivorsInMission

findDestinations() findDestinations() { checkDisappearedSurvivors(); checkNewSurvivors(); coordinateRescue(); }

coordinateRescue() SIM: calcNextPositionRescueTeam() Bildung der Rettungsteams aus ANIM wenn es SNIM gibt: calcAgentsForRescue() calcShortestWays() putPrioritySurviovrInMission()

Erweiterungen CollisionManager Sichtweite der Agenten momentan können sie hinter Mauern sehen

Erweiterungen

Verbesserungen search-Algorithmus Coordination-Agents: flexiblere Teams prioritySurvivor

Programmvorstellung

Ergebnisse der Simulation

Ergebnisse der Simulation

Ergebnisse der Simulation Größe 30x30 2 RandomAgents 1 CollisionNoCoordinationAgent 3 CollisionCoordinationAgent Sichtweite 2 Survivors 30 Episoden 10