Hallo, in meinem Hobby-Hirn spukt der Gedanke herum den Bauteppich meiner Kinder, ca DIN A2 zu missbrauchen als "Wandteppich" um ein Verkehrsmodell zu erzeugen. Folgendes schwebt mir vor: Bestückung der Fahrbahnen beidseitig mit LEDs, die fahrende Autos simulieren, ich rechne mit ca 500-800 LEDs für eine entsprechende Dichte, so dass die Autos auch fahren und nicht springen. An allen Kreuzungen sollen LED "Ampeln" sein, ebenso werden ussgängerüberwege mit LED Männchen simuliert. Die Verkehrsdichte und Fahrziele soll zufallserzeugt werden, "Autos" werden erzeugt und verlassen das Spielfeld wieder, halten an Ampeln, fahren weiter. Sie fahren auf andere auf, halten vor Hindernissen usw. Die Ampelsteuerung soll intelligent sein, d.h. alles soll so funktionieren wie bei einer richtigen Verkehrsregelung. D.h. nur wenn Auto da wird geschaltet, Wartezeiten usw. Die grün haben fahren und biegen ab, andere warten oder fahren in die Kreuzungen. Die reine Hardware ist ein Gattergrab, vermutlich so 50 Stück Schieberegister und Nächte die LED zu verdrahten (schon mal einen Flipper von innen gesehen?). Das eigentliche "Modell" soll komplett in einem Rechner laufen, ich denke da an den Raspberry Pi, denn Arduino ist zu schwach, selbst der Mega. Ich brauche einiges an Speicher für die ganze Matrix der Strassen, die Ampelsteuerung, evtl dynamische Bäume usw. Was meint ihr? Wie gross ist der Softwareaufwand? Werden Programmiertechniken benötigt, die sehr komplex sind? Ich denke bisher an Zustandsautomaten. Wie erzeugt man das "Spielraster", also die Strassen? Das Ganze soll an die Wand kommen und "schön aussehen" aber eben auch einen Beobachter fesseln, da es immer neue Situationen gibt.
Angehängte Dateien:
-
Bauteppich.jpg
64 KB
verkehrspolizist schrieb: > Lass den Kindern doch ihren Teppich :( Mit 12 und 14? Rappel vielleicht auch noch
Das sollte nicht allzu schwierig sein. Objektorientierte Programmierung kann da definitiv ihr Vorteile ausspielen. Wenn du allerdings von Arduino schreibst, gehe ich erstmal davon aus, dass das für dich doch ein größeres Projekt ist. Machbar ist es von der Software auf jeden Fall.
Dussel schrieb: > Das sollte nicht allzu schwierig sein. Objektorientierte Programmierung > kann da definitiv ihr Vorteile ausspielen. > Wenn du allerdings von Arduino schreibst, gehe ich erstmal davon aus, > dass das für dich doch ein größeres Projekt ist. > Machbar ist es von der Software auf jeden Fall. Nein, evtl ein Arduino als Interface für die LEDs, da die einfacher darüber anzusteuern sind als von einem Raspeberry mit seinen spartanischen Schnittstellen. Der kriegt nur eine SPI, über den alle Datensätze übertragen werden, Treiber werden geschrieben, die Hardware abstrahiert. Dafür ist der Kleine Ardu gut, er muss ja nur die LEDs steuern. Ich denke an komfortable Linux Programmierung auf der Konsole, C++ kann ich leider nicht. Nur Grundmuster wie Klassen, Templates usw. Ich schreibe seit 20 Jahren Programme, bisher aber nur Ansi C und Pascal. Gerade Free Pascal halte ich für sehr gut geeignet, da es eine strenge Syntax hat und strukturierte Programmierung erzwingt. Probleme: - Zufallsgesteuerte Autos, die aber intelligent fahren - Wechselnde Verehrsdichte je nach Uhrzeit. - Ampelschaltungen realisieren - Multitasking für mindestens 3 Kreuzungen und wenigstens 20 Fahrzeuge. Bei rund 500-800 LED sind also einiges an Daten zu übertragen, die aber der Arduino entschlüsselt und überträgt. Der kriegt notfalls noch externen SRAM dran, falls die 8kb zu wenig sind.
Christian J. schrieb: > Die reine Hardware ist ein Gattergrab, vermutlich so 50 Stück > Schieberegister und Nächte die LED zu verdrahten Und warum nicht einfach eine Lichterkette mit WS2812. Dann wäre die Hauptverdrahtung schon mal fertig, falls du eine mit passendem LED-Abstand findest.
Arduinoprogrammierer sind anscheinend oftmals nicht die Besten im
Programmieren. Da ich dich nicht kenne und das Stichwort Arduino gelesen
habe, gehe ich bei dir auch erstmal davon aus. Das ist nicht böse
gemeint, aber um abschätzen zu können, wie aufwändig das Projekt wird,
muss ich deine Programmierkenntnisse einschätzen.
> Nur Grundmuster wie Klassen, Templates usw.
Das reicht. Ich denke, dass Templates hier nichtmal was bringen würden.
War das deine Frage?
Dussel schrieb: > Arduinoprogrammierer sind anscheinend oftmals nicht die Besten im > Programmieren. Da ich dich nicht kenne und das Stichwort Arduino gelesen > habe, gehe ich bei dir auch erstmal davon aus. Das ist nicht böse Arduino ist ein Werkzeug alles andere auch. "So einfach wie möglich, so komplex wie nötig!". Ich bin Dipl.-Ing., also sind schon "erweiterte Kenntnisse" vorhanden. Ich versuche nur den Aufwand abzuschätzen, etwas Brain Storming zu machen. Wenn LED Ketten das machen, dann nehme ich die! Nur müssen sie auch um Kurven klebbar sein, jede LED einzeln ansteuern können. Ich kenne nur die zum Aufkleben. Meterware bei ebay aber eben alle gleichzeitig. Di9e Frage: "Wie komplex wird eine Software, die ein solches Modell steuert?" Wie bildet man sowas ab in einem Computer?
Reden wir vom Arduinoboard, also einem AVR auf einer Platine oder von der Arduinobibliothek? Aber darum soll es ja auch nicht gehen. Ohne das genau überlegt zu haben, würde ich mir zutrauen, das in 40 Stunden hinzukriegen (120 Stunden, wenn der Projektleiter fragt ;-) Man müsste die Fahrzeuge programmieren, die Ampeln, die Straßen und die Kreuzungen. Jedes davon müsste dann das entsprechende Verhalten haben und kann unabhängig von den anderen arbeiten. Außerdem müssen die Daten richtig an den Teppich übergeben werden. (Ein computergesteuerter Teppich. Wo sind wir gelandet? :D)
Dussel schrieb: > Reden wir vom Arduinoboard, also einem AVR auf einer Platine oder von > der Arduinobibliothek? Wir reden von einem RASPBERRY PI! Einem vollwertigen Computer mit genügend RAM und einer vollständigen C Bibliothek. und NICHT von einem minimalistischen Jehova. Jehova steuert nur die LEDS als INterface, da der Raspi dafür zu blöde ist, es ist kein "physical computing" computer. Ich bin absolut in der Lage 500 LED anzusteuern und mit einem SPI Interface ein Protokoll zu schreiben :-) >>Man müsste die Fahrzeuge programmieren, die Ampeln, die Straßen und die >>Kreuzungen. Jedes davon müsste dann das entsprechende Verhalten haben >>und kann unabhängig von den anderen arbeiten. Genau das ist des Pudels Kern! Und hier fehlen mir etwas die Kenntnisse eines Profis, der im Kopf direkt die Struktur hat und wie er Intelligenz da rein bringt. Man kann es ein wenig mit einem "Mensch Ärgern dich nicht" vergleichen wo der Computer alle Parteien steuert und nach dem Würfeln "intelligent zieht". Oder meintwegen "Lemmings" wo viele Objekte ebenfalls nach Regeln gesteuert werden, die über eine Klippe rennen, in Metzel-maschinen laufen, wenn kein Stoppper da ist usw.
Ich zitiere mich:
> Aber darum soll es ja auch nicht gehen.
Also sollten wir die Diskussion besser lassen.
Wie ich schrieb, kompliziert sollte das nicht werden. Viel genauer kann
ich auf die Frage nicht antworten. Wie soll man Komplexität ausdrücken?
Die Laufzeitkomplexität sollte etwa bei O(n) liegen ;-)
Es wäre schön, wenn du nicht jeden Beitrag nochmal bearbeiten würdest. Ich antworte und sehe danach, dass noch einiges dazugekommen ist. Christian J. schrieb: > Man kann es ein wenig mit einem "Mensch > Ärgern dich nicht" vergleichen wo der Computer alle Parteien steuert und > nach dem Würfeln "intelligent zieht". Oder meintwegen "Lemmings" wo > viele Objekte ebenfalls nach Regeln gesteuert werden, die über eine > Klippe rennen, in Metzel-maschinen laufen, wenn kein Stoppper da ist > usw. Das ist schonmal die Grundidee. Du hast viele gleiche Objekte, zum Beispiel die Autos. Diese sind in einer Liste gespeichert, die regelmäßig abgearbeitet wird. Dabei wird von jedem Auto die 'Bewegen'-Funktion aufgerufen, in der das Fahrzeug den nächsten Schritt berechnet. Wenn es auf einer Straße ist, wird es nur um einen Schritt vorwärts gesetzt, wenn es an einer Kreuzung ist, entscheidet es in der Funktion nach irgendeinem Muster, wohin es fährt. Das macht jedes Auto für sich. Das gleiche gilt für die Ampeln. Die bekommen die Information, wo ein Auto steht und schalten entsprechend.
Ok, definieren wir also ein Autos als Objekt mit den Methoden stop/fahre, rechts, links, vorwärts, rückwärts. + "Hinderniserkennung". Jedes Auto wird von einer Basisklasse abgeleitet und hat die gleichen Eigenschaften. Jedes Auto muss in der Lage sein Hindernisse zu erkennen, Ampeln zu "sehen". Das wird ganz schön komplex, je länger man sich damit befasst.....
Christian J. schrieb: > Wenn LED Ketten das machen, dann nehme ich die! Nur müssen sie auch um > Kurven klebbar sein, jede LED einzeln ansteuern können. Gibts grad bei OPI als 5m-Strang in RGB, allerdings immer 3 LEDs an einem Chip. Der Typ ist nicht erkennbar, ich nehm an das wird wie ein Schieberegister gesteuert. Auf den Anschlüssen steht +,-,DI,DO. Btw: Falls Du zuviel Zeit hast, ich hätte noch ein paar Beete im Garten zum Umgraben...
Wir haben mal einen Discoboden gebastelt der mit kanpp 500 RGB LEDs Muster in verschiedenen Farben bilden konnte. Zur Ansteuerung haben wir 19 ATxmega64A1 verwendet, von denen Jeder 26 LEDs angesteuert hat. Die µC haben über I2C kommunizert. Alle hatten das gleiche Programm drauf. Lediglich die ID der Slaves war bei jedem anders. Der Master, ein ATxmega128A1 war dann mit dem Steuercode programmiert. Das Programm war natürlich in C. Hardware Aufwand waren rund 80 Mannstunden für das Platinen entwickeln und bestücken. Programmierung kann ich schwer abschätzen, wir haben rund 1 Jahr zu zweit etwa jedes 2 Wochenende daran gearbeitet. Also rund 200-300h
Der A*-Algorithmus ('A-Star') kann hier hilfreich sein. Seine Aufgabe
ist normalerweise das Suchen eines Weges von Punkt A nach B unter
Rücksichtnahme auf Hindernisse und den 'Kosten' eines Weges. Z.B. Ampeln
könnten durch den Zustand ihres Knotens signalisieren, das die Kosten
hoch sind und evtl. während einer Haltephase noch steigen. Autos werden
dann entweder stehenbleiben, oder nach einer Weile sogar umdrehen und
einen anderen Weg suchen - genauso wie ein Fussgänger, der bei ewig
roter Ampel dann doch irgendwann losläuft. Kollisionen werden z.B. durch
verschiedene Zustände eines Knotens vermieden.
Das ganze ist aufgebaut wie ein Baum (Quadtree) und je nach
Representation des navigierbaren Raumes in Abzweigungen (Äste)
aufgeteilt, die auch unterschiedliche Kosten haben und auch für
unterschiedliche Vehikel (Autos/Fussgänger) geperrt sind.
O.k., für einen Verkehrsteppich vllt. ein bisschen überkandidelt, A*
wird aber in vielen Simulationen gerne benutzt:
https://en.wikipedia.org/wiki/A*_search_algorithm
Ich glaube, du machst es zu kompliziert. Es geht wohl erstmal darum, dass überhaupt Autos fahren. Dass die realistisch oder ideal fahren, sollte (erstmal) kein Ziel sein.
Christian J. schrieb: > Das wird ganz schön komplex, je länger man sich damit befasst..... Warst du mal in Hamburg? Die haben sich auf ihrer Modellbahnanlage einiges einfallen lassen, um realistischen Straßenverkehr zu generieren http://www.miniatur-wunderland.de/anlage/technik/carsystem/modell-auto/
Also ein ATMega sollte für so was locker reichen, wenn Du Einstriche beim Komfort machst. Du kannst da dann halt dann nur die C++-Art von Objektorientierung machen. Auf einem Raspberry Pi könntest Du das sogar richtig objektorientiert lösen, sprich mit einem Prozess pro Objekt und mit einem Botschaftssystem dazwischen.
Wolfgang A. schrieb: > Christian J. schrieb: >> Das wird ganz schön komplex, je länger man sich damit befasst..... > > Warst du mal in Hamburg? Die haben sich auf ihrer Modellbahnanlage > einiges einfallen lassen, um realistischen Straßenverkehr zu generieren > http://www.miniatur-wunderland.de/anlage/technik/carsystem/modell-auto/ Hi, habe mir das mal durchgelesen. Das erfordert ein objektorientiertes komplexes Programm, was sicherlich für eine Person zuviel ist, bzw den Rahmen von "LEDs" sprengt. Da fahrern ja naturgetreue Fahrzeuge umher. Der A* Alogorithums wird auch beim Autorouten von Platinen benutzt, bzw in Navi Systemen. Allein die Anzahl Einflussgrößen ist enorm, die jedes Objekt bei jedem Bewegungsschritt beachten muss. Ich stelle mir das so vor, dass der Rechner andauernd eine Schleife durchläuft, bei der der Zustand jedes Objektes neu bewertet wird und bei einer Bewegung diese Einfluss auf andere Objekte hat, deren Verhalten sich dann ebenfalls ändert. Das wäre für LEDs sogar zu machen, 20 Autos maximal, jedes bekommt eine Struktur mit den Daten seines Zustandes. Da würde ich sogar ohne OOP auskommen. Das Modellbahn Modell schiesst deutlich über alles hinaus was auf einem Demo Board überhaupt sichtbar wäre. Ich habe bisher nur - anderes Fahrzeug vor mir / hinter mir - Ampeln - evtl Gegenverkehr Die Autos werden an einem Rand "erzeugt", erhalten in dem Moment einen Zielort zugeteilt und diesen legen sie dann auf einem Weg zurück, der sagen wir maximal 3 Routen sein kann. Ein "Stau" wäre schon schwierig, denn den muss man erstmal definieren. Vielleicht: Wennb mehr als 3 Autos vor Ampel, dann wähle Umgehung. Probleme dieser Art sind in hunderten Videospielen schon gelöst worden, im Program "Live" auch, usw. Ohne fundierte Kenntnisse auf dem Gebiet der Simulation (Informatikstudium?) sind die nicht zu lösen. Das System ändert sich ja bei jedem Zustandswechsel eines seiner Objekte. Ich lasse mir das Ganz nochmal durch den Kopf gehen, denn ich werde dafür ja nicht bezahlt. Der Raspi scheint mir aber ideal dafür zu ein als vollwertiger Computer mit OS dahinter.
Christian J. schrieb: > Ich lasse mir das Ganz nochmal durch den Kopf gehen, denn ich werde > dafür ja nicht bezahlt. So kompliziert ist das wirklich nicht. Wenn du es einfach haben willst, begrenzt du halt die Gesamtanzahl der Autos so, dass sie sich an einer Ampel nicht bis zur nächsten Kreuzung zurückstauen können. Der Stau löst sich dann irgendwann wieder auf, wenn die Autos in einer Grünphase zufällig in irgendwelche Richtungen abbiegen. Wenn es dir Spaß macht, solltest du es anfangen und dich nicht von Problemen abhalten lassen, die erst auftreten, wenn man das System komplexer macht.
Christian J. schrieb: > Das eigentliche "Modell" soll komplett in > einem Rechner laufen Das ist eigentlich der einzige Spaßmacher an dem Projekt. Ein efizient berechenbares, aber gleichzeitig realistisch wirkendes Modell des Verkehrs zu schaffen. > ich denke da an den Raspberry Pi, denn Arduino ist > zu schwach, selbst der Mega. Unsinn, man kann das natürlich locker in einen Mega packen. Du hast nach deinen eigenen Angaben maximal ca. 800 diskrete LEDs zur Darstellung der Objekte zur Verfügung. Damit noch irgendwas erkennbar ist, dürfen sich grob über den Daumen gepeilt maximal 400 Objekte gleichzeitig auf dem Spielfeld tummeln, eher deutlich weniger. Ansonsten tritt nämlich leicht der Effekt auf, daß nicht die leuchtenden LEDs als Objekte wahrgenommen werden, sondern die "Lücken". Probier das einfach mal mit einem primitiven Lauflicht aus, dann siehst du, was ich meine. Und wenn dieser Effekt eintritt, wirkt selbst eine sonst durchaus stimmige Verkehrssimulation plötzlich garnicht mehr so stimmig... Bleiben wir also mal bei 400 Objekten als sinnvolle Obergrenze. Dann hast du schon bei einem Mega 644 ca. 10 Bytes pro Objekt zur Verfügung, um Statusinformationen dazu abzulegen. Die wirst du niemals brauchen, tatsächlich werden deutlich weniger genügen. Und wenn bei schlechter Programmierung der Speicher doch knapp werden sollte: Einem Upgrade auf einen 1284P steht nichts im Wege und schon hast du 40 Byte pro Objekt. Das reicht dann aber endgültig. Was die Rechenzeit betrifft: 20MHz und 400 Objekte bedeuten 50.000 Takte pro Objekt und Sekunde. Selbst wenn das gesamte Modell 50 mal pro Sekunde durchgerechnet werden soll (mehr hat ganz sicher keinen Sinn), bleiben also 1.000 Takte pro Objekt und Durchlauf. In 1.000 Takten kann man eine ganze Menge Scheiß rechnen... > Ich brauche einiges an Speicher für die > ganze Matrix der Strassen Dieser Ansatz ist grundfalsch und würde zu einer sehr ineffizienten Implementierung führen. Den potentiell hohen Speicherverbrauch hast du ja bereits selbst erkannt. Nein, die Straßen stellen natürlich keine Matrix dar, sondern ein Netz, bestehend aus Knoten (Kreuzungen, Einmündungen, Übergänge, Mapgrenzen) und Kanten (Straßen). Im sehr viel größeren Bereich der Kanten gelten ganz einfache Gesetze und ganz einfache Regeln zur Ermittlung der jeweils relevanten Objektumgebung. An den Knoten sind die Regeln deutlich komplexer, dafür ist aber die zu berücksichtigende Umgebung auch deutlich kleiner und sie muß nicht erst gesucht werden, sie besteht nämlich nur aus den jeweils letzten Positionen der vom Knoten ausgehenden Kanten und dem eigentlichen Knotenbereich selber. Zur Modellierung von Netzen sind Listen sehr gut geeignet. Das einzige, wofür du wirklich irgendwie eine Matrix benötigst, ist das Mapping vom Netz des Verkehrsmodells auf die physischen LEDs. Das Schöne daran ist aber: hier ist die ideale Schnittstelle, um die Software mittels einer Simulation der realen Hardware (in Form eines primitiven Bitmap-Bilds) testen zu können, einschließlich der Wirkung auf den Betrachter. So könnte man schon vorher entscheiden, ob es überhaupt sinnvoll ist, die Hardware wie geplant zu realisieren... > Was meint ihr? Wie gross ist der Softwareaufwand? Naja, an einem Nachmittag runterprogrammiert ist das sicher nicht. Aber es wird in den Grundzügen einen halbwegs fähigen Programmierer auch nicht wesentlich länger beschäftigen als Beschaffung, Bau und Inbetriebnahme der Hardware. Natürlich kann man dann noch die Modelle mit mehr Feinheiten (z.B. Beschleunigungs- und Bremsverhalten) ausstatten oder neue spezielle Modelle schaffen (Raser, Feuerwehr, Geisterfahrer usw.) > Werden > Programmiertechniken benötigt, die sehr komplex sind? Definitiv nein. Das einzige, was eventuell komplexer wäre, ist die Routenwahl durch das Netz. Aber da das vorliegende Netz doch noch ziemlich einfach strukturiert ist, ist es hier noch möglich, alle denkbaren Routen vollständig vorherzu"berechnen" und als fertiges Wissen für das Modell bereitstellen. Bei der Objektgenerierung wird dann einfach nur noch aus den verfügbaren Routen gewählt. > Ich denke bisher > an Zustandsautomaten. Einen? Hunderte!
Sicher geht das mit einem Atmega. Du kannst es auch mittels Bipolar Transistoren aufbauen. Spaß würde mir beides nicht sonderlich machen, da man viel zu viel Zeit damit verbringen muss, mit den begrenzten Ressourcen klar zu kommen. Bei so vielen gleichartigen Objekten kommst du mit einer objektorientierten Sprache wie C++ sicher mit dem geringsten Aufwand klar. Und es ist nachher einfach wartbar (was spätestens bei den Bipolartransistoren schwierig wird). Ob du jetzt einen Raspberry dafür nutzt oder einen anderen Controller deiner Wahl ist ja wurscht. Du könntest z.B. das STM32F4 Nucleo Board einsetzen, mit gratis online Compiler. Raten würde ich dir auf jeden Fall zu den WS2811/WS2812er LEDs. Die gibt es nicht nur als Streifen, sondern als LEDs mit IC dran, so dass du die beliebig positionieren kannst. Sind nicht zu teuer und machen die Verdrahtung einfach :) Code für die LEDs gibts zu Hauf schon.
c-hater schrieb: > Definitiv nein. Das einzige, was eventuell komplexer wäre, ist die > Routenwahl durch das Netz. Aber da das vorliegende Netz doch noch > ziemlich einfach strukturiert ist, ist es hier noch möglich, alle > denkbaren Routen vollständig vorherzu"berechnen" und als fertiges Wissen > für das Modell bereitstellen. Bei der Objektgenerierung wird dann > einfach nur noch aus den verfügbaren Routen gewählt. Super! Danke dir erstmal, werde das mal bei einem Wein durch den Kopf gehen lassen undn einiges skizzieren...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.