RP6 und RP6 V2

[lasergehirn]

Ne Du hast mich da völlig falsch verstanden.
Ich meinte einfach nur das die Roboter DAS GLEICHE Verhalten ausführen. Dafür braucht es keine Positionsinfos oder sowas. Das ist wie gesagt erstmal das einfachste.

Kann aber dennoch interessante Effekte produzieren.
Viele Schwarm Robotik Projekte arbeiten übrigens mit ähnlich simpler oder auch GAR KEINER direkten Kommunikation
zwischen den einzelnen Robotern (farbige LEDs oder sowas hab ich schonmal gesehen).


> WLAN teuer

Ja das sagte ich auch nur weil Du die M256 erwähnt hattest und ex535 ja sowieso schon eine hat... und weil man das direkt vom PC ansprechen kann.
Man kann die per Webcam ermittelte Position aller Roboter ja auch nur an EINEN mit dem WLAN Modul schicken und der broadcastet das dann per IR an die anderen weiter.
(das natürlich mit geringerer Update rate, geht mit IR ja nicht so schnell)


> bei dir ists dann eben 3 mal senden und warten...

Das was ich beschrieb entspricht grob ALOHA und funktioniert durchaus.
http://en.wikipedia.org/wiki/ALOHAne...ALOHA_protocol
(jaja ein paar Unterschiede gibts aber egal)

Klar CSMA ist besser aber eben auch aufwändiger.




> Mal davon ab, das die Übertragung eines Bildes oder eine 2D-Karte per IR Stunden dauert

Wo hab ich bitte geschrieben das über IR auch nur irgendwas in der Größenordnung übertragen werden soll? Ist doch völliger Unfug, wie kommste denn da drauf?

> Nur müsste das Bild wohl von einem PC ausgewertet werden

Ja und? Ist halt ein simuliertes "GPS System".
Nein, natürlich soll der Rechner einfach nur die Koordinaten der Roboter übertragen. Das reicht doch schon als "GPS Signal". Die Verhalten kann man dann trotzdem auf den Robotern laufen lassen (oder auch ganz andere Sachen damit machen).

[RolfD]

@Lasergehirn
hm ok da haben wir wohl stellenweise aneinander vorbei gedacht
Ja das mit denm LEDs kenn ich... http://www.schockwellenreiter.de/blo...klauen-bucher/
Aber Du glaubst doch nicht ernsthaft, das so ein Ablauf ohne Kommunikation gehen würde? Und ohne Hostrechner? Oder wenn ohne Hostrechner... dann werkelt da sicher nicht nur ein AVR mit 2 K Ram in den Dingern. Ok Ok... sowas komplexes ist auch nicht die Aufgabenstellung... seh ich ja ein.

Aloha ist ein Multiband Protokol und schon daher nicht mit IR zu vergleichen oder darauf umzusetzen.

Two 100 kHz channels in the experimental UHF band were used in the implemented system, one for the user-to-computer random access channel and one for the computer-to-user broadcast channel.

Egal is nich....
Dann schon eher ATM http://en.wikipedia.org/wiki/Asynchronous_Transfer_Mode


Gruß Rolf

[lasergehirn]

Ja das mit denm LEDs kenn ich... http://www.schockwellenreiter.de/blo...klauen-bucher/
Aber Du glaubst doch nicht ernsthaft, das so ein Ablauf ohne Kommunikation gehen würde? Und ohne Hostrechner? Oder wenn ohne Hostrechner... dann werkelt da sicher nicht nur ein AVR mit 2 K Ram in den Dingern.

Ja sowas meinte ich - aber da gabs auch noch einfachere Konstruktionen.
http://www.youtube.com/watch?v=ISMwLCFwgK4
http://www.youtube.com/watch?v=Lx8rvBB_A7I
http://www.youtube.com/watch?v=GnyDAuqorGo

Das Teil verwendet übrigens auch nen ATMEGA und IR Kommunikation.
(allerdings mit eingeschränkter Reichweite - hierfür könnte man evtl. das ACS zweckentfremden als lokaler Kanal und das IRCOMM als globalen benutzen)

Die Dinger sind aber im Verkauf gar nicht mal soo billig, kosten so um die 100 Euro pro Stück hatte den Preis mal irgendwo gesehen als ich geschaut hab ob das Teil wirklich so billig ist wie in den diversen News Artikeln dazu behauptet wurde - isses aber nur wenn man die Komponenten einzeln kauft und selbst zusammenlötet


> Aloha ist ein Multiband Protokol und schon daher nicht mit IR zu vergleichen oder darauf umzusetzen.

Nö.Nur weil da ein BEISPIEL für eine Implementierung genannt ist, ist das nicht allgemein.
Hier eine andere Quelle wo es expliziter steht:
http://www.scholarpedia.org/article/Aloha_random_access

--> Aloha random access is a widely used technique for coordinating the access of large numbers of intermittent transmitters in a single shared communication channel.

