Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

--- ws1617:optimierung_des_verkehrs [2017/09/22 06:08]
konstantingroll [Verbesserte Darstellung]
+++ ws1617:optimierung_des_verkehrs [2017/09/27 13:25] (aktuell)
dostuffthatmatters [Ein neues Sichtmodell]
@@ Zeile 157: / Zeile 157: @@
 ==== Darstellung ====
 Die Darstellung mit Tkinter ist weiterhin nicht optimal, da Tkinter nicht mit GPU Beschleunigung, sondern nur auf der CPU rechnet. Jedoch reicht dies für die weitere Entwicklung aus, da hier nicht der Bottleneck der Simulation liegt. Allerdings ist die maximale Bildrate einer sich permanent erneuernden Grafik in einem Tkinter Canvas bei etwa 60 bis 70 Frames pro Sekunde. Der Nachteil daran ist, dass die Performance der Simulation nicht auf Anhieb  einsehbar ist, da eine halb so rechenaufwendige Version nicht doppelt so viele Frames simulieren kann. Um den Fortschritt schnell zu sehen simulieren wir dazu ausreichend Fahrzeuge, sodass der Bottleneck wieder die Simulation und nicht die Darstellung ist.
+Daher verwenden wir den bisherigen Initialisierungs-Code weiter. Die Klasse ModifiedCanvas wird im Folgenden noch näher erläutert.
 <code python>
@@ Zeile 167: / Zeile 169: @@
 self.cv.bind("<Button-1>", self.pause_)
 </code>
+Um einen Frame der Simulation zu simulieren, rufen wir die Funktion “draw“ auf. Am Ende dieser Funktion (innerhalb) wird mit dem folgenden Befehl die Funktion wieder aufgerufen. Der Vorteil daran ist, das sie auf diese Weise nicht unendlich rekursiv ist.
+<code python>
+self.main.after(time, draw)
+</code>
+Die Anzeige wird jedes Mal erneuert, aber die Simulation läuft nur weiter, wenn die Variable “self.contin“ wahr ist.
 ==== Programmierung ====
 Eine weitere große Schwachstelle ist, dass wir zuvor nicht besonders objektorientiert programmiert haben und sehr viele Variablen und Objekte „hard-coded“ sind (Objekte werden nicht anonym und automatisch im Programmfluss erzeugt, sondern manuell und je nach Szenario erzeugt und wirklich benannt). Das ganze Raster ist keine Instanz einer Klasse, sondern alles basiert auf handgetippten Variablen auf.
@@ Zeile 195: / Zeile 205: @@
 {{:ws1617:bedingte_ampel_einfach.png|}}
-Dieses Konzept kann man beliebig erweitern indem man z.B. beim links Abbiegen alle Autos die an einer roten Ampel warten ignoriert. Dazu braucht es lediglich eine Unterscheidung zwischen den beiden Kontrollbereichen und eine Abfrage der Ampel.
+Dieses Konzept kann man beliebig erweitern indem man z.B. beim Linksabbiegen alle Autos die an einer roten Ampel warten ignoriert. Dazu braucht es lediglich eine Unterscheidung zwischen den beiden Kontrollbereichen und eine Abfrage der Ampel.
 {{:ws1617:bedingte_ampel_erweitert.png|}}
@@ Zeile 212: / Zeile 222: @@
 Ein Nachteil an dieser Methode bleibt jedoch noch, setzt man die Abweichung des Sichtbereiches auf einen festen Wert wie z.B 1°, dann kann es bei einer hohen Sichtweite vorkommen, dass Autos auf der entgegenkommenden Spur als Hindernisse wahrgenommen werden. Setzt man die Abweichung auf einen zu kleinen Wert wie z.B. 0,1°, dann kann es durch Rundungsfehler sein das Hindernisse übersehen werden.
-Um diese beiden Szenerien zu verhindern muss die Abweichung des Sichtvektors abhängig von
+Um diese beiden Szenarien zu verhindern muss die Abweichung des Sichtvektors abhängig von
 der Distanz sein: Zunächst wird die Distanz bestimmt; die Spurbreite ist bekannt. Dann gilt:
 <code python>
