RP6 und RP6 V2

[ex535]

Hi,

ich habe mir am Samstag den RP6 V2 gekauft.
Control M256 Wifi funktioniert auch.
Der Robby V2 macht weniger Lärm als der V1.

Leider hatte ich Probleme mit dem RP6 V1.
Drehgeber (Encoder) linke Motorseite war defekt.
Der neue Drehgebersatz (RP6v2) habe ich eingebaut.
Läuft einwandfrei. Kauf hat sich gelohnt.https://www.roboternetz.de/community/images/icons/icon14.png

Jetzt cruise ich mit zwei RP6 in der Wohnung.
RP6V2 mit WiFi und RP6V1 mit M32, Sharp Sensor am Heck.

Meine Frage.
Kann ich die alten Drehgeber noch für andere Anwendung verwenden.
Welches Signal liegt am Ausgang. (+ - Sig).
Handelt es sich um ein analoges Signal?

Naja, es macht wieder Spaß.
Muß mich wieder reindenken.

Schaun wir mal.

Gruß
Kurt
https://www.roboternetz.de/community/images/icons/icon7.png

[Dirk]

Hallo Kurt,

Kann ich die alten Drehgeber noch für andere Anwendung verwenden.
Wenn du Drehzahlen z.B. eines Motors messen willst, könntest du die noch nutzen (Codescheibe selbst basteln ...)

Welches Signal liegt am Ausgang. (+ - Sig). Handelt es sich um ein analoges Signal?
Nein, ein digitales. Sieh dir den Schaltplan an: RP6_ENCODERS.pdf.

[ex535]

Danke Dirk,

habe gefunden.

Reflexlichtschranke SFH9202 von Osram (1-5 mm Abstand).

Anwendungen
• Positionsmelder
• Endabschalter
• Drehzahlüberwachung
• Bewegungssensor

Gruß
Kurt

[Dirk]

Hallo Kurt,

kurze Frage:
Es gibt ja nicht sooo viele Leute, die 2 und mehr RP6(v2) haben.

Was wir noch nicht (?) hier angefangen haben, ist die IR-Kommunikation zwischen 2 RP6. Das wäre ja sehr toll, wenn sich 2 RP6 im Raum verständigen könnten. Die Hardware ist ja vorhanden.
Hättest du da Interesse (Software-Projekt)?

[RolfD]

https://www.roboternetz.de/community/threads/29313-gelöst-Einfache-IR-Kommunikation-für-den-RP6

Da gibts schon was, Dirk... sowohl als IR_COMM wie auch als Morsecode, steht alles in RN-Wissen.
Ich hab übrigends auch 2 und ein drittes RP6 Base Board wird demnächst auf nem anderen Kettenfahrgestell dazu kommen. Also ich hab in dem Bereich auch Interesse, allerdings noch diverse andere Baustellen.
LG Rolf

[Dirk]

Ja, ich weiss,- da steht schon einiges im RN-Wissen! (Den Morsecode über IRCOMM habe ich ja selbst verbockt...)
Der Thread von radbruch ist auch Klasse,- aber soweit ich mich erinnere, ging es um die IR-UART-Kommunikation zwischen RP6 und Asuro/PC?

Woran ich eher dachte ist die IR-Kommunikation im puren RC5-Code als Kommando-/Telemetrielösung ohne UART. Das gab es recht gut durchdacht mal beim CCRP5. Hier die "alte" Beschreibung:

'VEREINBARUNGEN ZUR NUTZUNG DES SUBSYSTEMS:
' IR-KOMMUNIKATION (IR-COMM, siehe "9_EINFÜHRUNG_IR_COMM.bas"):
' Der Prozessor übernimmt die Codierung der Daten in die gebräuchlichen
' Formate REC80 und RC5, sodass der C-Control Computer von dieser Aufgabe
' entlastet ist. Das Signal wird über zwei IR-LEDs abgestrahlt und ist
' in geschlossenen Raumen bis ca. 100qm überall zu empfangen (Reflektion an der Decke).
' Benutzen Sie diese Kommunikationseinrichtung zur Kommunikation von mehreren
' Robotern untereinander, zum Senden von Telemetriedaten, oder wenn Sie den Roboter
' fernsteuern wollen.
' Wie das ACS ist auch IR-COMM interruptfähig und kann einen Interrupt auslösen, wenn
' Daten empfangen wurden, siehe "9_EINFÜHRUNG_IR_COMM_INT.bas"!
'
' Beim Zugriff auf IR-COMM gelten folgende Vereinbarungen:
' 1) Der Zugriff wird bis zu 20ms verzögert ausgeführt, wenn IR-COMM gerade ein IR-Signal
' empfängt oder sendet.
' 2) Zu anderer Zeit wird der Zugriff sofort ausgeführt und ist nach 3ms beendet. In
' dieser Zeit kann kein IR-Signal empfangen werden und geht evtl. verloren.
' 3) Ein gültiger IR-Code kann mit gosub GET_IRDATA direkt abgefragt werden. Ist jedoch
' das ACS in Betrieb (und damit häufige Zugriffe mit sys COMNAV_STATUS auf das Subsystem
' notwendig), ist es besser, das Flag IR_F in SYSTEM_STATUS auszuwerten und den
' empfangenen Code nur im Bedarfsfall aufzurufen.
'
' FERNSTEUERUNG mit IR-COMM (siehe "9_EINFÜHRUNG_REMOTE_CONTROL2.bas"):
' Die Fernsteuerkommandos sind für die als Zubehör erhältliche IR-Fernbedienung CV100
' (Best.-Nr. 349127) oder CV150-2 (Best.-Nr. 350381, Geräte-Code: 169) zugeschnitten,
' können aber natürlich beliebig geändert werden.
' Folgende Kommandos sind vereinbart:
' 12 - LED ANZEIGEMODUS UMSCHALTEN (EIN/AUS)
' 13 - STOP (MUTE)
' 32 - VORWÄRTS (LED1) (P+)
' 33 - RÜCKWÄRTS (LED2) (P-)
' 17 - LINKS (LED3) (V-)
' 16 - RECHTS (LED4) (V+)
'
' Damit sich der Roboter schöner steuern lässt, wurden weitere Vereinbarungen getroffen:
' - Beim Druck auf die VORWÄRTS-Taste erhöht sich laufend die Geschwindigkeit, wenn
' der Roboter vorwärts fährt. Fährt er rückwärts, dann wird die Rückwärtsfahrt langsam
' gebremst.
' - Beim Druck auf die RÜCKWÄRTS-Taste erhöht sich laufend die Geschwindigkeit, wenn
' der Roboter rückwärts fährt. Fährt er vorwärts, dann wird die Vorwärtswärtsfahrt langsam
' gebremst.
'
' TELEMETRIE mit IR-COMM (siehe "9_EINFÜHRUNG TELEMETRIE1.bas"):
' Obwohl das verwendete RC5 Format von der Industrie zur Steuerung von Geräten der
' Unterhaltungselektronik entworfen wurde, lassen sich, wenn man sparsam damit umgeht
' (20ms für einen Datenrahmen!), durchaus auch Messwerte übertragen, entweder zu
' Informationszwecken für den Anwender oder für den Datenaustausch mehrerer
' Roboter untereinander.
' Formatierung der Daten:
' Wenn man sich die Datenformate ansieht, stellt man fest, dass weder in die ADRESSE,
' noch in das KOMMANDO ein ganzes Byte passt.
'
' 13-12-11-10-09-08-07-06-05-04-03-02-01-00 DATA BIT
' S S T a4 a3 a2 a1 a0 c5 c4 c3 c2 c1 c0 RC5
' S a5 a4 a3 a2 a1 a0 c6 c5 c4 c3 c2 c1 c0 REC 80
'
' In dieser Vereinbarung formatieren wir unsere Telemetriedaten so, dass das Datenbyte auf
' c0 bis a1 verteilt ist (RC5). In a2 bis a4 und T codieren wir den Messkanal, damit man
' mehrere Datenkanäle übertragen kann (bis zu 16 Kanäle).
'
' Das sieht dann so aus:
' S S T a4 a3 a2 a1 a0 c5 c4 c3 c2 c1 c0 RC5
' <-KANAL-> <------ DATEN -------->
' Telemetrie SENDEN:
' sys SEND_TLM erwartet den Messkanal in HBYTE (0-15), die Daten in LBYTE.
' Die Daten werden entsprechend dieser Vereinbarung formatiert und gesendet.
' Telemetrie EMPFANGEN:
' Wenn die Daten im Empfänger ausgewertet werden sollen, rufen Sie die empfangenen Daten
' mit gosub GET_TLM ab. Damit wird gleichzeitig die Umcodierung vorgenommen, damit der
' Messkanal wieder in HBYTE (0-15), die Daten in LBYTE stehen.
'
' TELEMETRIE-KANÄLE (siehe "9_EINFÜHRUNG TELEMETRIE2.bas"):
' Folgende Zuweisungen bezüglich der Kanäle und Sensoren sind zu empfehlen, die Sie
' natürlich beliebig ändern können:
' CHANNEL 0: SYSTEM (b0,b1=ACS b2=IR_DATA b3,b4=DIR b5,b6=ACS-PWR)
' CHANNEL 1: SYSTEM VOLTS
' CHANNEL 2: SYSTEM CURRENT
' CHANNEL 3: SYSTEM CHARGE CURRENT
' CHANNEL 4: LIGHT LEFT
' CHANNEL 5: LIGHT RIGHT
' CHANNEL 6: -MIC
' CHANNEL 7: PLM LEFT
' CHANNEL 8: PLM RIGHT
' CHANNEL 9: DISTANCE HI LEFT
' CHANNEL 10: DISTANCE LO RIGHT
' CHANNEL 11: SYS SECONDS
' CHANNEL 12: SYS MINUTES
' CHANNEL 13: LIGHT LEVEL
' CHANNEL 14: MAX DISTANCE
' CHANNEL 15: PGM ID
'
' NETWORKING mit IR-COMM (siehe "10_EINFÜHRUNG_NETWORKING.bas"):
' Mit dem Kommunikationssystem können Telemetrie-/Telekommando-Anwendungen realisiert
' werden (s.o.!). Das geht in dieser Form aber nur, wenn nur 1 Roboter in Betrieb
' ist, da sonst die Telemetriesendung des einen von einem anderen als Kommando
' interpretiert wird.
' Um mehrere Roboter miteinander kommunizieren zu lassen und auf Telemetrie nicht zu
' verzichten, treffen wir die Vereinbarungen:
'
' 1) Telemetrie ist immer RC5 Format S S T a4 a3 a2 a1 a0 c5 c4 c3 c2 c1 c0 RC5
' <-KANAL-> <------ DATEN -------->
'
' Telemetrie wird nur auf Anforderung von aussen verschickt, Kanal ist immer 0.
'
' 2) Telekommando ist immer RC5 Format S S T a4 a3 a2 a1 a0 c5 c4 c3 c2 c1 c0 RC5
' <-ADDR -> <------ DATEN -------->
' Die Adresse kann 1 bis 15 sein.
' Eine Telemetrieanforderung (hier CMD 0 bis 4) wird mit dem Senden des Telemetriekanals
' bestätigt.
' Alle anderen Telekommandos (hier CMD 5,6) werden mit einem einheitlichen Kommando (hier
' CMD 7) bestätigt.

