Dieses Paper behandelt die Entwicklung eines Sim- ulators, der Agenten mit einem künstlichen Bewusstsein enthält. Dieser Simulator dient zur Entwicklung einer AC die später auf den Volksbot aufgesetzt werden soll. Es werden verschiedene Ansätze zur AC eines Agenten entwickelt, diskutiert und entwickelt. Im ersten Abschnitt wird das erarbeitete Modell des Agenten und das des gesamten Simulators genauer beschrieben. In Abschnitt 2 werden dann einige Testdurchlufe mit mehreren Agenten genauer analysiert und bewertet. Im letzten Abschnitt wird die bisherige Arbeit bewertet.

Nach ausgiebiger Recherche gibt es z.Zt. keine bis nur wenige Assistenzsysteme. Die wenigen Systeme die es zur Un- tersttzung gibt, sind nur begrenzt in Ihrer Flexibilitt und knnen nur wenig bis gar nicht lernen. Systeme die es bereits gibt, ver- fgen grtenteils ber explizites, also Expertenwissen, das fest in den Systemen verankert ist. Durch die Veranstaltung Wissen, im Rahmen des Master-Studiengangs Barrierefreie Systeme - Intelligente Systeme an der Fachhochschule Frankfurt am Main - University of Applied Sciences, wurde uns bewusst, dass wir nur ein lernendes System designen knnen, wenn wir uns mit den Grundlagen des Lernens vertraut machen. Durch die Veranstaltung Wissen gefrdert und in Zusammenarbeit mit Herrn Prof. Dr. Döben-Henisch, der sich bereits eine sehr lange Zeit mit der Materie von lernen Systemen beschftigt, lernten wir die Grundprinzipien der genetischen Programmierung. Im verlauf dieser Studien begegneten wir Learning Classifier Sys- temen (LCS) sowie der Erweiterung der Emotional Learning Classifer Systemen (ELCS). Genetische Programmierung und Classifier Systeme bilden die Grundlage fr die Erstellung eines knstlichen Bewusstseins (Artificial Consciousness) das im gegensatz zu einem Expertensystem die Mglichkeit bi- etet neues zu Erlernen. Da wir kein Wissen vorgeben muss ein jedes knstliches Bewusstsein um zu Lernen, trainieren. Trainieren kann ein jedes System indem es sich in und mit seiner Umgebung interagiert. Durch die interaktion mit der Umgebung kann unser knstliches Bewusstsein, ein jeder Agent, lernen. Um Agenten in Umgebungen beliebig lernen zu lassen, ist es unser Ziel einen Simulator zu entwickeln. Im Verlauf unseres Studiums entwickelten wir bereits einen Simulator der ein Agentenmodel bis inkl. es Ansatzes der LCS beinhaltet und auch realisiert hat. Im Zuge unseres weiteren Studiums kam ein neuer Ansatz hinzu, der des Enhanced Emotional Learning Classifier Systems (EELCS). Die Weiterentwicklung unseres vorhandenen Simulators damit dieser Agenten mit dem EELCS-Ansatz implementiert, beschreibt dieses Paper.

Das Konzept beschreibt die Struktur der lernenden Agenten in ihrer Umgebung (Enviroment). Gleichzeitig zeigt die Ab- bildung 1 auch den Aufbau des Simulators. Die Umsetzung des Simulators erfolgte, wie auch in der Vorgaengerversion, erfolgte mit C++ unter Einsatz der Entwicklungsumgebung QT [2]. Wir entschieden uns fuer die Entwicklungsumgebung QT, da wir mit dieser eine Plattformunabhaengigkeit sowie eine einfache Oberflaechenerstellung realisieren konnten. Dies war fuer uns zu Beginn der Simulatorentwicklung aeuerst wichtig, da wir einen Prototyp realsiert haben, der die Ergebnisse bzw. den Verlauf der Simulation visualisieren kann.

Fig. 1: Simulator-Konzept

