Benutzer-Werkzeuge
ws1617:optimierung_des_verkehrs
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
|
ws1617:optimierung_des_verkehrs [2017/09/22 06:23] konstantingroll [Kreisverkehr] |
ws1617:optimierung_des_verkehrs [2017/09/27 13:25] (aktuell) dostuffthatmatters [Ein neues Sichtmodell] |
||
|---|---|---|---|
| Zeile 157: | Zeile 157: | ||
| ==== Darstellung ==== | ==== 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. | 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> | <code python> | ||
| Zeile 167: | Zeile 169: | ||
| self.cv.bind("<Button-1>", self.pause_) | self.cv.bind("<Button-1>", self.pause_) | ||
| </code> | </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 ==== | ==== 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. | 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|}} | {{: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|}} | {{: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. | 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: | der Distanz sein: Zunächst wird die Distanz bestimmt; die Spurbreite ist bekannt. Dann gilt: | ||
| <code python> | <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. | 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> | <code python> | ||
| self.freeIDs = range(255) | self.freeIDs = range(255) | ||
| Zeile 572: | Zeile 582: | ||
| 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. | 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 ==== | ==== 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 ==== | ==== Diverging Diamond Intersection ==== | ||
ws1617/optimierung_des_verkehrs.1506054192.txt.gz · Zuletzt geändert: 2017/09/22 06:23 von konstantingroll
Seiten-Werkzeuge