@@ Zeile 222: / Zeile 232: @@
 Das Raster ist in der Klasse “ObstacleGrid“ ein 3 dimensionales Numpy array “self.chunks“, das in jeder Liste alle Elemente als Integer-Zahlen enthält. Jeder Integer steht für ein Objekt, dessen Referenz in dem Dictionary "self.obstacles" gespeichert wird. Dieses Referenz weist jedoch nicht direkt auf das Objekt, sondern auf ein Hilfsobjekt, das die für die Sicht notwendigen Variablen enthält. Ohne dieses Zwischenobjekt könnten Autofahrer nicht wissen, welche Seite einer Ampel sie sehen und würden eine Ampel theoretisch von hinten sehen. Dies würde beim Abbiegen oft zu abruptem Abbremsen führen. Bei Autos braucht es dieses Zwischenobjekt nicht, jedoch haben wir es aus Gründen der Einheitlichkeit auch implementiert.
-Um einen Pool an mölichen Integer Kennung zu haben, aber nicht immer neue erzeugen zu müssen regelt die Raster-Klasse das mit zwei Listen für freie und benutzte IDs:
+Um einen Pool an möglichen Integer Kennung zu haben, aber nicht immer neue erzeugen zu müssen regelt die Raster-Klasse das mit zwei Listen für freie und benutzte IDs:
 <code python>
 self.freeIDs = range(255)
@@ Zeile 361: / Zeile 371: @@
 </code>
-Die nächste Baustelle in dieser Klasse ist der Zoom. Die Elemente werden bis jetzt nur von der Linken unteren Ecke aus vergrößert, Ziel ist es das man wie bei einer Karte - z.B. Google Maps - wirklich in bestimmte Punkte reinzoomen kann und auch die Pfeiltasten zum navigieren verwendet werden können.
+Die nächste Baustelle in dieser Klasse ist der Zoom. Die Elemente werden bis jetzt nur von der Linken unteren Ecke aus vergrößert, Ziel ist es das man wie bei einer Karte - z.B. Google Maps - in bestimmte Punkte reinzoomen kann und auch die Pfeiltasten zum navigieren verwendet werden können.
 Mögliche Weiterentwicklungen wären auch:
@@ Zeile 372: / Zeile 382: @@
 ===== Cython =====
-Wir haben ebenfalls mit Cython programmiert, die Dateien dafür befinden sich im Build 5.07 in dem Ordner "Hindernissicht". Jedoch benutzen wir die Dateien noch nicht; die Funktionen PYdistance und PYdirection in V07_Helper_Functions.py sind die gleichen Funktionen, bloß ganz in Python geschrieben. Wir haben gerade keine Geschwindigkeitsprobleme, sodass wir auch die Python Funktionen benutzen können. Es wäre jedoch kein großer Schritt, einige Funktionen in Cython zu benutzen.
+Wir haben ebenfalls mit Cython programmiert, die Dateien dafür befinden sich im Build 5.07 in dem Ordner "Hindernissicht". Jedoch benutzen wir die Dateien noch nicht, die Funktionen PYdistance und PYdirection in V07_Helper_Functions.py sind die gleichen Funktionen, nur vollständig in Python geschrieben. Wir haben aktuell keine Geschwindigkeitsprobleme, sodass wir auch die Python Funktionen benutzen können. Es wäre jedoch kein Aufwand einige Funktionen in Cython zu benutzen.
 ===== Phase 2: Realismus =====
@@ Zeile 378: / Zeile 388: @@
 ==== Zeitabhängigkeit ====