Vielleicht können wir uns ja da mal dran machen ...?
Schwarmintelligenz

[RolfD]

Schwarmintelligenz

Ich träume mit... aber was genau ist das eigentlich? Schwarmintelligenz...?
Was eine CPU nicht berechnet (mangels Programm, Sensoren, Aktoren), berechnen bzw. machen auch viele CPUs bzw. Bots nicht besser.
Dem RP6 fehlt z.B. eine genügend genaue Sensorik, man müsste erst eine Menge Grundlagenarbeit z.B. in ein stabiles Ortungssystem ala Sonarbojen o.ö. investieren.
Schwarmintelligenz... da war mal was mit neuronalen Netzen.. die auf mehrere Bots verteilt .. ist das Schwarmintelligenz?
Oder eine zweidimensionale Karte in der die Bots agieren und diese gemeinsam verwalten...?
Ich bin da offen für Ideen aber habe dazu keine wirklich zündende Idee.
Selbst ein "Single-Intelligenz-System" in Form einer Ladestation die der Bot selbstständig anfährt ist zwar schon mal hier diskutiert aber nicht praktisch umgesetzt worden.

Ansich wird damit aber klar... Odometriedaten austauschen wäre mit RC5 wohl möglich - ähnlich wie es der I2C Master/Salve der Remotrol machen, möchte man jedoch kompexere Datenstrukturen verarbeiten kommt man um Protokolle wie IRDA oder diverse Funksysteme nicht rum. Diese wären wegen Speichermangel aber auch nur auf einer M128 oder mit viel fummelei und Einschränkungen auf der M256 zu verarbeiten. Ein noch wichtigerer Punkt ist aber die Fehlerprüfung und bei IRDA das vorhandene Stacks meist nur 1:1 Verbindungen zu lassen. 1:X.. also Broadcasts.. gibts da eben so wenig wie CSMA. (http://en.wikipedia.org/wiki/Carrier_sense_multiple_access)

Es bleibt also bei recht einfachem Befehls- und Datenaustausch vergleichbar mit I2C Master/Slave über RC5 im 1:1 Mod zwischen max. 2 Geräten, und der offenen Frage, wie man die dringend nötige Fehlerprüfung erledigt. Man darf auch nicht vergessen das RC5 nach dem Verfahren "Senden bis zum Erfolg" funktioniert.. sprich man drückt so lange auf der Fernbedienung rum bis das Ding macht was es soll... so... ist aber eine geregelte Datenübertragung, womöglich auch noch in 2 Richtungen nicht machbar. Ein Verbindungsabbruch wird auch nicht erkannt.... Als Minimalvoraussetzung braucht man daher zumindest IRDA, welches im ISO-OSI Model auf Schicht 3 und 4 liegen müsste.
vgl. http://en.wikipedia.org/wiki/OSI_model

Es gab mal einen Pico-IRda Stack für AVR aber dieser scheint nach löschen der Domain im jahr 2007 aus dem Netz verschwunden zu sein, ich hab zumindest einiges in der Richtung gefunden. Es verweist aber alles auf www.blaulogic.com (http://www.blaulogic.com) oder auf irgendwelche Seiten die eine email Registrierung wollen - was für Opensource IMHO nicht zulässig ist. allerdings kann man sich die Quellen auch zusammen kopieren... da z.B. http://www.pudn.com/downloads77/sourcecode/embed/detail295441.html

Es scheint aber ein besser geeignetes Projekt zu geben, welches sich dort befindet. http://www.mikrocontroller.net/articles/IRMP
Ich hab das mal quer gelesen und es klang doch recht interssant. Es scheint sich dabei um SIRC zu handeln.

Man müsste sich beides wohl noch mal genauer ansehen bevor man da entscheidet ob man selbst sowas entwickelt oder fertiges anpasst. Der IRDA Stack hätte jedenfalls den Vorteil, das es zu alten Handys, PDAs und IRDA-Sticks kompatibel ist. Die bessere Alternative zu IRDA dürfte aber SIRC sein... RC5 ist dagegen komplett veraltet und auch zu eingeschränkt.
http://avrprogrammers.com/proj_sirc_1.php
Allerdings können viele Endgeräte bzw. IRDA Sticks zwar IRDA aber eben kein SIRC.

So.. ich lass das erst mal so im Raum stehen. Es gibt da schon so einiges zu bedenken...
Ich denke, um so bissel zu spielen ist die Ir-Geschichte ganz nett... aber für anständige Anwendugen tuts dann doch besser eine RFM12 am I2C Bus für 5 Euronen das Stück bei 115,2 kBit/s.
Der Bot sollte sich doch mit Schwarmintelligenz beschäftigen können statt mühsam Ir-Lichtblitze aus der Luft angeln zu müssen....

Was mir so dabei durch den Kopf geht.. ich hab noch - wie andere vielleicht auch - ne 3.5 Kanal IR-Fernbedienung eines defekten Zimmer-Hubis hier rumliegen... dafür würde es sich vielleicht lohnen ein Empfangstreiber zu schreiben. Da die aber auch alle unterschiedlich arbeiten dürften.... Naja also das mit dem SIRC/IRMP bzw. IRDA fänd ich ganz interssant... als universeller Ersatz für den RC5 Treiber in der RP6Lib z.b. aber ich versprech mir keinen großen Nutzen davon.

LG Rolf

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

[ex535]

Hallo Kurt,

kurze Frage:
Es gibt ja nicht sooo viele Leute, die 2 und mehr RP6(v2) haben.

Was wir noch nicht (?) hier angefangen haben, ist die IR-Kommunikation zwischen 2 RP6. Das wäre ja sehr toll, wenn sich 2 RP6 im Raum verständigen könnten. Die Hardware ist ja vorhanden.
Hättest du da Interesse (Software-Projekt)?

Hallo Dirk,

ich konnte hier schon einige Möglichkeiten entnehmen.
RFM12 an I2C ist eine gute Lösung.

Nächste Woche werde ich mit meinem Pro-Bot 128 (ISP) und RP6V1 die ersten
Schritte über IR versuchen.

Gruß
Kurt
:)

[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 :D 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/ALOHAnet#The_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 :D
Ja das mit denm LEDs kenn ich... http://www.schockwellenreiter.de/blog/2011/08/17/schwarmroboter-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
:D

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.