Gruppenmitglieder: Moritz, Fanny, Paul und Alva

Unsere Idee:

Der Evakuierungsplansimulator3000, kurz EVA3000, soll ein Programm sein, welches die Handlung von Menschen in einer Gefahrensituation simuliert. Wir wollen dabei bestimmte Ausgangssituationen näher betrachten, z.B. wie lange dauert eine Evakuierung eines bestimmten Gebäudes? Wie sehen die zeitlichen Unterschiede aus, bei einer geordneten Evakuierung und bei einer, bei der Panik ausbricht durch zum Beispiel Feuer?

Neben dem Programmieren müssen wir uns mit Statistiken von Evakuierungen, Psychologie und mit der Architektur von Gebäuden auseinandersetzen.

Eingabemöglichkeiten bei EVA3000:

1. Personenanzahl x
2. Gebäudegröße y
3. Stockwerkanzahl optional
4. Anzahl der Ausgänge z
5. Paniklevel (suggeriert die Ausgangslage)

Ausgabe:

1. Benötigte Zeit t zum Verlassen des Gebäudes von allen Personen x
2. Zeitpunkt t0, an dem x1 Personen das Gebäude verlassen haben bzw. wie viele Personen x2 noch drinnen sind
3. Mortalitätsrate

Verhalten der Individuen in einer Gruppensimulation:

Das Verhalten eines Individuums in einer Gruppensituation lässt sich berechnen, jedoch muss man viele Faktoren dabei beachten, sodass jedes Individuum schlussendlich seinen eigenen Weg-Zeit-Vektor besitzt. Dabei ist zu erwähnen, dass die Simulation nicht mit hundertprozentiger Zuverlässigkeit das Verhalten von Individuen simulieren kann, da das Verhalten des Menschen sehr komplex und auch emotionslastig ist.

Umsetzung:

Wir simulieren ein Agent Based Model mit dem Social Force Model nach Helbing. Unser Programm hat diverse Eingabefelder zur Skalierung des Raumes, sowie die Anzahl der in dem Raum zu befindenden Menschen. Zur Visualisierung nutzen wir Kivy. Unser Hauptprogramm DrawerApp hat folgende Unterprogramme:

• Agent (class Agent & class Direction)
• Boundery (class Boundery)
• Skaler (class Skaler)
• Mover (class Mover, Social Force)
• Space (class Space)
• Laufweg (Vektorfeld)
• Model (class Model)

Projektverlauf:

Ausführlicher finden sie das alles in unseren Protokollen

Wir haben zwei ausführliche Texte zum Social-Force-Modell nach Helbing bekommen. Anfangs haben wir uns dafür entschieden 2 Gruppen zu bilden. Eine sollte den Raum programmieren, die andere sich intensiver mit dem Text beschäftigen. Anfangs wurde der Raum einfach mit Turtle gezeichnet, was zwar für den Raum alleine recht schön anzusehen war, aber nicht wirklich zu gebrauchen für eine richtige Simulation.
Wir verständigten uns darauf, erstmal mit einem Gebäude, bzw. einem Raum zu beginnen.
Bis zur nächsten Woche sollten alle beide Texte durcharbeiten.

Wir haben uns hauptsächlich weiter mit den Texten beschäftigt, da wir zu wenig Zeit hatten um sie alleine richtig zu verstehen und sie außerdem zu komplex waren. Eine zusätzliche Hürde war das Englische. Außerdem suchten wir im Internet nach bereits umgesetzten Modellen um uns weitere Anregungen zu holen und es weiter zu verstehen.
Die Gruppeneinteilung behielten wir grundsätzlich bei, auch wenn wir sie nicht wirklich einhielten und uns hauptsächlich alle mit dem Social-Force-Modell beschäftigen.

Das Verständnis des Textes bereitete uns nach wie vor große Schwierigkeiten. Wie nahmen einzelne Formeln (Social-Force-Modell nach Helbing,Seite 11/12) detailliert auseinander um sie besser zu verstehen und sie demnach später auch besser in den Code implementieren zu können.
Außerdem haben wir uns vorgenommen, den restlichen Text zuhause auch in ähnlicher Form durchzuarbeiten.