-Der erste Schritt ist der, dass wir die Simulation nicht mehr abhängig von der Framerate machen. Bis jetzt lief die Simulation so ab, dass jedes Zeitintervall einen festen Zeitschritt bekommt. Und unabhängig von der eigentlichen Framerate simuliert wird. Also vergeht die Zeit in der Simulation schneller, wenn mehr Frames als erwartet simuliert werden, und vergeht in Zeitlupe, wenn die Framerate einbricht.
+Der erste Schritt ist die Simulation unabhängig von der Bildrate zu machen. Bis jetzt lief die Simulation so, dass jedes Zeitintervall einen festen Zeitschritt bekommt. Und unabhängig von der eigentlichen Framerate simuliert wird. Also vergeht die Zeit in der Simulation schneller, wenn mehr Frames als erwartet simuliert werden, und vergeht in Zeitlupe, wenn die Framerate einbricht.
-Ab dem jetzigen Zeitpunkt messen wir nach jeden Zeitschritt die vergangene Zeit und die Simulation läuft in Echtzeit. Es ist ebenfalls kein Problem, wenn man das ganze im Zeitraffer ablaufen lassen will.
+Ab dem jetzigen Zeitpunkt messen wir nach jeden Zeitschritt die vergangene Zeit und die Simulation läuft in Echtzeit. Es ist ebenfalls möglich das ganze im Zeitraffer ablaufen zu lassen.
 ==== Trennung von Auto und Fahrer ====
-Um die Fahreigenschaften zu optimieren trennen wir die Klassen Car und Driver. Der Fahrer bekommt bei der Initialisierung einige Variablen, wie Alter, Fähigkeit, Aggressivität und Geschlecht. In dieser Klasse wird nun alles berechnen, was von Fahrer zu Fahrer unterschiedlich ist, wie z.B. wie er auf eine Gelbe Ampel bei einer bestimmten Distanz und Geschwindigkeit reagiert.
+Um die Fahreigenschaften zu optimieren, trennen wir die Klassen Car und Driver. Der Fahrer bekommt bei der Initialisierung einige Variablen, wie Alter, Fähigkeit, Aggressivität und Geschlecht. In dieser Klasse wird nun alles berechnet, was von Fahrer zu Fahrer unterschiedlich ist, z.B. wie er auf eine Gelbe Ampel bei einer bestimmten Distanz und Geschwindigkeit reagiert.
 ==== Sichtweite ====
-Die Sichtweite ist bislang fest gesetzt. Diese sollte sowohl abhängig von der Fähigkeit und des Alters des Fahrers, als von Geschwindigkeit sein. Um diese zu bestimmen gibt die jeweilige Instanz der Autoklasse ihre Geschwindigkeit an ihren Fahrer weiter und dieser berechnet daraus die Sichtweite. Genau so läuft das mit der gesamten Sicht.
+Die Sichtweite ist bislang fest gesetzt. Diese sollte sowohl abhängig von der Fähigkeit und des Alters des Fahrers, wie von der Geschwindigkeit sein. Um diese zu bestimmen gibt die jeweilige Instanz der Autoklasse ihre Geschwindigkeit an ihren Fahrer weiter und dieser berechnet daraus die Sichtweite. Dies ist das gleiche Prinzip bei der Berechnung der gesamten Sicht.
 ==== Beschleunigung ====
-Eine Liste mit den gesehenen Objekten und den jeweiligen Distanzen wird an die Fahrerklasse weitergegeben. Anhand dieser Information und der statischen (Bremskraft, etc.) und dynamischen (aktuelle Geschwindigkeit, etc.) Daten des eigenen Fahrzeugs bestimmt der Fahrer die Geschwindigkeitsänderung in Prozent der maximalen Beschleunigung bzw. der maximalen Bremskraft. Dieses Modell ist sehr realitätsnah, da der Fahrer zunächst alle Informationen erhält - nicht relevante Hindernisse werden vorher entfernt (nicht in Sichtvektor) - und gibt zurück, was in der Realität ein „aufs Gaspedal bzw. Bremspedal Treten“ wäre.
+Eine Liste mit den gesehenen Objekten und den jeweiligen Distanzen wird an die Fahrerklasse weitergegeben. Anhand dieser Information und der statischen (Bremskraft, etc.) und dynamischen (aktuelle Geschwindigkeit, etc.) Daten des eigenen Fahrzeugs bestimmt der Fahrer die Geschwindigkeitsänderung in Prozent der maximalen Beschleunigung bzw. der maximalen Bremskraft. Dieses Modell ist sehr realitätsnah, da der Fahrer zunächst alle Informationen erhält - nicht relevante Hindernisse werden vorher entfernt (nicht in Sichtvektor) - und gibt zurück, was in der Realität ein „aufs Gaspedal bzw. Bremspedal treten“ wäre.
-In die Beschleunigungsberechnung fließen Autos, Ampeln, bedingte Ampeln und Änderungen des Tempolimits mit ein. Es ist noch nicht implementiert, dass die Fahrer vor dem Abbiegen auf eine Kurven- und Autoabhängige Geschwindigkeit abbremsen.
+In die Beschleunigungsberechnung fließen Autos, Ampeln, bedingte Ampeln und Änderungen des Tempolimits mit ein. Noch nicht implementiert ist das die Fahrer vor dem Abbiegen auf eine Kurven- und Autoabhängige Geschwindigkeit abbremsen.
 {{:ws1617:fahrerentscheidung.png|}}
 ==== Lenkung ====