Das Environment ist die Umgebung in der die Agenten leben und existieren. Der Agent kann mit seinem Environment agieren, indem er sich darin bewegt, Aktionen ausfuehrt und Feedbacks entgegennimmt. Das Environment wirkt auf den Agenten ein, indem es ihm ueber den Erfolg seiner Aktion Rueckmeldungen gibt. Dies ist natuerlich implizit zu verstehen. Der Agent bekommt natuerlich nicht verbal mitgeteilt das eine Aktion nicht gut oder sehr schlecht war, jedoch kann er z.B. kein Objekt passieren, das ihm im Weg liegt. In un- serem Environment existieren alle Gegenstaende als Objekte. Dies koennen Nahrungsfelder oder auch Hindernisse sein. Das Environment und somit auch die Art und die Anzahl der Objekte, kann entsprechend den Anforderungen an die Agenten angepasst werden.

Der Filter, den es zwar in einer vereinfachten Form bereits im vorherigen Konzept gab, wird im neuen Konzept als eigene Komponente angesehen. Der Filter filtert alle Eingehenden Inputsignale die von den Sensoren empfangen wurde und gibt nur die relevanten Daten weiter.

Der Agent in der aktuellen Version 2 (EELCS) (hier: Agent) ist ein Agent dessen Struktur auf der des ELCS aufbaut. Der Agent hat ebenfalls wie sein Vorgaenger innere Zustaende (Drives) und wird noch zusaetzlich mit einem Gedaechtnis (5) ausgestattet. Der Agent kann sich durch das Enviroment bewegen und hat hierfuer insgesamt neun Bewegungsmoeglichkeiten. Der Agent steht hierbei auf Feld 5.

Fig. 2: Bewegungsmoeglichkeiten

Des weiteren kann sich der Agent nun auch ohne eine eigentliche Bewegung zu machen, zunaechst einmal in einer Richtungen 3 umschauen (Blickrichtung nur in die Richtung der gruenen Felder). Dies ist jedoch nur dann Sinnvoll, wenn der Agent ein eingeschraenktes Sichtfeld 4 hat. Da der Agent nun auch die Moeglichkeit erhaelt nur eingeschraenkt zu sehen muss nun auch die Richtung in die er sieht, festgelegt werden. Der Agent erhaelt somit nun auch eine Richtung in die er aktuell schaut.

Fig. 3: Blickrichtungen

Fig. 4: Sichtfeld

Gruen: Sichtfeld. Gelb: eingeschrnktes Sichtfeld (Peripheres Sichtfeld). Rot: kein Sichtfeld.

Die Sensoren bilden die Input Einheit welche das sogenan- nte Perception (PERC) entgegen nimmt. Dabei erhalten die Sensoren alle Daten die Sie auf Grund ihres Aufbaus deuten bzw. entgegen nehmen koennen. Hinter die Sensoren wird aber noch ein Filter geschaltet, der die Daten selektiert und nur diese selektierten Daten weiter gibt. Diesen Prozess kann man an einem kleinen Beispiel verdeutlichen. Ein Hund sieht im Gegensatz zum Menschen nur schwarz/wei, wogegen der Mensch immer alles in Farbe sieht. Diese Ein- schraenkung wuerde direkt mit den Sensoren realisiert werden. Der Fokus des menschlichen Auges, d.h. das der Mensch nur im Fokus scharf sieht, wuerde dagegen mit einem Filter realisiert werden.

Die Aktoren fuehren den Output (die Aktionen) des Agents aus, d.h. ber die Aktoren bestimmt der Agent seine Aktionen in dem Enviroment. Dabei werden die Informationen von vom kuenstlichen Bewusstsein zur Verfuegung gestellt.

Fig. 5: Memory

