RP6 und RP6 V2

[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