Also selbstverständlich läuft das mit EINEM Kanal!

[RolfD]

Hi Lasergehirn,
Ok ALOHA wäre per IR wohl möglich, hab mich da eben mal eingelesen.
Im Prinzip ist das eine Art Zeitscheibenprotokoll mit ACK Antwort vom Empfänger. Pakete haben letztlich ein Timeout und erfolgt in dem Zeitraum kein ACK vom Empfänger, wird widerholt.
Baut man da noch ein CRC und eine Absender- und Emfpängeradresse ein, wärs sogar stabil weil der Empfänger fehlerhafte Daten durch nichtsenden des Ack verfallen lassen bzw. abweisen kann.
Das Ganze mit einem IR-freundlichem Modulationsverfahren ...

Ich sprach an anderer Stelle schon mal von MODBUS. http://freemodbus.berlios.de/

OK Fassen wir das mal im ISO-OSI Modell zusammen:
PysLinklayer Ebene 1: IR-Modulationsverfahren (noch ungeklärt, z.B. Pulslängen ähnlich SIRC/RC5 wegen der IR-LEDs am RP6)
Data Link Layer 2: ALOHA
Network Layer 3: Modbus (wobei man hier eine Art Repeater mit arp Table für Modbus schreiben könnte, sonst passiert hier erst mal nicht viel)
Transport Layer 4 : Modbus und API für Level 5, also Programme die den Stack nutzen.
Layer 5-7 sparen wir uns mal hier.. und die printf funktionen im Modbus (Layer 5 API) müsste mal wohl durch writestring ersetzen da diese sonst viel Platz brauchen.

Könnte klappen...

Hat man einmal das Modbus Protokol im System, könnte man es auch universell für I2C und Funk und andere Devices verwenden. Theoretisch kann dann jeder Bot jedes Gerät in einem anderen Bot ansprechen wobei ein Bot eben für nicht-Modbus Geräte eine art Emulation (Level 3) bieten müsste. Sprich.. schreibt Bot A mittels modbus in das EEPROM des Bot B, müsste Bot B dafür eine Emulation Modbus<->Eeprom anbieten und den String dort ablegen. Nicht byteorientiert wie beim aktuellen I2C-Slave sondern Paketorientiert fast wie bei TCP/IP ... damit wäre Zugriff auf Sensoren, Motoren, Daten, sowas ähnliches wie RPC (remote procedure call) und was weis ich noch alles möglich.

Mit den Kilobots hast du mich nu heiß gemacht... die kannte ich noch nicht.
http://ssr.wikidot.com/kilobot-documents
Zum schmökern...

Nachtrag: In Modbus müsste man dafür die Adressierung des Empfängers wohl erweitern... in der Art x.y wobei X dann für Bot Adresse und y für das Gerät bzw. Modbus-Emulationsteil auf Bot x steht, vergleichbar mit den Ports in TCP. Bot 1 (ohne Sonar) könnte aber dann z.b. auch auf das Sonarradar von Bot 2 zugreifen (mal vorausgesetzt sie stehen nebeneinander) und sich "umsehen". Also ich finde, das wäre schon sowas wie Schwarmintelligenz Problem daran... es wird immer mehr Software benötigt... denn Bot 1 ohne Sonar (und entsprechender Software) muss mit den Sonardaten von Bot 2 (der die Software ja schon hat aber nicht braucht) umgehen können. Klassische Betriebssysteme lösen sowas durch nachladen von Treibern z.B., was auf den Bots nicht gehen wird, führen echte RPCs aus... mit teils großem Aufwand an Verwaltung - scheidet daher auch aus... Da eine geschickte Lösung zu bauen dürfte das größte Hindernis in der Konstruktion sein, macht aber quasi das Hirn von Schwarmintelligenz aus. Zweites goßes Problem, das ganze muss Modular bleiben damit man leicht eigene Erweiterungen einpassen kann. Das System nutzt nix wenn es nur von 1 oder 2 Leuten bedient werden kann oder nur Standarthardware anspricht.

Gruß Rolf

[lasergehirn]

Hat man einmal das Modbus Protokol im System, könnte man es auch universell für I2C und Funk und andere Devices verwenden. Theoretisch kann dann jeder Bot jedes Gerät in einem anderen Bot ansprechen

Das wär ja mal was

> Modus

Irgendwie erinnert mich das ganze an
http://eagle.auc.ca/~dreid/
nur halt IR statt Bongos

Für I2C und Funk ist so ein high level protokoll aber sicher sinnvoll.
Nur, glaubste die IR Datenrate reicht um sinnvoll was machn zu können? Das sollte man erstmal testen.
Das IRCOMM ist ja für hohe Reichweite und nicht auf hohe Datenrate ausgelegt.
Mit RC5 geht des sowieso nicht sonderlich schnell, müsste man wohl was anderes machen.
Für kurze Kommandos und einzelne Sensordaten wirds aber reichen.