Unser Memory bildet unser Gedaechtnis ab. Das Gedaechtnis ist ein Tupel aus unserer Wahrnehmung (σ), einem Beduerfnis (Drive (δ), einer ausfuehrenden Aktion (ξ) und einer Lebensdauer (κ). < σ, δ, ξ, κ > σ bildet die aktuelle Wahrnehmung eines Agenten ab. Das σ erhaelt der Agent vom Mapper und ist somit bereits gefiltert. δ ist der Vektor der aktuellen Beduerfnisse ξ bildet die vorher gegangene Aktion ab. κ steht fuer die Lebensdauer des Eintrags und wird bei Neuerstellung eines Eintrags immer auf 10 gesetzt und je Zyklus um 1 dekrementiert. Wie zu vor beschrieben besitzt der Agent einen Default Drive, den sogenannten Play Drive. In diesem Drive lernt der Agent ohne einen wirklich aktiven Drive zu besitzen und kann Informationen im Memory abspeichern. Wenn der Agent einen aktiven Drive besitzt vergleicht dieser die Eintraege im Memory mit uebereinstimmung auf folgenden Komponenten: < σ, δ > Findet der Agent solch einen Eintrag im Kurzzeitgedaechtnis fuehrt er da dazu gehoerige ξ aus und erhoeht das κ. Lernt der Agent etwas Neues so wird < σ,δ,ξ,κ > mit Wert κ = 10 eingetragen. Falls κ ¿ 10 wird, wird der Eintrag in das Langzeitgedaechtnis wieder mit κ = 10 uebernommen.

Der Drive bildet ein Beduerfnis des Agenten ab. Vergleich- bar mit uns Menschen hat er Beduerfnisse die er Stillen muss. Ein Beduerfnis ist immer abhaengig von einem Energie-Wert. Energie kann hierbei alles sein. Wenn wir davon ausgehen, dass unser Beduerfnis das Stillen von Hunger ist, dann ist der Energie-Wert der das Beduerfnis auslaesst ein zu niedriger Energiewert. Da der Agent mehrere Beduerfnisse haben kann, besitzt jeder Agent eine Liste (Vektor) aus Drives.

Die Energie spiegelt einen Wert wieder den der Agent besitzt. Im Zuge unserer ueberlegungen sind wir auf die Idee gekommen, den Drive und die Energie in eine Gemeinsame Struktur abzubilden. Hierbei ist dann die Energie nicht mehr direkt Energie, sondern eher ein Energie-Level fuer verschiedene Beduerfnisse. Im Falle des Hungers (Beduerfnis: Essen, Futter suchen) kann es natuerlich Energie im eigentlichem Sinne sein, wenn wir hier vom Strom ausgehen. Unser Drive-Vektor wuerde folgendermaen aussehen:

Immer wenn die Energie-Value kleiner dem Level (Schwell- wert) ist, wird der entsprechende Drive aktiviert. Damit es jedoch zu keinen Blockade kommt und sich die Beduerfnisse gegenseitig blockieren, gibt es eine implizierte Prioritaet.

Iteriere ueber alle Drives beginnend mit n = 1 und waehle den Drive mit der groeten Energie-Treshhold differenz.

Fuer die drei dimensionale visuelle Darstellung der Simulator-Berechnungen wird die Grafik-Bilbliothek OpenGL verwendet. Diese Bibliothek bietet den Vorteil, dass es ein offener (open source) und vorallem ein wissenschaftlich an- erkannter Standart ist, welcher sich fuer diverse (u.a. drei dimensionale) Visuelle Darstellungen eignet.

Die visuelle Darstellung des Agenten bzw. des Block- Objekts (vom Agent nicht passierbares Objekt) wird in Form eines Wuerfels mit verschieden definierten Texturen wiedergegeben. Ereignis-Objekte werden in Form einer Flaeche dargestellt. Alle dynamischen Objekte (Agent und ggf. Ereignis-Objekt) bewegen sich in Abhaengigkeit der Simulator-Berechnung (Koordinaten), welche ueber den Map- per angefordert werden koennen, durch eine definierte Umge- bung (Environment). Das Environment wird als Raster (Groee in Abhaengigkeit des Szenarios) in OpenGL visualisiert ist. Statische Objekte (Block-Objekt und ggf. Ereignis-Objekt) werden in Abhaengigkeit des Szenarios im Environment plaziert. bergangseffekte wie die Bewegung des Agenten von einem Rasterfeld in ein anderes, wird durch OpenGL (glwidget Klasse) berechnet und gerendert. Des weiteren kann ueber das Eingabegeraet PC-Maus die Betrachtungsweise der Simulator Visualisierung geaendert werden (Zoom und Drehung des Environments).

Die Entwicklungsumgebung Qt enthaelt eine integrierte OpenGL Version (QGLWidget). Wird die QGLWidget-Klasse eingebunden bzw. davon geerbt stehen alle noetigen OpenGL- Funktionen zur Verfuegung. Im folgenden eine Zusammenfas- sung der verwendeten GL-Funktionen: glViewport - Positionierung und Format(Hoehe, Breite) des OpenGL-Window • gluPerspective - Einstellung der Sichtperspektive • glShadeModel(GL SMOOTH) - Grafische Feinheits-Einstellung • glTexParameteri (GL TEXTURE 2D,GL TEXTURE MIN FILTER,GL LINEAR) -Texturen • glBegin(GL QUADS) - Verwendeter Polygon-Typ um Wuerfel zu erstellen

Die realisierte Version des Agent muss noch ausgiebig getestet werden um fest zu stellen ob die Behandlung der Threshold Werte der Drives und die κ Werte fuer das Mem- ory auch so richtig bewertet sind. Moeglicherweise ist der Agent in der aktuellen Version noch zu vergesslich und Informationen aus dem Kurzzeitgedaechtnis gehen zu schnell verloren, so dass sie ueberhaupt keine Chance erhalten in das Langzeitgedaechtnis gespeichert zu werden. Diese Werte koennen aber nur mittels Evaluation genau bes- timmt und angepasst werden.

Die vorgestellte Technik OpenGL kann bei nicht optimierter Programmierung ein schlechtes Frames per Second Resultat liefern. Da die Visualisierung des Prototyps (APS-Simulators) nicht optimiert wurde (d.h hardcodierte Mesh-Objekte, keine GL-List-Aufrufe, etc.), besteht die Moeglichkeit (abhaengig des Grafikartenmodells), das die Frames per Second nicht ausreichen und es einen zuckenden Bild-Effekt zur Folge hat. Loesungsansatz: In einer Weiterentwickelten Version des APS-Simulators werden aus Performance-Gruenden ausschlielich Triangles-Polygone verwendet. Des Weiteren sind Bewegungsablaeufe (GL-Rotation, -Transition) ueber Matrizen realisiert und Mesh-Objekte dynamisch ueber Dateien einlesbar. Alle genannten Punkte verbessern die Performance der Visualisierung (Frames per Second) 1) Performance erheblich. Problem: 2) Ego-Perspektiven Realisierung: In Ausblick auf die Vorstellung, dass Menschen in Form eines Avatars den Sim- ulator betreten koennen ist es essentiell eine Ego-Perspektive einzufuehren. Dies garantiert die Gleichstellung (im Bereich: Sicht-winkel und -weite) gegenueber dem Agenten, welcher ebenfalls eine eingeschraenkte Sichtweise besitzt (in Ab- haengigkeit der Konfiguration des Agenten). Ein netter Neben- effekt ist das Beobachten eines Agenten, d.h. wirklich das mitzuerleben was der Agent sieht. Loesungsansatz: Diese Erweiterung ist ebenfalls in der weit- erentwickelten Version des APS-Simulators realisiert wor- den. Die Schwierigkeit liegt in der Berechnung der dy- namischen Objekte, welche durch einen Sichtwechsel (Ego- Perspektive) Ueber diverse Matrizenfunktionen neu berechnet werden muessen. Grund hierfuer ist, dass in OpenGL die Welt so angepasst (rotiert bzw. transitiert) werden muss, dass fuer den Betrachter der Eindruck einer eigenen Bewegung entsteht.

Fig. 6: OpenGL Visualisierung EGO Perspektive

Der Simulator funktioniert mit dem entwickeltem Konzept und bietet viele Moeglichkeiten fr neue Ideen und zur Weiterentwicklung. Der neue Name des Simulators lautet im Zuge des Loewe Projekts und der Fertigstellung mit dem Agent2: APS Simulator (Abrami-Pfaff-Struwe Simulator)

Die folgende Abbildung zeigt einen Prototyp des Simulator mit gerendeter Visualisierung.

Fig. 7: OpenGL Visualisierung APS Simulator

[1] Professor Dr. G.Doeben-Henisch, Stand 26.11.2010www.uffmm.org/science- technology/single/themes/computer- science/ personal- sites/doeben-henisch/KNOW/GBBLT/gbblt/index.html [2] QT-Internetseite. Stand 10.02.2011 http://qt.nokia.com/ [3] Giuseppe Abrami, Marcus Pfaff, Marvin Struwe, aiips projekthandbuch SS10.pdf, Abschlussbericht SoSe 2010