Wir haben uns tiefer gehend damit beschäftigt, welches Programm wir verwenden sollen. Die zuerst nahe liegende Entscheidung war Matplotlib, da wir dies schon kannten. Außerdem hatten wir damit schon eine Modellierung gesehen und hatten schon Materialien. Nach einer Beratung mit Stefan, haben wir uns auf seinen Rat hin für Kivy entschieden.
Dies war komplett neu für uns und wir haben entschieden uns bis zur nächsten Woche einzuarbeiten.

Das Ziel des Tages war einen Raum zu erstellen und Menschen zufällig im Raum zu platzieren und diese dann zu einem bestimmten Punkt laufen zu lassen.
Um dieses Ziel zu erreichen teilten wir unsere Gruppe in Raum Programmierung in Kivy und die gerichtete Bewegung eines Punktes.

• Gerichtete Bewegung:

Wir haben uns das Kivy Beispielprogramm mit einem Thread angeschaut, und eine Richtung eingebaut. Unsere Punkte(Menschen) werden per Klick in unsere Grafik hinzugefügt und bewegen sich darauf hin in die Richtung unseres Zielpunktes (0,0). Die Geschwindigkeit ist dabei gleichbleibend.
Detailiert ist dies in unseren Protokollen nachzuschauen. (Protokoll vom 20.12.18)

• Raum:

Der Raum kam nicht wirklich gut voran, da doch mehr Wissen über Kivy notwendig ist.
Bis zur nächsten Woche: Vertiefung in Kivy

Der Raum wurde fertig gestellt (Siehe Protokoll vom 10.01.19). Außerdem wurde der Mover so abgeändert, dass die Punkte nicht mehr (0,0) ansteuern, sondern den gewählten Türpunkt. Hauptsächlich wurde dann an der Verknüpfung beider Bereiche gearbeitet, was aber nicht fertig geworden ist.

Es wurde ein komplett neues Klassensystem ausgearbeitet. Dadurch gibt es jetzt die Programmteile Space, Agents, Mover, Skaler, Drawerapp. Wobei die DrawerApp das Hauptprogramm ist.

Ein anderer Teil der Gruppe hat sich dagegen noch einmal weiterführend mit den Social-Force-Modellen und deren bisherigen Umsetzungen beschäftigt. Dafür wurden Programme ausgeführt und deren Code betrachtet.

Wir haben den vorhandenen Code überarbeitet und dann die neue Klasse Mover erstellt.
Wir verwenden in unserem Programm das Social-Force Model von Helbing für unser Verhalten unserer Agenten. Dabei haben wir uns zunächst mit der Theorie beschäftigt um zu schauen, wie es sich am besten in den Mover implementieren lässt.
Begonnen haben wir mit der Beschleunigungskraft und der sozialen Kraft.

Der Mover funktioniert. Menschen bewegen sich in die richtige Richtung und laufen nicht in einander. (Details)
Nächste Ziele sind das „verschwinden“ lassen von Menschen, die den Raum verlassen haben, damit die anderen nachlaufen können. Außerdem sollen die geretteten gezählt werden.

Wir haben an einem Optimierungsproblem des Ausganges gearbeitet. Wir müssen für die Tür ein Vektorfeld bestimmen, welches durch zwei Richtungsfunktionen beschrieben wird. Die Transitzone wird durch Optimierungsfunktion annähernd gelöst, damit wir Stetigkeit erhalten. Dadurch haben wir die Direction-Class unter dem Agent-Programm definiert.

Dies brauchen wir, damit unsere Agents sich durch den Ausgang bewegen können und sich nicht stauen, wie es momentan noch der Fall ist. Wir haben eine ExitAgent-Funktion für einen Counter definiert, welcher auch visualisiert wird. Dieser zählt die evakuierten Agents.

Nächstes Ziel: Counter visualiseren und eventuell mit einem Zeitcounter verbinden.

Wir haben wie geplant den Counter der evakuierten Agents erstellt. Außerdem haben wir von Stefan die Vektorfeld erzeugende Funktion bekommen. Diese berechnet für jeden Punkt im Raum den Richtungsvektor für den schnellsten Weg zum Ausgang. Allerdings geraten einige Menschen noch in die Wände. Sobald dies geschieht, bewegen sie sich gar nicht mehr, da sie keinen Richtungsvektor mehr übergeben bekommen. Dies wollen wir mit abstoßenden Kräften beheben.

