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.
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.
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...