RP6 und RP6 V2

[lasergehirn]

@Rolf:
Ich glaub Du denkst da zu komplex... man sollte da erstmal realistischere Ziele setzen.
Es reicht doch für den Anfang schon wenn Roboter in einem Schwarm z.B. gleichzeitig ein bestimmtes Verhalten aktivieren.
Beispielhaft:
- helle Lichtquellen suchen => Alle Roboter schwärmen wie die Motten um eine Lampe
- oder das gegenteil => alle Roboter verstecken sich im Dunkeln
- bestimmte bewegungsmuster ausführen also z.b. spiralförmig umher fahren oder einen Wandfolgealgorithmus ausführen, auf der Stelle drehen oder sowas...
- man kann auch gleichzeitig anhalten und nach einer weile weitermachen (Mittagspause )
- Wenn man weitere Sensoren hat, kann man damit natürlich auf weitere Dinge reagieren...

Die Verhalten dann zufällig durchschalten.

Das die Roboter jetzt nicht genau die Position des anderen kennen - na das Problem hat man immer bei so billigteilen ohne viel Sensorik. Kannste auch nicht lösen wenn Du nicht viel Geld da rein investierst (oder extern machen - s.u.).
Odometrie Daten alleine helfen dabei überhaupt nichts, die wären ja sowieso nur RELATIV zueinander die Roboter kennen dadurch ja noch nicht ihre absolute Position.

Irgendwelche komplexen Fehlerkorrekturen sind für die Anwendung oben gar nicht notwendig.
Einfach 3x senden, zufällige Zeit auf Bestätigung warten, nochmal senden usw..

Mit dem WLAN Modul wär das eh schon drin dann kannste auch einfach nen Host PC verwenden - das hat vor Jahren schonmal wer mit dem ASURO gemacht (glaube auch per IR): Webcam oben an die Decke schrauben (oder kleben/hängen ) und darüber die Position der Roboter ermitteln - sozusagen als indoor GPS
Das dann an die Roboter funken und die damit steuern.
Geht natürlich nur in einem eingeschränkten Bereich dann.

[RolfD]

Hallo Lasergehirn,

@Rolf:
Ich glaub Du denkst da zu komplex... man sollte da erstmal realistischere Ziele setzen.

hm... gehen wir erst mal deine "realistischen" Ziele mal durch:
1. Helle Lichtquelle suchen oder verstecken -> wäre möglich, benötigt aber keine Interaktion zwischen bots, es sei denn, die bots funken sich zu wer die dunkelste Stelle hat was dann für andere weitersuchen bedeutet. Ein "wir treffen uns am hellsten dunkelsten Ort" ist _vielleicht_ möglich wenn der dunkelste/hellste eine Art IR-Peilsignal schickt. Ok... Problem daran... kein Signal, keine Verständigung, Sichthindernisse unterbrechen den Kontakt. Man bräuchte bei 3 oder mehr einen Repeater? Fährt ein Bot z.B. unters Sofa, kann er ggf. andere nicht mehr benachrichtigen. Die Grundidee könnte aber klappen.
2. Bewegungsmuster -> dazu müssten die Bots ihre eigene Lage im Raum, und die der anderen Bots kennen. Dazu ist ein Ortungssystem nötig wie ich schon sagte. Per Sonar/Ultraschall, per Licht/Laser, per Bodenlinen oder sonst wie... so einfache Sachen wie "alle bots drehen sich auf Befehl um 360°" fällt unter Punkt 3.
3. Anhalten, Aktionen syncronisieren.. richtig aber dazu reicht auch schon ein einfaches Morseprogramm wie es bereits vorliegt, oder von mir aus auch RC5. Dies trifft auch so für Punkt 1 und 2 zu.

Du lieferst mir im Prinzip sogar das Argumet dazu:

Odometrie Daten alleine helfen dabei überhaupt nichts, die wären ja sowieso nur RELATIV zueinander die Roboter kennen dadurch ja noch nicht ihre absolute Position.

Dann bestätigst du meine Ansicht zu Try&Error bei RC5 .. bei dir ists dann eben 3 mal senden und warten...
Ich sage, das funktioniert eher schlecht für Datenübertragungen, du sagst es geht.. praktische Erfahrung gibts dazu hier nicht und es steht Aussage gegen Aussage. Was nu?

Das WLAN modul kostet mal eben das 25fache eines RFM12 Moduls... von dem man pro Bot eins bräuchte.... und nur dafür das die Dinger untereinander funken...?
Da geb ich bei 2 Bots die schlappen 240 euro doch lieber für ein odometrie System und ein paar RFM12 aus Aber um die gehts nicht, es geht hier um IR.

Du kannst mir glauben.. auch wenn es sich komplex anhört, das hat schon Hand und Fuß was ich da schreibe.
Die Idee mit der Cam an der Decke finde ich grundsätzlich aber mal gut. Nur müsste das Bild wohl von einem PC ausgewertet werden und das ist nicht Sinn des Schwarm-Ansatzes.
Mal davon ab, das die Übertragung eines Bildes oder eine 2D-Karte per IR Stunden dauert wenn man keine ordentlichen Stacks hat...und mit 3 mal senden und ähnlichen Konstruktionen arbeitet.. benutze ich aber Wlan/Funk, wozu dann IR?

IR ist für gegenseitige Ortung und Hindernisortung ok... wie man es z.B. von IR-Bällen im Bereich Roboterfußball kennt. Für Datenübertragungen als Pulspakete mit wenigen bits/byte sollte schon etwas mehr gehen als RC5 zulässt. Daher SIRC. Aber für eine Verbindung im Sinne von ISO-OSI eignet sich omnidirektionales IR wenig, und wenn doch sollte man sich zumindest auf ausgelatschten Pfaden bewegen - bevor IRDA/SIRC raus kam haben sich diverse Forscher und Wissenschaftler im Consumerbereich damit intensiv beschäftigt - das Fachwissen dazu muss hier nicht neu erfunden werden... und es steckt eben heute in Standarts wie IRDA und SIRC.

Das kann man akzeptieren oder nicht... aber es liegt sicher nicht daran, das ich zu komplex denke. Es sei aber jedem selbst überlassen das zu widerlegen.

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