-Gelenkt wird allerdings in der Autoklasse, da die Autos nach wie vor “auf Schienen“ fahren. Wir sind dabei geblieben, da wir sonst ein neues Spursystem einführen müssten und die Simulation wesentlich komplexer werden würde. Dieser Schritt ist auch nicht geplant.
+Gelenkt wird in der Autoklasse, da die Autos nach wie vor wie auf “Schienen“ fahren. Wir sind dabei geblieben, da wir sonst ein neues Spursystem einführen müssten und die Simulation wesentlich komplexer werden würde. Dieser Schritt ist auch nicht geplant.
 ==== Erweiterte Sicht ====
-Leider haben wir bis jetzt noch nicht implementiert, dass Fahrer mehr als nur geradeaus sehen können. Optimal wäre es, wenn die Fahrer an ihrer geplanten Fahrspur entlang „sehen“ und diese kontrollieren, als wäre es eine gerade. Um dies zu erreichen müsste das Auto seine Route und seine Position und Sichtweite an die Klasse “ObstacleGrid“ weitergeben und diese Klasse errechnet daraus die Hindernisse. An diesem Gedanken ist zu sehen, dass erweiterte Konzept einer Verkehrssimulation in der jetzigen Struktur sehr einfach zu implementieren wären. Mit dem Objekt-Orientierten Design Pattern wird alles an der Stelle berechnet, wo es hingehört und alles bleibt getrennt, erweiterbar und austauschbar.
+Leider haben wir bis jetzt noch nicht implementiert, dass Fahrer mehr als nur geradeaus sehen können. Optimal wäre es, wenn die Fahrer an ihrer geplanten Fahrspur entlang „sehen“ und diese kontrollieren, als wäre es eine gerade. Um dies zu erreichen müsste das Auto seine Route und seine Position und Sichtweite an die Klasse “ObstacleGrid“ weitergeben und diese Klasse errechnet daraus die Hindernisse. Daran ist zu sehen, dass erweiterte Konzepte einer Verkehrssimulation in der jetzigen Struktur sehr einfach zu implementieren wären. Mit dem Objekt-Orientierten Design wird alles an der Stelle berechnet, wo es hingehört und alles bleibt getrennt, erweiterbar und austauschbar.
 ===== Phase 3: Anwendung =====
-Mit der Struktur und der Realitätsnähe der Simulation haben wir nun die Möglichkeiten die Simulation für wirkliche Szenarien zu benutzen.
+Mit der Struktur und der Realitätsnähe der Simulation haben wir jetzt die Möglichkeiten die Simulation für wirkliche Szenarien zu benutzen.
 ==== Normales Straßennetz mit Ampelkreuzungen ====
-Die Initialisierung unseres herkömmlichen Straßennetzes mit Ampelkreuzungen haben wir so weit wie möglich abstrahiert. Nötig sind bloß:
+Die Initialisierung unseres herkömmlichen Straßennetzes mit Ampelkreuzungen haben wir so weit wie möglich abstrahiert. Dafür sind nur nötig:
 die Ampeltaktungen
@@ Zeile 457: / Zeile 467: @@
 Die Klasse Grid errechnet sich selbst, welche Kreuzungsseiten mit anderen verbunden werden und entfernt die übrigen offenen Seiten. Bei den Spawnkreuzungen werden von selbst Spawn- und Despawn-Punkte getrennt.