Ziele sind die abstoßenden Kräfte von den Wänden, einen Timer für die Zeit und Aufteilung des Raumes durch zusätzliche Wände zu implementieren.

Wir haben heute begonnen die Abstoßenden Kräfte von den Wänden einzufügen. Zunächst haben wir uns dabei überlegt, diese ähnlich wie die Abstoßenden Kräfte zu anderen Agents zu definieren. Dafür brauchen wir den Abstand zwischen Boundery und Agent, welchen wir mit der Normalform einer Hilfsebene aus der Vektorrechnung berechnen. Dabei kam das Problem auf, dass Agents, die in die Wand liefen, verschwanden und von oben außerhalb des Raumes wieder zum angestrebten Punkt liefen. Außerdem konnten sie noch durch Wände gehen. Daher haben wir eine Überprüfung eingebaut, welche dafür sorgt, dass sie die Wand maximal berühren können. Außerdem haben wir nun 3 verschiedene Modelle unseres Raumes, von denen man eins per Eingabe beim Ausführen des Programms wählen kann. Davon enthalten die neuen beiden Modelle Innenwände, die den Raum in eine Etage unterteilen. Die Bilder der Modelle finden sie hier

Wir haben neben dem Counter der Evakuierten nun auch einen Zeitcounter eingefügt, der die vergangene Zeit in Sekunden angibt und stoppt, wenn die letzte Person evakuiert ist. Außerdem sind nun beide Counter betitelt. Den restlichen Tag haben wir damit zugebracht, an einer Methode zur Einlesung von Gebäudeplänen zu arbeiten. Diese funktioniert mit turtle, indem man den Plan als Hintergrundbild verwendet und dann mithilfe der onscreenclick-Funktion die Wände durch jeweils 2 Mausklicks markiert und die Koordinaten dieser dann als Boundarys abspeichert. Zum Ende hin haben wir noch mit der Einbindung von dem Modul Pickle begonnen, was das Abspeichern und dann wieder Aufrufen der fertigen Gebäudepläne erleichtert. So können wir dann unseren Evakuierungssimulator auf existierende Gebäude anwenden und so zu unserem ursprünglichen Ziel gelangen, nämlich der Simulation einer real möglichen Evakuierung und anschließend der Optimierung.

Da heute der letzte Tag war, haben wir uns dannach vorallem mit Problemlösungen beschäftigt. Bis jetzt lassen sich die neuen Modelle, welche wir mit Hilfe von Turtle zeichnen können, noch nicht speichern.
Gleichzeitig haben wir uns auf die Präsentation vorbereitet, welche wir am Ende der Einheit alle gehalten haben.

Endgültiger Code

Wir haben noch mit dem gemeinsamen Chatroom begonnen und viele kleine nützliche bzw auch anstrengende Tools programmiert. Zwischendurch gab es sehr leckere, selbstgemachte Pizza.

Fazit:

Das Modellieren und Simulieren von Menschen in Evakuierungssituationen hat uns vor einigen Herausforderungen gestellt, jedoch hat uns dieses Projekt sehr viel näher an die Materie gebracht. EVA3000 kann nun auf der Basis von einem Agent Based Model die Bewegung von Menschen im geschlossenen Raum berechnen und simulieren. Dabei gibt es auch die Möglichkeit verschiedener Raummodelle und wie diese auf unsere Agents wirken und ihr Verhalten in Bewegung und Geschwindigkeit verändert. Schlussendlich ist EVA3000 aber nur eine weite Annäherung an das Bewegungsverhalten, da wir zum einen bewusst einige Faktoren, wie beispielsweise eine Anziehungskraft zu gewissen Objekten, nicht betrachten, zum anderen, da das Verhalten und somit auch die Psyche des Menschens sehr willkürlich sein kann, und die Komplexität bis heute noch nicht vollends ergründet worden ist.

Fehleranalyse:

Wie auch schon oben beschrieben, sind unsere Rechnungen nur Annäherungen an das Verhalten oder der physikalischen Formeln. Insgesamt hatten wir teilweise überhaupt Probleme mit dem Verständnis des Social Force Models, was uns wiederum viel Zeit gekostet hat.

Links (auch im Text zu finden):

Social Force Model nach Helbing

Protokolle

Literatur