-Diese automatische Verbindung haben wir in diesem Stück Code, das in der Klasse Grid beinhaltet ist. Der Code funktioniert und wir haben noch nie eine falsche Verlinkung der Kreuzungen gesehen, jedoch ist der Code sehr schwer zu durchblicken und wir werden die Klasse Grid als einen der nächsten Schritte ordnen und besser organisieren.
+Diese automatische Verbindung haben wir in diesem Stück Code, das in der Klasse Grid beinhaltet ist eingefügt. Der Code funktioniert und wir haben noch nie eine falsche Verlinkung der Kreuzungen gesehen, jedoch ist der Code sehr schwer zu durchblicken und wir werden die Klasse Grid als einen der nächsten Schritte ordnen und besser organisieren.
 ==== Kreisverkehr ====
 An unserem Build eines Kreisverkehrs ist gut zu sehen, dass wir die einzelnen Bestandteile der Initialisierung schon sehr gut abstrahiert haben, wir sie jedoch für die spezielleren Anwendungsfälle noch nicht vereinfacht haben.
-Die Reaktionspunkte sehen wie folgt aus, bei großen Kreisverkehren sind die Einfahrten jedoch dementsprechend groß, sobald wir die Erstellung der Kreisverkehr vereinfahct haben, werden wir uns diesem Punkt widmen.
+Die Reaktionspunkte sehen wie folgt aus, bei großen Kreisverkehren sind die Einfahrten jedoch dementsprechend groß, sobald wir die Erstellung der Kreisverkehr vereinfacht haben, werden wir uns diesem Punkt widmen.
 {{:ws1617:reaktionspunkte_kreisverkehr.png|}}
-Bei diesem Kreisverkehr muss jeder Bestandteil, wie z.B. die Routen, die die einzelnen Reaktionspunkte verbinden oder die bedingten Ampeln manuell getippt werden. Jedoch muss in dieser Version nur die Variable "rad" verändert werden, dann baut alles daruaf auf. man könnte also diesen Code schon fast in eine Funktion von "Grid" packen und die Kreuzung in ein ganzes System integrieren.
+Bei diesem Kreisverkehr muss jeder Bestandteil, wie z.B. die Routen, die die einzelnen Reaktionspunkte verbinden oder die bedingten Ampeln manuell getippt werden. Jedoch muss in dieser Version nur die Variable "rad" verändert werden, dann baut alles daruaf auf. man könnte also diesen Code schon fast in eine Funktion von "Grid" implementieren und die Kreuzung in ein ganzes System integrieren.
 <code python>
@@ Zeile 570: / Zeile 580: @@
 </code>
-Unser Ziel ist es, für jeden Kreuzungstyp schon ein vorgefertigtes Geometrieschema zu haben, sodass diese reibungslos miteinander funktionieren. Es wäre auch ok, wenn wir die einzelnen Kreuzungen manuell miteinander verbinden müssten. Dann wäre das Chaos ist der Funktion Grid.adIntersectionLink(self, ...) beseitigt.
+Unser Ziel ist es, für jeden Kreuzungstyp schon ein vorgefertigtes Geometrieschema zu haben, sodass diese reibungslos miteinander funktionieren. Es wäre auch aktzeptabel, wenn wir die einzelnen Kreuzungen manuell miteinander verbinden müssten. Dann wäre die Unübersichtlichkeit ist der Funktion Grid.adIntersectionLink(self, ...) beseitigt.
 ==== Rechts vor Links Kreuzung ====
-Eine Rechts-Vor-Links-Kreuzung lässt sich mit den Bestandteilen ebenfalls sehr einfach erstellen. Die Rechts-Vor-Links-Regel lässt sich, wie beim Kreisverkehr mit bedingten Ampel implementieren. In dem Fall, dass von jeder Seite ein Auto kommt, könnte man bei einer der Seiten ein Ausnahmeregel einbetten.
+Eine Rechts-Vor-Links-Kreuzung lässt sich mit den gegebenen Bestandteilen ebenfalls sehr einfach erstellen. Die Rechts-Vor-Links-Regel lässt sich, wie beim Kreisverkehr mit bedingten Ampel realisieren. Für den Fall das von jeder Seite ein Auto kommt, könnte man bei einer der Seiten ein Ausnahmeregel einbetten.
 ==== Diverging Diamond Intersection ====

Mathesis Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge